Umieszczanie zasobów kubernetes z klastra koncentratora do klastrów członkowskich
W tym artykule opisano koncepcję umieszczania zasobów Kubernetes z klastrów piasty do klastrów członkowskich przy użyciu usługi Azure Kubernetes Fleet Manager (Kubernetes Fleet).
Administratorzy platformy często muszą wdrażać zasoby kubernetes w wielu klastrach z różnych powodów, na przykład:
- Zarządzanie kontrolą dostępu przy użyciu ról i powiązań ról w wielu klastrach.
- Uruchamianie aplikacji infrastruktury, takich jak Prometheus lub Flux, które muszą znajdować się we wszystkich klastrach.
Deweloperzy aplikacji często muszą wdrażać zasoby Kubernetes w wielu klastrach z różnych powodów, na przykład:
- Wdrażanie aplikacji obsługującej wideo w wielu klastrach w różnych regionach w celu oglądania z małym opóźnieniem.
- Wdrażanie aplikacji koszyka zakupów w dwóch sparowanych regionach dla klientów w celu kontynuowania zakupów podczas awarii jednego regionu.
- Wdrażanie aplikacji obliczeniowej wsadowej w klastrach z dostępnymi niedrogimi pulami węzłów typu spot.
Żmudne jest ręczne tworzenie, aktualizowanie i śledzenie tych zasobów Kubernetes w wielu klastrach. Rozwiązanie Fleet zapewnia propagację zasobów Kubernetes w celu umożliwienia zarządzania zasobami Kubernetes na dużą skalę. Za pomocą rozwiązania Kubernetes Fleet możesz utworzyć zasoby Kubernetes w klastrze centrum i propagować je do wybranych klastrów członkowskich za pośrednictwem zasobów niestandardowych Kubernetes: MemberCluster i ClusterResourcePlacement.
Platforma Kubernetes Fleet obsługuje te zasoby niestandardowe oparte na rozwiązaniu natywnym dla chmury typu open source, które można przeczytać więcej na temat dokumentacji floty typu open source.
Wprowadzenie do klastraResourcePlacement
Obiekt ClusterResourcePlacement służy do określania harmonogramu floty, jak umieścić dany zestaw obiektów o zakresie klastra z klastra centrum floty na klastry członkowskie. Obiekty o zakresie przestrzeni nazw, takie jak Wdrożenia, StatefulSets, DaemonSets, ConfigMaps, Secrets i PersistentVolumeClaims, są uwzględniane podczas wybierania ich zawierającej przestrzeń nazw.
Za pomocą ClusterResourcePlacementprogramu można wykonywać następujące czynności:
- Wybierz zasoby Kubernetes o zakresie klastra, które mają być propagowane do klastrów członkowskich.
- Określ zasady umieszczania ręcznie lub automatycznie wybieraj klastry członkowskie jako klastry docelowe.
- Określ strategie wdrażania, aby bezpiecznie wdrożyć wszystkie aktualizacje wybranych zasobów Kubernetes w wielu klastrach docelowych.
- Wyświetl postęp propagacji w każdym klastrze docelowym.
Przykład pokazano na poniższym diagramie.
Hermetyzowanie zasobów
ClusterResourcePlacement program obsługuje używanie narzędzia ConfigMap do otoki niektórych typów zasobów Kubernetes, dzięki czemu można je przygotować w klastrze koncentratora bez niezamierzonych skutków ubocznych klastra koncentratora. Aby uzyskać listę typów zasobów i zrozumieć, jak działa ta funkcja, zobacz dokumentację obiektu koperty
Typy umieszczania
Dostępne są następujące typy umieszczania do kontrolowania liczby klastrów, do których należy propagować określony zasób Kubernetes:
- PickFixed umieszcza zasób na określoną listę klastrów członkowskich według nazwy.
- PickAll umieszcza zasób we wszystkich klastrach członkowskich lub wszystkich klastrach członkowskich spełniających kryteria. Te zasady są przydatne w przypadku umieszczania obciążeń infrastruktury, takich jak aplikacje do monitorowania klastra lub raportowania.
- PickN jest najbardziej elastyczną opcją umieszczania i umożliwia wybór klastrów na podstawie ograniczeń rozkładu koligacji lub topologii i jest przydatny podczas rozmieszczania obciążeń w wielu odpowiednich klastrach w celu zapewnienia dostępności.
PickFixed typ umieszczania
Jeśli chcesz wdrożyć obciążenie w znanym zestawie klastrów członkowskich, możesz użyć PickFixed zasad umieszczania, aby wybrać klastry według nazwy.
clusterNames jest jedyną prawidłową opcją zasad dla tego typu umieszczania.
W poniższym przykładzie pokazano, jak wdrożyć test-deployment przestrzeń nazw w klastrach cluster1 członkowskich i 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 typ umieszczania
Można użyć PickAll typu umieszczania, aby wdrożyć obciążenie we wszystkich klastrach członkowskich w floty lub w podzestawie klastrów, które spełniają ustawione kryteria.
Podczas tworzenia tego typu umieszczania można określić następujące typy koligacji klastra:
- requiredDuringSchedulingIgnoredDuringExecution: ponieważ te zasady są wymagane podczas planowania, filtruje klastry na podstawie określonych kryteriów.
W poniższym przykładzie pokazano, jak wdrożyć prod-deployment przestrzeń nazw i wszystkie jej obiekty we wszystkich klastrach oznaczonych etykietą 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 umieszczania pickN
Typ umieszczania PickN jest najbardziej elastyczną opcją i umożliwia umieszczanie zasobów w konfigurowalnej liczbie klastrów na podstawie ograniczeń rozkładu koligacji i topologii.
Podczas tworzenia tego typu umieszczania można określić następujące typy koligacji klastra:
- requiredDuringSchedulingIgnoredDuringExecution: ponieważ te zasady są wymagane podczas planowania, filtruje klastry na podstawie określonych kryteriów.
- preferredDuringSchedulingIgnoredDuringExecution: ponieważ te zasady są preferowane, ale nie są wymagane podczas planowania, klasyfikuje klastry na podstawie określonych kryteriów.
Można ustawić zarówno wymagane, jak i preferowane koligacje. Wymagane koligacje uniemożliwiają umieszczanie w klastrach, które nie są zgodne, a preferowane koligacje zapewniają kolejność prawidłowych klastrów.
PickN z koligacjami
Używanie koligacji z PickN funkcjami zasad umieszczania podobnie do używania koligacji z planowaniem zasobników.
W poniższym przykładzie pokazano, jak wdrożyć obciążenie w trzech klastrach. Tylko klastry z etykietą critical-allowed: "true" są prawidłowymi miejscami docelowymi umieszczania, a preferencje są przekazywane klastrom z etykietą 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 z ograniczeniami rozprzestrzeniania topologii
Aby wymusić dzielenie klastrów na granice topologii, można użyć ograniczeń rozprzestrzeniania topologii, aby spełnić wymagania dotyczące dostępności. Na przykład użyj tych ograniczeń, aby podzielić umieszczanie między regionami lub pierścieniami aktualizacji. Można również skonfigurować ograniczenia rozprzestrzeniania topologii, aby zapobiec harmonogramowi, jeśli ograniczenie nie może być spełnione (whenUnsatisfiable: DoNotSchedule) lub jak najlepiej (whenUnsatisfiable: ScheduleAnyway).
W poniższym przykładzie pokazano, jak rozłożyć dany zestaw zasobów w wielu regionach i próbuje zaplanować harmonogram między klastrami członkowskimi z różnymi dniami aktualizacji.
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
Aby uzyskać więcej informacji, zobacz ograniczenia dotyczące topologii dokumentacji floty typu open source.
Opcje zasad umieszczania
Tabela zawiera podsumowanie dostępnych pól zasad planowania dla każdego typu umieszczania.
| Pole zasad | PickFixed | PickAll | Wybierz nazwę |
|---|---|---|---|
placementType |
✅ | ✅ | ✅ |
affinity |
❌ | ✅ | ✅ |
clusterNames |
✅ | ❌ | ❌ |
numberOfClusters |
❌ | ❌ | ✅ |
topologySpreadConstraints |
❌ | ❌ | ✅ |
Wybieranie klastrów na podstawie etykiet i właściwości
Dostępne etykiety i właściwości do wybierania klastrów
W przypadku korzystania z PickN typów i PickAll umieszczania można użyć następujących etykiet i właściwości w ramach zasad.
Etykiety
Następujące etykiety są automatycznie dodawane do wszystkich klastrów członkowskich i mogą być używane do wyboru klastra docelowego w zasadach umieszczania zasobów.
| Etykieta | opis |
|---|---|
| fleet.azure.com/location | Region platformy Azure klastra (westus) |
| fleet.azure.com/resource-group | Grupa zasobów platformy Azure klastra (rg_prodapps_01) |
| fleet.azure.com/subscription-id | Identyfikator subskrypcji platformy Azure, w którym znajduje się klaster. Sformatowany jako UUID/GUID. |
Możesz również użyć dowolnych etykiet niestandardowych, które mają zastosowanie do klastrów.
Właściwości
Poniższe właściwości są dostępne do użycia w ramach zasad umieszczania.
Właściwości procesora CPU i pamięci są reprezentowane jako jednostki zasobów platformy Kubernetes.
Właściwości kosztów to liczby dziesiętne, które reprezentują koszt za godzinę w dolarach amerykańskich dla zasobów obliczeniowych platformy Azure używanych dla węzłów w klastrze. Koszt jest oparty na cenach publicznych platformy Azure.
| Nazwa właściwości | Opis |
|---|---|
| kubernetes-fleet.io/node-count | Dostępne węzły w klastrze członkowskim. |
| resources.kubernetes-fleet.io/total-cpu | Łączna liczba jednostek zasobów procesora CPU klastra. |
| resources.kubernetes-fleet.io/allocatable-cpu | Wszystkie jednostki zasobów procesora CPU klastra. |
| resources.kubernetes-fleet.io/available-cpu | Dostępne jednostki zasobów procesora CPU klastra. |
| resources.kubernetes-fleet.io/total-memory | Łączna jednostka zasobów pamięci klastra. |
| resources.kubernetes-fleet.io/allocatable-memory | Allocatable jednostki zasobów pamięci klastra. |
| resources.kubernetes-fleet.io/available-memory | Dostępne jednostki zasobów pamięci klastra. |
| kubernetes.azure.com/per-cpu-core-cost | Koszt rdzeni procesora CPU klastra. |
| kubernetes.azure.com/per-gb-memory-cost | Koszt pamięci za giB klastra. |
Określanie kryteriów dopasowywania zaznaczenia
W przypadku używania właściwości klastra w kryteriach zasad należy określić:
Nazwa: nazwa właściwości, która jest jedną z właściwości wymienionych we właściwościach w tym artykule.
Operator: Operator używany do wyrażania warunku między ograniczeniem/żądaną wartością a obserwowaną wartością w klastrze. Obecnie obsługiwane są następujące operatory:
Gt(Większe niż): obserwowana wartość danej właściwości klastra musi być większa niż wartość warunku, zanim będzie można ją wybrać do umieszczania zasobów.Ge(Większe lub równe): obserwowana wartość danej właściwości klastra musi być większa lub równa wartości w warunku, zanim będzie można ją wybrać do umieszczania zasobów.Lt(Mniej niż): obserwowana wartość danej właściwości klastra musi być mniejsza niż wartość warunku, zanim będzie można ją wybrać do umieszczania zasobów.Le(Mniejsze niż lub równe): obserwowana wartość danej właściwości klastra musi być mniejsza lub równa wartości w warunku, zanim będzie można ją wybrać do umieszczania zasobów.Eq(Równe): obserwowana wartość danej właściwości klastra musi być równa wartości w warunku, zanim będzie można ją wybrać do umieszczania zasobów.Ne(Nie równe): obserwowana wartość danej właściwości klastra nie może być równa wartości warunku, zanim będzie można ją wybrać do umieszczania zasobów.
Jeśli używasz operatora
Gt, ,Ge,LtLe,EqlubNe, lista wartości w warunku powinna mieć dokładnie jedną wartość.Wartości: lista wartości, które są możliwymi wartościami właściwości.
Fleet ocenia każdy klaster na podstawie właściwości określonych w warunku. Niepowodzenie spełnienia warunków wymienionych w obszarze requiredDuringSchedulingIgnoredDuringExecution wyklucza ten klaster członkowski z umieszczania zasobów.
Uwaga
Jeśli klaster członkowski nie ma właściwości wyrażonej w warunku, automatycznie zakończy się niepowodzeniem warunku.
Oto przykładowe zasady umieszczania, aby wybrać tylko klastry z co najmniej pięcioma węzłami.
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 działa klasyfikacja właściwości
Gdy preferredDuringSchedulingIgnoredDuringExecution jest używany, sortator właściwości klasyfikuje wszystkie klastry w floty na podstawie ich wartości w kolejności rosnącej lub malejącej. Wagi używane do zamawiania są obliczane na podstawie określonej wartości.
Sorter właściwości składa się z:
- Nazwa: nazwa właściwości klastra.
- Kolejność sortowania: kolejność sortowania może mieć wartość
AscendinglubDescending. W przypadkuAscendingużycia kolejności preferowane są klastry składowe o niższych obserwowanych wartościach. W przypadkuDescendingużycia kolejności preferowane są klastry członkowskie o wyższej obserwowanej wartości.
Malejącym
W przypadku kolejności sortowania Malejąco proporcjonalna waga jest obliczana przy użyciu formuły:
((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight
Załóżmy na przykład, że chcesz sklasyfikować klastry na podstawie właściwości dostępnej pojemności procesora CPU w kolejności malejącej i że masz flotę trzech klastrów z następującym dostępnym procesorem CPU:
| Klaster | Dostępna pojemność procesora CPU |
|---|---|
cluster-a |
100 |
cluster-b |
20 |
cluster-c |
10 |
W tym przypadku sorter oblicza następujące wagi:
| Klaster | Dostępna pojemność procesora CPU | Obliczenia | Weight |
|---|---|---|---|
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% |
Kolejność rosnąca
W przypadku kolejności sortowania Rosnąco proporcjonalna waga jest obliczana przy użyciu formuły:
(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight
Załóżmy na przykład, że chcesz sklasyfikować klastry na podstawie ich kosztu rdzenia procesora CPU w kolejności rosnącej i że masz flotę trzech klastrów z następującymi kosztami rdzeni procesora CPU:
| Klaster | Koszt rdzenia procesora CPU |
|---|---|
cluster-a |
1 |
cluster-b |
0,2 |
cluster-c |
0.1 |
W tym przypadku sorter oblicza następujące wagi:
| Klaster | Koszt rdzenia procesora CPU | Obliczenia | Weight |
|---|---|---|---|
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% |
Używanie tolerancji
ClusterResourcePlacement obiekty obsługują specyfikację tolerancji, które mają zastosowanie do ClusterResourcePlacement obiektu. Każdy obiekt tolerancji składa się z następujących pól:
key: klucz tolerancji.value: wartość tolerancji.effect: Efekt tolerancji, taki jakNoSchedule.operator: operator tolerancji, taki jakExistslubEqual.
Każda tolerancja jest używana do tolerowania co najmniej jednego konkretnego defektu stosowanego w obiekcie ClusterResourcePlacement. Po tolerowaniu wszystkich defektów na obiekcie MemberCluster harmonogram może następnie propagować zasoby do klastra. Nie można zaktualizować ani usunąć tolerancji z obiektu po utworzeniu ClusterResourcePlacement .
Aby uzyskać więcej informacji, zobacz dokumentację floty typu open source dotyczącą tolerancji.
Konfigurowanie strategii wdrażania
Rozwiązanie Fleet używa strategii aktualizacji stopniowej do kontrolowania sposobu wdrażania aktualizacji w klastrach.
W poniższym przykładzie harmonogram floty wdraża aktualizacje dla każdego klastra sekwencyjnie, czekając co najmniej unavailablePeriodSeconds między klastrami. Stan wdrożenia jest uznawany za pomyślny, jeśli wszystkie zasoby zostały poprawnie zastosowane do klastra. Sprawdzanie stanu wdrożenia nie powoduje kaskadowego przejścia do zasobów podrzędnych, więc na przykład nie potwierdza, że zasobniki utworzone przez wdrożenie staną się gotowe.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
...
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
unavailablePeriodSeconds: 60
Aby uzyskać więcej informacji, zobacz dokumentację floty typu open source dotyczącą strategii wdrażania.
Określanie stanu umieszczania
Harmonogram floty aktualizuje szczegóły i stan decyzji dotyczących umieszczania ClusterResourcePlacement na obiekcie. Dane wyjściowe zawierają następujące informacje:
- Warunki, które są obecnie stosowane do umieszczania, które obejmują, jeśli umieszczanie zostało pomyślnie ukończone.
- Sekcja stanu umieszczania dla każdego klastra członkowskiego, która pokazuje stan wdrożenia w tym klastrze.
W poniższym przykładzie pokazano, ClusterResourcePlacement że wdrożono test przestrzeń nazw i test-1 ConfigMap w dwóch klastrach członkowskich przy użyciu polecenia PickN. Umieszczanie zostało ukończone pomyślnie, a zasoby zostały umieszczone w aks-member-1 klastrach i aks-member-2 .
Te informacje można wyświetlić przy użyciu kubectl describe crp <name> polecenia .
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
Wyzwalacze zmiany umieszczania
Harmonogram floty określa priorytety stabilności istniejących umieszczania obciążeń. Ta priorytetyzacja może ograniczyć liczbę zmian, które powodują usunięcie obciążenia i jego ponowne utworzenie. Następujące scenariusze mogą wyzwalać zmiany umieszczania:
- Zmiany zasad umieszczania w
ClusterResourcePlacementobiekcie mogą wyzwalać usuwanie i ponowne zmienianie obciążenia.- Skalowanie operacji w poziomie (zwiększanie
numberOfClustersbez innych zmian) powoduje umieszczenie obciążeń tylko w nowych klastrach i nie ma wpływu na istniejące miejsca.
- Skalowanie operacji w poziomie (zwiększanie
- Zmiany klastra, w tym:
- Nowy klaster kwalifikujący się może wyzwolić umieszczanie, jeśli nowy klaster spełnia zasady umieszczania
PickAll, na przykład zasady. - Klaster z rozmieszczeniem jest usuwany z floty. W zależności od zasad harmonogram próbuje umieścić wszystkie obciążenia, których dotyczy problem, na pozostałych klastrach bez wpływu na istniejące umieszczanie.
- Nowy klaster kwalifikujący się może wyzwolić umieszczanie, jeśli nowy klaster spełnia zasady umieszczania
Zmiany tylko dla zasobów (aktualizowanie zasobów lub aktualizowanie ResourceSelector obiektu) są stopniowo wdrażane w ClusterResourcePlacement istniejących miejscach, ale nie wyzwalają ponownej zmiany obciążenia.
Następne kroki
Azure Kubernetes Service