Sdílet prostřednictvím


Použití ClusterResourcePlacement k nasazení prostředků s vymezeným clusterem

Tento článek popisuje rozhraní API ClusterResourcePlacement, které umožňuje umístění prostředků z centrálních clusterů do členských clusterů pomocí Azure Kubernetes Fleet Manageru.

Správci platformy často potřebují nasadit prostředky Kubernetes do několika clusterů z různých důvodů, například:

  • Správa řízení přístupu pomocí rolí a vazeb rolí napříč několika clustery
  • Spouštění aplikací infrastruktury, jako je Například Prometheus nebo Flux, které musí být na všech clusterech.

Vývojáři aplikací často potřebují nasadit prostředky Kubernetes do několika clusterů z různých důvodů, například:

  • Nasazení aplikace obsluhující video do několika clusterů v různých oblastech za účelem sledování nízké latence
  • Nasazení aplikace nákupního košíku do dvou spárovaných oblastí, aby zákazníci mohli pokračovat v nákupu během výpadku jedné oblasti.
  • Nasazení dávkové výpočetní aplikace do clusterů se skupinami levných spotových uzlů.

Je zdlouhavé vytvářet, aktualizovat a sledovat tyto prostředky Kubernetes napříč několika clustery ručně. Správce flotily poskytuje rozšiřování prostředků Kubernetes s cílem umožnit správu prostředků Kubernetes v rozsáhlém měřítku. Pomocí Správce flotily můžete vytvářet prostředky Kubernetes v clusteru centra spravovaného pro flotilu a rozšířit je do vybraných členských clusterů prostřednictvím vlastních prostředků Kubernetes: MemberCluster a ClusterResourcePlacement.

Fleet Manager podporuje tyto vlastní zdroje založené na projektu CNCF KubeFleet , o kterém si můžete přečíst více na webu dokumentace KubeFleet.

Přehled rozhraní API ClusterResourcePlacement

Objekt ClusterResourcePlacement slouží k oznámení plánovači vozového parku, jak umístit danou sadu objektů s oborem clusteru z clusteru centra flotily na členské clustery. Při výběru oboru názvů jsou všechny objekty ve vybraném oboru názvů, jako například Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets a PersistentVolumeClaims, zahrnuty a propagovány společně.

Scénáře vyžadující jemně řízenou kontrolu nad jednotlivými prostředky v rámci oboru názvů, viz ResourcePlacement, které umožňuje selektivní šíření specifických prostředků místo celých oborů názvů.

Pomocí ClusterResourcePlacement:

  • Vyberte, které prostředky se mají propagovat. Může jít o prostředky Kubernetes s oborem zaměřeným na klastr, které jsou definované pomocí odkazů Kubernetes Group Version Kind (GVK), nebo o obor názvů, který propaguje obor názvů a všechny jeho prostředky.
  • Zadejte zásady umístění pro výběr členských clusterů. Tyto zásady můžou explicitně vybrat clustery podle názvů nebo dynamicky vybírat clustery na základě popisků a vlastností clusteru.
  • Určete strategie zavedení pro bezpečné zavedení všech aktualizací vybraných prostředků Kubernetes do více cílových clusterů.
  • Zobrazte průběh šíření pro každý cílový cluster.

Výběr zdroje

ClusterResourcePlacement podporuje výběr prostředků a oborů názvů s rozsahem clustru pomocí selektorů prostředků. Každý selektor prostředků může zadat:

  • Group, Version, Kind (GVK): Typ prostředku Kubernetes, který chcete vybrat.
  • Název: Název konkrétního prostředku.
  • Selektory štítků: Štítky odpovídají více prostředkům

Rozsah výběru oboru názvů (náhled)

Důležité

Pole selectionScope je k dispozici ve placement.kubernetes-fleet.io/v1beta1 verzi API jako funkce Preview. Není k dispozici v placement.kubernetes-fleet.io/v1 rozhraní API.

