Dela via

Kubernetes-resursspridning från hubbkluster till medlemskluster

  • Artikel

I den här artikeln beskrivs begreppet Kubernetes-resursspridning från hubbkluster till medlemskluster med Azure Kubernetes Fleet Manager (Fleet).

Plattformsadministratörer behöver ofta distribuera Kubernetes-resurser till flera kluster av olika skäl, till exempel:

  • Hantera åtkomstkontroll med hjälp av roller och rollbindningar i flera kluster.
  • Köra infrastrukturprogram, till exempel Prometheus eller Flux, som måste finnas i alla kluster.

Programutvecklare behöver ofta distribuera Kubernetes-resurser till flera kluster av olika skäl, till exempel:

  • Distribuera ett videotjänstprogram till flera kluster i olika regioner för en låg svarstidsvisning.
  • Distribuera ett kundvagnsprogram till två parkopplade regioner så att kunderna kan fortsätta att handla under ett avbrott i en enda region.
  • Distribuera ett batchberäkningsprogram till kluster med billiga skalningsuppsättningsnodpooler tillgängliga.

Det är tråkigt att skapa, uppdatera och spåra dessa Kubernetes-resurser i flera kluster manuellt. Fleet tillhandahåller Kubernetes-resursspridning för att möjliggöra skalningsbaserad hantering av Kubernetes-resurser. Med Fleet kan du skapa Kubernetes-resurser i hubbklustret och sprida dem till valda medlemskluster via Kubernetes Anpassade resurser: MemberCluster och ClusterResourcePlacement. Fleet stöder dessa anpassade resurser baserat på en molnbaserad lösning med öppen källkod med flera kluster. Mer information finns i dokumentationen för den överordnade flottan.

Viktigt!

Förhandsversionsfunktionerna i Azure Kubernetes Fleet Manager är tillgängliga via självbetjäning och opt-in. Förhandsversioner tillhandahålls "som är" och "som tillgängliga", och de undantas från serviceavtalen och den begränsade garantin. Förhandsversioner av Azure Kubernetes Fleet Manager omfattas delvis av kundsupport på bästa sätt. Därför är dessa funktioner inte avsedda för produktionsanvändning.

Arbetsflöde för resursspridning

Diagram som visar hur Kubernetes-resursen sprids till medlemskluster.

Vad är en MemberCluster?

När ett kluster ansluter till en flotta skapas en motsvarande MemberCluster anpassad resurs i hubbklustret. Du kan använda den här anpassade resursen för att välja målkluster i resursspridning.

Följande etiketter kan användas för val av målkluster i resursspridning och läggs automatiskt till i alla medlemskluster:

  • fleet.azure.com/location
  • fleet.azure.com/resource-group
  • fleet.azure.com/subscription-id

Mer information finns i API-referensen för MemberCluster.

Vad är en ClusterResourcePlacement?

Ett ClusterResourcePlacement objekt används för att berätta för Fleet Scheduler hur en viss uppsättning klusteromfattningsobjekt ska placeras från hubbklustret i medlemskluster. Namnområdesomfångsobjekt som Distributioner, StatefulSets, DaemonSets, ConfigMaps, Secrets och PersistentVolumeClaims inkluderas när deras innehållande namnområde väljs.

Med ClusterResourcePlacementkan du:

  • Välj vilka Kubernetes-resurser med klusteromfattning som ska spridas till medlemskluster.
  • Ange placeringsprinciper för att manuellt eller automatiskt välja en delmängd eller alla medlemskluster som målkluster.
  • Ange distributionsstrategier för att på ett säkert sätt distribuera alla uppdateringar av de valda Kubernetes-resurserna till flera målkluster.
  • Visa spridningsförloppet mot varje målkluster.

Objektet ClusterResourcePlacement stöder användning av ConfigMap för att omsluta objektet så att det kan spridas till medlemskluster utan oavsiktliga biverkningar. Urvalsmetoderna omfattar:

  • Grupp, version och typ: Välj och placera alla resurser av den angivna typen.
  • Grupp, version, typ och namn: Välj och placera en viss resurs av en viss typ.
  • Grupp, version, typ och etiketter: Välj och placera alla resurser av en viss typ som matchar de angivna etiketterna.

