Zone di disponibilità nel Servizio Azure Kubernetes (AKS)

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 delle zone di disponibilità.

Risorse AKS

Questo diagramma mostra le risorse Azure che vengono create quando si crea un cluster AKS.

Piano di controllo AKS

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 il cluster gestito e contiene le risorse indicate nelle sezioni seguenti.

Pool di nodi

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

Quando crei un cluster di Azure Kubernetes Services (AKS), è necessario un pool di nodi di sistema che viene creato automaticamente. Ospita pod di sistema critici, ad esempio CoreDNS e metrics-server. È possibile aggiungere altri pool di nodi utente al cluster del servizio Azure Kubernetes per ospitare le applicazioni.

È possibile distribuire i pool di nodi in tre modi:

• Attraversamento della zona
• Allineato alla zona
• Regionale

Le zone del pool di nodi di sistema vengono configurate quando viene creato il cluster o il pool di nodi.

Che si estende attraverso le zone

In questa configurazione i nodi vengono distribuiti in tutte le zone selezionate. Queste zone vengono specificate usando il --zones parametro .

# Create an AKS cluster, and create a zone-spanning system node pool 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 node pool, 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

AKS bilancia automaticamente il numero di nodi tra le zone.

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

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

kubectl get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.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

Allineato alla zona specifica

In questa configurazione ogni nodo è allineato (aggiunto) a una zona specifica. Per creare tre pool di nodi per un'area con tre zone di disponibilità:

# # Add three new zone-aligned user node pools, 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.

Regionale (senza utilizzare zone di disponibilità)

La modalità a livello di area viene usata quando l'assegnazione di zona non è impostata nel modello di distribuzione , ad esempio "zones"=[] o "zones"=null.

In questa configurazione, il pool di nodi crea istanze regionali (non vincolate a una zona) e distribuisce automaticamente le istanze in tutta la regione. Non esiste alcuna garanzia che le istanze siano bilanciate o distribuite tra zone o che le istanze si trovino nella stessa zona di disponibilità.

Nel raro caso di un'interruzione completa della zona geografica, è possibile che qualche o tutte le istanze all'interno del pool di nodi siano interessate.

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

kubectl get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.topology\.kubernetes\.io/zone'

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   0
aks-nodepool1-34917322-vmss000001   eastus   0
aks-nodepool1-34917322-vmss000002   eastus   0

Distribuzioni

Pod

Kubernetes è a conoscenza delle 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 nel riferimento a Kubernetes Well-Known Etichette, Annotazioni e Taints, Kubernetes usa l'etichetta topology.kubernetes.io/zone per distribuire automaticamente i pod in un controller di replica o in un servizio tra le varie zone disponibili.

Per verificare quali pod e nodi sono in esecuzione, eseguire il comando seguente:

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

Il maxSkew parametro descrive il grado in cui i pod potrebbero essere distribuiti in modo non uniforme. Supponendo che ci siano tre zone e tre repliche, impostare questo valore su 1 assicurandosi che ogni zona abbia almeno un pod in esecuzione:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-app
      containers:
      - name: my-container
        image: my-image

Archiviazione e volumi

Per impostazione predefinita, le versioni di Kubernetes dalla 1.29 in poi utilizzano Azure Managed Disks con archiviazione a ridondanza di zona per le Richieste di Volume Persistente.

Questi dischi vengono replicati tra zone per migliorare la resilienza delle applicazioni. Questa azione consente di proteggere i dati dagli errori del data center.

L'esempio seguente mostra una richiesta di volume persistente che utilizza l'SSD Standard di Azure nell'archiviazione a ridondanza di 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 skuname parametro impostato su LRS (archiviazione con ridondanza locale). È quindi possibile usare la nuova classe di archiviazione nel PersistentVolumeClaim.

Anche se i dischi di archiviazione 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.

L'esempio seguente mostra una classe di archiviazione SSD Standard con ridondanza locale:

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 Azure Load Balancer Standard 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.

Un 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

Limiti

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

• Vedere Quote, restrizioni relative alle dimensioni delle macchine virtuali e disponibilità della regione in AKS.
• Il numero di zone di disponibilità usate non può essere modificato dopo la creazione del pool di nodi.
• La maggior parte delle aree supporta le zone di disponibilità. Vedere un elenco di aree.

Contenuti correlati

• Informazioni sui pool di nodi di sistema.
• Informazioni sui pool di nodi utente.
• Informazioni sui servizi di bilanciamento del carico.
• Ottenere le procedure consigliate per la continuità operativa e il recupero dei disastri in AKS.