Posizionamento delle risorse Kubernetes dal cluster hub ai cluster membri

Questo articolo descrive il concetto di posizionamento delle risorse Kubernetes dai cluster hub ai cluster membri usando Azure Kubernetes Fleet Manager (Kubernetes Fleet).

Gli amministratori della piattaforma spesso devono distribuire risorse Kubernetes in più cluster per diversi motivi, ad esempio:

• Gestione del controllo di accesso tramite ruoli e associazioni di ruolo in più cluster.
• Esecuzione di applicazioni di infrastruttura, ad esempio Prometheus o Flux, che devono trovarsi in tutti i cluster.

Gli sviluppatori di applicazioni spesso devono distribuire risorse Kubernetes in più cluster per diversi motivi, ad esempio:

• Distribuzione di un'applicazione di gestione video in più cluster in aree diverse per un'esperienza di visione a bassa latenza.
• Distribuzione di un'applicazione di carrello acquisti in due aree abbinate per consentire ai clienti di continuare a acquistare durante un'interruzione di un'area.
• Distribuzione di un'applicazione di calcolo batch in cluster con pool di nodi spot economici disponibili.

La creazione, l’aggiornamento e il tracciamento manuale di queste risorse di Kubernetes in più cluster sono operazioni noiose. Flotta fornisce la propagazione delle risorse di Kubernetes per abilitare la gestione su larga scala delle risorse di Kubernetes. Con Kubernetes Fleet è possibile creare risorse Kubernetes nel cluster hub e propagarle ai cluster membri selezionati tramite risorse personalizzate Kubernetes: MemberCluster e ClusterResourcePlacement.

Kubernetes Fleet supporta queste risorse personalizzate basate su una soluzione nativa del cloud open source che è possibile leggere altre informazioni sulla documentazione di Fleet open source.

Introduzione a ClusterResourcePlacement

Un ClusterResourcePlacement oggetto viene usato per indicare all'utilità di pianificazione della flotta come inserire un determinato set di oggetti con ambito cluster dal cluster hub della flotta ai cluster membri. Gli oggetti con ambito spazio dei nomi, ad esempio Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets e PersistentVolumeClaims, vengono inclusi quando viene selezionato lo spazio dei nomi contenitore.

Con ClusterResourcePlacement è possibile:

• Selezionare le risorse di Kubernetes in ambito cluster da propagare ai cluster membri.
• Specificare i criteri di posizionamento per selezionare manualmente o automaticamente i cluster membri come cluster di destinazione.
• Specificare le strategie di implementazione per implementare in modo sicuro tutti gli aggiornamenti delle risorse di Kubernetes selezionate in più cluster di destinazione.
• Visualizzare lo stato di propagazione verso ogni cluster di destinazione.

Nel diagramma seguente è illustrato un esempio.

Incapsulamento delle risorse

ClusterResourcePlacement supporta l'uso di ConfigMap per eseguire la busta di determinati tipi di risorse Kubernetes in modo che possano essere distribuiti nel cluster hub senza effetti collaterali imprevisti nel cluster hub. Per un elenco dei tipi di risorse e per comprendere il funzionamento di questa funzionalità, vedere la documentazione relativa agli oggetti envelope

Tipi di posizionamento

I tipi di posizionamento seguenti sono disponibili per controllare il numero di cluster a cui deve essere propagata una risorsa Kubernetes specificata:

• PickFixed inserisce la risorsa in un elenco specifico di cluster membri in base al nome.
• PickAll inserisce la risorsa in tutti i cluster membri o in tutti i cluster membri che soddisfano criteri. Questi criteri sono utili per posizionare carichi di lavoro dell'infrastruttura, ad esempio il monitoraggio del cluster o le applicazioni di creazione report.
• PickN è l'opzione di posizionamento più flessibile e consente la selezione di cluster in base ai vincoli di diffusione di affinità o topologia ed è utile quando si distribuiscono carichi di lavoro in più cluster appropriati per garantire la disponibilità.

