Konfigurieren von Verfügbarkeitszonen in Azure Kubernetes Service (AKS)

Verfügbarkeitszonen helfen dabei, Ihre Anwendungen und Daten vor Rechenzentrumsausfällen zu schützen. Zonen sind eindeutige physische Standorte in einer Azure-Region. Jede Zone umfasst eines oder mehrere Rechenzentren, die mit unabhängiger Stromversorgung, Kühlung und unabhängigem Netzwerk ausgestattet sind.

Die Verwendung von Azure Kubernetes Service (AKS) mit Verfügbarkeitszonen verteilt Ressourcen physisch über verschiedene Verfügbarkeitszonen innerhalb einer einzelnen Region und verbessert die Zuverlässigkeit. Das Bereitstellen von Knoten in mehreren Zonen verursacht keine zusätzlichen Kosten. In diesem Artikel erfahren Sie, wie Sie AKS-Ressourcen für die Verwendung von Verfügbarkeitszonen mithilfe der Azure CLI oder Terraform konfigurieren.

Voraussetzungen

• Ein aktives Azure-Abonnement. Wenn Sie noch kein Azure-Abonnement haben, erstellen Sie ein kostenloses Konto, bevor Sie beginnen.

• Legen Sie ihren Abonnementkontext mithilfe des az account set Befehls fest. Beispiel:

  az account set --subscription "00000000-0000-0000-0000-000000000000"
  

• Azure CLI installiert und konfiguriert. Installationsanweisungen finden Sie unter Installieren der Azure CLI.

• kubectl installiert. Sie können es lokal mit dem az aks install-cli Befehl installieren.

Einschränkungen und Überlegungen

Beachten Sie bei der Verwendung von Verfügbarkeitszonen in AKS die folgenden Einschränkungen und Überlegungen:

• Überprüfen Sie Kontingente, Größenbeschränkungen für virtuelle Maschinen und Verfügbarkeit von Regionen in AKS.
• Die meisten Azure-Regionen unterstützen Verfügbarkeitszonen. Weitere Informationen finden Sie in der Liste der Azure-Regionen.
• Sie können die Anzahl der Verfügbarkeitszonen nicht ändern , nachdem Sie einen Knotenpool erstellt haben. Um die Anzahl der Verfügbarkeitszonen zu ändern, müssen Sie einen neuen Knotenpool mit der gewünschten Anzahl von Zonen erstellen und Ihre Workloads in den neuen Knotenpool migrieren.

AKS-Clusterkomponenten

Das folgende Diagramm zeigt die verschiedenen Komponenten eines AKS-Clusters, einschließlich AKS-Komponenten, die von Microsoft- und AKS-Komponenten in Ihrem Azure-Abonnement gehostet werden:

AKS-Steuerungsebene

Microsoft hostet die AKS-Kontrollebene, den Kubernetes-API-Server und Dienste wie scheduler und etcd als verwaltete Dienste. Microsoft repliziert die Steuerungsebene in mehreren Zonen.

Andere Ressourcen Ihres Clusters werden in einer verwalteten Ressourcengruppe in Ihrem Azure-Abonnement bereitgestellt. Standardmäßig wird dieser Ressourcengruppe MC_ (für verwaltetes Cluster) vorangestellt und enthält die in den folgenden Abschnitten beschriebenen Ressourcen.

Knotenpools

Knotenpools werden als Skalierungsgruppen für virtuelle Computer in Ihrem Azure-Abonnement erstellt.

Wenn Sie einen AKS-Cluster erstellen, ist ein Systemknotenpool erforderlich. Dieser Knotenpool wird automatisch erstellt und hostet kritische System pods wie CoreDNS und metrics-server. Sie können Ihrem AKS-Cluster weitere Benutzerknotenpools hinzufügen, um Ihre Anwendungen zu hosten.

Sie können Knotenpools auf drei Arten bereitstellen: zonenübergreifend, zonenausgerichtet oder regional (ohne Verfügbarkeitszonen zu verwenden).

Das folgende Diagramm zeigt die Verteilung von Knoten über Verfügbarkeitszonen in jedem der drei Modelle:

