Definiera en distributionsstrategi för Azure Kubernetes Fleet Manager-klusterresursplacering

Under livslängden för en klusterresursplacering (CRP) kan ändringar göras i CRP som kan resultera i något av följande scenarier:

• Nya arbetsbelastningar kan behöva placeras på alla plockade kluster
• Arbetsbelastningar som redan placerats i ett valt kluster kan uppdateras eller tas bort
• Vissa kluster som tidigare valts har nu valts bort, så att arbetsbelastningar behöver tas bort från sådana kluster.
• Vissa kluster har nyligen valts och arbetsbelastningar måste läggas till i dem.

De flesta scenarier kan leda till tjänstavbrott eftersom arbetsbelastningar som körs i medlemskluster tillfälligt blir otillgängliga när Fleet Manager skickar uppdaterade resurser. Kluster som inte längre är valda förlorar alla placerade resurser, vilket resulterar i förlorad trafik. Om för många nya kluster väljs och Fleet Manager placerar resurser på dem samtidigt kan kluster bli överbelastade. Det exakta avbrottsmönstret kan variera beroende på vilka resurser som placeras.

För att minimera avbrott gör Fleet Managers placering av klusterresurser att användarna kan konfigurera en distributionsstrategi, liknande den interna Kubernetes-distributionen, för att övergå mellan ändringar så smidigt som möjligt.

I den här artikeln går vi igenom de distributionsstrategialternativ som är tillgängliga för placering av klusterresurser.

Standardbeteende utan explicit strategi

Klusterresursplaceringar kräver inte att du definierar en distributionsstrategi. Om du inte anger något är standardbeteendet att använda en RollingUpdate strategi med maxSurge 25%, maxUnavailable 25%och unavailablePeriodSeconds 10 sekunder.

Strategi för löpande uppdatering

En explicit strategi för löpande uppdatering kan användas genom att lägga till en strategy specifikation i en CRP enligt beskrivningen. Du kan definiera parametrar som styr hur störande Fleet Manager-resursplaceringen är.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-example
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-namespace
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 2
    affinity:
      clusterAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  fleet.azure.com/location: westus
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 50%

Strategier för löpande uppdateringar kan konfigureras med följande parametrar:

• maxUnavailable: betraktar ett kluster som otillgängligt om resurserna inte har tillämpats på klustret och ser till att det när som helst finns minst (N – maxUnavailable) antal tillgängliga kluster. Du kan ange som ett absolut tal eller en procentsats. Standardvärdet är 25% och noll ska inte användas. Om du ställer in den här parametern på ett lägre värde blir det mindre avbrott under en ändring, men det leder till långsammare distributioner.

• maxSurge: säkerställer att det när som helst finns högst (N + maxSurge) antal tillgängliga kluster. Du kan ange som ett absolut tal eller en procentsats. Standardvärdet är 25% och noll ska inte användas. Om du anger den här parametern till ett lägre värde resulterar det i färre resursplaceringar i fler kluster av Fleet Manager, vilket gör distributionsprocessen långsammare.

• unavailablePeriodSeconds gör att du kan definiera en tidsperiod innan resurser ska utvärderas som "redo". Standardvärdet är 60 sekunder. Fleet Manager betraktar endast nyligen använda resurser i ett kluster som "redo" unavailablePeriodSeconds sekunder efter att resurserna har tillämpats på klustret. Om du anger ett lägre värde för den här parametern resulterar det i snabbare distributioner. Vi rekommenderar dock starkt att användarna anger ett värde som gör att initierings-/förberedelseuppgifterna kan slutföras.

Hur antalet kluster bestäms

Fleet Manager använder placeringstypen för att fastställa baslinjeantalet kluster (N) som ska användas vid beräkning maxUnavailable eller maxSurge:

• PickFixed: antalet clusterNames angivna
• PickAll: antalet kluster som valts
• PickN: värdet numberOfClusters .

Om du använder en procentandel för parametern beräknas den även mot N .

