Definizione di una strategia di implementazione per il posizionamento delle risorse di Azure Kubernetes Fleet Manager

Per tutta la durata di un posizionamento delle risorse (con ambito cluster ClusterResourcePlacement o con ambito spazio dei nomi ResourcePlacement), le modifiche apportate possono comportare uno degli scenari seguenti:

Potrebbe essere necessario inserire nuovi carichi di lavoro in tutti i cluster scelti
I carichi di lavoro già inseriti in un cluster selezionato potrebbero essere aggiornati o eliminati
Alcuni cluster selezionati in precedenza ora sono deselezionati ed è necessario rimuovere i carichi di lavoro da questi cluster
Alcuni cluster sono appena selezionati e vi devono essere aggiunti i carichi di lavoro.

La maggior parte degli scenari può causare interruzioni del servizio perché i carichi di lavoro in esecuzione nei cluster membri potrebbero diventare temporaneamente non disponibili quando Fleet Manager invia risorse aggiornate. I cluster che non sono più selezionati perdono tutte le risorse inserite, causando la perdita del traffico. Se sono selezionati troppi nuovi cluster e Fleet Manager inserisce le risorse contemporaneamente, i cluster potrebbero diventare sovraccarichi. Il modello di interruzione esatto può variare a seconda delle risorse inserite.

Per ridurre al minimo l'interruzione, le API di posizionamento delle risorse di Fleet Manager consentono agli utenti di configurare una strategia di implementazione, simile alla distribuzione nativa di Kubernetes, per passare tra le modifiche il più facilmente possibile.

In questo articolo vengono illustrate le opzioni di strategia di implementazione disponibili sia per ClusterResourcePlacement che per ResourcePlacement.

Note

Se non si ha già familiarità con i concetti di posizionamento delle risorse di Fleet Manager, leggere la panoramica concettuale del posizionamento delle risorse prima di leggere questo articolo.

Comportamento predefinito senza strategia esplicita

Sia ClusterResourcePlacement che ResourcePlacement non richiedono di definire una strategia di implementazione. Se non ne specifichi una, il comportamento predefinito consiste nell'usare una strategia RollingUpdate con maxSurge di 25%, maxUnavailable di 25%e unavailablePeriodSeconds di 10 secondi.

Strategia di aggiornamento in sequenza

Una strategia esplicita di aggiornamento in sequenza può essere utilizzata aggiungendo una specifica strategy a un ClusterResourcePlacement o a un ResourcePlacement come illustrato. È possibile definire i parametri che controllano quanto è dirompente il posizionamento delle risorse di Fleet Manager.

Esempio di ClusterResourcePlacement

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%

Esempio di ResourcePlacement

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%

Parametri di configurazione

Le strategie di aggiornamento in sequenza possono essere configurate con i parametri seguenti:

maxUnavailable: considera un cluster non disponibile se le risorse non vengono applicate correttamente al cluster e garantisce che in qualsiasi momento siano disponibili almeno (N - maxUnavailable) numero di cluster. È possibile impostare come numero assoluto o percentuale. Il valore predefinito è 25% e zero non deve essere usato. L'impostazione di questo parametro su un valore inferiore comporta un'interruzione inferiore durante una modifica, ma comporta un rallentamento delle implementazioni.
maxSurge: garantisce che in qualsiasi momento siano disponibili al massimo (N + maxSurge) numero di cluster. È possibile impostare come numero assoluto o percentuale. Il valore predefinito è 25% e zero non deve essere usato. L'impostazione di questo parametro su un valore inferiore comporta un minor numero di posizionamento delle risorse in più cluster da Fleet Manager, che rallenta il processo di implementazione.
unavailablePeriodSeconds consente di definire un periodo di tempo prima che le risorse vengano valutate come "pronte". Il valore predefinito è 60 secondi. Fleet manager considera solo le risorse appena applicate in un cluster come "pronto" unavailablePeriodSeconds secondi dopo che le risorse vengono applicate correttamente a tale cluster. L'impostazione di un valore inferiore per questo parametro comporta implementazioni più veloci. È tuttavia consigliabile che gli utenti impostino un valore che consenta il completamento delle attività di inizializzazione/preparazione.

Come viene determinato il numero di cluster

Fleet Manager usa il tipo di posizionamento per determinare il numero di base di cluster (N) da usare durante il calcolo maxUnavailable o maxSurge:

