Share via

Propagazione delle risorse Kubernetes dal cluster hub ai cluster membri

  • Articolo

Questo articolo descrive il concetto di propagazione delle risorse di Kubernetes dal cluster hub ai cluster membri tramite Gestione flotta Kubernetes di Azure (Flotta).

Gli amministratori della piattaforma spesso devono distribuire le risorse di 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 le risorse di 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 Flotta è possibile creare risorse di Kubernetes nel cluster hub e propagarle ai cluster membri selezionati tramite risorse personalizzate di Kubernetes: MemberCluster e ClusterResourcePlacement. Flotta supporta queste risorse personalizzate basate su una soluzione open source multi-cluster nativa del cloud. Per altre informazioni, vedere la documentazione di Flotta upstream.

Importante

Le funzionalità di anteprima di Gestione flotta Kubernetes di Azure sono disponibili in modalità self-service e acconsentono esplicitamente. 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 in base al massimo impegno. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione.

Flusso di lavoro di propagazione delle risorse

Diagramma che illustra in che modo le risorse di Kubernetes vengono propagate ai cluster membri.

Cos’è un MemberCluster?

Una volta aggiunto un cluster a una flotta, viene creata una risorsa MemberCluster personalizzata corrispondente nel cluster hub. È possibile usare questa risorsa personalizzata per selezionare i cluster di destinazione nella propagazione delle risorse.

Le etichette seguenti possono essere usate per la selezione del cluster di destinazione nella propagazione delle risorse e vengono aggiunte automaticamente a tutti i cluster membri:

  • fleet.azure.com/location
  • fleet.azure.com/resource-group
  • fleet.azure.com/subscription-id

Per altre informazioni, vedere le informazioni di riferimento sull’API MemberCluster.

Cos’è un ClusterResourcePlacement?

Un oggetto ClusterResourcePlacement viene usato per indicare all'utilità di pianificazione Flotta come posizionare un determinato set di oggetti con ambito cluster dal cluster hub in 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 selezione host per selezionare manualmente o automaticamente un subset o tutti 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.

L'oggetto ClusterResourcePlacement supporta l'uso di ConfigMap per racchiudere l'oggetto allo scopo di facilitare la propagazione ai cluster membri senza effetti collaterali imprevisti. I metodi di selezione sono:

  • Gruppo, versione e tipo: selezionare e posizionare tutte le risorse del tipo specificato.
  • Gruppo, versione, tipo e nome: selezionare e posizionare una particolare risorsa di un determinato tipo.
  • Gruppo, versione, tipo ed etichette: selezionare e posizionare tutte le risorse di un determinato tipo che corrispondono alle etichette fornite.

Per altre informazioni, vedere le informazioni di riferimento sull’API ClusterResourcePlacement.

Quando si crea il ClusterResourcePlacement, è possibile specificare i tipi di affinità seguenti:

  • requiredDuringSchedulingIgnoredDuringExecution: poiché questa affinità è del tipo richiesto durante la pianificazione, filtra i cluster in base alle relative proprietà.
  • preferredDuringSchedulingIgnoredDuringExecution: poiché questa affinità è solo del tipo preferito, ma non è necessaria durante la pianificazione, fornisce una classificazione preferenziale ai cluster in base alle proprietà specificate dall'utente, ad esempio la disponibilità di costi o risorse.

Sono disponibili più tipi di selezione host per controllare il numero di cluster a cui deve essere propagata la risorsa di Kubernetes:

  • PickAll posiziona le risorse in tutti i cluster membri disponibili. Questi criteri sono utili per posizionare carichi di lavoro dell'infrastruttura, ad esempio il monitoraggio del cluster o le applicazioni di creazione report.
  • PickFixed posiziona le risorse in un elenco specifico di cluster membri in base al nome.
  • PickN è l'opzione di selezione host più flessibile e consente di selezionare i 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à.

Criteri di selezione host PickAll

