Gestione dei carichi di lavoro esistenti con il posizionamento delle risorse in Azure Kubernetes Fleet Manager (anteprima)

Si applica a: ✔️ Fleet Manager con cluster di hub

Quando un ambiente multi-cluster matura, la presenza di un carico di lavoro specifico in più cluster è una situazione comune. Un motivo per aggiungere cluster a una flotta consiste nell'centralizzare la gestione dei carichi di lavoro per migliorare la visibilità e la gestibilità dei carichi di lavoro in più cluster. Tuttavia, l'aggiunta di cluster con carichi di lavoro esistenti a una flotta può causare conflitti di posizionamento quando Fleet Manager tenta di inserire un carico di lavoro gestito in un cluster membro aggiunto.

In questo articolo verrà esaminato come utilizzare la whenToTakeOver proprietà di un applyStrategy nella distribuzione delle risorse (ambito cluster ClusterResourcePlacement o ambito spazio dei nomiResourcePlacement) per controllare esplicitamente come Fleet Manager gestisce i carichi di lavoro esistenti durante l'esecuzione delle distribuzioni.

Annotazioni

Se non si ha già familiarità con i concetti di posizionamento delle risorse di Fleet Manager, leggere la panoramica del posizionamento delle risorse con ambito cluster e la panoramica del posizionamento delle risorse con ambito spazio dei nomi prima di leggere questo articolo.

Importante

Le funzionalità in anteprima di Gestione flotta Kubernetes di Azure sono disponibili in modalità self-service, previo consenso esplicito. 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.

Le anteprime del piano dati vengono rilasciate tramite la versione dell'API v1beta1. Se gli oggetti di anteprima non vengono visualizzati, verificare di richiedere l'API v1beta1 quando si interagisce con il cluster hub di Fleet Manager.

Opzioni di acquisizione del carico di lavoro

Il punto di partenza per l'acquisizione del carico di lavoro consiste nel distribuire i manifesti del carico di lavoro nel cluster hub di Fleet Manager. Dopo la distribuzione, definisci un ClusterResourcePlacement o un ResourcePlacement che specifica un comportamento esplicito di acquisizione tramite la proprietà whenToTakeOver.

La whenToTakeOver proprietà consente i valori seguenti:

  • Always: Fleet Manager applica immediatamente il carico di lavoro corrispondente dal cluster hub e le eventuali differenze di valore nei campi gestiti vengono sovrascritte nel cluster di destinazione. Questo comportamento è l'impostazione predefinita sia per ClusterResourcePlacement che per ResourcePlacement, in assenza di un'impostazione esplicita whenToTakeOver.

  • IfNoDiff: Fleet Manager verifica le differenze di configurazione quando rileva un carico di lavoro esistente e applica il carico di lavoro del cluster hub solo se non vengono rilevate differenze di configurazione.

  • Never: Fleet Manager ignora i carichi di lavoro esistenti e non applica il carico di lavoro del cluster hub. Fleet Manager identifica ancora i carichi di lavoro corrispondenti e genera un errore di applicazione, in modo da poter verificare in modo sicuro la presenza di carichi di lavoro esistenti.

Definire i campi usati per il confronto

È possibile usare una proprietà facoltativa comparisonOptions per ottimizzare il modo in cui whenToTakeOver determina le differenze di configurazione.

  • partialComparison: solo i campi presenti nel carico di lavoro del cluster hub e nel carico di lavoro del cluster di destinazione vengono usati per il confronto dei valori. Tutti i campi aggiuntivi non gestiti nel carico di lavoro del cluster di destinazione vengono ignorati. Questo comportamento è di default senza alcuna impostazione esplicita comparisonOptions.

  • fullComparison: tutti i campi nella definizione del carico di lavoro nel cluster hub Fleet devono essere presenti nel cluster membro selezionato. Se il cluster di destinazione include campi aggiuntivi non gestiti, il confronto non riesce.

Verificare la presenza di carichi di lavoro in conflitto

Per verificare la presenza di carichi di lavoro esistenti, iniziare aggiungendo un oggetto applyStrategy con un whenToTakeOver valore di Never , come illustrato negli esempi seguenti.

Esempio di ClusterResourcePlacement

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: web-2-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      version: v1
      labelSelector:
        matchLabels:
          app: web-2
  policy:
    placementType: PickAll
  strategy:
    applyStrategy:
      whenToTakeOver: Never
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
      unavailablePeriodSeconds: 1

Applica il ClusterResourcePlacement al cluster hub di Fleet Manager.

kubectl apply -f web-2-crp.yaml

Esempio di ResourcePlacement

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ResourcePlacement
metadata:
  name: web-2-rp
  namespace: web-2
spec:
  resourceSelectors:
    - group: "apps"
      kind: Deployment
      name: web-app
      version: v1
  policy:
    placementType: PickAll
  strategy:
    applyStrategy:
      whenToTakeOver: Never
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
      unavailablePeriodSeconds: 1

Applica il ResourcePlacement al cluster hub di Fleet Manager.

kubectl apply -f web-2-rp.yaml

Controllare lo stato di posizionamento

