Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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
selectionScopenení 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,LeEqneboNe, 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ď
AscendingneboDescending. PřiAscendingpoužití pořadí se preferují členské clustery s nižšími pozorovanými hodnotami. PřiDescendingpouž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:
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.
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.
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říkladNoSchedule. -
operator: Operátor tolerance, napříkladExistsneboEqual.
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
ClusterResourcePlacementmůžou aktivovat odebrání a přeplánování úlohy.- Operace škálování (zvýšení
numberOfClustersbez dalších změn) umístí úlohy pouze do nových clusterů a nemá vliv na stávající umístění.
- Operace škálování (zvýšení
- 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í.
- 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
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
- Pomocí umístění prostředků clusteru nasaďte úlohy napříč několika clustery.
- Použití ResourcePlacementu k nasazení prostředků s oborem názvů
- Inteligentní umístění prostředků Kubernetes napříč clustery na základě vlastností členských clusterů
- Řízení vytěsnění a narušení při umísťování prostředků v clusteru
- Definování strategie nasazení pro umístění prostředků clusteru
- Nejčastější dotazy k umístění prostředků clusteru
Azure Kubernetes Service