Introductie van Azure Kubernetes Fleet Manager intelligente plaatsing van resources

Van toepassing op ✔️ Fleet Manager met hubcluster

Het beheren van Kubernetes-resources in meerdere clusters biedt aanzienlijke uitdagingen voor zowel platformbeheerders als toepassingsontwikkelaars. Naarmate organisaties hun Kubernetes-infrastructuur buiten één cluster schalen, hebben ze vaak te maken met complexe problemen met betrekking tot resourcedistributie, consistentie en handmatige beheeroverhead. De traditionele benadering van het onafhankelijk beheren van elk cluster creëert operationele silo's die steeds moeilijker te onderhouden worden naarmate de vloot groter wordt.

Platformbeheerders moeten Kubernetes-resources vaak om verschillende redenen implementeren op meerdere clusters, waaronder:

• 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:

• Implementatie van een videoverstrekkende applicatie in meerdere clusters in verschillende regio's voor een kijkervaring 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 tijdrovend en mogelijk foutgevoelig om Kubernetes-resources handmatig te maken, bij te werken en bij te houden in meerdere clusters.

In dit artikel verkennen we hoe u de intelligente resourceplaatsingscapaciteit van Fleet Manager kunt gebruiken om de distributie van op clusters en naamruimtes afgebakende Kubernetes-resources te beheren over lidclusters in een vloot.

De capaciteiten voor resourceplaatsing van de Fleet Manager zijn gebaseerd op het KubeFleet CNCF-project.

Overzicht van het resourceplaatsingsproces

Volg deze stappen om gebruik te maken van de intelligente plaatsing van resources van Fleet Manager:

1. Resources voorbereiden op het hubcluster: gebruik Continuous Deployment, GitOps of een vergelijkbare methode om de manifesten voor resourcedistributies toe te passen op het Fleet Manager-hubcluster.
2. Een plaatsing voor een resource maken: maak een plaatsingsmanifest dat de resource selecteert en een beleid definieert om te bepalen welke lidclusters de resource ontvangen.
3. Plaatsing van resources toepassen op het hubcluster: pas het plaatsingsmanifest toe op het hubcluster om de resource te distribueren.
4. Fleet Manager plant middelen in: Fleet Manager bekijkt de plaatsing van de middelen en het geselecteerde bereik en verdeelt de middelen.
5. Bekijk de distributie via resourceplaatsing: voer een query uit op de plaatsing van resources in het hubcluster om de status van de resource te controleren terwijl deze wordt uitgerold.

Fleet Manager heeft een Azure portalervaring voor resourceplaatsing die een meer visuele weergave van de implementatie biedt.

Resourceplaatsingscomponenten

Een plaatsing van resources, ongeacht het bereik (cluster of naamruimte), bestaat uit de volgende onderdelen:

• Resourceselectors: selecteer de resources die u via resourceSelectors wilt opnemen.
• Plaatsingsbeleid: definieer hoe u clusters kiest met placementType behulp van een van de PickAll, PickFixedof PickN typen.
• Implementatiestrategie: bepalen hoe resources worden geïmplementeerd in geselecteerde clusters door een optionele optie op te strategyslaan.

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

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Hulpbronnenselectors

Selecteer resources met behulp van een of meer resourceSelectors binnen een plaatsing. Elke hulpbronselector kan het volgende opgeven:

• Groep, versie, soort (GVK): het type Kubernetes-resource dat u wilt selecteren.
• Naam: De naam van een specifieke resource.
• Labelkiezers: Labels die overeenkomen met meerdere resources.

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

Plaatsingsbeleid

De resourceplaatsing van Fleet Manager ondersteunt de volgende typen plaatsingsbeleid voor het bepalen van de manier waarop clusters worden geselecteerd:

• PickFixed plaatst resources op lidclusters met behulp van hun clusternamen.
• PickAll plaatst resources 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. Hiermee kunt u clusters selecteren op basis van beperkingen voor affiniteit of topologiespreiding. Gebruik dit beleid wanneer u workloads verspreidt over meerdere vergelijkbare clusters om ervoor te zorgen dat de beschikbaarheid behouden blijft.

Plaatsingstype PickFixed

Gebruik PickFixed deze optie om de clusters op naam te selecteren. Geef namen op in de clusterNames matrix.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-fixed
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-deployment
      version: v1
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

PickAll-plaatsingstype

Gebruik PickAll dit om resources te distribueren over alle lidclusters of alle clusters die voldoen aan een criterium dat u opgeeft.