Mer information finns i API-referensenClusterResourcePlacement.

När du skapar ClusterResourcePlacementkan du ange följande tillhörighetstyper:

  • requiredDuringSchedulingIgnoredDuringExecution: Eftersom den här tillhörigheten är av den typ som krävs under schemaläggningen filtreras klustren baserat på deras egenskaper.
  • preferredDuringSchedulingIgnoredDuringExecution: Eftersom den här tillhörigheten bara är av önskad typ, men inte krävs under schemaläggningen, ger den prioriterad rangordning till kluster baserat på egenskaper som angetts av dig, till exempel kostnads- eller resurstillgänglighet.

Flera placeringstyper är tillgängliga för att styra antalet kluster som Kubernetes-resursen måste spridas till:

  • PickAll placerar resurserna i alla tillgängliga medlemskluster. Den här principen är användbar för att placera infrastrukturarbetsbelastningar, till exempel klusterövervakning eller rapporteringsprogram.
  • PickFixed placerar resurserna i en specifik lista över medlemskluster efter namn.
  • PickN är det mest flexibla placeringsalternativet och möjliggör val av kluster baserat på tillhörighets- eller topologispridningsbegränsningar och är användbart när du sprider arbetsbelastningar över flera lämpliga kluster för att säkerställa att tillgänglighet önskas.

PickAll placeringsprincip

Du kan använda en PickAll placeringsprincip för att distribuera en arbetsbelastning i alla medlemskluster i flottan (om du vill matcha en uppsättning kriterier).

I följande exempel visas hur du distribuerar ett prod-deployment namnområde och alla dess objekt i alla kluster som är märkta med environment: production:

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

Den här enkla principen tar prod-deployment namnområdet och alla resurser som finns i den och distribuerar den till alla medlemskluster i flottan med den angivna environment etiketten. Om alla kluster önskas kan du ta bort affinity termen helt.

PickFixed placeringsprincip

Om du vill distribuera en arbetsbelastning till en känd uppsättning medlemskluster kan du använda en PickFixed placeringsprincip för att välja klustren efter namn.

I följande exempel visas hur du distribuerar test-deployment namnområdet till medlemskluster cluster1 och cluster2:

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

PickN placeringsprincip

Placeringsprincipen PickN är det mest flexibla alternativet och möjliggör placering av resurser i ett konfigurerbart antal kluster baserat på både tillhörighet och begränsningar för topologispridning.

PickN med tillhörighet

Att använda tillhörighet med en PickN placeringsprincip fungerar på samma sätt som att använda tillhörighet med poddschemaläggning. Du kan ange både obligatoriska och önskade tillhörigheter. Obligatoriska tillhörigheter förhindrar placering till kluster som inte matchar de angivna tillhörigheterna, och önskade tillhörigheter gör det möjligt att beställa uppsättningen giltiga kluster när ett placeringsbeslut fattas.

I följande exempel visas hur du distribuerar en arbetsbelastning till tre kluster. Endast kluster med critical-allowed: "true" etiketten är giltiga placeringsmål och inställningar ges till kluster med etiketten critical-level: 1:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
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 med begränsningar för topologispridning

Du kan använda begränsningar för topologispridning för att tvinga klustrets placeringar över topologigränserna att uppfylla tillgänglighetskraven, till exempel genom att dela upp placeringar mellan regioner eller uppdateringsringar. Du kan också konfigurera begränsningar för topologispridning för att förhindra schemaläggning om villkoret inte kan uppfyllas (whenUnsatisfiable: DoNotSchedule) eller schemaläggas så bra som möjligt (whenUnsatisfiable: ScheduleAnyway).

I följande exempel visas hur du sprider ut en viss uppsättning resurser över flera regioner och försöker schemalägga mellan medlemskluster med olika uppdateringsdagar:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Mer information finns i dokumentationen om uppströms topologispridningsbegränsningar i Fleet.