PickFixed: numero di clusterNames specificato
PickAll: numero di cluster scelti
PickN: il valore numberOfClusters.

Se si usa una percentuale per il parametro, Fleet Manager lo calcola anche su N .

Strategia di aggiornamento a fasi (anteprima)

La strategia di aggiornamento a fasi fornisce un controllo granulare sulle implementazioni delle risorse organizzando i cluster in fasi sequenziali con regole di progressione configurabili. A differenza della strategia di aggiornamento in sequenza, gli aggiornamenti a fasi vengono definiti esternamente usando risorse personalizzate separate che interagiscono per orchestrare le distribuzioni.

Important

Le funzionalità di anteprima di Gestione flotta Kubernetes di Azure sono disponibili in modalità self-service e opt-in. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime di Gestione flotta Kubernetes di Azure sono parzialmente coperte dal supporto clienti con il massimo sforzo. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione.

Funzionamento degli aggiornamenti a fasi

Gli aggiornamenti a fasi usano risorse personalizzate diverse a seconda dell'ambito:

Per i posizionamenti a livello di cluster:

ClusterResourcePlacement - Configurato con strategy.type: External per indicare la gestione della strategia esterna
ClusterStagedUpdateStrategy : definisce le fasi, la selezione del cluster e le regole di avanzamento
ClusterStagedUpdateRun: esegue il clusterStagedUpdateStrategy contro un'entità specifica ClusterResourcePlacement e uno snapshot delle risorse del cluster.

Per i posizionamenti con ambito spazio dei nomi:

ResourcePlacement - Configurato con strategy.type: External per indicare la gestione della strategia esterna
StagedUpdateStrategy : definisce le fasi, la selezione del cluster e le regole di progressione (a livello di spazio dei nomi)
StagedUpdateRun : esegue la StagedUpdateStrategy su uno specifico snapshot del ResourcePlacement e della risorsa (con ambito spazio dei nomi)

ClusterResourcePlacement con strategia esterna

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 con una strategia esterna

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 (con ambito cluster)

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 (con ambito spazio dei nomi)

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

Configurazione della fase

Ogni fase della strategia può specificare:

Selettore di etichette per determinare quali cluster appartengono alla fase
Ordinamento per i cluster all'interno della fase usando sortingLabelKey (facoltativo: i cluster vengono ordinati alfabeticamente in base al nome, se non specificato)
Attività post-fase con tempo di attesa programmato o con richiesta di approvazione (facoltativo, fino a 2 attività per fase, massimo uno di ogni tipo)

ClusterStagedUpdateRun (a livello di cluster)

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 (con ambito delimitato dal namespace)

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.

Avanzamento della fase

Fleet Manager elabora i passaggi in sequenza:

Tutti i cluster in una fase ricevono gli aggiornamenti in base al relativo ordinamento
Dopo che tutti i cluster in una fase sono stati aggiornati correttamente, tutte le attività dopo la fase configurate vengono eseguite
La fase successiva inizia solo dopo il completamento di tutte le attività di fase precedenti

Per la progressione basata sull'approvazione, Fleet Manager crea una risorsa ClusterApprovalRequest (per posizionamenti con ambito di cluster) o ApprovalRequest (per posizionamenti con ambito di spazio dei nomi) che deve essere approvata prima di continuare con la fase successiva.

Modello di distribuzione di esempio

Il diagramma seguente illustra un tipico modello di distribuzione a tre fasi:

Questo modello consente di:

Eseguire prima la distribuzione nei cluster di staging per la convalida iniziale
Attendere un'ora specifica prima di procedere ai cluster canary
Richiedere l'approvazione manuale prima dell'implementazione nell'ambiente di produzione
Controllare l'ordine degli aggiornamenti nelle fasi di canary e di produzione

Quando usare gli aggiornamenti a fasi

Le strategie di aggiornamento a fasi sono ideali quando è necessario:

Implementazioni basate sull'ambiente (sviluppo → gestione temporanea → produzione)
Ritardi nella convalida e barriere di approvazione tra le fasi
Ordinamento deterministico degli aggiornamenti del cluster all'interno delle fasi
Modelli di distribuzione riutilizzabili in più posizioni delle risorse

Per scenari più semplici in cui le implementazioni basate su percentuale sono sufficienti, è consigliabile usare invece la strategia di aggiornamento in sequenza inline.