Migrowanie klastrów AKS Automatic i zarządzanych systemowych pul węzłów

Dotyczy: ✔️ AKS Automatic AKS Standard ✔️

W tym artykule pokazano, jak przeprowadzić migrację klastrów automatycznych usługi AKS między obsługiwaną pulą węzłów systemu zarządzanego a konfiguracjami usługi AKS Standard.

Obsługiwane ścieżki migracji

Korzystając z zarządzanych pul węzłów systemowych, usługa AKS za Ciebie aprowizuje, skaluje i uaktualnia pule węzłów systemowych oraz składniki systemu, a także izoluje je od obciążeń. Klastry automatyczne AKS są również wspierane przez umowę SLA dotyczącą gotowości podu i umowę SLA dotyczącą dostępności. Aby uzyskać więcej informacji, zobacz Omówienie klastrów automatycznych usługi AKS z zarządzanymi pulami węzłów systemu.

Migracja z klastra AKS Automatic z zarządzanymi systemowymi pulami węzłów do klastra AKS Standard

Jak działa migracja

Automatyczny klaster AKS z zarządzanymi pulami węzłów systemowych uruchamia swoje składniki systemowe w pulach węzłów systemowych, które usługa AKS aprowizuje, skaluje i aktualizuje za Ciebie.

Aby przeprowadzić migrację z usługi AKS Automatic do usługi AKS Standard, wykonaj następujące ogólne kroki:

1. Dodaj zarządzaną samodzielnie pulę węzłów systemowych do klastra AKS Automatic.
2. Zaktualizuj jednostkę SKU klastra z automatic do base.

Po zaktualizowaniu warstwy SKU klaster działa jako klaster AKS w warstwie Standard, a składniki systemowe działają w dodanej i zarządzanej przez Ciebie systemowej puli węzłów.

Przejdź do klastra AKS w warstwie Standard

1. Dodaj samodzielnie zarządzaną pulę węzłów systemowych do istniejącego klastra AKS Automatic za pomocą polecenia az aks nodepool add. Ustaw tryb puli węzłów na System, aby po migracji można było uruchamiać składniki systemowe.

   az aks nodepool add \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --name systempool \
       --mode System \
       --node-count 3
   

2. Zaktualizuj SKU klastra z automatic do base za pomocą polecenia az aks update.

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --sku base
   

Weryfikowanie migracji

1. Potwierdź, że klaster używa teraz jednostki SKU base, używając polecenia az aks show.

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "sku" \
       --output table
   

2. Wyświetl listę pul węzłów w klastrze, aby potwierdzić, że Twoja samodzielnie zarządzana systemowa pula węzłów jest obecna i działa w trybie System, używając polecenia az aks nodepool list.

   az aks nodepool list \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --query "[].{Name:name, Mode:mode, Count:count}" \
       --output table
   

Migracja z klastra AKS Automatic bez zarządzanych pul węzłów systemowych do AKS Automatic z zarządzanymi pulami węzłów systemowych (wersja zapoznawcza)

Usługa AKS Automatic obsługuje migrację w wersji zapoznawczej z pul węzłów systemu niezarządzanego do zarządzanych pul węzłów systemu w regionach, w których zarządzane pule węzłów systemu są ogólnie dostępne. Ta migracja utrzymuje klaster w warstwie SKU automatic i przenosi składniki systemowe AKS do puli węzłów systemowych zarządzanej przez usługę AKS.

Wymagania wstępne

• Istniejący klaster automatyczny AKS bez zarządzanych pul węzłów systemowych.
• Azure CLI w wersji 2.86.0 lub nowszej. Aby dowiedzieć się, jaka wersja jest używana, uruchom polecenie az --version. Jeśli musisz zainstalować lub uaktualnić, zobacz Install Azure CLI.
• Najnowsza wersja rozszerzenia Azure CLI.
• Flaga funkcji Microsoft.ContainerService/NonHoboToHoboConversionPreview zarejestrowana w Twojej subskrypcji.

Zarejestruj flagę funkcji NonHoboToHoboConversionPreview przy użyciu polecenia az feature register.

az feature register \
    --namespace Microsoft.ContainerService \
    --name NonHoboToHoboConversionPreview

Sprawdź stan rejestracji przy użyciu az feature show polecenia :