Uppdateringsstrategi

Fleet använder en löpande uppdateringsstrategi för att styra hur uppdateringar distribueras över flera klusterplaceringar.

I följande exempel visas hur du konfigurerar en löpande uppdateringsstrategi med hjälp av standardinställningarna:

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

Schemaläggaren distribuerar uppdateringar till varje kluster sekventiellt och väntar minst unavailablePeriodSeconds mellan kluster. Distributionsstatusen anses vara lyckad om alla resurser har tillämpats korrekt på klustret. Distributionsstatuskontrollen överlappar inte underordnade resurser, till exempel bekräftar den inte att poddar som skapats av en distribution blir klara.

Mer information finns i dokumentationen om den överordnade distributionsstrategin För flottan.

Placeringsstatus

Fleet Scheduler uppdaterar information och status för placeringsbeslut på ClusterResourcePlacement objektet. Du kan visa den här informationen med hjälp av kubectl describe crp <name> kommandot . Utdata innehåller följande information:

  • De villkor som för närvarande gäller för placeringen, bland annat om placeringen har slutförts.
  • Ett avsnitt om placeringsstatus för varje medlemskluster som visar status för distributionen till klustret.

I följande exempel visas en ClusterResourcePlacement som distribuerade test namnområdet och test-1 ConfigMap till två medlemskluster med hjälp av PickN. Placeringen slutfördes och resurserna placerades i klustren aks-member-1 och aks-member-2 .

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1beta1
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

Placeringsändringar

Fleet Scheduler prioriterar stabiliteten i befintliga arbetsbelastningsplaceringar. Den här prioriteringen kan begränsa antalet ändringar som gör att en arbetsbelastning tas bort och schemaläggs om. Följande scenarier kan utlösa placeringsändringar:

  • Ändringar i placeringsprincipen i ClusterResourcePlacement objektet kan utlösa borttagning och omplanering av en arbetsbelastning.
    • Skala ut åtgärder (öka numberOfClusters utan andra ändringar) placera endast arbetsbelastningar på nya kluster och påverkar inte befintliga placeringar.
  • Klusterändringar, inklusive:
    • Ett nytt kluster som blir berättigat kan utlösa placering om det uppfyller placeringsprincipen, till exempel en PickAll princip.
    • Ett kluster med en placering tas bort från flottan försöker ersätta alla berörda arbetsbelastningar utan att påverka deras andra placeringar.

Ändringar som endast gäller resurser (uppdaterar resurserna eller uppdaterar ResourceSelector i ClusterResourcePlacement -objektet) distribueras gradvis i befintliga placeringar, men utlöser inte schemaläggning av arbetsbelastningen.

Toleranser

ClusterResourcePlacement objekt stöder specifikationen av toleranser, som gäller för ClusterResourcePlacement objektet. Varje toleransobjekt består av följande fält:

  • key: Tolerationens nyckel.
  • value: Värdet för toleransen.
  • effect: Effekten av toleransen, till exempel NoSchedule.
  • operator: Operatorn för toleransen, till exempel Exists eller Equal.

Varje tolerans används för att tolerera en eller flera specifika taints som tillämpas på ClusterResourcePlacement. När alla taints i en MemberCluster tolereras kan schemaläggaren sedan sprida resurser till klustret. Du kan inte uppdatera eller ta bort toleranser från ett ClusterResourcePlacement objekt när det har skapats.

Mer information finns i dokumentationen för den överordnade flottan.

Få åtkomst till Kubernetes-API:et för resursklustret för flottan

Om du har skapat en Azure Kubernetes Fleet Manager-resurs med hubbklustret aktiverat kan du använda den för att centralt styra scenarier som Kubernetes-objektspridning. Om du vill komma åt Kubernetes-API:et för resursklustret för flottan följer du stegen i Åtkomst till Kubernetes-API:et för resursklustret för flottan med Azure Kubernetes Fleet Manager.

Nästa steg

Konfigurera Kubernetes-resursspridning från hubbkluster till medlemskluster.