Tipo di posizionamento PickFixed

Se si vuole distribuire un carico di lavoro in un set noto di cluster membri, è possibile usare un PickFixed criterio di posizionamento per selezionare i cluster in base al nome.

clusterNames è l'unica opzione di criteri valida per questo tipo di posizionamento.

Nell'esempio seguente viene illustrato come distribuire lo test-deployment spazio dei nomi in cluster cluster1 membri e cluster2.

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

Tipo di posizionamento PickAll

È possibile usare un PickAll tipo di posizionamento per distribuire un carico di lavoro in tutti i cluster membri della flotta o in un subset di cluster che soddisfano i criteri impostati.

Quando si crea questo tipo di posizionamento, è possibile specificare i tipi di affinità cluster seguenti:

• requiredDuringSchedulingIgnoredDuringExecution: poiché questo criterio è necessario durante la pianificazione, filtra i cluster in base ai criteri specificati.

Nell'esempio seguente viene illustrato come distribuire uno spazio dei nomi prod-deployment e tutti i relativi oggetti in tutti i cluster etichettati con environment: production:

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

Tipo di posizionamento PickN

Il PickN tipo di posizionamento è l'opzione più flessibile e consente il posizionamento delle risorse in un numero configurabile di cluster in base sia alle affinità che ai vincoli di distribuzione della topologia.

Quando si crea questo tipo di posizionamento, è possibile specificare i tipi di affinità cluster seguenti:

• requiredDuringSchedulingIgnoredDuringExecution: poiché questo criterio è necessario durante la pianificazione, filtra i cluster in base ai criteri specificati.
• preferredDuringSchedulingIgnoredDuringExecution: poiché questo criterio è preferibile, ma non richiesto durante la pianificazione, classifica i cluster in base ai criteri specificati.

È possibile impostare affinità obbligatorie e preferite. Le affinità necessarie impediscono il posizionamento ai cluster che non corrispondono e le affinità preferite forniscono l'ordinamento di cluster validi.

PickN con affinità

L'uso di affinità con criteri di selezione host PickN funziona in modo analogo all'uso delle affinità con la pianificazione dei pod.

L'esempio seguente illustra come distribuire un carico di lavoro in tre cluster. Solo i cluster con l'etichetta critical-allowed: "true" sono destinazioni di selezione host valide e la preferenza viene assegnata ai cluster con l'etichetta critical-level: 1:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-01
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 con vincoli di distribuzione della topologia

È possibile usare i vincoli di distribuzione della topologia per forzare la divisione dei posizionamenti del cluster attraverso i limiti della topologia per soddisfare i requisiti di disponibilità. Ad esempio, usare questi vincoli per suddividere i posizionamenti tra aree o aggiornare gli anelli. È anche possibile configurare i vincoli di distribuzione della topologia per impedire la pianificazione se il vincolo non può essere soddisfatto (whenUnsatisfiable: DoNotSchedule) o per eseguire la migliore pianificazione possibile (whenUnsatisfiable: ScheduleAnyway).

L'esempio seguente illustra come distribuire un determinato set di risorse in più aree e tenta di pianificare tra cluster membri con giorni di aggiornamento diversi.

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

Per altre informazioni, vedere i vincoli di distribuzione della topologia della flotta open source.

Opzioni dei criteri di posizionamento

La tabella riepiloga i campi dei criteri di pianificazione disponibili per ogni tipo di posizionamento.

Selezione di cluster in base a etichette e proprietà

Etichette e proprietà disponibili per selezionare i cluster

Quando si usano i PickN tipi di posizionamento e PickAll , è possibile usare le etichette e le proprietà seguenti come parte dei criteri.

Etichette

Le etichette seguenti vengono aggiunte automaticamente a tutti i cluster membri e possono essere usate per la selezione del cluster di destinazione nei criteri di posizionamento delle risorse.