az feature show \
    --namespace Microsoft.ContainerService \
    --name NonHoboToHoboConversionPreview \
    --query properties.state \
    --output tsv

Zaczekaj, aż polecenie powróci Registered przed kontynuowaniem. Następnie odśwież rejestrację dostawcy Microsoft.ContainerService zasobów.

az provider register --namespace Microsoft.ContainerService

Zainstaluj lub zaktualizuj aks-preview rozszerzenie:

az extension add --name aks-preview
az extension update --name aks-preview

Migrowanie klastra sieci wirtualnej zarządzanej przez usługę AKS

W przypadku automatycznego klastra AKS korzystającego z sieci zarządzanej przez AKS zmigruj do zarządzanych pul węzłów systemowych za pomocą polecenia az aks update z parametrem --enable-hosted-system:

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --enable-hosted-system

Migrowanie niestandardowego klastra sieci wirtualnej

W przypadku automatycznego klastra AKS korzystającego z niestandardowej sieci wirtualnej podaj podsieć dla zarządzanej puli węzłów systemowych przy użyciu parametru --system-node-subnet-id. Podsieć węzła systemu musi:

• Należy do tej samej sieci wirtualnej i regionu co klaster.
• Co najmniej /26.
• Nie należy delegować do innej usługi.
• Musi być inna niż podsieć węzła.

Parametr --node-subnet-id jest opcjonalny. Jeśli jej nie podasz, usługa AKS użyje istniejącej podsieci dla puli węzłów systemowych.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --enable-hosted-system \
    --system-node-subnet-id "${SYSTEM_NODE_SUBNET_ID}" \
    --node-subnet-id "${NODE_SUBNET_ID}"

Weryfikowanie migracji

Potwierdź, że klaster używa zarządzanych systemowych pul węzłów, za pomocą polecenia az aks show:

az aks show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --query hostedSystemProfile \
    --output json

Następujące przykładowe dane wyjściowe pokazują właściwość ustawioną hostedSystemProfile.enabled na true:

{
  "enabled": true,
  "nodeSubnetId": "<node-subnet-resource-id>",
  "systemNodeSubnetId": "<system-node-subnet-resource-id>"
}

Migrowanie z klastra usługi AKS w warstwie Standardowa do klastra AKS Automatic z zarządzanymi pulami węzłów systemowych (wersja zapoznawcza)

Usługa AKS obsługuje migrację w wersji zapoznawczej z klastrów AKS Standard (base SKU) do klastrów AKS Automatic z zarządzanymi pulami węzłów systemu w regionach, w których zarządzane pule węzłów systemu są ogólnie dostępne.

Aby przeprowadzić migrację, należy najpierw skonfigurować klaster usługi AKS w warstwie Standardowa tak, aby był zgodny z konfiguracją AKS Automatic, a następnie zaktualizować SKU klastra. Większość pracy polega na przygotowaniu klastra. Uzupełnij poniższe sekcje w kolejności, ponieważ kilka ustawień zależy od innych skonfigurowanych jako pierwsze.

Przed rozpoczęciem

• Istniejący klaster AKS Standard (base SKU). Aby uzyskać ogólne wymagania i ograniczenia AKS Automatic, zobacz Szybki start: tworzenie klastra automatycznego Azure Kubernetes Service (AKS) i omówienie klastrów automatycznych usługi AKS z zarządzanymi pulami węzłów systemu.
• Azure CLI w wersji 2.86.0 lub nowszej oraz najnowsza wersja rozszerzenia aks-preview.
• Flaga funkcji Microsoft.ContainerService/NonHoboToHoboConversionPreview zarejestrowana w Twojej subskrypcji. Aby zarejestrować flagę funkcji i zainstalować rozszerzenie, wykonaj kroki opisane w temacie Wymagania wstępne.

Ustaw zmienne środowiskowe dla klastra:

export RESOURCE_GROUP="<resource-group>"
export RESOURCE_NAME="<cluster-name>"
export NODE_RESOURCE_GROUP=$(az aks show --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}" --query nodeResourceGroup --output tsv)

Wymagania dotyczące migracji

Aby można było zaktualizować jednostkę SKU, klaster musi spełniać następujące wymagania. Niektóre wymagania różnią się w zależności od tego, czy klaster korzysta z sieci wirtualnej zarządzanej przez usługę AKS, czy niestandardowej sieci wirtualnej. Te ustawienia można skonfigurować przy użyciu portalu Azure, Azure CLI, szablonu usługi ARM lub innych narzędzi. W pozostałej części tego artykułu przedstawiono kroki Azure CLI w kolejności, w której należy je zastosować.

