Kubernetes-resursplacering från hubbkluster till medlemskluster
I den här artikeln beskrivs begreppet Kubernetes-resursplacering från hubbkluster till medlemskluster med Azure Kubernetes Fleet Manager (Kubernetes Fleet).
Plattformsadministratörer behöver ofta distribuera Kubernetes-resurser till flera kluster av olika skäl, till exempel:
- Hantera åtkomstkontroll med hjälp av roller och rollbindningar i flera kluster.
- Köra infrastrukturprogram, till exempel Prometheus eller Flux, som måste finnas i alla kluster.
Programutvecklare behöver ofta distribuera Kubernetes-resurser till flera kluster av olika skäl, till exempel:
- Distribuera ett videotjänstprogram till flera kluster i olika regioner för en låg svarstidsvisning.
- Distribuera ett kundvagnsprogram till två parkopplade regioner så att kunderna kan fortsätta att handla under ett avbrott i en enda region.
- Distribuera ett batchberäkningsprogram till kluster med billiga skalningsuppsättningsnodpooler tillgängliga.
Det är tråkigt att skapa, uppdatera och spåra dessa Kubernetes-resurser i flera kluster manuellt. Fleet tillhandahåller Kubernetes-resursspridning för att möjliggöra skalningsbaserad hantering av Kubernetes-resurser. Med Kubernetes Fleet kan du skapa Kubernetes-resurser i hubbklustret och sprida dem till valda medlemskluster via Kubernetes Anpassade resurser: MemberCluster och ClusterResourcePlacement.
Kubernetes Fleet stöder dessa anpassade resurser baserat på en molnbaserad lösning med öppen källkod som du kan läsa mer om i dokumentationen om öppen källkod Fleet.
Introduktion till ClusterResourcePlacement
Ett ClusterResourcePlacement objekt används för att berätta för schemaläggaren för flottan hur en viss uppsättning klusteromfattningsobjekt ska placeras från fleet hub-klustret på medlemskluster. Namnområdesomfångsobjekt som Distributioner, StatefulSets, DaemonSets, ConfigMaps, Secrets och PersistentVolumeClaims inkluderas när deras innehållande namnområde väljs.
Med ClusterResourcePlacementkan du:
- Välj vilka Kubernetes-resurser med klusteromfattning som ska spridas till medlemskluster.
- Ange placeringsprinciper för att manuellt eller automatiskt välja medlemskluster som målkluster.
- Ange distributionsstrategier för att på ett säkert sätt distribuera alla uppdateringar av de valda Kubernetes-resurserna till flera målkluster.
- Visa spridningsförloppet mot varje målkluster.
Ett exempel visas i följande diagram.
Kapsla in resurser
ClusterResourcePlacement stöder användning av ConfigMap för att omsluta vissa Kubernetes-resurstyper så att de kan mellanlagras på hubbklustret utan oavsiktliga biverkningar på hubbklustret. En lista över resurstyper och för att förstå hur den här funktionen fungerar finns i vår dokumentation om kuvertobjekt
Placeringstyper
Följande placeringstyper är tillgängliga för att styra antalet kluster som en angiven Kubernetes-resurs måste spridas till:
- PickFixed placerar resursen på en specifik lista över medlemskluster efter namn.
- PickAll placerar resursen på alla medlemskluster eller alla medlemskluster som uppfyller ett villkor. Den här principen är användbar för att placera infrastrukturarbetsbelastningar, till exempel klusterövervakning eller rapporteringsprogram.
- PickN är det mest flexibla placeringsalternativet och möjliggör val av kluster baserat på tillhörighets- eller topologispridningsbegränsningar och är användbart när du sprider arbetsbelastningar över flera lämpliga kluster för att säkerställa att tillgänglighet önskas.
PickFixed-placeringstyp
Om du vill distribuera en arbetsbelastning till en känd uppsättning medlemskluster kan du använda en PickFixed placeringsprincip för att välja klustren efter namn.
clusterNames är det enda giltiga principalternativet för den här placeringstypen.
I följande exempel visas hur du distribuerar test-deployment namnområdet till medlemskluster cluster1 och cluster2.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-fixed
spec:
policy:
placementType: PickFixed
clusterNames:
- cluster1
- cluster2
resourceSelectors:
- group: ""
kind: Namespace
name: test-deployment
version: v1
PickAll placeringstyp
Du kan använda en PickAll placeringstyp för att distribuera en arbetsbelastning i alla medlemskluster i flottan eller till en delmängd av kluster som matchar de kriterier som du anger.
När du skapar den här typen av placering kan du ange följande klustertillhörighetstyper:
- requiredDuringSchedulingIgnoredDuringExecution: eftersom den här principen krävs under schemaläggningen filtreras klustren baserat på de angivna kriterierna.
I följande exempel visas hur du distribuerar ett prod-deployment namnområde och alla dess objekt i alla kluster som är märkta med environment: production:
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickall
spec:
policy:
placementType: PickAll
affinity:
clusterAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- labelSelector:
matchLabels:
environment: production
resourceSelectors:
- group: ""
kind: Namespace
name: prod-deployment
version: v1
PickN-placeringstyp
Placeringstypen PickN är det mest flexibla alternativet och möjliggör placering av resurser i ett konfigurerbart antal kluster baserat på både tillhörighet och begränsningar för topologispridning.
När du skapar den här typen av placering kan du ange följande klustertillhörighetstyper:
- requiredDuringSchedulingIgnoredDuringExecution: eftersom den här principen krävs under schemaläggningen filtreras klustren baserat på de angivna kriterierna.
- preferredDuringSchedulingIgnoredDuringExecution: eftersom den här principen föredras, men inte krävs under schemaläggningen, rangordnas kluster baserat på angivna kriterier.
Du kan ange både obligatoriska och önskade tillhörigheter. Obligatoriska tillhörigheter förhindrar placering till kluster som inte matchar, och önskade tillhörigheter ger ordning på giltiga kluster.
PickN med tillhörighet
Att använda tillhörighet med en PickN placeringsprincip fungerar på samma sätt som att använda tillhörighet med poddschemaläggning.
I följande exempel visas hur du distribuerar en arbetsbelastning till tre kluster. Endast kluster med critical-allowed: "true" etiketten är giltiga placeringsmål och inställningar ges till kluster med etiketten critical-level: 1:
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickn-01
spec:
resourceSelectors:
- ...
policy:
placementType: PickN
numberOfClusters: 3
affinity:
clusterAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
weight: 20
preference:
- labelSelector:
matchLabels:
critical-level: 1
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- labelSelector:
matchLabels:
critical-allowed: "true"
PickN med begränsningar för topologispridning
Du kan använda begränsningar för topologispridning för att tvinga divisionen av klusterplaceringarna över topologigränserna att uppfylla tillgänglighetskraven. Använd till exempel dessa begränsningar för att dela upp placeringar mellan regioner eller uppdateringsringar. Du kan också konfigurera begränsningar för topologispridning för att förhindra schemaläggning om villkoret inte kan uppfyllas (whenUnsatisfiable: DoNotSchedule) eller schemaläggas så bra som möjligt (whenUnsatisfiable: ScheduleAnyway).
I följande exempel visas hur du sprider ut en viss uppsättning resurser över flera regioner och försöker schemalägga mellan medlemskluster med olika uppdateringsdagar.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickn-02
spec:
resourceSelectors:
- ...
policy:
placementType: PickN
topologySpreadConstraints:
- maxSkew: 2
topologyKey: region
whenUnsatisfiable: DoNotSchedule
- maxSkew: 2
topologyKey: updateDay
whenUnsatisfiable: ScheduleAnyway
Mer information finns i begränsningarna för spridning av topologispridning för fleetdokumentation med öppen källkod.
Alternativ för placeringsprincip
Tabellen sammanfattar de tillgängliga schemaläggningsprincipfälten för varje placeringstyp.
| Principfält | PickFixed | PickAll | PickN |
|---|---|---|---|
placementType |
✅ | ✅ | ✅ |
affinity |
❌ | ✅ | ✅ |
clusterNames |
✅ | ❌ | ❌ |
numberOfClusters |
❌ | ❌ | ✅ |
topologySpreadConstraints |
❌ | ❌ | ✅ |
Välja kluster baserat på etiketter och egenskaper
Tillgängliga etiketter och egenskaper för att välja kluster
När du använder placeringstyperna PickN och PickAll kan du använda följande etiketter och egenskaper som en del av dina principer.
Etiketter
Följande etiketter läggs automatiskt till i alla medlemskluster och kan användas för val av målkluster i resursplaceringsprinciper.
| Etikett | Description |
|---|---|
| fleet.azure.com/location | Azure-regionen för klustret (westus) |
| fleet.azure.com/resource-group | Azure-resursgruppen för klustret (rg_prodapps_01) |
| fleet.azure.com/subscription-id | Azure Subscription Identifier som klustret finns i. Formaterad som UUID/GUID. |
Du kan också använda alla anpassade etiketter som du tillämpar på dina kluster.
Egenskaper
Följande egenskaper är tillgängliga för användning som en del av placeringsprinciper.
Cpu- och minnesegenskaper representeras som Kubernetes-resursenheter.
Kostnadsegenskaper är decimaler som representerar en kostnad per timme i US-dollar för Den Azure-beräkning som används för noder i klustret. Kostnaden baseras på offentliga Priser i Azure.
| Egenskapsnamn | beskrivning |
|---|---|
| kubernetes-fleet.io/node-count | Tillgängliga noder i medlemsklustret. |
| resources.kubernetes-fleet.io/total-cpu | Totalt antal cpu-resursenheter i klustret. |
| resources.kubernetes-fleet.io/allocatable-cpu | Allokerbara CPU-resursenheter i klustret. |
| resources.kubernetes-fleet.io/available-cpu | Tillgängliga CPU-resursenheter i klustret. |
| resources.kubernetes-fleet.io/total-memory | Total minnesresursenhet i klustret. |
| resources.kubernetes-fleet.io/allocatable-memory | Allokerbara minnesresursenheter i klustret. |
| resources.kubernetes-fleet.io/available-memory | Tillgängliga minnesresursenheter i klustret. |
| kubernetes.azure.com/per-cpu-core-cost | Kostnaden per cpu-kärna för klustret. |
| kubernetes.azure.com/per-gb-memory-cost | Kostnaden per GiB-minne för klustret. |
Ange urvalsmatchningsvillkor
När du använder klusteregenskaper i ett principvillkor anger du:
Namn: Namnet på egenskapen, som är en av egenskaperna som anges i egenskaperna i den här artikeln.
Operator: En operator som används för att uttrycka villkoret mellan villkoret/önskat värde och det observerade värdet i klustret. Följande operatorer stöds för närvarande:
Gt(Större än): ett klusters observerade värde för den angivna egenskapen måste vara större än värdet i villkoret innan det kan väljas för resursplacering.Ge(Större än eller lika med): ett klusters observerade värde för den angivna egenskapen måste vara större än eller lika med värdet i villkoret innan det kan väljas för resursplacering.Lt(Mindre än): ett klusters observerade värde för den angivna egenskapen måste vara mindre än värdet i villkoret innan det kan väljas för resursplacering.Le(Mindre än eller lika med): ett klusters observerade värde för den angivna egenskapen måste vara mindre än eller lika med värdet i villkoret innan det kan plockas för resursplacering.Eq(Lika med): ett klusters observerade värde för den angivna egenskapen måste vara lika med värdet i villkoret innan det kan väljas för resursplacering.Ne(Inte lika med): ett klusters observerade värde för den angivna egenskapen får inte vara lika med värdet i villkoret innan det kan väljas för resursplacering.
Om du använder operatorn
Gt,Ge,Lt,Le,EqellerNe, bör listan med värden i villkoret ha exakt ett värde.Värden: En lista med värden, som är möjliga värden för egenskapen.
Flottan utvärderar varje kluster baserat på de egenskaper som anges i villkoret. Om det inte går att uppfylla de villkor som anges under requiredDuringSchedulingIgnoredDuringExecution undantas det här medlemsklustret från resursplacering.
Kommentar
Om ett medlemskluster inte har den egenskap som uttrycks i villkoret misslyckas villkoret automatiskt.
Här är ett exempel på en placeringsprincip för att endast välja kluster med fem eller fler noder.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
placementType: PickAll
affinity:
clusterAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- propertySelector:
matchExpressions:
- name: "kubernetes-fleet.io/node-count"
operator: Ge
values:
- "5"
Så här fungerar egenskapsrankning
När preferredDuringSchedulingIgnoredDuringExecution används rangordnar en egenskapssorterare alla kluster i flottan baserat på deras värden i en stigande eller fallande ordning. De vikter som används för beställning beräknas baserat på det angivna värdet.
En egenskapssorterare består av:
- Namn: Namnet på klusteregenskapen.
- Sorteringsordning: Sorteringsordning kan vara antingen
AscendingellerDescending. NärAscendingordningen används föredras medlemskluster med lägre observerade värden. NärDescendingordningen används föredras medlemskluster med högre observerat värde.
Fallande ordning
För fallande sorteringsordning beräknas den proportionella vikten med hjälp av formeln:
((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight
Anta till exempel att du vill rangordna kluster baserat på egenskapen för tillgänglig CPU-kapacitet i fallande ordning och att du har en flotta på tre kluster med följande tillgängliga CPU:
| Kluster | Tillgänglig processorkapacitet |
|---|---|
cluster-a |
100 |
cluster-b |
20 |
cluster-c |
10 |
I det här fallet beräknar sorteraren följande vikter:
| Kluster | Tillgänglig processorkapacitet | Beräkning | Grovlek |
|---|---|---|---|
cluster-a |
100 | (100 - 10) / (100 - 10) | 100 % |
cluster-b |
20 | (20 - 10) / (100 - 10) | 11.11% |
cluster-c |
10 | (10 - 10) / (100 - 10) | 0 % |
Stigande ordning
För sorteringsordningen Stigande beräknas den proportionella vikten med hjälp av formeln:
(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight
Anta till exempel att du vill rangordna kluster baserat på kostnaden per CPU-kärna i stigande ordning och att du har en flotta på tre kluster med följande processorkärnor:
| Kluster | Kostnad per cpu-kärna |
|---|---|
cluster-a |
1 |
cluster-b |
0.2 |
cluster-c |
0,1 |
I det här fallet beräknar sorteraren följande vikter:
| Kluster | Kostnad per cpu-kärna | Beräkning | Grovlek |
|---|---|---|---|
cluster-a |
1 | 1 - ((1 - 0.1) / (1 - 0.1)) | 0 % |
cluster-b |
0.2 | 1 - ((0.2 - 0.1) / (1 - 0.1)) | 88.89% |
cluster-c |
0,1 | 1 - (0.1 - 0.1) / (1 - 0.1) | 100 % |
Använda toleranser
ClusterResourcePlacement objekt stöder specifikationen av toleranser, som gäller för ClusterResourcePlacement objektet. Varje toleransobjekt består av följande fält:
key: Tolerationens nyckel.value: Värdet för toleransen.effect: Effekten av toleransen, till exempelNoSchedule.operator: Operatorn för toleransen, till exempelExistsellerEqual.
Varje tolerans används för att tolerera en eller flera specifika taint som tillämpas på ClusterResourcePlacement. När alla taints i en MemberCluster tolereras kan schemaläggaren sedan sprida resurser till klustret. Du kan inte uppdatera eller ta bort toleranser från ett ClusterResourcePlacement objekt när det har skapats.
Mer information finns i dokumentationen för fleet med öppen källkod om toleranser.
Konfigurera distributionsstrategi
Fleet använder en löpande uppdateringsstrategi för att styra hur uppdateringar distribueras mellan kluster.
I följande exempel distribuerar schemaläggaren för flottan uppdateringar till varje kluster sekventiellt och väntar minst unavailablePeriodSeconds mellan kluster. Distributionsstatusen anses vara lyckad om alla resurser har tillämpats korrekt på klustret. Distributionsstatuskontrollen överlappar inte underordnade resurser, så till exempel bekräftar den inte att poddar som skapats av en distribution blir klara.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
...
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
unavailablePeriodSeconds: 60
Mer information finns i dokumentationen om fleet med öppen källkod om distributionsstrategi.
Fastställa placeringsstatus
Fleet Scheduler uppdaterar information och status för placeringsbeslut på ClusterResourcePlacement objektet. Utdata innehåller följande information:
- De villkor som för närvarande gäller för placeringen, bland annat om placeringen har slutförts.
- Ett avsnitt om placeringsstatus för varje medlemskluster som visar status för distributionen till klustret.
I följande exempel visas en ClusterResourcePlacement som distribuerade test namnområdet och test-1 ConfigMap till två medlemskluster med hjälp av PickN. Placeringen slutfördes och resurserna placerades i klustren aks-member-1 och aks-member-2 .
Du kan visa den här informationen med hjälp av kubectl describe crp <name> kommandot .
kubectl describe crp crp-1
Name: crp-1
Namespace:
Labels: <none>
Annotations: <none>
API Version: placement.kubernetes-fleet.io/v1
Kind: ClusterResourcePlacement
Metadata:
...
Spec:
Policy:
Number Of Clusters: 2
Placement Type: PickN
Resource Selectors:
Group:
Kind: Namespace
Name: test
Version: v1
Revision History Limit: 10
Status:
Conditions:
Last Transition Time: 2023-11-10T08:14:52Z
Message: found all the clusters needed as specified by the scheduling policy
Observed Generation: 5
Reason: SchedulingPolicyFulfilled
Status: True
Type: ClusterResourcePlacementScheduled
Last Transition Time: 2023-11-10T08:23:43Z
Message: All 2 cluster(s) are synchronized to the latest resources on the hub cluster
Observed Generation: 5
Reason: SynchronizeSucceeded
Status: True
Type: ClusterResourcePlacementSynchronized
Last Transition Time: 2023-11-10T08:23:43Z
Message: Successfully applied resources to 2 member clusters
Observed Generation: 5
Reason: ApplySucceeded
Status: True
Type: ClusterResourcePlacementApplied
Placement Statuses:
Cluster Name: aks-member-1
Conditions:
Last Transition Time: 2023-11-10T08:14:52Z
Message: Successfully scheduled resources for placement in aks-member-1 (affinity score: 0, topology spread score: 0): picked by scheduling policy
Observed Generation: 5
Reason: ScheduleSucceeded
Status: True
Type: ResourceScheduled
Last Transition Time: 2023-11-10T08:23:43Z
Message: Successfully Synchronized work(s) for placement
Observed Generation: 5
Reason: WorkSynchronizeSucceeded
Status: True
Type: WorkSynchronized
Last Transition Time: 2023-11-10T08:23:43Z
Message: Successfully applied resources
Observed Generation: 5
Reason: ApplySucceeded
Status: True
Type: ResourceApplied
Cluster Name: aks-member-2
Conditions:
Last Transition Time: 2023-11-10T08:14:52Z
Message: Successfully scheduled resources for placement in aks-member-2 (affinity score: 0, topology spread score: 0): picked by scheduling policy
Observed Generation: 5
Reason: ScheduleSucceeded
Status: True
Type: ResourceScheduled
Last Transition Time: 2023-11-10T08:23:43Z
Message: Successfully Synchronized work(s) for placement
Observed Generation: 5
Reason: WorkSynchronizeSucceeded
Status: True
Type: WorkSynchronized
Last Transition Time: 2023-11-10T08:23:43Z
Message: Successfully applied resources
Observed Generation: 5
Reason: ApplySucceeded
Status: True
Type: ResourceApplied
Selected Resources:
Kind: Namespace
Name: test
Version: v1
Kind: ConfigMap
Name: test-1
Namespace: test
Version: v1
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal PlacementScheduleSuccess 12m (x5 over 3d22h) cluster-resource-placement-controller Successfully scheduled the placement
Normal PlacementSyncSuccess 3m28s (x7 over 3d22h) cluster-resource-placement-controller Successfully synchronized the placement
Normal PlacementRolloutCompleted 3m28s (x7 over 3d22h) cluster-resource-placement-controller Resources have been applied to the selected clusters
Utlösare för placeringsändring
Fleet Scheduler prioriterar stabiliteten i befintliga arbetsbelastningsplaceringar. Den här prioriteringen kan begränsa antalet ändringar som gör att en arbetsbelastning tas bort och schemaläggs om. Följande scenarier kan utlösa placeringsändringar:
- Ändringar i placeringsprincipen i
ClusterResourcePlacementobjektet kan utlösa borttagning och omplanering av en arbetsbelastning.- Skala ut åtgärder (öka
numberOfClustersutan andra ändringar) placerar arbetsbelastningar endast på nya kluster och påverkar inte befintliga placeringar.
- Skala ut åtgärder (öka
- Klusterändringar, inklusive:
- Ett nytt kluster som blir berättigat kan utlösa placering om det nya klustret uppfyller placeringsprincipen, till exempel en
PickAllprincip. - Ett kluster med en placering tas bort från flottan. Beroende på principen försöker schemaläggaren placera alla berörda arbetsbelastningar på återstående kluster utan att påverka befintliga placeringar.
- Ett nytt kluster som blir berättigat kan utlösa placering om det nya klustret uppfyller placeringsprincipen, till exempel en
Ändringar som endast gäller resurser (uppdaterar resurserna eller uppdaterar ResourceSelector i ClusterResourcePlacement -objektet) distribueras gradvis i befintliga placeringar, men utlöser inte schemaläggning av arbetsbelastningen.
Nästa steg
Azure Kubernetes Service