Propagazione delle risorse di Kubernetes dal cluster hub ai cluster membri
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
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 prod-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 prod-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.
- Le operazioni di aumento (incrementando
- 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.
- Un nuovo cluster che diventa idoneo potrebbe attivare la selezione host se soddisfa i criteri di selezione host, ad esempio criteri
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 esempioNoSchedule
.operator
: operatore della tolleranza, ad esempioExists
oEqual
.
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.
Azure Kubernetes Service