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

Under livslängden för en resursplacering (klusteromfattning ClusterResourcePlacement eller namnområdesomfång ResourcePlacement) kan ändringar göras, vilket 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 tillåter Fleet Managers resursplacerings-API:er användare att 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 både ClusterResourcePlacement och ResourcePlacement.

Note

Om du inte redan är bekant med Fleet Managers resursplaceringsbegrepp läser du den konceptuella översikten över resursplacering innan du läser den här artikeln.

Standardbeteende utan explicit strategi

Både ClusterResourcePlacement och ResourcePlacement 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 uttrycklig strategi för löpande uppdatering kan användas genom att lägga till en strategy-specifikation i en ClusterResourcePlacement eller ResourcePlacement så som visas. Du kan definiera parametrar som styr hur störande Fleet Manager-resursplaceringen är.

ClusterResourcePlacement-exempel

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%

ResourcePlacement-exempel

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ResourcePlacement
metadata:
  name: rp-example
  namespace: test-namespace
spec:
  resourceSelectors:
    - group: "apps"
      kind: Deployment
      name: my-app
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 50%

Konfigurationsparametrar

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äknar Fleet Manager den också 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 rullande uppdateringsstrategin definieras stegvisa uppdateringar externt med hjälp av separata anpassade resurser som fungerar tillsammans för att samordna driftsättningar.

Important

Förhandsversionsfunktionerna i Azure Kubernetes Fleet Manager är tillgängliga via självbetjäning och opt-in. Förhandsversioner tillhandahålls "i befintligt skick" och "i mån av tillgång," och de är undantagna från servicenivåavtal och begränsad garanti. Förhandsversioner av Azure Kubernetes Fleet Manager omfattas delvis av kundsupport på bästa sätt. Dessa funktioner är därmed inte avsedda för produktionsanvändning.

Så här fungerar gradvisa uppdateringar

Mellanlagrade uppdateringar använder olika anpassade resurser beroende på omfång:

För klusterövergripande placeringar:

ClusterResourcePlacement – Konfigurerad med strategy.type: External för att indikera extern strategihantering
ClusterStagedUpdateStrategy – Definierar faser, klusterval och progressionsregler
ClusterStagedUpdateRun – kör ClusterStagedUpdateStrategy mot en specifik ClusterResourcePlacement snapshot av klusterresurser

För namnområdesomfångsplaceringar:

ResourcePlacement – Konfigurerad med strategy.type: External för att indikera extern strategihantering
StagedUpdateStrategy – Definierar faser, klusterval och progressionsregler (namnområdesomfång)
StagedUpdateRun – kör stagedUpdateStrategy mot en specifik ResourcePlacement och resurs-snapshot inom ett namnområde

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.

ResourcePlacement med extern strategi

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ResourcePlacement
metadata:
  name: my-app-placement
  namespace: my-app
spec:
  resourceSelectors:
    - group: "apps"
      kind: Deployment
      name: my-deployment
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External  # Rollout is controlled by StagedUpdateRun, StagedUpdateStrategy.

ClusterStagedUpdateStrategy (klusteromfattning)

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

StagedUpdateStrategy (namnområdesomfång)

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: StagedUpdateStrategy
metadata:
  name: three-stage-strategy
  namespace: my-app
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

Scenkonfiguration

Varje steg i strategin kan ange:

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

ClusterStagedUpdateRun (klusteromfattning)

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" # ClusterResourceSnapshot index of the selected resources to be updated across clusters.
  stagedRolloutStrategyName: three-stage-strategy # The name of the update strategy to use.

StagedUpdateRun (namnområdebegränsad)

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

Fasutveckling

Fleet Manager bearbetar stegsekventiellt:

Alla kluster i en fas får uppdateringar enligt sorteringsordningen
När alla kluster i en fas har uppdaterats, körs de konfigurerade uppgifterna efter fasen
Nästa steg börjar först efter att alla tidigare steguppgifter har slutförts

För godkännandebaserad progression skapar Fleet Manager en ClusterApprovalRequest (för klusteromfattande placeringar) eller ApprovalRequest (för placeringar inom namnområdet) 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 distribution 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ännandepunkter mellan steg
Deterministisk ordning av klusteruppdateringar inom en fas
Återanvändbara distributionsmönster för flera resursplaceringar

För enklare scenarier där procentbaserade distributioner räcker bör du överväga att använda den inbyggda strategin för kontinuerlig uppdatering som alternativ.