Använda ClusterResourcePlacement för att distribuera klusteromfattande resurser

I den här artikeln beskrivs ClusterResourcePlacement-API:et, som möjliggör resursplacering från hubbkluster till medlemskluster med Azure Kubernetes Fleet Manager.

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 en videoströmningstjänst till flera kluster i olika regioner för en upplevelse med låg latens.
• Distribuera ett kundvagnsprogram till två parkopplade regioner så att kunderna kan fortsätta att handla under ett avbrott i en enda region.
• Distribuera ett batchbearbetningsprogram till kluster med tillgängliga och billiga spotnodpooler.

Det är tråkigt att skapa, uppdatera och spåra dessa Kubernetes-resurser i flera kluster manuellt. Fleet Manager tillhandahåller Kubernetes-resursspridning för att möjliggöra skalningshantering av Kubernetes-resurser. Med Fleet Manager kan du skapa Kubernetes-resurser i ett Fleet-hanterat hubbkluster och sprida dem till valda medlemskluster via Kubernetes Anpassade resurser: MemberCluster och ClusterResourcePlacement.

Fleet Manager stöder dessa anpassade resurser baserat på CNCF-projektet KubeFleet som du kan läsa mer om på KubeFleet-dokumentationswebbplatsen.

Översikt över ClusterResourcePlacement API

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. När du väljer ett namnområde inkluderas och sprids alla namnområdesomfångsobjekt i det, såsom Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets och PersistentVolumeClaims.

För scenarier som kräver detaljerad kontroll över enskilda namnområdesomfångsresurser inom ett namnområde, se ResourcePlacement, som möjliggör selektiv spridning av specifika resurser i stället för hela namnområden.

Med ClusterResourcePlacementkan du:

• Välj vilka resurser som ska spridas. Dessa kan vara Kubernetes-resurser med klusteromfattning som definierats med hjälp av GVK-referenser (Kubernetes Group Version Kind) eller ett namnområde som sprider namnområdet och alla dess resurser.
• Ange placeringsprinciper för att välja medlemskluster. Dessa principer kan uttryckligen välja kluster efter namn eller dynamiskt välja kluster baserat på klusteretiketter och egenskaper.
• 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 för varje målkluster.

Resursval

ClusterResourcePlacement stöder val av klusteromfattande resurser och namnområden med hjälp av resursväljare. Varje resursväljare kan ange:

• Grupp, Version, Typ (GVK): Den typ av Kubernetes-resurs som ska väljas.
• Namn: Namnet på en specifik resurs.
• Etikettväljare: Etiketter som matchar flera resurser.

Namnområdesvalsomfång (förhandsversion)

Viktigt!

Fältet selectionScope är tillgängligt i API-versionen placement.kubernetes-fleet.io/v1beta1 som en förhandsversionsfunktion. Den är inte tillgänglig i API:et placement.kubernetes-fleet.io/v1 .

När du väljer en namnområdesresurs kan du använda fältet selectionScope för att styra om endast namnområdet ska spridas eller namnområdet och allt dess innehåll:

• Standardbeteende (när selectionScope anges inte): Sprider namnområdet och alla resurser i det.
• NamespaceOnly: Sprider endast själva namnområdesobjektet, utan några resurser i namnområdet. Det här är användbart när du vill upprätta namnområden mellan kluster samtidigt som du hanterar enskilda resurser separat med hjälp av ResourcePlacement.

I följande exempel visas hur du endast sprider namnområdet utan dess innehåll med hjälp av api:et v1beta1:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly
  policy:
    placementType: PickAll

Den här metoden möjliggör ett arbetsflöde där plattformsadministratörer använder ClusterResourcePlacement för att upprätta namnområden, medan programteam använder ResourcePlacement för detaljerad kontroll över specifika resurser inom dessa namnområden.

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 denna policy föredras men inte krävs under schemaläggningen, rangordnar den kluster baserat på angivna kriterier.

Du kan ange både obligatoriska och önskade affiniteter. Obligatoriska tillhörigheter förhindrar placering till kluster som inte matchar, och önskade tillhörigheter ger ordning på giltiga kluster.

PickN med släktskap

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 företräde ges åt 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 KubeFleet-dokumentationen om topologispridningsbegränsningar.

Alternativ för placeringspolicy

Tabellen sammanfattar de tillgängliga schemaläggningsprincipfälten för varje placeringstyp.

