Uaktualnianie z usługi Load Balancer w warstwie Podstawowa w usłudze Azure Kubernetes Service (AKS)

Z tego artykułu dowiesz się, jak uaktualnić wystąpienia usługi Load Balancer w warstwie Podstawowa do usługi Load Balancer w warstwie Standardowa w usłudze Azure Kubernetes Services (AKS). Zalecamy używanie standardowego równoważenia obciążenia dla każdego wystąpienia produkcyjnego. Zapewnia wiele kluczowych różnic w infrastrukturze. Aby uzyskać wskazówki dotyczące uaktualniania z usługi Load Balancer w warstwie Podstawowa do usługi Load Balancer w warstwie Standardowa poza usługą AKS, zobacz oficjalne wskazówki dotyczące uaktualniania usługi Load Balancer w warstwie Podstawowa.

Zanim rozpoczniesz

Przed rozpoczęciem migracji przejrzyj następujące informacje:

• Przestój występuje podczas migracji. Zaplanuj odpowiednio przestój.
• Po rozpoczęciu migracji wycofywanie jest niedozwolone.
• Ten proces umożliwia również migrowanie podstawowego adresu IP do standardowego adresu IP przy zachowaniu adresów IP dla ruchu przychodzącego skojarzonego z modułem równoważenia obciążenia. Nowe publiczne adresy IP są tworzone i skojarzone z regułami ruchu wychodzącego usługi Load Balancer w warstwie Standardowa w celu obsługi ruchu wychodzącego klastra.

Wymagania wstępne

Aby można było przeprowadzić migrację, klaster musi spełniać następujące wymagania wstępne:

• Minimalna wersja platformy Kubernetes dla tego skryptu to 1.27. Jeśli chcesz uaktualnić klaster usługi AKS, zobacz Uaktualnianie klastra usługi AKS.
• Potrzebujesz zainstalowanego Azure CLI. Minimalna potrzebna wersja to 2.76.0.
• Jeśli klaster uruchamia usługę zarządzania kluczami z prywatnym magazynem kluczy, należy wyłączyć usługę zarządzania kluczami przed przeprowadzeniem migracji. Aby uzyskać więcej informacji, zobacz Wyłączanie usługi KMS.
• Przed przeprowadzeniem migracji należy wyłączyć wszystkie elementy ValidatingAdmissionWebhooks lub MutatingAdmissionWebhooks.

Zaktualizuj Load Balancer w wersji Podstawowej do Load Balancer w wersji Standardowej

1. Uaktualnij Podstawowy Load Balancer do Standardowego Load Balancera za pomocą polecenia az aks update z flagą --load-balancer-sku ustawioną na Standard.

   az aks update \
     --name $CLUSTER_NAME \
     --resource-group $RESOURCE_GROUP \
     --load-balancer-sku=Standard
   

2. Sprawdź, czy migracja zakończyła się pomyślnie, używając az aks show polecenia .

   az aks show \
     --name $CLUSTER_NAME \
     --resource-group $RESOURCE_GROUP
   

   W danych wyjściowych sprawdź, czy typ load-balancer jest ustawiony na wartość Standard.

3. Sprawdź, czy wszystkie zasobniki i usługi są uruchomione pomyślnie przy użyciu poleceń kubectl get pods i kubectl get svc.

   kubectl get svc -A
   kubectl get pods -A
   

Potwierdzanie nowych wychodzących adresów IP

Nowe adresy IP skojarzone z regułami ruchu wychodzącego można potwierdzić, potwierdzając identyfikatory zasobów dla adresów IP, a następnie wyświetlając listę adresów IP.

1. Pobierz identyfikator zasobu dla wychodzących adresów IP przy użyciu polecenia az aks show.

   az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id
   

2. Pobierz nowy adres IP dla każdego identyfikatora zasobu za pomocą polecenia az network public-ip show.

   az network public-ip show --ids $IP_RESOURCE_ID --query ipAddress -o tsv
   

Często zadawane pytania

Dlaczego pojawia się Error: “Load Balancer SKU 'basic' is invalid; must use 'standard'. podczas tworzenia nowego klastra AKS lub jego aktualizacji?

Microsoft zaniechało stosowania SKU Podstawowego Load Balancera dla niektórych operacji AKS, a jego tworzenie jest teraz blokowane w niektórych regionach.

Aby rozwiązać ten problem, upewnij się, że określisz --load-balancer-sku standard podczas tworzenia nowego klastra. Przykład:

az aks create \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku standard

Dlaczego nie mogę zmienić Basic Load Balancer na Standard Load Balancer bezpośrednio?

SKU Load Balancer jest niezmienny po utworzeniu w klastrze AKS, gdyż stanowi zarządzany zasób należący do klastra.

Możesz rozwiązać ten problem, korzystając z jednej z następujących opcji:

• Opcja 1: Użyj polecenia az aks update run , aby zaktualizować Load Balancer z Podstawowej na Standardową. Aby uzyskać więcej informacji, zobacz Uaktualnianie podstawowego modułu równoważenia obciążenia w usłudze Azure Kubernetes Service (AKS).
• Opcja 2: Utwórz nowy klaster AKS z Standard Load Balancer (migracja niebiesko-zielona) i przenieś wszelkie istniejące obciążenia.