È possibile usare criteri di selezione host PickAll per distribuire un carico di lavoro in tutti i cluster membri della flotta (che corrisponde facoltativamente a un set di criteri).

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

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

Questi semplici criteri accettano lo spazio dei nomi test-deployment e tutte le risorse al suo interno e lo distribuiscono in tutti i cluster membri della flotta con l'etichetta environment specificata. Se si desiderano tutti i cluster, è possibile rimuovere completamente il termine affinity.

Criteri di selezione host PickFixed

Se si desidera distribuire un carico di lavoro in un set noto di cluster membri, è possibile usare criteri di selezione host PickFixed per selezionare i cluster in base al nome.

L'esempio seguente illustra come distribuire lo spazio dei nomi test-deployment nei cluster membri cluster1 e cluster2:

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

Criteri di selezione host PickN

I criteri di selezione host PickN costituiscono l'opzione più flessibile e consentono la selezione host delle risorse in un numero configurabile di cluster in base a vincoli di affinità e distribuzione della topologia.

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. È possibile impostare affinità obbligatorie e preferite. Le affinità obbligatorie impediscono la selezione host in cluster che non corrispondono alle affinità specificate, mentre le affinità preferite consentono di ordinare il set di cluster validi in fase di decisione della selezione host.

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/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
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 delle selezioni host dei cluster oltre i limiti della topologia per soddisfare i requisiti di disponibilità, ad esempio suddividendo le selezioni host tra aree o anelli di aggiornamento. È 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/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Per altre informazioni, vedere la documentazione di Flotta sui vincoli di distribuzione della topologia upstream.

Strategia di aggiornamento

Fleet usa una strategia di aggiornamento in sequenza per controllare la modalità di implementazione degli aggiornamenti in più selezioni host dei cluster.

L'esempio seguente illustra come configurare una strategia di aggiornamento in sequenza usando le impostazioni predefinite:

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

L'utilità di pianificazione distribuisce gli aggiornamenti a ogni cluster in sequenza, attendendo 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, ad esempio non conferma che i pod creati da una distribuzione diventano pronti.

Per altre informazioni, vedere la documentazione di Flotta sulla strategia di implementazione upstream.

Stato della selezione host

L'utilità di pianificazione di Flotta aggiorna i dettagli e lo stato delle decisioni di selezione host sull'oggetto ClusterResourcePlacement. È possibile visualizzare queste informazioni tramite il comando kubectl describe crp <name>. 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.

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

Modifiche di selezione host

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 aumento (incrementando numberOfClusters senza altre modifiche) collocano i carichi di lavoro solo nei nuovi cluster e non influiscono sulle selezioni host esistenti.
  • Modifiche del cluster, tra cui:
    • Un nuovo cluster che diventa idoneo potrebbe attivare la selezione host se soddisfa i criteri di selezione host, ad esempio criteri PickAll.
    • Un cluster con una selezione host rimosso dalla flotta tenterà di sostituire tutti i carichi di lavoro interessati senza influire sulle altre selezioni host.

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.

Tolleranze

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 tolleranza viene usata per tollerare uno o più taint specifici applicati al 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 tolleranze da un oggetto ClusterResourcePlacement dopo la creazione.

Per altre informazioni, vedere la documentazione di Flotta upstream.

Accedere all'API Kubernetes del cluster di risorse Flotta

Se è stata creata una risorsa di Gestione flotta Kubernetes di Azure con il cluster hub abilitato, è possibile usarla per controllare in modo centralizzato scenari come la propagazione degli oggetti di Kubernetes. Per accedere all'API Kubernetes del cluster di risorse Fleet, eseguire i passaggi descritti in Accedere all'API Kubernetes del cluster di risorse Flotta con Gestione flotta Kubernetes di Azure.

Passaggi successivi

Configurare la propagazione delle risorse di Kubernetes dal cluster hub ai cluster membri.