Politikområde	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	Beskrivning
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	Prenumerationsidentifieraren i Azure som klustret finns i. Formaterad som UUID/GUID.
fleet.azure.com/cluster-name	Namnet på klustret
fleet.azure.com/member-name	Namnet på den fleetmedlem som motsvarar klustret

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 placeringspolicyer.

Cpu- och minnesegenskaper representeras som Kubernetes-resursenheter.

Kostnadsegenskaper är decimaler som representerar en kostnad per timme i US-dollar för Azure-beräkningen som används för noder i klustret. Kostnaden baseras på offentliga priser hos 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/tilldelningsbar-cpu	Allokerbara CPU-resursenheter i klustret.
resources.kubernetes-fleet.io/tillgänglig-cpu	Tillgängliga CPU-resursenheter i klustret.
resources.kubernetes-fleet.io/total-memory	Total minnesresursenhet i klustret.
resources.kubernetes-fleet.io/tillgängligt-minne	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-minneskostnad	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, Eqeller Ne, 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 Ascending eller Descending. När Ascending ordningen används föredras medlemskluster med lägre observerade värden. När Descending ordningen 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	Vikt
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	Vikt
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 %

Resursögonblicksbilder

Fleet Manager har en historik över de 10 senast använda principerna för schemaläggning av placeringar, tillsammans med resursversioner som placeringen har valt.

Dessa ögonblicksbilder kan användas med stegvisa distributionsstrategier för att styra den distribuerade versionen.

Mer information finns i dokumentationen om ögonblicksbilder.

Kapsla in resurser med hjälp av kuvertobjekt

När du sprider resurser till medlemskluster som följer hubb- och ekermodellen är det viktigt att förstå att själva hubbklustret också är ett Kubernetes-kluster. Alla resurser som du vill sprida tillämpas först direkt på hubbklustret, vilket kan leda till några potentiella biverkningar:

1. Oönskade biverkningar: Resurser som ValidatingWebhookConfigurations, MutatingWebhookConfigurations eller Antagningskontrollanter skulle bli aktiva i hubbklustret, vilket kan fånga upp och påverka hubbklusteråtgärder.

2. Säkerhetsrisker: RBAC-resurser (Roller, ClusterRoles, RoleBindings, ClusterRoleBindings) som är avsedda för användning i medlemskluster kan oavsiktligt bevilja behörigheter på hubbklustret.

3. Resursbegränsningar: ResourceQuotas, FlowSchema eller LimitRanges som definierats för medlemskluster skulle träda i kraft på hubbklustret. Även om dessa biverkningar i allmänhet inte gör någon skada, kan det finnas fall där du vill undvika dessa begränsningar på hubbklustret.

För att undvika de onödiga biverkningarna tillhandahåller Azure Kubernetes fleet manager anpassade resurser för att omsluta objekt för att lösa dessa problem. Själva kuvertobjektet tillämpas på hubben, men de resurser som det innehåller extraheras och tillämpas bara när de når medlemskluster. På så sätt kan man definiera resurser som ska spridas utan att faktiskt distribuera innehållet i hubbklustret. Mer information finns i dokumentationen om kuvertobjekt.

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 exempel NoSchedule.
• operator: Operatorn för toleransen, till exempel Exists eller Equal.

Varje tolerans används för att tolerera en eller flera specifika taints 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 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. Utrullningsstatusen anses vara framgångsrik 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 distributionsstrategier.

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

Mer information finns i dokumentationen om hur du förstår placeringsresultatet.

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 ClusterResourcePlacement objektet kan utlösa borttagning och omplanering av en arbetsbelastning.
  • Skalningsoperationer (öka numberOfClusters utan andra ändringar) placerar arbetsbelastningar endast på nya kluster och påverkar inte befintliga placeringar.
• Klusterändringar, inklusive:
  • Ett nytt kluster som blir berättigat kan utlösa placering om det nya klustret uppfyller placeringsprincipen, till exempel en PickAll princip.
  • 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.

Ä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

• Använd klusterresursplacering för att distribuera arbetsbelastningar i flera kluster.
• Använda ResourcePlacement för att distribuera namnområdesomfångsbegränsade resurser.
• Intelligent kubernetes-resursplacering mellan kluster baserat på medlemsklusteregenskaper.
• Kontroll av utestängning och störningar vid placering av klusterresurser.
• Definiera en distributionsstrategi för en klusterresursplacering.
• Vanliga frågor och svar om placering av klusterresurser.