Wanneer u dit type plaatsing maakt, geeft u de volgende clusteraffiniteitstypen op:

• requiredDuringSchedulingIgnoredDuringExecution: omdat dit beleid is vereist tijdens het plannen, worden de clusters gefilterd op basis van de opgegeven criteria.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickall
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production

PickN-plaatstype

Gebruik PickN dit om resources te distribueren naar een configureerbaar aantal clusters op basis van zowel affiniteiten als limieten voor topologiespreiding.

Wanneer u dit type plaatsing maakt, geeft u de volgende clusteraffiniteitstypen op:

• 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. Voorkeursaffiniteiten bieden rangschikking van overeenkomende clusters.

PickN met affiniteiten

Het gebruik van affiniteiten met een PickN plaatsingsbeleid werkt op dezelfde manier als het gebruik van affiniteiten bij de planning van pods op één Kubernetes-cluster.

In het volgende voorbeeld ziet u hoe u een resource 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-critical-preferences
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-critical-preferences
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  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

Gebruik topologiespreidingsbeperkingen om plaatsingen binnen topologiegrenzen af te dwingen om te voldoen aan beschikbaarheidsvereisten.

U kunt het gedrag van beperkingen voor topologiespreiding configureren met behulp van de whenUnsatisfiable eigenschap:

• DoNotSchedule: als er niet aan de beperking kan worden voldaan, mislukt de plaatsingsaanvraag.
• ScheduleAnyway: als niet aan de voorwaarde kan worden voldaan, worden resources toch geplaatst.

In het volgende voorbeeld ziet u hoe u resources over meerdere Azure regio's kunt verdelen en probeert te plannen tussen lidclusters met verschillende updatedagen met behulp van een aangepast labelupdateDay.

Wanneer de Azure regiospreiding niet kan worden bereikt, mislukt de plaatsing. Als niet aan de updateDay beperking wordt voldaan, gebeurt de plaatsing nog steeds.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-locations-updates
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-locations-updates
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Zie de KubeFleet-documentatie over topologiespreidingsbeperkingen voor meer informatie.

Clusters selecteren met behulp van labels en eigenschappen

Fleet Manager intelligente plaatsing van resources biedt een reeks krachtige criteria die u kunt gebruiken om te bepalen hoe u clusters selecteert bij het gebruik van de plaatsingstypen PickN en PickAll. In deze sectie leert u hoe u deze opties kunt gebruiken om beleidsregels te bouwen die aan uw behoeften voldoen.

Opties voor plaatsingsbeleid

In de volgende tabel ziet u de beschikbare planningsbeleidsvelden voor elk plaatsingstype.

Ledenclusterlabels

U kunt de MemberCluster resource in het hubcluster labelen zoals elke Kubernetes-resource.

Daarnaast voegt Fleet Manager automatisch de volgende alleen-lezen-labels toe aan alle lidclusters.

Clustereigenschappen

Gebruik de volgende eigenschappen als onderdeel van plaatsingsbeleid.

• Kubernetes-resource-eenheden vertegenwoordigen CPU- en geheugeneigenschappen. Zie Resource-eenheden in Kubernetes voor meer informatie.

• Kosteneigenschappen zijn decimalen die een kosten per uur in Amerikaanse dollars vertegenwoordigen voor de Azure rekenkracht die knooppunten binnen het cluster gebruiken. Kosten zijn gebaseerd op Azure openbare prijzen.

Selectiekoppelingscriteria

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 de voorwaarde uitdrukt tussen de beperking of gewenste waarde en de waargenomen waarde op het cluster. De volgende operators worden momenteel ondersteund:

  • Gt (Groter dan): de waargenomen waarde van een bepaalde eigenschap van een cluster moet groter zijn dan de waarde in de voorwaarde voordat deze kan worden gekozen voor de plaatsing van middelen.
  • Ge (Groter dan of gelijk aan): de waargenomen waarde van een cluster voor de opgegeven eigenschap moet groter dan of gelijk aan de waarde in de voorwaarde zijn voordat deze kan worden gekozen voor resource-allocatie.
  • Lt (Kleiner dan): de waargenomen waarde van de gegeven eigenschap van een cluster moet kleiner zijn dan de waarde in de voorwaarde voordat deze kan worden gekozen voor de plaatsing van resources.
  • Le (Kleiner dan of gelijk aan): De waargenomen waarde van de gespecificeerde eigenschap van een cluster moet kleiner zijn dan of gelijk zijn aan de waarde in de voorwaarde, voordat deze voor de plaatsing van middelen kan worden geselecteerd.
  • Eq (Gelijk aan): de waargenomen waarde van een cluster van de gegeven eigenschap moet gelijk zijn aan de waarde in de voorwaarde voordat deze kan worden gekozen voor resource-toewijzing.
  • 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 plaatsing van resources.

  Als u de operator Gt, Ge, Lt, Le, Eq of Ne gebruikt, moet de lijst met waarden in de voorwaarde precies één waarde hebben.

