Zone di disponibilità in servizio Azure Kubernetes (servizio Azure Kubernetes)

Articolo
02/04/2025

Le zone di disponibilità consentono di proteggere le applicazioni e i dati dagli errori del data center. Le zone sono località fisiche esclusive all'interno di un'area di Azure. Ogni zona comprende uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete.

L'uso del servizio Azure Kubernetes con zone di disponibilità distribuisce fisicamente le risorse tra zone di disponibilità diverse all'interno di una singola area, migliorando l'affidabilità. La distribuzione di nodi in più zone non comporta costi aggiuntivi.

Questo articolo illustra come configurare le risorse del servizio Azure Kubernetes per l'uso di zone di disponibilità.

Risorse servizio Azure Kubernetes

Questo diagramma mostra le risorse di Azure create quando si crea un cluster del servizio Azure Kubernetes:

Piano di controllo del servizio Azure Kubernetes

Microsoft ospita il piano di controllo del servizio Azure Kubernetes, il server API Kubernetes e i servizi come scheduler e etcd come servizio gestito. Microsoft replica il piano di controllo in più zone.

Altre risorse del cluster vengono distribuite in un gruppo di risorse gestite nella sottoscrizione di Azure. Per impostazione predefinita, questo gruppo di risorse è preceduto da MC_, per Cluster gestito e contiene le risorse seguenti:

Pool di nodi

I pool di nodi vengono creati come set di scalabilità di macchine virtuali nella sottoscrizione di Azure.

Quando si crea un cluster del servizio Azure Kubernetes, è necessario e creato automaticamente un pool di nodi di sistema. Ospita pod di sistema critici, CoreDNS ad esempio e metrics-server. È possibile aggiungere più pool di nodi utente al cluster del servizio Azure Kubernetes per ospitare le applicazioni.

È possibile distribuire i pool di nodi in tre modi:

Spanning della zona
Zona allineata
Regional

Per il pool di nodi di sistema, il numero di zone usate viene configurato al momento della creazione del cluster.

Spanning della zona

Un set di scalabilità che estende la zona distribuisce i nodi in tutte le zone selezionate specificando queste zone con il --zones parametro .

# Create an AKS Cluster, and create a zone spanning System Nodepool in all three AZs, one node in each AZ
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1, 2, 3
# Add one new zone spanning User Nodepool, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a  --node-count 6 --zones 1, 2, 3

Il servizio Azure Kubernetes bilancia automaticamente il numero di nodi tra le zone.

Se si verifica un'interruzione di zona, i nodi all'interno della zona interessata possono essere interessati, mentre i nodi in altre zone di disponibilità rimangono invariati.

Zona allineata

Ogni nodo è allineato (bloccato) a una zona specifica. Per creare tre pool di nodi per un'area con tre zone di disponibilità:

# # Add three new zone aligned User Nodepools, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-x  --node-count 2 --zones 1
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-y  --node-count 2 --zones 2
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-z  --node-count 2 --zones 3

Questa configurazione può essere usata quando è necessaria una latenza inferiore tra i nodi. Offre anche un controllo più granulare sulle operazioni di ridimensionamento o quando si usa il ridimensionamento automatico del cluster.

Nota

Se un singolo carico di lavoro viene distribuito tra pool di nodi, è consigliabile impostare --balance-similar-node-groups su true per mantenere una distribuzione bilanciata di nodi tra zone per i carichi di lavoro durante le operazioni di aumento delle prestazioni.

Area (non con zone di disponibilità)

La modalità a livello di area viene usata quando l'assegnazione di zona non è impostata nel modello di distribuzione ("zones"=[] or "zones"=null).

In questa configurazione il pool di nodi crea istanze internazionali (non aggiunte alla zona) e inserisce in modo implicito le istanze in tutta l'area. Non esiste alcuna garanzia per il bilanciamento o la distribuzione tra zone o che le istanze si trovano nella stessa zona di disponibilità.

