Tworzenie klastra usługi Azure Kubernetes Service (AKS) korzystającego ze stref dostępności

  • Artykuł

W tym artykule pokazano, jak utworzyć klaster usługi AKS i dystrybuować składniki węzła w różnych strefach dostępności.

Zanim rozpoczniesz

Szablony usługi Azure Resource Manager i strefy dostępności

Podczas tworzenia klastra usługi AKS ze strefami dostępności przy użyciu szablonu usługi Azure Resource Manager należy pamiętać o następujących szczegółach:

  • Jeśli jawnie zdefiniujesz wartość null w szablonie, na przykład , szablon traktuje właściwość tak, "availabilityZones": nulljakby nie istnieje. Oznacza to, że klaster nie jest wdrażany w strefie dostępności.
  • Jeśli nie dołączysz "availabilityZones": właściwości do szablonu, klaster nie zostanie wdrożony w strefie dostępności.
  • Nie można zaktualizować ustawień stref dostępności w istniejącym klastrze, ponieważ zachowanie jest inne podczas aktualizowania klastra usługi AKS przy użyciu szablonów usługi Azure Resource Manager. Jeśli jawnie ustawisz wartość null w szablonie dla stref dostępności i zaktualizujesz klaster, nie zaktualizuje klastra pod kątem stref dostępności. Jeśli jednak pominięto właściwość stref dostępności ze składnią, taką jak "availabilityZones": [], wdrożenie próbuje wyłączyć strefy dostępności w istniejącym klastrze usługi AKS i zakończy się niepowodzeniem.

Tworzenie klastra usługi AKS w różnych strefach dostępności

Podczas tworzenia klastra przy użyciu az aks create polecenia parametr określa strefy dostępności do --zones wdrażania węzłów agenta. Strefy dostępności, do których są wdrażane składniki zarządzanej płaszczyzny sterowania, nie są kontrolowane przez ten parametr. Są one automatycznie rozmieszczone we wszystkich strefach dostępności (jeśli istnieją) w regionie podczas wdrażania klastra.

Poniższe przykładowe polecenia pokazują, jak utworzyć grupę zasobów i klaster usługi AKS z łącznie trzema węzłami. Jeden węzeł agenta w strefie 1, jeden na 2, a następnie jeden na 3.

  1. Utwórz grupę zasobów przy użyciu az group create polecenia .

    az group create --name $RESOURCE_GROUP --location $LOCATION

  2. Utwórz klaster usługi AKS przy użyciu az aks create polecenia z parametrem --zones .

    az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --generate-ssh-keys \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --node-count 3 \
    --zones 1 2 3

    Utworzenie klastra AKS może potrwać kilka minut.

    Podczas podejmowania decyzji o strefie, do której powinien należeć nowy węzeł, określona pula węzłów usługi AKS korzysta z najlepszego równoważenia nakładu pracy oferowanego przez bazowe zestawy skalowania maszyn wirtualnych platformy Azure. Pula węzłów usługi AKS jest "zrównoważona", gdy każda strefa ma taką samą liczbę maszyn wirtualnych lub +- jedną maszynę wirtualną we wszystkich innych strefach dla zestawu skalowania.

Weryfikowanie dystrybucji węzłów między strefami

Gdy klaster jest gotowy, wyświetl listę stref dostępności węzłów agenta w zestawie skalowania.

  1. Pobierz poświadczenia klastra usługi AKS przy użyciu az aks get-credentials polecenia :

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

  2. Wyświetl listę węzłów w klastrze przy użyciu kubectl describe polecenia i filtruj topology.kubernetes.io/zone wartość.

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

    W poniższych przykładowych danych wyjściowych przedstawiono trzy węzły rozproszone w określonym regionie i strefach dostępności, takich jak eastus2-1 dla pierwszej strefy dostępności i eastus2-2 dla drugiej strefy dostępności:

    Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3

W miarę dodawania kolejnych węzłów do puli agentów platforma Azure automatycznie dystrybuuje bazowe maszyny wirtualne w określonych strefach dostępności.

W przypadku platformy Kubernetes w wersji 1.17.0 lub nowszej usługa AKS używa topology.kubernetes.io/zone etykiety i przestarzałej failure-domain.beta.kubernetes.io/zone. Ten sam wynik można uzyskać z uruchomienia kubectl describe nodes polecenia w poprzednim przykładzie przy użyciu następującego polecenia:

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

Poniższy przykład przypomina dane wyjściowe z bardziej szczegółowymi szczegółami:

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

Weryfikowanie dystrybucji zasobników między strefami

Zgodnie z opisem w sekcji Dobrze znane etykiety, adnotacje i znaki, platforma Kubernetes używa topology.kubernetes.io/zone etykiety do automatycznego dystrybuowania zasobników w kontrolerze replikacji lub usłudze w różnych dostępnych strefach. W tym przykładzie przetestujesz etykietę i przeprowadź skalowanie klastra z 3 do 5 węzłów, aby sprawdzić, czy zasobnik został prawidłowo rozłożony.

  1. Przeskaluj klaster usługi AKS z 3 do 5 węzłów przy użyciu az aks scale polecenia z zestawem --node-count na wartość 5.

    az aks scale \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --node-count 5

  2. Po zakończeniu operacji skalowania sprawdź dystrybucję zasobnika w strefach przy użyciu następującego kubectl describe polecenia:

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

    W poniższych przykładowych danych wyjściowych przedstawiono pięć węzłów rozmieszczonych w określonym regionie i strefach dostępności, takich jak eastus2-1 dla pierwszej strefy dostępności i eastus2-2 dla drugiej strefy dostępności:

    Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3
Name:       aks-nodepool1-28993262-vmss000003
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000004
            topology.kubernetes.io/zone=eastus2-2

  3. Wdróż aplikację NGINX z trzema replikami przy użyciu następujących kubectl create deployment poleceń i kubectl scale :

    kubectl create deployment nginx --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
kubectl scale deployment nginx --replicas=3

  4. Sprawdź dystrybucję zasobników w różnych strefach przy użyciu następującego kubectl describe polecenia:

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

    W poniższych przykładowych danych wyjściowych przedstawiono trzy zasobniki rozproszone w określonym regionie i strefach dostępności, takie jak eastus2-1 dla pierwszej strefy dostępności i eastus2-2 dla drugiej strefy dostępności:

    Name:         nginx-6db489d4b7-ktdwg
Node:         aks-nodepool1-28993262-vmss000000/10.240.0.4
Name:         nginx-6db489d4b7-v7zvj
Node:         aks-nodepool1-28993262-vmss000002/10.240.0.6
Name:         nginx-6db489d4b7-xz6wj
Node:         aks-nodepool1-28993262-vmss000004/10.240.0.8

    Jak widać z poprzednich danych wyjściowych, pierwszy zasobnik jest uruchomiony w węźle 0 znajdującym się w strefie eastus2-1dostępności . Drugi zasobnik jest uruchomiony w węźle 2 odpowiadającym eastus2-3wartościom , a trzeci w węźle 4 w systemie eastus2-2. Bez żadnej dodatkowej konfiguracji platforma Kubernetes prawidłowo rozkłada zasobniki we wszystkich trzech strefach dostępności.

Następne kroki

W tym artykule opisano sposób tworzenia klastra usługi AKS przy użyciu stref dostępności. Aby uzyskać więcej informacji na temat klastrów o wysokiej dostępności, zobacz Najlepsze rozwiązania dotyczące ciągłości działania i odzyskiwania po awarii w usłudze AKS.