Fleet Manager tenta di posizionare il carico di lavoro e quando trova un carico di lavoro corrispondente in un cluster membro di destinazione restituisce una failedPlacement risposta.

È possibile determinare quali cluster membri hanno fallito il posizionamento a causa di un carico di lavoro conflittuale usando i seguenti comandi. Il comando jq viene usato per formattare l'output.

Per ClusterResourcePlacement:

kubectl get clusterresourceplacement.v1beta1.placement.kubernetes-fleet.io web-2-crp -o jsonpath='{.status.placementStatuses}' \
    | jq '[.[] | select (.failedPlacements != null)] | map({clusterName, failedPlacements})'

Per ResourcePlacement:

kubectl get resourceplacement.v1beta1.placement.kubernetes-fleet.io web-2-rp -n web-2 -o jsonpath='{.status.placementStatuses}' \
    | jq '[.[] | select (.failedPlacements != null)] | map({clusterName, failedPlacements})'

Ogni cluster che non riesce nel posizionamento a causa di un carico di lavoro esistente restituisce una voce simile al seguente esempio.

{
    "clusterName": "member-2",
    "failedPlacements": [
        {
            "condition": {
                "lastTransitionTime": "...",
                "message": "Failed to apply the manifest (error: no ownership of the object in the member cluster; takeover is needed)",
                "reason": "NotTakenOver",
                "status": "False",
                "type": "Applied"
            },
            "kind": "Namespace",
            "name": "web-2",
            "version": "v1"
        }
    ]
}

Assumere in modo sicuro i carichi di lavoro corrispondenti

Per procedere con il controllo di un carico di lavoro esistente, è possibile modificare l'oggetto esistente ClusterResourcePlacement o ResourcePlacement, cambiando whenToTakeOver in IfNoDiff.

Fleet Manager applica il carico di lavoro del cluster hub al posto del carico di lavoro esistente nel cluster di destinazione quando non esistono differenze tra i campi gestiti in entrambi i carichi di lavoro. I campi aggiuntivi vengono ignorati.

Esempio di ClusterResourcePlacement

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: web-2-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      version: v1
      labelSelector:
        matchLabels:
          app: web-2
  policy:
    placementType: PickAll
  strategy:
    applyStrategy:
      whenToTakeOver: IfNoDiff
      comparisonOption: PartialComparison
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
      unavailablePeriodSeconds: 1

Applica il ClusterResourcePlacement al cluster hub di Fleet Manager.

kubectl apply -f web-2-crp.yaml

Esempio di ResourcePlacement

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ResourcePlacement
metadata:
  name: web-2-rp
  namespace: web-2
spec:
  resourceSelectors:
    - group: "apps"
      kind: Deployment
      name: web-app
      version: v1
  policy:
    placementType: PickAll
  strategy:
    applyStrategy:
      whenToTakeOver: IfNoDiff
      comparisonOption: PartialComparison
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
      unavailablePeriodSeconds: 1

Applica il ResourcePlacement al cluster hub di Fleet Manager.

kubectl apply -f web-2-rp.yaml

Verificare la presenza di posizionamenti non riusciti

Fleet Manager tenta di allocare il carico di lavoro sovrascrivendo i cluster membri di destinazione che hanno campi corrispondenti.

I posizionamenti possono comunque non riuscire, quindi verificare la presenza di messaggi aggiuntivi failedPlacement . Determinare quali cluster membro hanno fallito utilizzando i comandi seguenti. Il comando jq viene usato per formattare l'output.

Per ClusterResourcePlacement:

kubectl get clusterresourceplacement.v1beta1.placement.kubernetes-fleet.io web-2-crp -o jsonpath='{.status.placementStatuses}' \
    | jq '[.[] | select (.failedPlacements != null)] | map({clusterName, failedPlacements})'

Per ResourcePlacement:

kubectl get resourceplacement.v1beta1.placement.kubernetes-fleet.io web-2-rp -n web-2 -o jsonpath='{.status.placementStatuses}' \
    | jq '[.[] | select (.failedPlacements != null)] | map({clusterName, failedPlacements})'

Ogni cluster che ha avuto esito negativo a causa di una differenza di configurazione restituisce una voce simile all'esempio seguente.

{
    "clusterName": "member-2",
    "failedPlacements": [
        {
            "condition": {
                "lastTransitionTime": "...",
                "message": "Failed to apply the manifest (error: cannot take over object: configuration differences are found between the manifest object and the corresponding object in the member cluster)",
                "reason": "FailedToTakeOver",
                "status": "False",
                "type": "Applied"
            },
            "kind": "Namespace",
            "name": "work-2",
            "version": "v1"
        }
    ]
}

La visualizzazione dei campi deviati può essere ottenuta seguendo il processo descritto nella sezione relativa ai cluster deviati della documentazione sul rilevamento della deriva.

A questo punto è necessario decidere come gestire la deriva, includendo le modifiche del cluster membro nella definizione del carico di lavoro del cluster hub o scegliendo di sovrascrivere il carico di lavoro del cluster membro impostando la whenToTakeOver proprietà su Always.

Passaggi successivi

  • Last updated on