Plaatsing van Kubernetes-resources van hubcluster naar lidclusters
In dit artikel wordt het concept van Kubernetes-resourceplaatsing van hubclusters tot lidclusters beschreven met behulp van Azure Kubernetes Fleet Manager (Kubernetes Fleet).
Platformbeheerders moeten kubernetes-resources vaak om verschillende redenen implementeren op meerdere clusters, bijvoorbeeld:
- Toegangsbeheer beheren met behulp van rollen en rolbindingen in meerdere clusters.
- Het uitvoeren van infrastructuurtoepassingen, zoals Prometheus of Flux, die zich op alle clusters moeten bevinden.
Toepassingsontwikkelaars moeten Kubernetes-resources vaak om verschillende redenen implementeren op meerdere clusters, bijvoorbeeld:
- Het implementeren van een video die een toepassing in meerdere clusters in verschillende regio's biedt voor een weergave met lage latentie.
- Het implementeren van een winkelwagentoepassing in twee gekoppelde regio's voor klanten om te blijven winkelen tijdens een storing in één regio.
- Een batch-rekentoepassing implementeren in clusters met goedkope spot-knooppuntgroepen die beschikbaar zijn.
Het is vervelend om deze Kubernetes-resources handmatig te maken, bij te werken en bij te houden in meerdere clusters. Fleet biedt Kubernetes-resourcedoorgifte om op schaal beheer van Kubernetes-resources mogelijk te maken. Met Kubernetes Fleet kunt u Kubernetes-resources maken in het hubcluster en deze doorgeven aan geselecteerde lidclusters via aangepaste Kubernetes-resources: MemberCluster en ClusterResourcePlacement.
Kubernetes Fleet ondersteunt deze aangepaste resources op basis van een opensource-cloudoplossing waarover u meer kunt lezen in de opensource Fleet-documentatie.
Inleiding tot ClusterResourcePlacement
Een ClusterResourcePlacement object wordt gebruikt om de vlootplanner te laten weten hoe een bepaalde set clusterobjecten van het fleet hub-cluster naar lidclusters kan worden geplaatst. Naamruimteobjecten zoals Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets en PersistentVolumeClaims worden opgenomen wanneer hun naamruimte is geselecteerd.
Met ClusterResourcePlacementkunt u het volgende doen:
- Selecteer welke Kubernetes-resources binnen het clusterbereik moeten worden doorgegeven aan lidclusters.
- Geef plaatsingsbeleid op om lidclusters handmatig of automatisch te selecteren als doelclusters.
- Geef implementatiestrategieën op om eventuele updates van de geselecteerde Kubernetes-resources veilig uit te rollen naar meerdere doelclusters.
- Bekijk de voortgang van de doorgifte naar elk doelcluster.
In het volgende diagram ziet u een voorbeeld.
Resources inkapselen
ClusterResourcePlacement ondersteunt het gebruik van ConfigMap om bepaalde Kubernetes-resourcetypen te enveloppen, zodat ze kunnen worden gefaseerd op het hubcluster zonder onbedoelde neveneffecten op het hubcluster. Zie onze documentatie voor envelopobjecten voor een lijst met resourcetypen en om te begrijpen hoe deze functie werkt
Plaatsingstypen
De volgende plaatsingstypen zijn beschikbaar voor het beheren van het aantal clusters waarvoor een opgegeven Kubernetes-resource moet worden doorgegeven:
- Met PickFixed wordt de resource op naam geplaatst in een specifieke lijst met lidclusters.
- PickAll plaatst de resource op alle lidclusters of alle lidclusters die voldoen aan een criterium. Dit beleid is handig voor het plaatsen van infrastructuurworkloads, zoals clusterbewaking of rapportagetoepassingen.
- PickN is de meest flexibele plaatsingsoptie en maakt selectie van clusters mogelijk op basis van beperkingen voor affiniteit of topologiespreiding en is handig bij het spreiden van workloads over meerdere geschikte clusters om ervoor te zorgen dat beschikbaarheid gewenst is.
Type PickFixed-plaatsing
Als u een workload wilt implementeren in een bekende set lidclusters, kunt u een PickFixed plaatsingsbeleid gebruiken om de clusters op naam te selecteren.
clusterNames is de enige geldige beleidsoptie voor dit plaatsingstype.
In het volgende voorbeeld ziet u hoe u de test-deployment naamruimte implementeert op lidclusters cluster1 en 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-plaatsingstype
U kunt een PickAll plaatsingstype gebruiken om een workload te implementeren in alle lidclusters in de vloot of voor een subset van clusters die voldoen aan de criteria die u hebt ingesteld.
Wanneer u dit type plaatsing maakt, kunnen de volgende clusteraffiniteitstypen worden opgegeven:
- requiredDuringSchedulingIgnoredDuringExecution: omdat dit beleid is vereist tijdens het plannen, worden de clusters gefilterd op basis van de opgegeven criteria.
In het volgende voorbeeld ziet u hoe u een prod-deployment naamruimte en alle bijbehorende objecten implementeert in alle clusters met environment: productionhet label :
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
Type PickN-plaatsing
Het PickN plaatsingstype is de meest flexibele optie en maakt plaatsing van resources mogelijk in een configureerbaar aantal clusters op basis van affiniteiten en topologiespreidingsbeperkingen.
Wanneer u dit type plaatsing maakt, kunnen de volgende clusteraffiniteitstypen worden opgegeven:
- requiredDuringSchedulingIgnoredDuringExecution: omdat dit beleid is vereist tijdens het plannen, worden de clusters gefilterd op basis van de opgegeven criteria.
- preferredDuringSchedulingIgnoredDuringExecution: omdat dit beleid de voorkeur heeft, maar niet vereist tijdens het plannen, worden clusters gerangschikt op basis van opgegeven criteria.
U kunt zowel vereiste als voorkeuraffiniteit instellen. Vereiste affiniteiten voorkomen plaatsing in clusters die niet overeenkomen en voorkeuraffiniteit bieden volgorde van geldige clusters.
PickN met affiniteiten
Affiniteiten gebruiken met een PickN plaatsingsbeleidsfuncties die vergelijkbaar zijn met het gebruik van affiniteiten met podplanning.
In het volgende voorbeeld ziet u hoe u een workload implementeert in drie clusters. Alleen clusters met het critical-allowed: "true" label zijn geldige plaatsingsdoelen en de voorkeur wordt gegeven aan clusters met het label 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 met beperkingen voor topologiespreiding
U kunt beperkingen voor topologiespreiding gebruiken om de verdeling van de clusterplaatsingen over topologiegrenzen af te dwingen om te voldoen aan beschikbaarheidsvereisten. Gebruik deze beperkingen bijvoorbeeld om plaatsingen te splitsen tussen regio's of updateringen. U kunt ook beperkingen voor topologiespreiding configureren om planning te voorkomen als aan de beperking niet kan worden voldaan (whenUnsatisfiable: DoNotSchedule) of planning zo goed mogelijk kan worden gepland (whenUnsatisfiable: ScheduleAnyway).
In het volgende voorbeeld ziet u hoe u een bepaalde set resources verspreidt over meerdere regio's en probeert te plannen tussen lidclusters met verschillende updatedagen.
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
Zie de opensource Fleet-documentatietopologie, verspreid over beperkingen voor meer informatie.
Opties voor plaatsingsbeleid
De tabel bevat een overzicht van de beschikbare planningsbeleidsvelden voor elk type plaatsing.
| Beleidsveld | PickFixed | PickAll | PickN |
|---|---|---|---|
placementType |
✅ | ✅ | ✅ |
affinity |
❌ | ✅ | ✅ |
clusterNames |
✅ | ❌ | ❌ |
numberOfClusters |
❌ | ❌ | ✅ |
topologySpreadConstraints |
❌ | ❌ | ✅ |
Clusters selecteren op basis van labels en eigenschappen
Beschikbare labels en eigenschappen om clusters te selecteren
Wanneer u de PickN typen plaatsing gebruikt PickAll , kunt u de volgende labels en eigenschappen gebruiken als onderdeel van uw beleid.
Etiketten
De volgende labels worden automatisch toegevoegd aan alle lidclusters en kunnen worden gebruikt voor doelclusterselectie in het plaatsingsbeleid voor resources.
| Etiket | Beschrijving |
|---|---|
| fleet.azure.com/location | Azure-regio van het cluster (westus) |
| fleet.azure.com/resource-group | Azure-resourcegroep van het cluster (rg_prodapps_01) |
| fleet.azure.com/subscription-id | Azure Subscription Identifier waarin het cluster zich bevindt. Opgemaakt als UUID/GUID. |
U kunt ook aangepaste labels gebruiken die u op uw clusters toepast.
Eigenschappen
De volgende eigenschappen zijn beschikbaar voor gebruik als onderdeel van plaatsingsbeleid.
CPU- en geheugeneigenschappen worden weergegeven als Kubernetes-resource-eenheden.
Kosteneigenschappen zijn decimalen die een kosten per uur vertegenwoordigen in US Dollars voor de Azure-rekenkracht die wordt gebruikt voor knooppunten binnen het cluster. Kosten zijn gebaseerd op openbare prijzen van Azure.
| Eigenschapsnaam | Beschrijving |
|---|---|
| kubernetes-fleet.io/node-count | Beschikbare knooppunten in het lidcluster. |
| resources.kubernetes-fleet.io/total-cpu | Totaal aantal CPU-resource-eenheden van het cluster. |
| resources.kubernetes-fleet.io/allocatable-cpu | Toe te passen CPU-resource-eenheden van het cluster. |
| resources.kubernetes-fleet.io/available-cpu | Beschikbare CPU-resource-eenheden van het cluster. |
| resources.kubernetes-fleet.io/total-memory | Totale geheugenresource-eenheid van cluster. |
| resources.kubernetes-fleet.io/allocatable-memory | Alleocatable geheugenresource-eenheden van het cluster. |
| resources.kubernetes-fleet.io/available-memory | Beschikbare geheugenresource-eenheden van het cluster. |
| kubernetes.azure.com/per-cpu-core-cost | De kosten per CPU-kern van het cluster. |
| kubernetes.azure.com/per-gb-memory-cost | De kosten per GiB-geheugen van het cluster. |
Selectiekoppelingscriteria opgeven
Wanneer u clustereigenschappen in een beleidscriteria gebruikt, geeft u het volgende op:
Naam: Naam van de eigenschap, een van de eigenschappen die worden vermeld in eigenschappen in dit artikel.
Operator: Een operator die wordt gebruikt om de voorwaarde uit te drukken tussen de beperking/gewenste waarde en de waargenomen waarde op het cluster. De volgende operators worden momenteel ondersteund:
Gt(Groter dan): de waargenomen waarde van een cluster van de opgegeven eigenschap moet groter zijn dan de waarde in de voorwaarde voordat deze kan worden gekozen voor resourceplaatsing.Ge(Groter dan of gelijk aan): de waargenomen waarde van een cluster van de opgegeven eigenschap moet groter zijn dan of gelijk zijn aan de waarde in de voorwaarde voordat deze kan worden gekozen voor resourceplaatsing.Lt(Kleiner dan): de waargenomen waarde van een cluster van de opgegeven eigenschap moet kleiner zijn dan de waarde in de voorwaarde voordat deze kan worden gekozen voor resourceplaatsing.Le(Kleiner dan of gelijk aan): de waargenomen waarde van een cluster van de opgegeven eigenschap moet kleiner zijn dan of gelijk zijn aan de waarde in de voorwaarde voordat deze kan worden gekozen voor resourceplaatsing.Eq(Gelijk aan): de waargenomen waarde van een cluster van de opgegeven eigenschap moet gelijk zijn aan de waarde in de voorwaarde voordat deze kan worden gekozen voor resourceplaatsing.Ne(Niet gelijk aan): de waargenomen waarde van een cluster van de opgegeven eigenschap mag niet gelijk zijn aan de waarde in de voorwaarde voordat deze kan worden gekozen voor resourceplaatsing.
Als u de operator
Gt,Ge,Lt,Le, ,EqofNe, de lijst met waarden in de voorwaarde precies één waarde moet hebben.Waarden: Een lijst met waarden, die mogelijke waarden van de eigenschap zijn.
Fleet evalueert elk cluster op basis van de eigenschappen die zijn opgegeven in de voorwaarde. Het niet voldoen aan de voorwaarden die worden vermeld onder requiredDuringSchedulingIgnoredDuringExecution dit lidcluster wordt uitgesloten van resourceplaatsing.
Notitie
Als een lidcluster niet beschikt over de eigenschap die in de voorwaarde is uitgedrukt, mislukt de voorwaarde automatisch.
Hier volgt een voorbeeld van plaatsingsbeleid om alleen clusters met vijf of meer knooppunten te selecteren.
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"
De werking van classificatie van eigenschappen
Wanneer preferredDuringSchedulingIgnoredDuringExecution deze wordt gebruikt, rangschikt een eigenschapssorteerder alle clusters in de vloot op basis van hun waarden in oplopende of aflopende volgorde. De gewichten die worden gebruikt voor bestellen, worden berekend op basis van de opgegeven waarde.
Een eigenschapssorteerder bestaat uit:
- Naam: Naam van de clustereigenschap.
- Sorteervolgorde: Sorteervolgorde kan een
AscendingofDescending. WanneerAscendingvolgorde wordt gebruikt, hebben lidclusters met lagere waargenomen waarden de voorkeur. WanneerDescendingvolgorde wordt gebruikt, hebben lidclusters met een hogere waargenomen waarde de voorkeur.
Aflopende volgorde
Voor aflopende sorteervolgorde wordt het proportionele gewicht berekend met behulp van de formule:
((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight
Stel dat u clusters wilt rangschikken op basis van de eigenschap van de beschikbare CPU-capaciteit in aflopende volgorde en dat u een vloot van drie clusters hebt met de volgende beschikbare CPU:
| Cluster | Beschikbare CPU-capaciteit |
|---|---|
cluster-a |
100 |
cluster-b |
20 |
cluster-c |
10 |
In dit geval berekent de sorteerfunctie de volgende gewichten:
| Cluster | Beschikbare CPU-capaciteit | Berekening | Gewicht |
|---|---|---|---|
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% |
Oplopende volgorde
Voor oplopend sorteren wordt het proportionele gewicht berekend met behulp van de formule:
(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight
Stel dat u clusters wilt rangschikken op basis van hun kosten per CPU-kern in oplopende volgorde en dat u een vloot van drie clusters hebt met de volgende CPU-kernkosten:
| Cluster | Kosten per CPU-kern |
|---|---|
cluster-a |
1 |
cluster-b |
0,2 |
cluster-c |
0,1 |
In dit geval berekent de sorteerfunctie de volgende gewichten:
| Cluster | Kosten per CPU-kern | Berekening | Gewicht |
|---|---|---|---|
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% |
Toleranties gebruiken
ClusterResourcePlacement objecten ondersteunen de specificatie van toleranties, die van toepassing zijn op het ClusterResourcePlacement object. Elk tolerantieobject bestaat uit de volgende velden:
key: De sleutel van de tolerantie.value: De waarde van de tolerantie.effect: Het effect van de tolerantie, zoalsNoSchedule.operator: De operator van de tolerantie, zoalsExistsofEqual.
Elke tolerantie wordt gebruikt voor het tolereren van een of meer specifieke taint die op de ClusterResourcePlacement. Zodra alle taints op een MemberCluster worden getolereerd, kan de scheduler vervolgens resources doorgeven aan het cluster. U kunt toleranties niet bijwerken of verwijderen uit een ClusterResourcePlacement object dat is gemaakt.
Zie de opensource Fleet-documentatie over toleranties voor meer informatie.
Implementatiestrategie configureren
Fleet maakt gebruik van een strategie voor rolling updates om te bepalen hoe updates worden geïmplementeerd in clusters.
In het volgende voorbeeld implementeert de fleet scheduler updates voor elk cluster sequentieel, waarbij ten minste unavailablePeriodSeconds tussen clusters wordt gewacht. De implementatiestatus wordt als geslaagd beschouwd als alle resources correct zijn toegepast op het cluster. De statuscontrole van de implementatie wordt niet trapsgewijs gecontroleerd op onderliggende resources, dus er wordt niet bevestigd dat pods die door een implementatie zijn gemaakt, gereed zijn.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
...
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
unavailablePeriodSeconds: 60
Zie de opensource Fleet-documentatie over de implementatiestrategie voor meer informatie.
Plaatsingsstatus bepalen
De Fleet scheduler werkt details en status bij over plaatsingsbeslissingen op het ClusterResourcePlacement object. De uitvoer bevat de volgende informatie:
- De voorwaarden die momenteel van toepassing zijn op de plaatsing, waaronder als de plaatsing is voltooid.
- Een sectie over de plaatsingsstatus voor elk lidcluster, waarin de implementatiestatus voor dat cluster wordt weergegeven.
In het volgende voorbeeld ziet u een ClusterResourcePlacement waarin de test naamruimte en de test-1 ConfigMap zijn geïmplementeerd in twee lidclusters met behulp van PickN. De plaatsing is voltooid en de resources zijn in de aks-member-1 en aks-member-2 clusters geplaatst.
U kunt deze informatie weergeven met behulp van de kubectl describe crp <name> opdracht.
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
Triggers voor plaatsingswijziging
De Fleet scheduler geeft prioriteit aan de stabiliteit van bestaande workloadplaatsingen. Deze prioriteitsaanduiding kan het aantal wijzigingen beperken waardoor een workload wordt verwijderd en opnieuw wordt gepland. In de volgende scenario's kunnen plaatsingswijzigingen worden geactiveerd:
- Wijzigingen in het plaatsingsbeleid in het
ClusterResourcePlacementobject kunnen het verwijderen en opnieuw plannen van een workload activeren.- Uitschalen van bewerkingen (verhogen
numberOfClusterszonder andere wijzigingen) plaatst workloads alleen op nieuwe clusters en heeft geen invloed op bestaande plaatsingen.
- Uitschalen van bewerkingen (verhogen
- Clusterwijzigingen, waaronder:
- Een nieuw cluster dat in aanmerking komt, kan plaatsing activeren als het nieuwe cluster voldoet aan het plaatsingsbeleid, bijvoorbeeld een
PickAllbeleid. - Een cluster met plaatsing wordt verwijderd uit de vloot. Afhankelijk van het beleid probeert de planner alle betrokken workloads op resterende clusters te plaatsen zonder dat dit van invloed is op bestaande plaatsingen.
- Een nieuw cluster dat in aanmerking komt, kan plaatsing activeren als het nieuwe cluster voldoet aan het plaatsingsbeleid, bijvoorbeeld een
Wijzigingen in alleen resources (het bijwerken van de resources of het bijwerken van het ResourceSelector ClusterResourcePlacement object) worden geleidelijk geïmplementeerd in bestaande plaatsingen, maar activeren geen herplanning van de workload.
Volgende stappen
Azure Kubernetes Service