Při výběru prostředku oboru názvů můžete pomocí pole selectionScope určit, jestli se má šířit pouze samotný obor názvů nebo obor názvů a veškerý jeho obsah:

  • Výchozí chování (pokud selectionScope není zadáno): Přenese obor názvů a všechny zdroje v něm.
  • NamespaceOnly: Propaguje pouze samotný objekt oboru názvů, bez jakýchkoli prostředků v rámci oboru názvů. To je užitečné, když chcete vytvořit obory názvů napříč různými clustery a spravovat jednotlivé prostředky samostatně pomocí ResourcePlacement.

Následující příklad ukazuje, jak rozšířit pouze obor názvů bez jeho obsahu pomocí rozhraní API 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

Tento přístup umožňuje pracovní postup, ve kterém správci platformy používají ClusterResourcePlacement k vytváření jmenných prostorů, zatímco aplikační týmy používají ResourcePlacement k podrobné kontrole nad konkrétními prostředky v rámci těchto jmenných prostorů.

Typy umístění

Pro řízení počtu clusterů, do kterých je potřeba rozšířit zadaný prostředek Kubernetes, jsou k dispozici následující typy umístění:

  • PickFixed umístí prostředek do konkrétního seznamu členských clusterů podle názvu.
  • Funkce PickAll umístí prostředek do všech členských clusterů nebo do všech členských clusterů, které splňují kritéria. Tato zásada je užitečná pro umístění pracovní zátěže infrastruktury, jako jsou aplikace pro monitorování clusteru nebo reportovací aplikace.
  • PickN je nejflexibilnější možnost umístění a umožňuje výběr clusterů na základě omezení týkajících se spřažení nebo rozložení topologie. Je to užitečné pro šíření úloh napříč několika vhodnými clustery, když je požadována zajištění dostupnosti.

Typ umístění PickFixed

Pokud chcete nasadit úlohu do známé sady členských clusterů, můžete pomocí PickFixed zásady umístění vybrat clustery podle názvu.

clusterNames je jedinou platnou možností zásad pro tento typ umístění.

Následující příklad ukazuje, jak nasadit test-deployment obor názvů na členské clustery cluster1 a 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

Typ umístění PickAll

Typ umístění můžete použít PickAll k nasazení úlohy napříč všemi členskými clustery ve vozovém parku nebo do podmnožiny clusterů, které splňují vámi nastavená kritéria.

Při vytváření tohoto typu umístění je možné zadat následující typy spřažení clusteru:

  • requiredDuringSchedulingIgnoredDuringExecution: protože se tato zásada vyžaduje během plánování, filtruje clustery na základě zadaných kritérií.

Následující příklad ukazuje, jak nasadit prod-deployment obor názvů a všechny jeho objekty ve všech clusterech označených 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

Typ umístění PickN

Typ umístění PickN je nejflexibilnější možností a umožňuje umístění prostředků do konfigurovatelného počtu clusterů na základě afinit i omezení rozložení topologie.

Při vytváření tohoto typu umístění je možné zadat následující typy spřažení clusteru:

  • requiredDuringSchedulingIgnoredDuringExecution: protože se tato zásada vyžaduje během plánování, filtruje clustery na základě zadaných kritérií.
  • preferredDuringSchedulingIgnoredDuringExecution: tato zásada je preferována, ale nevyžaduje se při plánování, řadí clustery podle zadaných kritérií.

Můžete nastavit požadované i upřednostňované spřažení. Požadované spřažení brání umístění do clusterů, které se neshodují, a upřednostňované spřažení zajišťují řazení platných clusterů.

PickN s afinitami

Použití afinit s zásadou umisťování funguje podobně jako použití afinit s plánováním podů.

Následující příklad ukazuje, jak nasadit úlohu do tří clusterů. Platné cíle umístění jsou pouze clustery s critical-allowed: "true" popiskem a předvolba je udělena clusterům s popiskem 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 s omezeními rozložení topologie

Omezení rozložení topologie můžete použít k vynucení rozdělení umístění clusteru napříč hranicemi topologie, aby splňovaly požadavky na dostupnost. Tato omezení můžete například použít k rozdělení umístění mezi oblasti nebo aktualizační okruhy. Omezení rozložení topologie můžete také nakonfigurovat tak, aby se zabránilo plánování, pokud omezení nejde splnit (whenUnsatisfiable: DoNotSchedule) nebo naplánovat co nejlépe (whenUnsatisfiable: ScheduleAnyway).