• Waarden: Een lijst met waarden, die mogelijke waarden van de eigenschap zijn.

Fleet evalueert elk cluster op basis van de eigenschappen die u in de voorwaarde opgeeft. Als een cluster niet voldoet aan de voorwaarden die worden vermeld onder requiredDuringSchedulingIgnoredDuringExecution, sluit Fleet het cluster uit van de plaatsing van resources.

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-pickall-five-nodes
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-five-nodes
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

De werking van rangschikking van eigenschappen

Wanneer u gebruikt preferredDuringSchedulingIgnoredDuringExecution, 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 waarde die u opgeeft.

Een eigenschapssorteerder bestaat uit:

• Naam: Naam van de clustereigenschap.
• Sorteervolgorde: De sorteervolgorde kan Ascending of Descending zijn. Wanneer u volgorde gebruikt Ascending , hebben lidclusters met lagere waargenomen waarden de voorkeur. Wanneer u volgorde gebruikt Descending , hebben lidclusters met een hogere waargenomen waarde de voorkeur.

Zie de KubeFleet-documentatie over planning op basis van eigenschappen voor meer informatie.

Implementatiestrategie configureren

Fleet Manager-resourceplaatsing gebruikt een standaardstrategie RollingUpdate om te bepalen hoe resources naar lidclusters worden gedistribueerd.

In het volgende voorbeeld wordt de plaatsing opeenvolgend naar elk lidcluster uitgerold, met een wachttijd van ten minste unavailablePeriodSeconds tussen de clusters.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pick-all-rolling
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

De implementatiestatus wordt als geslaagd beschouwd als alle resources correct worden toegepast op het cluster. Deze status geeft de status van onderliggende resources niet door en bevestigt dus niet dat pods die door een Deployment op een membercluster zijn gemaakt, gereed zijn.

Zie de documentatie over implementatiestrategieën voor meer informatie.

Toleranties gebruiken

U kunt memberclusters net als knooppunten in een cluster van een taint voorzien.

Resource-toewijzingen ondersteunen het gebruik van toleranties, waarbij elke tolerantie bestaat uit de volgende velden:

• key: De sleutel van de tolerantie.
• value: De waarde van de tolerantie.
• effect: Het effect van de tolerantie, zoals NoSchedule.
• operator: De operator van de tolerantie, zoals Exists of Equal.

Elke tolerantie wordt gebruikt om een of meer specifieke tainten die op een MemberCluster zijn toegepast, te verdragen. Zodra alle taints zijn getolereerd, kan Fleet Manager resources verdelen naar het lidcluster.

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: test-ns
spec:
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-ns
      version: v1
  revisionHistoryLimit: 10
  strategy:
    type: RollingUpdate

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Zie de documentatie over toleranties voor meer informatie.

Omhulselbronnen gebruiken

Het Fleet Manager-hubcluster is ook een Kubernetes-cluster. U past eerst een resource toe die u wilt distribueren naar het hubcluster. Deze aanpak kan leiden tot:

1. Onbedoelde bijwerkingen: ValidatingWebhookConfigurations, MutatingWebhookConfigurations of Admission Controllers worden actief op het hubcluster en kunnen mogelijk hubclusterbewerkingen onderscheppen en beïnvloeden.

2. Beveiligingsrisico's: RBAC-resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) die bedoeld zijn voor memberclusters kunnen machtigingen op het hubcluster verlenen of beperken.

3. Resourcebeperkingen: ResourceQuotas, FlowSchema of LimitRanges die zijn gedefinieerd voor lidclusters, worden van kracht op het hubcluster.

Om onnodige bijwerkingen te voorkomen, biedt Fleet Manager aangepaste envelopresources (ClusterResourceEnvelope en ResourceEnvelope) om objecten te verpakken en deze potentiële problemen te voorkomen.

