Uppgradera från Basic Load Balancer på Azure Kubernetes Service (AKS)

I den här artikeln får du lära dig hur du uppgraderar dina Basic Load Balancer-instanser till Standard Load Balancer på Azure Kubernetes Services (AKS). Vi rekommenderar att du använder Standard Load Balancer för alla produktionsinstanser. Det ger många viktiga skillnader i infrastrukturen. Information om hur du uppgraderar från Basic Load Balancer till Standard Load Balancer utanför AKS finns i den officiella vägledningen för Basic Load Balancer-uppgradering.

Innan du börjar

Granska följande information innan du påbörjar migreringen:

• Stilleståndstid inträffar under migreringen. Planera för stilleståndstid i enlighet med detta.
• När migreringen har påbörjats tillåts inte återställning.
• Den här processen migrerar även din grundläggande IP-adress till en standard-IP, samtidigt som de inkommande IP-adresserna som är associerade med lastbalanseraren hålls desamma. Nya offentliga IP-adresser skapas och associeras med utgående regler för Standard Load Balancer för att hantera utgående klustertrafik.

Förutsättningar

Klustret måste uppfylla följande krav innan du kan utföra migreringen:

• Den minsta Kubernetes-versionen för det här skriptet är 1.27. Om du behöver uppgradera ditt AKS-kluster kan du läsa Uppgradera ett AKS-kluster.
• Du behöver Azure CLI installerat. Den lägsta version du behöver är 2.76.0.
• Om klustret kör Key Management Service med ett privat nyckelvalv måste du inaktivera Key Management Service innan du utför migreringen. Mer information finns i Inaktivera KMS.
• Du måste inaktivera alla ValidatingAdmissionWebhooks eller MutatingAdmissionWebhooks innan du utför migreringen.

Uppgradera Basic Load Balancer till Standard Load Balancer

1. Uppgradera din Basic Load Balancer till Standard Load Balancer med kommandot az aks update och flaggan --load-balancer-sku inställd på Standard.

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

2. Kontrollera att migreringen lyckades med kommandot az aks show .

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

   I utdata bekräftar du att load-balancer typen är inställd på Standard.

3. Kontrollera att alla poddar och tjänster körs med hjälp av kommandona kubectl get pods och kubectl get svc .

   kubectl get svc -A
   kubectl get pods -A
   

Bekräfta nya utgående IP-adresser

Du kan bekräfta de nya IP-adresserna som är associerade med utgående regler genom att bekräfta resurs-ID:n för IP-adresserna och sedan lista IP-adresserna.

1. Hämta resurs-ID:t för de utgående IP-adresserna med kommandot az aks show .

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

2. Hämta den nya IP-adressen för varje resurs-ID med kommandot az network public-ip show .

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

Vanliga frågor

Varför får jag Error: “Load Balancer SKU 'basic' is invalid; must use 'standard'. när jag skapar ett nytt AKS-kluster eller uppgraderar?

Microsoft har avskrivit Basic Load Balancer SKU för vissa AKS-åtgärder, och skapande är nu blockerat i vissa regioner.

Lös problemet genom att ange --load-balancer-sku standard när du skapar ett nytt kluster. Till exempel:

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

Varför kan jag inte ändra min Basic Load Balancer till Standard Load Balancer på plats?

Load Balancer SKU är oföränderlig när den har skapats i AKS, eftersom det är en hanterad resurs som ägs av klustret.

Du kan lösa detta med något av följande alternativ:

• Alternativ 1: Använd az aks update run kommandot för att uppgradera Basic Load Balancer till Standard. Mer information finns i Uppgradera Basic Load Balancer på Azure Kubernetes Service (AKS).
• Alternativ 2: Skapa ett nytt AKS-kluster med Standard Load Balancer (blågrön migrering) och flytta befintliga arbetsbelastningar.

Varför hittar jag inte min offentliga IP-adress när jag har uppgraderat från Basic till Standard Load Balancer?

Load Balancer-objektet förlorade referensen till din offentliga IP-resurs under migreringen. Detta kan inträffa om IP-adressen var kopplad till Basic SKU Load Balancer och inte återvanns.

Så här löser du problemet:

1. Kontrollera att den nya offentliga IP-adressen standard finns i rätt resursgrupp.

2. Associera det igen i tjänstmanifestet med hjälp av följande konfiguration:

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

Varför skapas fortfarande en offentlig IP-adress under migreringen när du migrerar lastbalanseraren i ett privat kluster utan en offentlig IP-adress?

Om outboundType är LoadBalanceretablerar AKS automatiskt en offentlig IP-adress (PIP), oavsett lastbalanserarens SKU.

Så här löser du problemet:

1. Ändra outboundType till userDefinedRouting för ett helt privat kluster.
2. Se till att anpassad utgående routning konfigureras via Azure Firewall/NVA.

Varför misslyckas migreringen i min interna load balancer-konfiguration?

Aktuella migreringsverktyg stöder inte interna lastbalanserare för virtuella nätverk (VNet) från Basic till Standard i befintligt skick.

Så här löser du problemet:

1. Återskapa klustret i samma virtuella nätverk med Standard Load Balancer.
2. Distribuera arbetsbelastningar och verifiera intern namnmatchning.

Mina nodpooler använder tillgänglighetsuppsättningar. Kommer jag fortfarande att ha problem även efter load balancer-migreringen?

Ja. Om dina nodpooler använder tillgänglighetsuppsättningar är de också inaktuella i AKS efter den 30 september 2025.

Så här löser du problemet:

1. För kluster som använder både tillgänglighetsuppsättningar och Basic Load Balancer finns det ett separat az aks update kommando som du måste köra för att utföra båda migreringarna samtidigt (tillgänglighetsuppsättningar till nodpooler för virtuella datorer och Basic Load Balancer till Standard Load Balancer). Anvisningar om hur du utför den här migreringen finns i migreringsvägledningen för tillgänglighetsuppsättningar .
2. Efter uppgraderingen måste Azure CLI- eller REST-API:er användas för att utföra CRUD-åtgärder eller hantera poolen. Kontrollera begränsningarna.

Behöver jag ta bort standardwebbhooks innan jag uppgraderar?

Nej. Om inga andra ValidatingAdmissionWebhooks eller MutatingAdmissionWebhooks är närvarande i klustret, kan standardwebbhooks i kontrollplanen behållas under migreringen.

Standardwebbhooks är:

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

Vilken åtkomst krävs för att köra migreringskommandona?

Om du vill köra migreringskommandona behöver du:

• Rollen Deltagare eller Ägare för prenumerationen eller resursgruppen.
• Azure CLI-versionen måste vara ≥ 2.72.0.
• Versionen av AKS-förhandsgranskningstillägget måste vara ≥ 0.5.170.

Hur kan jag se om KMS-kryptering (Key Management Service) är inaktiverat?

Du kan kontrollera om KMS-kryptering är aktiverat i AKS-klustret med hjälp av az aks list kommandot .

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

• Om utdata visar "KmsEnabled": nullbetyder det att KMS-kryptering inte är aktiverat för klustret, och du kan hoppa över alla steg för att inaktivera det. Till exempel:

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

• Om KMS är aktiverat och du vill inaktivera det kan du läsa Inaktivera KMS-kryptering.

Nästa steg

Mer information om AKS-nätverk finns i Nätverksbegrepp för Azure Kubernetes Service (AKS).