Dlaczego nie mogę znaleźć publicznego adresu IP po uaktualnieniu Load Balancer z warstwy Podstawowa na warstwę Standardowa?

Obiekt modułu równoważenia obciążenia stracił odwołanie do zasobu publicznego adresu IP podczas migracji. Może się tak zdarzyć, jeśli adres IP był powiązany z Podstawowym SKU modułu równoważenia obciążenia i nie został ponownie przypisany.

Aby rozwiązać ten problem:

1. Upewnij się, że nowy publiczny adres IP w standardowej warstwie istnieje w odpowiedniej grupie zasobów.

2. Ponownie skojarz element w manifeście usługi przy użyciu następującej konfiguracji.

   annotations:
     service.beta.kubernetes.io/azure-load-balancer-ipv4: <your-ip>
   

Dlaczego podczas migracji modułu równoważenia obciążenia w klastrze prywatnym, bez publicznego adresu IP, nadal tworzony jest publiczny adres IP?

Jeśli outboundType jest to LoadBalancer, usługa AKS automatycznie aprowizuje publiczny adres IP (PIP), niezależnie od wersji SKU modułu równoważenia obciążenia.

Aby rozwiązać ten problem:

1. Zmień outboundType na userDefinedRouting na w pełni prywatny klaster.
2. Upewnij się, że niestandardowy routing wychodzący jest skonfigurowany za pomocą Azure Firewall/NVA.

Dlaczego migracja kończy się niepowodzeniem w wewnętrznej konfiguracji modułu równoważenia obciążenia?

Bieżące narzędzia migracji nie obsługują wewnętrznych modułów równoważenia obciążenia w sieciach wirtualnych (VNet) podczas migracji z warstwy Podstawowa do Standardowa.

Aby rozwiązać ten problem:

1. Utwórz ponownie klaster w tej samej sieci wirtualnej z użyciem Standardowego Load Balancera.
2. Wdrażanie obciążeń i weryfikowanie wewnętrznego rozpoznawania nazw.

Moje pule węzłów używają zestawów dostępności. Czy nadal występują problemy nawet po migracji usługi Load Balancer?

Tak. Jeśli pule węzłów używają Zestawów dostępności, będą również uznawane za przestarzałe w usłudze AKS po 30 września 2025 r.

Aby rozwiązać ten problem:

1. W przypadku klastrów korzystających zarówno z grup dostępności, jak i podstawowego Load Balancer, należy uruchomić oddzielne az aks update polecenie w celu przeprowadzenia obu migracji jednocześnie (przeniesienie z grup dostępności do pul węzłów maszyn wirtualnych oraz z Podstawowego Load Balancer do Standardowego Load Balancer). Aby uzyskać instrukcje dotyczące przeprowadzania tej migracji, zobacz wskazówki dotyczące migracji zestawów dostępności .
2. Po uaktualnieniu do wykonywania operacji CRUD lub zarządzania pulą należy używać Azure CLI lub interfejsów API REST. Sprawdź ograniczenia.

Czy muszę usunąć domyślne webhooki przed aktualizacją?

Nie. Jeśli w klastrze nie ma innego ValidatingAdmissionWebhooks lub MutatingAdmissionWebhooks, domyślne webhooki na płaszczyźnie sterowania powinny zostać zachowane podczas migracji.

Domyślne webhooki obejmują:

• aks-node-mutating-webhook
• webhook-admission-controller
• node-validating-webhook

Jaki dostęp jest wymagany do uruchamiania poleceń migracji?

Aby uruchomić polecenia migracji, potrzebne są następujące elementy:

• Albo rola Współautora, albo Właściciela w subskrypcji lub grupie zasobów.
• Wersja interfejsu wiersza polecenia platformy Azure musi być ≥ 2.72.0.
• Wersja rozszerzenia usługi AKS w wersji zapoznawczej musi być ≥ 0.5.170.

Jak sprawdzić, czy szyfrowanie usługi zarządzania kluczami (KMS) jest wyłączone?

Możesz sprawdzić, czy szyfrowanie KMS jest włączone w klastrze usługi AKS, używając az aks list polecenia .

az aks list --query "[].{Name:name, KmsEnabled:securityProfile.azureKeyVaultKms.enabled, KeyId:securityProfile.azureKeyVaultKms.keyId}"

• Jeśli dane wyjściowe pokazują "KmsEnabled": null, oznacza to, że szyfrowanie KMS nie jest włączone dla tego klastra i można pominąć jakiekolwiek kroki związane z jego wyłączeniem. Przykład:

    {
  
      "KeyId": null,
  
      "KmsEnabled": null,
  
      "Name": "myAKSCluster"
  
    },
  ...
  

• Jeśli usługa KMS jest włączona i chcesz ją wyłączyć, zobacz Wyłączanie szyfrowania KMS.

Dalsze kroki

Aby uzyskać więcej informacji na temat sieci usługi AKS, zobacz Pojęcia dotyczące sieci dla usługi Azure Kubernetes Service (AKS).