U past de envelopresource toe op het hubcluster, maar de resources die deze bevat, worden geëxtraheerd en toegepast wanneer ze lidclusters bereiken.

Zie de documentatie over envelopobjecten voor meer informatie.

Plaatsingsstatus bepalen

Fleet Manager-resourceplaatsing biedt twee manieren om de status weer te geven, afhankelijk van het toegangsniveau en de vereisten van uw hubcluster:

kubectl describe resourceplacement place-cmap-1

kubectl describe clusterresourceplacement 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

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-with-status-reporting
spec:
  statusReportingScope: NamespaceAccessible
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll

kubectl describe clusterresourceplacementstatuses.v1beta1.placement.kubernetes-fleet.io crp-with-status-reporting -n my-app

Triggers voor plaatsingswijziging

De Fleet Manager-scheduler geeft prioriteit aan de stabiliteit van bestaande resourceplaatsingen. Deze prioriteit beperkt het aantal wijzigingen waarbij een resource wordt verwijderd en opnieuw wordt gepland.

In de volgende scenario's kunnen plaatsingswijzigingen worden geactiveerd:

• Wijzigingen in het plaatsingsbeleid voor resources (ClusterResourcePlacement of ResourcePlacement) kunnen verwijdering en herplanning van een resource activeren.
  • Uitschaalbewerkingen (waarbij alleen numberOfClusters wordt verhoogd, zonder andere wijzigingen) plaatsen workloads alleen op nieuwe clusters en hebben geen invloed op bestaande plaatsingen.
• Wijzigingen in lidclusters, waaronder:
  • Een nieuw lidcluster dat in aanmerking komt en voldoet aan het beleid voor plaatsing, bijvoorbeeld een beleid van het type PickAll.
  • Het verwijderen van een lidcluster uit de vloot. Afhankelijk van het beleid probeert de planner alle betrokken resources op resterende clusters te plaatsen zonder dat dit van invloed is op bestaande plaatsingen.

Het bijwerken van de geselecteerde resources (bijvoorbeeld het wijzigen van een Deployment) of het bijwerken van de resourceSelector in een resourceplaatsing zorgt ervoor dat Fleet Manager bestaande plaatsingen geleidelijk uitrolt, maar geen herplanning van de resource activeert (dat wil zeggen: het wijzigen van de gekozen clusters).

Samenwerken met ResourcePlacement en ClusterResourcePlacement

Hoewel ClusterResourcePlacement ervan wordt uitgegaan dat naamruimten toepassingsgrenzen vertegenwoordigen, zijn praktijkgebruikspatronen vaak complexer. Organisaties gebruiken vaak naamruimten als teamgrenzen in plaats van toepassingsgrenzen, wat leidt tot verschillende uitdagingen die ResourcePlacement rechtstreeks worden aangepakt:

Naamruimten voor meerdere toepassingen: In veel organisaties bevat één naamruimte meerdere onafhankelijke toepassingen die eigendom zijn van hetzelfde team. Deze toepassingen kunnen het volgende hebben:

• Verschillende levenscyclusvereisten (de ene toepassing heeft mogelijk frequente updates nodig terwijl een andere toepassing stabiel blijft).
• Verschillende behoeften voor clusterplaatsing (ontwikkeling versus productietoepassingen).
• Onafhankelijke schaal- en resourcevereisten.
• Afzonderlijke nalevings- of governancevereisten.

Afzonderlijke planningsbeslissingen: voor veel workloads, met name AI/ML-taken, zijn afzonderlijke planningsbeslissingen vereist:

• AI-taken: Machine learning-workloads bestaan vaak uit kortstondige, resource-intensieve taken die moeten worden gepland op basis van beschikbaarheid van clusterresources, GPU-beschikbaarheid of gegevenslocatie.
• Batch workloads: Verschillende batchtaken binnen dezelfde naamruimte kunnen op basis van rekenvereisten verschillende clustertypen gebruiken.

Volledig beheer van toepassingsteam: ResourcePlacement biedt toepassingsteams directe controle over hun resourceplaatsing zonder tussenkomst van het platformteam:

• Zelfbedieningsoperaties: Teams kunnen hun eigen strategieën voor de toewijzing van middelen beheren.
• Onafhankelijke implementatiecycli: verschillende toepassingen binnen een naamruimte kunnen onafhankelijke implementatieschema's hebben.
• Granulaire overschrijfmogelijkheden: Teams kunnen resourceconfiguraties per cluster aanpassen zonder invloed te hebben op andere toepassingen in de namespace.