È anche possibile usare qualsiasi etichetta personalizzata applicata ai cluster.

Proprietà

Le proprietà seguenti sono disponibili per l'uso come parte dei criteri di posizionamento.

Le proprietà della CPU e della memoria sono rappresentate come unità di risorsa Kubernetes.

Le proprietà dei costi sono decimali che rappresentano un costo orario in dollari USA per il calcolo di Azure utilizzato per i nodi all'interno del cluster. Il costo è basato sui prezzi pubblici di Azure.

Specifica dei criteri di corrispondenza della selezione

Quando si usano le proprietà del cluster in criteri, è necessario specificare:

• Nome: nome della proprietà, ovvero una delle proprietà elencate nelle proprietà di questo articolo.

• Operatore: operatore usato per esprimere la condizione tra il vincolo/valore desiderato e il valore osservato nel cluster. Sono attualmente supportati gli operatori seguenti:

  • Gt (Maggiore di): il valore osservato di un cluster della proprietà specificata deve essere maggiore del valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.
  • Ge (Maggiore o uguale a): il valore osservato di un cluster della proprietà specificata deve essere maggiore o uguale al valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.
  • Lt (Minore di): il valore osservato di un cluster della proprietà specificata deve essere minore del valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.
  • Le (Minore o uguale a): il valore osservato di un cluster della proprietà specificata deve essere minore o uguale al valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.
  • Eq (Uguale a): il valore osservato di un cluster della proprietà specificata deve essere uguale al valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.
  • Ne (Diverso da): il valore osservato di un cluster della proprietà specificata non deve essere uguale al valore nella condizione prima che possa essere selezionato per il posizionamento delle risorse.

  Se si usa l'operatore Gt, Lt Ge, Le, Eq o Ne, l'elenco di valori nella condizione deve avere un valore esatto.

• Valori: elenco di valori possibili della proprietà.

Fleet valuta ogni cluster in base alle proprietà specificate nella condizione. Il mancato rispetto delle condizioni elencate in requiredDuringSchedulingIgnoredDuringExecution esclude questo cluster membro dal posizionamento delle risorse.

Ecco un esempio di criteri di posizionamento per selezionare solo i cluster con cinque o più nodi.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

Funzionamento della classificazione delle proprietà

Quando preferredDuringSchedulingIgnoredDuringExecution viene usato, un ordinamento di proprietà classifica tutti i cluster della flotta in base ai valori in ordine crescente o decrescente. I pesi utilizzati per l'ordinamento vengono calcolati in base al valore specificato.

Un ordinamento delle proprietà è costituito da:

• Nome: nome della proprietà del cluster.
• Ordinamento: l'ordinamento può essere Ascending o Descending. Quando Ascending si usa l'ordine, è preferibile usare cluster membri con valori osservati inferiori. Quando si usa l'ordine Descending, è preferibile utilizzare cluster membri con un valore osservato superiore.

Decrescente

Per l'ordinamento decrescente, il peso proporzionale viene calcolato usando la formula :