Stegvis uppdateringsstrategi (förhandsversion)

Den stegvisa uppdateringsstrategin ger detaljerad kontroll över resursdistributioner genom att organisera kluster i sekventiella steg med konfigurerbara progressionsregler. Till skillnad från den löpande uppdateringsstrategin definieras mellanlagrade uppdateringar externt med hjälp av separata anpassade resurser som fungerar tillsammans för att samordna distributioner.

Så här fungerar mellanlagrade uppdateringar

Mellanlagrade uppdateringar använder tre anpassade resurser:

• ClusterResourcePlacement – Konfigurerad med strategy.type: External för att indikera extern strategihantering
• ClusterStagedUpdateStrategy – Definierar faser, klusterval och progressionsregler
• ClusterStagedUpdateRun – kör klustretStagedUpdateStrategy mot en specifik CRP och resursögonblicksbild

ClusterResourcePlacement med extern strategi

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: my-app-placement
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External  # Rollout is controlled by ClusterStagedUpdateRun, ClusterStagedUpdateStrategy.

ClusterStagedUpdateStrategy

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterStagedUpdateStrategy
metadata:
  name: three-stage-strategy
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1h
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: name
      afterStageTasks:
        - type: Approval
    - name: production
      labelSelector:
        matchLabels:
          environment: production
      sortingLabelKey: order

Varje steg i strategin kan ange:

• Etikettväljare för att avgöra vilka kluster som tillhör fasen
• Sorteringsordning för kluster i fasen med ( sortingLabelKey valfritt – kluster sorteras alfabetiskt efter namn om de inte anges)
• Uppgifter efter fasen har antingen tidsinväntning eller godkännandekrav (valfritt, upp till 2 aktiviteter per steg, högst en av varje typ)

ClusterStagedUpdateRun

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterStagedUpdateRun
metadata:
  name: my-app-rollout
spec:
  placementName: my-app-placement # ClusterResourcePlacement name the update run is applied to.
  resourceSnapshotIndex: "0" # Resource snapshot index of the selected resources to be updated across clusters.
  stagedRolloutStrategyName: three-stage-strategy # The name of the update strategy to use.

Stage progression

Fleet Manager-processer steg för steg sekventiellt:

1. Alla kluster i en fas får uppdateringar enligt sorteringsordningen
2. När alla kluster i en fas har uppdaterats körs alla konfigurerade uppgifter efter fas
3. Nästa steg börjar först efter att alla tidigare steguppgifter har slutförts

För godkännandebaserad utveckling skapar Fleet Manager en ClusterApprovalRequest resurs som måste godkännas innan du fortsätter till nästa steg.

Exempel på distributionsmönster

Följande diagram illustrerar ett typiskt distributionsmönster i tre steg:

Med det här mönstret kan du:

• Distribuera till mellanlagringskluster först för inledande validering
• Vänta en angiven tid innan du fortsätter till kanariekluster
• Kräv manuellt godkännande innan du distribuerar till produktion
• Kontrollera ordningen på uppdateringar inom kanarie- och produktionsfaser

När du ska använda mellanlagrade uppdateringar

Stegvisa uppdateringsstrategier är idealiska när du behöver:

• Miljöbaserade distributioner (dev → mellanlagring → produktion)
• Valideringsfördröjningar och godkännandegrindar mellan steg
• Deterministisk ordning på klusteruppdateringar inom steg
• Återanvändbara distributionsmönster för flera klusterresursplaceringar

För enklare scenarier där procentbaserade distributioner räcker bör du överväga att använda den infogade strategin för löpande uppdatering i stället.

Next steps

• Använda ClusterStagedUpdateRun för att orkestrera mellanlagrade distributioner.
• Kontroll av utestängning och störningar vid placering av klusterresurser.
• Använd klusterresursplacering för att distribuera arbetsbelastningar i flera kluster.
• Intelligent kubernetes-resursplacering mellan kluster baserat på medlemsklusteregenskaper.