Deze gedetailleerde benadering zorgt ervoor dat ResourcePlacement deze zich kan aanpassen aan diverse organisatiestructuren en workloadpatronen, terwijl de eenvoud en kracht van het Fleet-planningsframework behouden blijft.

Belangrijkste verschillen tussen ResourcePlacement en ClusterResourcePlacement

In de volgende tabel worden de belangrijkste verschillen tussen ResourcePlacement en ClusterResourcePlacement:

Beide ResourcePlacement en ClusterResourcePlacement delen dezelfde kernmogelijkheden voor alle andere aspecten die niet worden vermeld in de verschillentabel.

Voorbeeldscenario met ResourcePlacement en ClusterResourcePlacement

ResourcePlacement werkt met ClusterResourcePlacement (CRP) om een volledige multiclusterresourcebeheeroplossing te bieden. Het begrijpen van deze relatie is van cruciaal belang voor effectief vlootbeheer.

Typische workflow:

1. Platformbeheerders: gebruiken ClusterResourcePlacement om naamruimten in de hele vloot te implementeren.
2. Toepassingsteams: gebruiken ResourcePlacement om specifieke resources binnen die gevestigde naamruimten te beheren.

In de volgende voorbeelden ziet u hoe u CRP en RP coördineert.

Platformbeheerder: Maak de naamruimte met behulp van ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: app-namespace-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly # only namespace itself is placed, no resources within the namespace
  policy:
    placementType: PickAll # If placement type is not PickAll, the application teams needs to know what are the clusters they can place their applications.

Toepassingsteam: Specifieke resources binnen de naamruimte beheren met behulp van ResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Aanbevolen procedures voor ResourcePlacement en ClusterResourcePlacement

Wanneer u ResourcePlacement met ClusterResourcePlacement gebruikt, volgt u deze aanbevolen werkwijzen:

• Stel eerst naamruimten in: implementeer altijd naamruimten via CRP voordat u objecten maakt ResourcePlacement .
• Afhankelijkheden bewaken: Gebruik Fleet-bewaking om ervoor te zorgen dat CSP's op naamruimteniveau in orde zijn voordat afhankelijke RPs worden geïmplementeerd.
• Beleid coördineren: CRP- en RP-plaatsingsbeleid uitlijnen om conflicten te voorkomen. Als CRP bijvoorbeeld de naamruimte op clusters A, B en C plaatst, kan RP zich richten op een subset van deze clusters.
• Teamgrenzen: CRP gebruiken voor door het platform beheerde resources (naamruimten, RBAC) en RP voor door toepassingen beheerde resources (app-configuraties, geheimen).

Deze gecoördineerde aanpak zorgt ervoor dat ResourcePlacement de flexibiliteit biedt die teams nodig hebben, terwijl de basisinfrastructuur behouden blijft, beheerd door platformoperators.

Resourceselectie, plaatsing en implementatie

ResourcePlacement gebruikt dezelfde plaatsingspatronen als ClusterResourcePlacement:

• Plaatsingsbeleid: PickAll, PickFixeden PickN beleidsregels werken identiek voor beide API's.
• Implementatiestrategie: bepalen hoe updates worden doorgegeven in clusters met dezelfde rolling updatemechanismen.
• Status en waarneembaarheid: de voortgang van de implementatie bewaken met behulp van kubectl describe resourceplacement <name> -n <namespace>.
• Geavanceerde functies: Gebruik toleranties, resourceoverschrijvingen, beperkingen voor topologiespreiding en affiniteitsregels.

Het belangrijkste verschil is in het bereik van resourceselectie . Hoewel ClusterResourcePlacement u doorgaans volledige naamruimten en de inhoud ervan selecteert, ResourcePlacement beschikt u over verfijnde controle over afzonderlijke resources met een naamruimtebereik.

:::zone-end

Volgende stappen 

• Gebruik resourceplaatsing in Fleet Manager om workloads over meerdere clusters uit te rollen.
• ResourcePlacement gebruiken om resources met naamruimtebereik te implementeren.
• Intelligente plaatsing van Kubernetes-resources tussen clusters op basis van eigenschappen van lidclusters.
• Uitzetting en verstoring voor plaatsing van resources beheren.
• Een uitrolstrategie definiëren voor de plaatsing van resources.
• Veelgestelde vragen over de plaatsing van Fleet Manager-resources.