Zaplanuj migrację

1. Określ, czy klaster korzysta z sieci wirtualnej zarządzanej przez usługę AKS, czy niestandardowej sieci wirtualnej. Jeśli następujące polecenie zwraca nazwę sieci wirtualnej, klaster używa sieci wirtualnej zarządzanej przez usługę AKS. Jeśli nic nie zwróci, klaster używa niestandardowej sieci wirtualnej.

   az network vnet list --resource-group "${NODE_RESOURCE_GROUP}" --query "[].name" --output tsv
   

   Kilka kroków w tym artykule różni się w zależności od typu sieci wirtualnej.

2. Sprawdź bieżącą wtyczkę sieciową klastra, typ komunikacji wychodzącej, jednostkę SKU modułu równoważenia obciążenia i poziom ograniczeń grupy zasobów węzła:

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "{networkPlugin:networkProfile.networkPlugin, networkPluginMode:networkProfile.networkPluginMode, outboundType:networkProfile.outboundType, loadBalancerSku:networkProfile.loadBalancerSku, nrgRestrictionLevel:nodeResourceGroupProfile.restrictionLevel}" \
       --output table
   

   • Wtyczka sieciowa: musi być azure z trybem overlaywtyczki . Jeśli klaster używa rozwiązania kubenet lub Azure CNI bez Overlay, przed kontynuowaniem zaktualizuj go do Azure CNI Overlay. Aby uzyskać więcej informacji, zobacz Aktualizowanie trybu IPAM na Azure CNI Overlay.
   • SKU modułu równoważenia obciążenia: musi mieć wartość standard. Jeśli klaster nadal używa polecenia basic, zaktualizuj go za pomocą az aks update --load-balancer-sku standardpolecenia.
   • Poziom ograniczeń grupy zasobów węzła: w przypadku sieci wirtualnej zarządzanej przez usługę AKS należy utworzyć podsieć w grupie zasobów węzła. Jeśli poziom ograniczeń to ReadOnly, ustaw go na Unrestricted przed kontynuowaniem. Zablokuj go ponownie w późniejszym kroku.

3. Przejrzyj zmiany, które zakłócają działające obciążenia lub dostęp, i zaplanuj okno obsługi:

   • Zmiana typu ruchu wychodzącego zmienia wyjściowe adresy IP klastra. Zaktualizuj wszystkie reguły zapory zezwalające na ruch z klastra.
   • Włączenie integracji z siecią wirtualną serwera interfejsu API zmienia adres IP serwera interfejsu API i wymaga ponownego uruchomienia klastra. Ta zmiana jest trwała.
   • Zmiana ustawień płaszczyzny danych sieci, jednostki SKU systemu operacyjnego i dostępu SSH powoduje ponowne utworzenie węzłów.
   • Wyłączenie kont lokalnych usuwa statyczne poświadczenia kubeconfig. Przed ich wyłączeniem upewnij się, że masz dostęp za pośrednictwem Microsoft Entra ID i roli RBAC platformy Azure, takiej jak Azure Kubernetes Service RBAC Cluster Admin.
   • Migracja umożliwia Deployment Safeguards w trybie Enforce z bazowymi standardami Pod Security Standards. Wdrożenia, które nie są zgodne, są odrzucane. Przestrzenie nazw można wykluczyć, ale nie można przełączyć poziomu całego klastra na Warn. Przed migracją przejrzyj obciążenia robocze. Aby uzyskać więcej informacji, zobacz Korzystanie z zabezpieczeń wdrażania.

Przygotowanie sieci klastra

1. Typ ruchu wychodzącego: w przypadku sieci wirtualnej zarządzanej przez usługę AKS typ ruchu wychodzącego musi być zarządzaną bramą NAT. Typ loadBalancer ruchu wychodzącego nie jest obsługiwany. W razie potrzeby zaktualizuj typ ruchu wychodzącego:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --outbound-type managedNATGateway \
       --outbound-type-sku StandardV2
   

   W przypadku niestandardowej sieci wirtualnej obsługiwany jest dowolny typ ruchu wychodzącego i nie jest wymagana żadna zmiana. Aby uzyskać więcej informacji, zobacz Aktualizowanie parametru outboundType po utworzeniu klastra.