Následující příklad ukazuje, jak distribuovat danou sadu prostředků napříč několika regiony a pokusit se naplánovat mezi členské clustery s různými dny aktualizace.

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

Další informace najdete v dokumentaci kubeFleet týkající se omezení šíření topologie.

Možnosti zásad umístění

Tabulka shrnuje dostupná pole zásad plánování pro každý typ umístění.

Pole Politiky PickFixed PickAll PickN
placementType
affinity
clusterNames
numberOfClusters
topologySpreadConstraints

Výběr clusterů na základě popisků a vlastností

Dostupné popisky a vlastnosti pro výběr clusterů

Při použití typů umístění PickN a PickAll můžete v rámci svých zásad použít následující popisky a vlastnosti.

Štítky

Následující popisky se automaticky přidají do všech členských clusterů a dají se použít pro výběr cílového clusteru v zásadách umístění prostředků.

Štítek Popis
fleet.azure.com/location Oblast služby Azure clusteru ve West US
fleet.azure.com/resource-group Skupina prostředků clusteru Azure (rg_prodapps_01)
fleet.azure.com/subscription-id Identifikátor předplatného Azure, ve kterém se cluster nachází. Formátováno jako UUID/GUID.
fleet.azure.com/cluster-name Název clusteru
fleet.azure.com/member-name Název člena flotily odpovídající clusteru

Můžete také použít jakékoli vlastní popisky, které použijete u clusterů.

Vlastnosti

Následující vlastnosti jsou k dispozici pro použití v rámci zásad umístění.

Vlastnosti procesoru a paměti jsou reprezentovány jako jednotky prostředků Kubernetes.

Vlastnosti nákladů jsou vyjádřeny jako desetinná čísla, která představují hodinové náklady v amerických dolarech za využití výpočetních prostředků Azure pro uzly v clusteru. Náklady jsou založené na veřejných cenách Azure.

Název vlastnosti Popis
kubernetes-fleet.io/počet-uzlů Dostupné uzly v členském clusteru.
resources.kubernetes-fleet.io/total-cpu Celkový počet jednotek CPU zdrojů clusteru
resources.kubernetes-fleet.io/allocatable-cpu Jednotky prostředků procesoru s možností přidělování prostředků clusteru
resources.kubernetes-fleet.io/available-cpu Dostupné jednotky prostředků procesoru clusteru.
resources.kubernetes-fleet.io/celková-paměť (total-memory) Celková jednotka prostředků paměti clusteru
resources.kubernetes-fleet.io/allocatable-memory Jednotky prostředků paměti s možností přidělení v clusteru.
resources.kubernetes-fleet.io/dostupna-pamet Dostupné jednotky prostředků paměti clusteru
kubernetes.azure.com/náklady-na-každý-CPU-jádro Náklady na jádro procesoru clusteru.
kubernetes.azure.com/per-gb-memory-cost Náklady na paměť na GiB clusteru.

Zadání kritérií shody výběru

Při použití vlastností clusteru v kritériích zásad zadáte:

  • Název: Název vlastnosti, která je jednou z vlastností uvedených v tomto článku.

  • Operátor: Operátor použitý k vyjádření podmínky mezi omezující/požadovanou hodnotou a pozorovanou hodnotou v clusteru. V současné době jsou podporovány následující operátory:

    • Gt (Větší než): Aby byla pozorovaná hodnota dané vlastnosti clusteru vybrána pro umístění prostředků, musí být větší než hodnota v podmínce.
    • Ge (Větší než nebo rovno): Aby mohl být cluster vybrán k umístění prostředků, musí být pozorovaná hodnota dané vlastnosti větší nebo rovna hodnotě v podmínce.
    • Lt (Menší než): Pozorovaná hodnota clusteru dané vlastnosti musí být menší než hodnota v podmínce, aby bylo možné ji vybrat pro umístění prostředků.
    • Le (Menší nebo rovno): Aby byla pozorovaná hodnota clusteru určené vlastnosti vybrána pro umístění prostředků, musí být menší nebo rovna hodnotě v podmínce.
    • Eq (Rovná se): Pozorovaná hodnota clusteru dané vlastnosti musí být rovna hodnotě v podmínce, aby bylo možné ji vybrat pro umístění prostředků.
    • Ne (Nerovná se): Pozorovaná hodnota clusteru dané vlastnosti nesmí být rovna hodnotě v podmínce, aby bylo možné ji vybrat pro umístění prostředků.

    Pokud použijete operátor Gt, , Ge, Lt, LeEqnebo Ne, seznam hodnot v podmínce by měl mít přesně jednu hodnotu.

  • Hodnoty: Seznam hodnot, které jsou možné hodnoty vlastnosti.