Nel raro caso di interruzione completa della zona, è possibile influire su qualsiasi o tutte le istanze all'interno del pool di nodi.

Per convalidare i percorsi dei nodi, eseguire il comando seguente:

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   eastus-1
aks-nodepool1-34917322-vmss000001   eastus   eastus-2
aks-nodepool1-34917322-vmss000002   eastus   eastus-3

Deployments

Pod

Kubernetes è a conoscenza dei zone di disponibilità di Azure e può bilanciare i pod tra nodi in zone diverse. Nel caso in cui una zona non sia più disponibile, Kubernetes sposta automaticamente i pod dai nodi interessati.

Come documentato in Etichette note, annotazioni e taint, Kubernetes usa l'etichetta topology.kubernetes.io/zone per distribuire automaticamente i pod in un controller o un servizio di replica tra le diverse zone disponibili.

Per visualizzare i nodi dei pod in esecuzione, eseguire il comando seguente:

  kubectl describe pod | grep -e "^Name:" -e "^Node:"

Il parametro 'maxSkew' descrive il grado in cui i pod potrebbero essere distribuiti in modo non uniforme. Supponendo che tre zone e tre repliche, l'impostazione di questo valore su 1 garantisce che ogni zona abbia almeno un pod in esecuzione:

kind: Pod
apiVersion: v1
metadata:
  name: myapp
spec:
  replicas: 3
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule # or ScheduleAnyway
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Archiviazione e volumi

Per impostazione predefinita, Kubernetes versioni 1.29 e successive usano Azure Managed Disks usando Archiviazione con ridondanza della zona (ZRS) per le attestazioni di volume persistente.

Questi dischi vengono replicati tra zone per migliorare la resilienza delle applicazioni e protegge i dati dagli errori del data center.

Esempio di un'attestazione di volume permanente che usa UNITÀ SSD Standard in archiviazione con ridondanza della zona:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-csi
  #storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 5Gi

Per le distribuzioni allineate alla zona, è possibile creare una nuova classe di archiviazione con il parametro impostato su Archiviazione con ridondanza locale.For zone aligned deployments, you can create a new storage class with the skuname parameter set to LRS (Local Redundant Storage). È quindi possibile usare la nuova classe di archiviazione nell'attestazione di volume persistente (PVC).

Anche se i dischi con ridondanza locale sono meno costosi, non sono ridondanti della zona e il collegamento di un disco a un nodo in una zona diversa non è supportato.

Esempio di classe di archiviazione SSD Standard LRS:

kind: StorageClass

metadata:
  name: azuredisk-csi-standard-lrs
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
  #skuname: PremiumV2_LRS

Servizi di bilanciamento del carico

Kubernetes distribuisce un Load Balancer Standard di Azure per impostazione predefinita, che bilancia il traffico in ingresso tra tutte le zone di un'area. Se un nodo non è più disponibile, il servizio di bilanciamento del carico reindirizza il traffico a nodi integri.

Servizio di esempio che usa Azure Load Balancer:

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080

Importante

Il servizio Load Balancer Basic verrà ritirato il 30 settembre 2025. Per altre informazioni, consultare l'annuncio ufficiale. Se attualmente si usa Load Balancer Basic, assicurarsi di eseguire l'aggiornamento a Load Balancer Standard prima della data di ritiro.

Limiti

Quando si usa zone di disponibilità, si applicano le limitazioni seguenti:

Vedere Quote, restrizioni relative alle dimensioni delle macchine virtuali e disponibilità dell'area nel servizio Azure Kubernetes.
Il numero di zone di disponibilità utilizzati non può essere modificato dopo la creazione del pool di nodi.
La maggior parte delle aree supporta zone di disponibilità. Un elenco è disponibile qui.

Passaggi successivi

Informazioni sul pool di nodi di sistema
Informazioni sui pool di nodi utente
Informazioni sui servizi di bilanciamento del carico
Procedure consigliate su continuità aziendale e ripristino di emergenza su AKS

Condividi tramite