2. Tożsamość klastra: w przypadku sieci wirtualnej zarządzanej przez usługę AKS zachowaj tożsamość zarządzaną przypisaną przez system klastra. W przypadku niestandardowej sieci wirtualnej klaster musi używać tożsamości zarządzanej przypisanej przez użytkownika, która ma rolę Network Contributor w sieci wirtualnej. W razie potrzeby przypisz tożsamość:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --enable-managed-identity \
       --assign-identity "${IDENTITY_RESOURCE_ID}" \
       --yes
   

   Zastąp IDENTITY_RESOURCE_ID identyfikatorem zasobu tożsamości zarządzanej przypisanej przez użytkownika. Aby uzyskać więcej informacji, zobacz Użyj tożsamości zarządzanej przypisanej przez użytkownika.

3. Podsieć serwera interfejsu API: utwórz dedykowaną podsieć dla serwera interfejsu API w tej samej sieci wirtualnej co węzły. Podsieć musi być oddzielona od podsieci węzła, mieć co najmniej /28 i być delegowana do Microsoft.ContainerService/managedClusters.

   W przypadku sieci wirtualnej zarządzanej przez usługę AKS utwórz podsieć w sieci wirtualnej w grupie zasobów węzła:

   export VNET_NAME=$(az network vnet list --resource-group "${NODE_RESOURCE_GROUP}" --query "[0].name" --output tsv)
   
   export APISERVER_SUBNET_ID=$(az network vnet subnet create \
       --resource-group "${NODE_RESOURCE_GROUP}" \
       --vnet-name "${VNET_NAME}" \
       --name apiserver-subnet \
       --address-prefixes "<unused-address-range>" \
       --delegations Microsoft.ContainerService/managedClusters \
       --query id --output tsv)
   

   W przypadku niestandardowej sieci wirtualnej zamiast tego utwórz podsieć we własnej sieci wirtualnej i ustaw APISERVER_SUBNET_ID na jej identyfikator zasobu.

4. Integracja serwera API z siecią VNet: włącz integrację serwera API z utworzoną podsiecią VNet, a następnie uruchom ponownie klaster:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --enable-apiserver-vnet-integration \
       --apiserver-subnet-id "${APISERVER_SUBNET_ID}"
   
   az aks stop --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   az aks start --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   

   Aby uzyskać więcej informacji, zobacz Konwertowanie istniejącego klastra usługi AKS Standard na integrację z siecią wirtualną serwera api.

5. Płaszczyzna danych sieci: zaktualizuj płaszczyznę danych sieci na Cilium. To polecenie ustawia również politykę sieciową na Cilium.

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --network-dataplane cilium
   

   Aby uzyskać więcej informacji, zobacz Azure CNI Powered by Cilium.

Przygotuj pulę węzłów systemowych i aprowizację węzłów

1. Efemeryczny dysk systemu operacyjnego: pula węzłów systemowych musi używać efemerycznego dysku systemu operacyjnego. Sprawdź bieżący typ dysku systemu operacyjnego:

   az aks nodepool list \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --query "[?mode=='System'].{name:name, osDiskType:osDiskType}" \
       --output table
   

   Nie można zmienić typu dysku systemu operacyjnego istniejącej puli węzłów. Jeśli pula węzłów systemu używa Managed dysku systemu operacyjnego, dodaj nową pulę węzłów systemowych za pomocą --mode System --node-osdisk-type Ephemeral --os-sku AzureLinux --ssh-access disabledpolecenia , przenieś do niej obciążenia systemowe, a następnie usuń starą pulę węzłów. Następnie możesz pominąć następny krok.

2. SKU systemu operacyjnego i dostęp za pomocą protokołu SSH: zaktualizuj pulę węzłów systemu, aby użyć Azure Linux i wyłączyć dostęp za pomocą protokołu SSH:

   az aks nodepool update \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --name "<system-node-pool-name>" \
       --os-sku AzureLinux \
       --ssh-access disabled \
       --yes
   

   To polecenie ponownie tworzy obraz puli węzłów. Poczekaj na zakończenie, zanim wprowadzisz inne zmiany w puli węzłów. Aby uzyskać więcej informacji, zobacz Korzystanie z hosta kontenerów Azure Linux i Zarządzanie dostępem SSH w węzłach klastra AKS.