Flotila vyhodnocuje každý cluster na základě vlastností zadaných v podmínce. Nesplnění podmínek uvedených v rámci requiredDuringSchedulingIgnoredDuringExecution vylučuje tohoto člena clusteru z umístění prostředků.

Poznámka:

Pokud členský klastr nemá vlastnost vyjádřenou v podmínce, podmínka nebude automaticky splněna.

Tady je příklad zásad umístění pro výběr pouze clusterů s pěti nebo více uzly.

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"

Jak funguje hodnocení nemovitostí

Při použití preferredDuringSchedulingIgnoredDuringExecution uspořadatel vlastností seřadí všechny clustery ve flotile podle jejich hodnot ve vzestupném nebo sestupném pořadí. Váhy použité pro řazení se počítají na základě zadané hodnoty.

Třídič vlastností se skládá z:

  • Název: Název vlastnosti clusteru.
  • Řazení: Pořadí může být buď Ascending nebo Descending. Při Ascending použití pořadí se preferují členské clustery s nižšími pozorovanými hodnotami. Při Descending použití pořadí se preferují členské clustery s vyšší pozorovanou hodnotou.
Sestupné pořadí

Pro pořadí řazení Sestupně se vypočítá proporcionální váha pomocí vzorce:

((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight

Řekněme například, že chcete seřadit clustery na základě vlastnosti dostupné kapacity procesoru v sestupném pořadí a že máte flotilu tří clusterů s následujícím dostupným procesorem:

Klastr Dostupná kapacita procesoru
cluster-a 100
cluster-b 20
cluster-c 10

V tomto případě třídič vypočítá následující váhy:

Klastr Dostupná kapacita procesoru Výpočet Hmotnost
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 %
Vzestupné pořadí

Pro vzestupné pořadí řazení se proporcionální váha vypočítá pomocí vzorce:

(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight

Řekněme například, že chcete seřadit clustery na základě jejich nákladů na jádro procesoru vzestupně a že máte flotilu tří clusterů s následujícími náklady na jádra procesoru:

Klastr Náklady na jádro procesoru
cluster-a 1
cluster-b 0,2
cluster-c 0,1

V tomto případě třídič vypočítá následující váhy:

Klastr Náklady na jádro procesoru Výpočet Hmotnost
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 %

Snímky prostředků

Správce flotily uchovává historii 10 naposledy použitých zásad plánování umístění spolu s verzemi prostředků, které umístění vybralo.

Tyto snímky je možné použít se strategiemi postupného zavedení k řízení nasazené verze.

Další informace najdete v dokumentaci ke snímkům.

Zapouzdření prostředků pomocí objektů obálky

Při šíření prostředků do členských clusterů podle modelu hub and spoke je důležité pochopit, že centrální cluster je také cluster Kubernetes. ** Jakýkoli prostředek, který chcete propagovat, by se nejprve použil přímo na hub cluster, což může vést k některým potenciálním vedlejším účinkům:

  1. Nezamýšlené vedlejší účinky: Prostředky, jako je ValidatingWebhookConfigurations, MutatingWebhookConfigurations nebo Admission Controllers, by se staly aktivními na clusteru hub, potenciálně zachycujícím a ovlivňujícím operace clusteru hub.

  2. Rizika zabezpečení: Prostředky RBAC (role, role clusteru, vazby rolí, clusterrolebindingy) určené pro členské clustery můžou udělovat nezamýšleným oprávněním v clusteru centra.

  3. Omezení prostředků: ResourceQuotas, FlowSchema nebo LimitRanges definované pro členské clustery by měly účinek na centrálním clusteru. I když tyto vedlejší účinky obvykle neuškodí, mohou se zde vyskytovat případy, kdy se chcete těmto omezením v clusteru rozbočovačů vyhnout.

Aby se zabránilo těmto zbytečným vedlejším účinkům, správce vozového parku Azure Kubernetes poskytuje vlastní prostředky pro zabalení objektů za účelem vyřešení těchto problémů. Samotný objekt obálky se použije v centru, ale prostředky, které obsahuje, jsou extrahovány a aplikovány pouze tehdy, když se dostanou do členských clusterů. Tímto způsobem můžete definovat prostředky, které by se měly rozšířit bez skutečného nasazení jejich obsahu do clusteru centra. Další informace najdete v dokumentaci k objektům obálky.

Používání tolerance

ClusterResourcePlacement objekty podporují specifikaci tolerance, která se vztahuje na ClusterResourcePlacement objekt. Každý objekt tolerance se skládá z následujících polí:

  • key: Klíč tolerance.
  • value: Hodnota tolerance.
  • effect: Účinek tolerance, například NoSchedule.
  • operator: Operátor tolerance, například Exists nebo Equal.

Každá tolerance se používá k tolerování jednoho nebo více specifických taintů použitých na ClusterResourcePlacement. Jakmile jsou na serveru MemberCluster tolerovány všechny tainty, plánovací nástroj může následně přidělit prostředky do clusteru. Po vytvoření objektu ClusterResourcePlacement není možné aktualizovat ani odebrat tolerance.

Další informace najdete v dokumentaci k tolerancím.

Konfigurace strategie zavedení

Flotila používá strategii postupné aktualizace k řízení způsobu zavádění aktualizací napříč clustery.

V následujícím příkladu plánovač flotily postupně zavede aktualizace do každého clusteru a čeká alespoň unavailablePeriodSeconds mezi clustery. Stav zavedení se považuje za úspěšný, pokud byly na cluster správně použity všechny prostředky. Kontrola stavu zavedení se nešíří na podřízené prostředky, takže například nepotvrdí, že se pody vytvořené nasazením stanou připravenými.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Další informace najdete v dokumentaci ke strategiím zavedení.

Určení stavu umístění

Plánovač Flotily aktualizuje podrobnosti a stav rozhodnutí o umístění objektu ClusterResourcePlacement . Výstup obsahuje následující informace:

  • Podmínky, které se aktuálně vztahují na umístění, mezi které patří, pokud bylo umístění úspěšně dokončeno.
  • Oddíl stavu umístění pro každý členský cluster, který zobrazuje stav nasazení do tohoto clusteru.

Následující příklad ukazuje ClusterResourcePlacement, který nasadil obor názvů test a objekt ConfigMap test-1 do dvou členských clusterů pomocí PickN. Umístění bylo úspěšně dokončeno a prostředky byly umístěny do clusterů aks-member-1 a aks-member-2.

Tyto informace můžete zobrazit pomocí kubectl describe crp <name> příkazu.

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

Další informace najdete v dokumentaci k tomu, jak porozumět výsledku umístění.

Spouštěče změny umístění

Plánovač flotily upřednostňuje stabilitu stávajících umístění úloh. Toto stanovení priority může omezit počet změn, které způsobují odebrání a přeplánování úlohy. Následující scénáře můžou aktivovat změny umístění:

  • Změny zásad umístění v objektu ClusterResourcePlacement můžou aktivovat odebrání a přeplánování úlohy.
    • Operace škálování (zvýšení numberOfClusters bez dalších změn) umístí úlohy pouze do nových clusterů a nemá vliv na stávající umístění.
  • Změny clusteru, včetně:
    • Nový cluster, který se stane způsobilým, může aktivovat umístění, pokud nový cluster splňuje zásady umístění, například zásadu PickAll .
    • Cluster s umístěním se odebere z flotily. V závislosti na zásadách se plánovač pokusí umístit všechny ovlivněné úlohy do zbývajících clusterů bez ovlivnění stávajících umístění.

Změny týkající se pouze prostředků (aktualizace prostředků nebo aktualizace ResourceSelector v objektu ClusterResourcePlacement) se postupně zavádějí v současných umístěních, ale ne aktivují opětovné plánování úlohy.

Další kroky