Die Systemknotenpoolzonen werden beim Erstellen eines Cluster- oder Knotenpools konfiguriert.

Zonenübergreifende Knotenpools

In zonenübergreifenden Knotenpools werden Knoten über alle ausgewählten Zonen verteilt. AKS gleicht automatisch die Anzahl der Knoten zwischen Zonen ab. Wenn ein Zonenausfall auftritt, können Knoten innerhalb der betroffenen Zone beeinträchtigt werden, aber Knoten in anderen Verfügbarkeitszonen bleiben davon unberührt.

Zonen-ausgerichtete Knotenpools

In dieser Konfiguration wird jeder Knoten an eine bestimmte Zone ausgerichtet (angeheftet). Sie können diese Konfiguration verwenden, wenn Sie eine niedrigere Latenz zwischen Knoten benötigen, genauere Kontrolle über Skalierungsvorgänge oder wenn Sie die Clusterautoskalierung verwenden.

Regionale Knotenpools

Der regionale Modus wird verwendet, wenn Sie keine Zonenzuweisung in der Bereitstellungsvorlage festlegen (zum Beispiel "zones"=[] oder "zones"=null).

In dieser Konfiguration erstellt der Knotenpool regionale (nicht zonenanheftete) Instanzen und platziert Instanzen implizit in der gesamten Region. Es gibt keine Garantie dafür, dass Instanzen über Zonen hinweg ausgeglichen oder verteilt sind oder sich Instanzen in derselben Verfügbarkeitszone befinden. Im seltenen Fall eines vollständigen Zonenausfalls könnten einige oder alle Instanzen innerhalb des Knotenpools betroffen sein.

Bereitstellungen

Azure Kubernetes Service (AKS) verwendet Pods, Speicher und Volumes sowie Lastenausgleicher, um eine zonenübergreifende hohe Verfügbarkeit für Ihre Anwendungen aufrechtzuerhalten.

Pods

Kubernetes kennt die Azure-Verfügbarkeitszonen und kann die Last der Pods auf Knoten in verschiedenen Zonen verteilen. Wenn eine Zone nicht verfügbar ist, entfernt Kubernetes automatisch die Pods von den betroffenen Knoten.

Wie in der Kubernetes-Referenz Well-Known Labels, Annotations, and Taints (Bekannte Bezeichnungen, Anmerkungen und Taints) dokumentiert, wird in Kubernetes die Bezeichnung topology.kubernetes.io/zone zum automatischen Verteilen von Pods in einem Replikationscontroller oder Replikationsdienst in den verschiedenen verfügbaren Zonen verwendet.

Der maxSkew Parameter beschreibt den Grad, in dem Pods ungleich verteilt werden können. Angenommen, es gibt drei Zonen und drei Replikate: Durch Festlegen dieses Wertes auf 1 wird sichergestellt, dass in jeder Zone mindestens ein Pod läuft. Beispiel:

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

Speicher und Volumes

Standardmäßig verwenden Kubernetes-Versionen 1.29 und höher Azure Managed Disks, indem zonenredundanter Speicher für Persistent Volume Claims (PVCs) verwendet wird. Diese Datenträger werden zwischen Zonen repliziert, um die Resilienz Ihrer Anwendungen zu verbessern.

Das folgende Beispiel zeigt ein PVC, das Azure Standard SSD im zonenredundanten Speicher verwendet:

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

Für zonenorientierte Bereitstellungen können Sie eine neue Speicherklasse erstellen, deren skuname Parameter auf LRS (lokal redundanter Speicher) festgelegt ist. Anschließend können Sie die neue Speicherklasse in Ihrem PVC verwenden.

Obwohl lokal redundante Speicherdatenträger weniger teuer sind, sind sie nicht zonenredundant, und das Anfügen eines Datenträgers an einen Knoten in einer anderen Zone wird nicht unterstützt.

Das folgende Beispiel zeigt eine lokal redundante Speicherstandard-SSD-Speicherklasse:

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

Lastenausgleichsgeräte