((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight

Si supponga, ad esempio, di voler classificare i cluster in base alla proprietà della capacità CPU disponibile in ordine decrescente e che si disponga di una flotta di tre cluster con la CPU disponibile seguente:

In questo caso, l'ordinamento calcola i pesi seguenti:

Ordine crescente

Per l'ordinamento crescente, il peso proporzionale viene calcolato usando la formula :

(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight

Si supponga, ad esempio, di voler classificare i cluster in base al costo per core CPU in ordine crescente e di avere una flotta di tre cluster con i costi principali della CPU seguenti:

In questo caso, l'ordinamento calcola i pesi seguenti:

Uso delle tolerazioni

Gli oggetti ClusterResourcePlacement supportano la specifica di tolleranze che si applicano all'oggetto ClusterResourcePlacement. Ogni tolleranza è costituita dagli elementi seguenti:

• key: chiave della tolleranza.
• value: valore della tolleranza.
• effect: effetto della tolleranza, ad esempio NoSchedule.
• operator: operatore della tolleranza, ad esempio Exists o Equal.

Ogni tollerazione viene usata per tollerare uno o più taint specifici applicati a ClusterResourcePlacement. Una volta tollerati tutti i taint in un MemberCluster, l'utilità di pianificazione può quindi propagare le risorse al cluster. Non è possibile aggiornare o rimuovere tollerazioni da un ClusterResourcePlacement oggetto dopo la creazione.

Per altre informazioni, vedere la documentazione della flotta open source sulle tollerazioni.

Configurazione della strategia di implementazione

Fleet usa una strategia di aggiornamento in sequenza per controllare la modalità di implementazione degli aggiornamenti nei cluster.

Nell'esempio seguente, l'utilità di pianificazione della flotta distribuisce gli aggiornamenti a ogni cluster in sequenza, in attesa almeno unavailablePeriodSeconds tra i cluster. Lo stato di implementazione viene considerato corretto se tutte le risorse sono state applicate correttamente al cluster. Il controllo dello stato dell'implementazione non si propaga alle risorse figlio, quindi, ad esempio, non conferma che i pod creati da una distribuzione diventano pronti.

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

Per altre informazioni, vedere la documentazione di Fleet open source sulla strategia di implementazione.

Determinare lo stato di posizionamento

L'utilità di pianificazione di Flotta aggiorna i dettagli e lo stato delle decisioni di selezione host sull'oggetto ClusterResourcePlacement. L'output include le informazioni seguenti:

• Condizioni che attualmente si applicano alla selezione host, che includono se la selezione host è stata completata correttamente.
• Sezione relativa allo stato di selezione host per ogni cluster membro, che mostra lo stato della distribuzione in tale cluster.

Nell'esempio seguente viene illustrato un ClusterResourcePlacement che ha distribuito lo spazio dei nomi test e il ConfigMap test-1 in due cluster membri usando PickN. La selezione host è stata completata correttamente e le risorse sono state inserite nei cluster aks-member-1 e aks-member-2.

È possibile visualizzare queste informazioni tramite il comando kubectl describe crp <name>.

kubectl describe crp crp-1

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

Trigger di modifica del posizionamento

L'utilità di pianificazione di Flotta assegna la priorità alla stabilità delle selezioni host per i carichi di lavoro esistenti. Questo definizione delle priorità può limitare il numero di modifiche che causano la rimozione e la ripianificazione di un carico di lavoro. Gli scenari seguenti possono attivare modifiche di selezione host:

• Le modifiche ai criteri di selezione host nell'oggetto ClusterResourcePlacement possono attivare la rimozione e la ripianificazione di un carico di lavoro.
  • Le operazioni di scalabilità orizzontale (aumentando numberOfClusters senza altre modifiche) inseriscono i carichi di lavoro solo nei nuovi cluster e non influiscono sui posizionamenti esistenti.
• Modifiche del cluster, tra cui:
  • Un nuovo cluster diventa idoneo può attivare il posizionamento se il nuovo cluster soddisfa i criteri di posizionamento, ad esempio un PickAll criterio.
  • Un cluster con un posizionamento viene rimosso dalla flotta. A seconda dei criteri, l'utilità di pianificazione tenta di inserire tutti i carichi di lavoro interessati nei cluster rimanenti senza influire sulle posizioni esistenti.

Le modifiche che interessano solo le risorse (con l’aggiornamento delle risorse o del ResourceSelector nell'oggetto ClusterResourcePlacement) vengono implementate gradualmente nelle selezioni host esistenti, ma non attivano la ripianificazione del carico di lavoro.

Passaggi successivi

• Configurare la propagazione delle risorse di Kubernetes dal cluster hub ai cluster membri.
• Posizionamento intelligente delle risorse Kubernetes tra cluster in base alle proprietà dei cluster membri