3. Tryb aprowizacji węzłów: Włącz tryb automatycznej aprowizacji węzłów:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --node-provisioning-mode Auto
   

   Po włączeniu trybu automatycznego nie można wrócić do trybu ręcznego bez uprzedniego usunięcia wszystkich węzłów z automatyczną aprowizacją. Aby uzyskać więcej informacji, zobacz Automatyczne aprowizowanie węzłów.

Włącz wymagane funkcje i dodatki

1. Zaktualizuj warstwę klastra do warstwy Standard i włącz dodatki Azure Policy i Azure Key Vault Secrets Provider z rotacją secrets:

   az aks update --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}" --tier standard
   
   az aks enable-addons \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --addons azure-policy,azure-keyvault-secrets-provider \
       --enable-secret-rotation
   

2. Włącz pozostałe wymagane funkcje:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --auto-upgrade-channel stable \
       --node-os-upgrade-channel NodeImage \
       --enable-workload-identity \
       --enable-oidc-issuer \
       --enable-aad \
       --enable-azure-rbac \
       --disable-local-accounts \
       --enable-image-cleaner \
       --enable-vpa \
       --enable-keda \
       --yes
   

Zablokuj grupę zasobów węzła

Ustaw poziom ograniczeń grupy zasobów węzła na ReadOnly. Wykonaj ten krok ostatni, ponieważ blokada blokuje zmiany zasobów w grupie zasobów węzła, w tym utworzoną wcześniej podsieć serwera interfejsu API.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --nrg-lockdown-restriction-level ReadOnly

Aby uzyskać więcej informacji, zobacz Blokada grupy zasobów węzła.

Migruj klaster do usługi AKS Automatic

Jeśli jakiekolwiek wymaganie jest nadal niezaspokojone, polecenie migracji zakończy się niepowodzeniem i wyświetli listę niezaspokojonych wymagań. Niektóre testy są uruchamiane dopiero, gdy wcześniejsze zakończą się powodzeniem, dlatego rozwiąż wymienione elementy i uruchom polecenie ponownie, aż zakończy się powodzeniem.

wirtualna sieć zarządzana przez usługę AKS

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --sku automatic \
    --enable-hosted-system

Niestandardowa sieć wirtualna

Podaj podsieć dla puli węzłów systemowych zarządzanego systemu przy użyciu parametru --system-node-subnet-id. Aby uzyskać informacje o wymaganiach dotyczących podsieci, zobacz Migrowanie istniejącego klastra automatycznego usługi AKS do zarządzanych pul węzłów systemowych. Parametr --node-subnet-id jest opcjonalny. Jeśli jej nie podasz, usługa AKS użyje istniejącej podsieci dla puli węzłów systemowych.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --sku automatic \
    --enable-hosted-system \
    --system-node-subnet-id "${SYSTEM_NODE_SUBNET_ID}" \
    --node-subnet-id "${NODE_SUBNET_ID}"

Weryfikowanie migracji

1. Upewnij się, że klaster używa automatic jednostki SKU i Standard warstwy oraz że aktualizacja zakończyła się pomyślnie:

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "{sku:sku, provisioningState:provisioningState}" \
       --output json
   

   Potwierdź, że sku.name to Automatic, sku.tier to Standard, i provisioningState ma wartość Succeeded.

2. Upewnij się, że klaster używa zarządzanych pul węzłów systemowych:

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query hostedSystemProfile \
       --output json
   

   Potwierdź hostedSystemProfile.enabled , że to true. W przypadku niestandardowej sieci wirtualnej elementy systemNodeSubnetId i nodeSubnetId pokazują identyfikatory zasobów podsieci. W przypadku sieci wirtualnej zarządzanej przez usługę AKS te wartości są puste: null.

3. Pobierz poświadczenia dla klastra i upewnij się, że wszystkie węzły są w Ready stanie:

   az aks get-credentials --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   kubectl get nodes -o wide
   

Zachowanie w przypadku awarii

Jeśli migracja nie może udostępnić infrastruktury zarządzanej puli systemowej (na przykład ze względu na ograniczenia pojemności regionalnej), usługa AKS zachowuje istniejące pule węzłów systemowych i użytkownika w stanie sprzed migracji.