Kubernetes stellt standardmäßig azure Standard Load Balancer bereit, der eingehenden Datenverkehr über alle Zonen in einer Region verteilt. Wenn ein Knoten nicht verfügbar ist, leitet der Lastenausgleich den Verkehr auf intakte Knoten um.

Das folgende Beispiel zeigt einen Dienst, der Azure Load Balancer verwendet:

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

# Create an AKS cluster with a zone-spanning system node pool in all three availability zones with one node in each availability zone
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 with two nodes in each availability zone
az aks nodepool add \
  --resource-group example-rg \
  --cluster-name example-cluster \
  --name userpoola  \
  --node-count 6 \
  --zones 1 2 3

# Add three new zone-aligned user node pools with two nodes in each
az aks nodepool add \
  --resource-group example-rg \
  --cluster-name example-cluster \
  --name userpoolx  \
  --node-count 2 \
  --zones 1

az aks nodepool add \
  --resource-group example-rg \
  --cluster-name example-cluster \
  --name userpooly  \
  --node-count 2 \
  --zones 2

az aks nodepool add \
  --resource-group example-rg \
  --cluster-name example-cluster \
  --name userpoolz  \
  --node-count 2 \
  --zones 3

resource "azurerm_kubernetes_cluster" "example" {
  name                = "aks-zones"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  dns_prefix          = "akszones"
  default_node_pool {
    name       = "system"
    node_count = 1
    vm_size    = "Standard_DS2_v2"
    zones      = ["1", "2", "3"]
  }
  identity {
    type = "SystemAssigned"
  }
}

resource "azurerm_kubernetes_cluster_node_pool" "zonespan" {
  name                  = "userpool"
  kubernetes_cluster_id = azurerm_kubernetes_cluster.example.id
  vm_size               = "Standard_DS2_v2"
  node_count            = 2
  zones                 = ["1", "2", "3"]
}

resource "azurerm_kubernetes_cluster_node_pool" "zone1" {
  name                  = "userpool1"
  kubernetes_cluster_id = azurerm_kubernetes_cluster.example.id
  vm_size               = "Standard_DS2_v2"
  node_count            = 1
  zones                 = ["1"]
}
resource "azurerm_kubernetes_cluster_node_pool" "zone2" {
  name                  = "userpool2"
  kubernetes_cluster_id = azurerm_kubernetes_cluster.example.id
  vm_size               = "Standard_DS2_v2"
  node_count            = 1
  zones                 = ["2"]
}
resource "azurerm_kubernetes_cluster_node_pool" "zone3" {
  name                  = "userpool3"
  kubernetes_cluster_id = azurerm_kubernetes_cluster.example.id
  vm_size               = "Standard_DS2_v2"
  node_count            = 1
  zones                 = ["3"]
}

terraform init

terraform plan

terraform apply

Überprüfen der Konfiguration der Verfügbarkeitszone

Nachdem Sie Ihre AKS-Cluster- und Knotenpools erstellt haben, können Sie überprüfen, ob Ihre Knoten über Verfügbarkeitszonen verteilt werden, indem Sie den az aks show Befehl mit dem --query Parameter verwenden, um die Ausgabe zu filtern. Beispiel:

az aks show \
 --name example-cluster \
 --resource-group example-rg \
 --query agentPoolProfiles[].availabilityZones \
 --output tsv

Standorte von Knoten überprüfen

Überprüfen Sie die Verteilung von Knoten über Verfügbarkeitszonen mithilfe des folgenden kubectl get nodes Befehls:

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

Beispielausgabe:

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

Auflisten ausgeführter Pods und Knoten

Überprüfen Sie, welche Pods und Knoten mit dem kubectl describe Befehl laufen. Beispiel:

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

Verwandte Inhalte

Weitere Informationen zur Zuverlässigkeit in AKS finden Sie in den folgenden Artikeln:

• Zuverlässigkeit in AKS
• Verwalten von Systemknotenpools in AKS
• Öffentliche Standard-Load-Balancer in AKS verwenden
• Bewährte Methoden für Geschäftskontinuität und Notfallwiederherstellung in AKS