AKS-felsökningAKS troubleshooting

När du skapar eller hanterar AKS-kluster (Azure Kubernetes service) kan du ibland stöta på problem.When you create or manage Azure Kubernetes Service (AKS) clusters, you might occasionally come across problems. I den här artikeln beskrivs några vanliga problem och fel söknings steg.This article details some common problems and troubleshooting steps.

I allmänhet hittar jag information om fel sökning av Kubernetes-problem?In general, where do I find information about debugging Kubernetes problems?

Testa den officiella guiden för att felsöka Kubernetes-kluster.Try the official guide to troubleshooting Kubernetes clusters. Det finns också en fel söknings guidesom publicerats av en Microsoft-tekniker för att felsöka poddar, noder, kluster och andra funktioner.There's also a troubleshooting guide, published by a Microsoft engineer for troubleshooting pods, nodes, clusters, and other features.

Jag får ett fel meddelande om att kvoten överskreds vid skapandet eller uppgraderingen.I'm getting a "quota exceeded" error during creation or upgrade. Vad ska jag göra?What should I do?

Begär flera kärnor.Request more cores.

Jag får ett insufficientSubnetSize-fel när jag distribuerar ett AKS-kluster med avancerade nätverksfunktioner.I'm getting an insufficientSubnetSize error while deploying an AKS cluster with advanced networking. Vad ska jag göra?What should I do?

Det här felet anger att ett undernät som används för ett kluster inte längre har tillgängliga IP-adresser i CIDR för lyckad resurs tilldelning.This error indicates a subnet in use for a cluster no longer has available IPs within its CIDR for successful resource assignment. För Kubernetes-kluster är kravet tillräckligt med IP-utrymme för varje nod i klustret.For Kubenet clusters, the requirement is sufficient IP space for each node in the cluster. För Azure CNI-kluster är kravet tillräckligt med IP-utrymme för varje nod och Pod i klustret.For Azure CNI clusters, the requirement is sufficient IP space for each node and pod in the cluster. Läs mer om utformningen av Azure-cni för att tilldela IP-adresser till poddar.Read more about the design of Azure CNI to assign IPs to pods.

Dessa fel finns också i AKS- diagnostik, som proaktivt utsätter problem som en otillräcklig under näts storlek.These errors are also surfaced in AKS Diagnostics, which proactively surfaces issues such as an insufficient subnet size.

Följande tre (3) ärenden orsakar ett otillräckligt näts storleks fel:The following three (3) cases cause an insufficient subnet size error:

  1. Skala AKS Scale eller AKS Node poolAKS Scale or AKS Node pool scale

    1. Om du använder Kubernetes när number of free IPs in the subnet är mindre än number of new nodes requested .If using Kubenet, when the number of free IPs in the subnet is less than the number of new nodes requested.
    2. Om du använder Azure-CNI när number of free IPs in the subnet är mindre än number of nodes requested times (*) the node pool's --max-pod value .If using Azure CNI, when the number of free IPs in the subnet is less than the number of nodes requested times (*) the node pool's --max-pod value.
  2. Uppgradering av AKS-eller AKS Node-poolAKS Upgrade or AKS Node pool upgrade

    1. Om du använder Kubernetes när number of free IPs in the subnet är mindre än number of buffer nodes needed to upgrade .If using Kubenet, when the number of free IPs in the subnet is less than the number of buffer nodes needed to upgrade.
    2. Om du använder Azure-CNI när number of free IPs in the subnet är mindre än number of buffer nodes needed to upgrade times (*) the node pool's --max-pod value .If using Azure CNI, when the number of free IPs in the subnet is less than the number of buffer nodes needed to upgrade times (*) the node pool's --max-pod value.

    Som standard anger AKS-kluster värdet för maximal överspänning (Upgrade buffer) för ett (1), men det här uppgraderings beteendet kan anpassas genom att ange [Max värdet för överspänning för en nod, vilket ökar antalet tillgängliga IP-adresser som krävs för att slutföra en uppgradering.By default AKS clusters set a max surge (upgrade buffer) value of one (1), but this upgrade behavior can be customized by setting the [max surge value of a node pool, which will increase the number of available IPs needed to complete an upgrade.

  3. AKS Create eller AKS Node pool AddAKS create or AKS Node pool add

    1. Om du använder Kubernetes när number of free IPs in the subnet är mindre än number of nodes requested for the node pool .If using Kubenet, when the number of free IPs in the subnet is less than the number of nodes requested for the node pool.
    2. Om du använder Azure-CNI när number of free IPs in the subnet är mindre än number of nodes requested times (*) the node pool's --max-pod value .If using Azure CNI, when the number of free IPs in the subnet is less than the number of nodes requested times (*) the node pool's --max-pod value.

Följande åtgärder kan vidtas genom att skapa nya undernät.The following mitigation can be taken by creating new subnets. Behörighet att skapa ett nytt undernät krävs för att undvika åtgärder på grund av möjligheten att uppdatera ett befintligt undernäts CIDR-intervall.The permission to create a new subnet is required for mitigation due to the inability to update an existing subnet's CIDR range.

  1. Återskapa ett nytt undernät med ett större CIDR-intervall tillräckligt för åtgärds mål:Rebuild a new subnet with a larger CIDR range sufficient for operation goals:
    1. Skapa ett nytt undernät med ett nytt intervall som inte överlappar.Create a new subnet with a new desired non-overlapping range.
    2. Skapa en ny Node-pool i det nya under nätet.Create a new node pool on the new subnet.
    3. Töm poddar från den gamla Node-poolen som finns i det gamla under nätet som ska ersättas.Drain pods from the old node pool residing in the old subnet to be replaced.
    4. Ta bort det gamla under nätet och den gamla Node-poolen.Delete the old subnet and old node pool.

Mitt Pod fastnar i CrashLoopBackOff-läge.My pod is stuck in CrashLoopBackOff mode. Vad ska jag göra?What should I do?

Det kan finnas olika orsaker till att Pod har fastnat i det läget.There might be various reasons for the pod being stuck in that mode. Du kan titta på:You might look into:

  • Själva pod, med hjälp av kubectl describe pod <pod-name> .The pod itself, by using kubectl describe pod <pod-name>.
  • Loggarna med hjälp av kubectl logs <pod-name> .The logs, by using kubectl logs <pod-name>.

Mer information om hur du felsöker Pod-problem finns i Felsöka program.For more information on how to troubleshoot pod problems, see Debug applications.

Jag får TCP timeouts när jag använder kubectl eller andra verktyg från tredje part som ansluter till API-servernI'm receiving TCP timeouts when using kubectl or other third-party tools connecting to the API server

AKS har kontroll plan som skalas lodrätt i enlighet med antalet kärnor för att säkerställa dess service nivå mål (SLO: erna) och service nivå avtal (service avtal).AKS has HA control planes that scale vertically according to the number of cores to ensure its Service Level Objectives (SLOs) and Service Level Agreements (SLAs). Om du råkar ut för anslutnings tids gränsen kontrollerar du följande:If you're experiencing connections timing out, check the below:

  • Är alla API-kommandon timeout-bara konsekventa eller bara några?Are all your API commands timing out consistently or only a few? Om det bara är några få tunnelfront POD eller aks-link pod, som ansvarar för kommunikation mellan noder i > kontroll planet, kanske inte är i körnings tillstånd.If it's only a few, your tunnelfront pod or aks-link pod, responsible for node -> control plane communication, might not be in a running state. Se till att noderna som är värdar för denna Pod inte är överutnyttjade eller under stress.Make sure the nodes hosting this pod aren't over-utilized or under stress. Överväg att flytta dem till en egen system Node-pool.Consider moving them to their own system node pool.
  • Har du öppnat alla obligatoriska portar, FQDN-namn och IP-adresser som anges i AKS-begränsningen av utgående trafikflöden?Have you opened all required ports, FQDNs, and IPs noted on the AKS restrict egress traffic docs? Annars går det inte att anropa flera kommandon.Otherwise several commands calls can fail.
  • Omfattas den aktuella IP-adressen av API IP-auktoriserade intervall?Is your current IP covered by API IP Authorized Ranges? Om du använder den här funktionen och din IP-adress inte ingår i de intervall som dina samtal ska blockeras.If you're using this feature and your IP is not included in the ranges your calls will be blocked.
  • Har du en klient eller ett program som läcker anrop till API-servern?Do you have a client or application leaking calls to the API server? Se till att använda arm i stället för att få frekventa samtal och att program från tredje part inte läcker sådana samtal.Make sure to use watches instead of frequent get calls and that your third-party applications aren't leaking such calls. Ett fel i Istio-mixern gör till exempel att en ny API Server Watch-anslutning skapas varje gång en hemlighet läses internt.For example, a bug in the Istio mixer causes a new API Server watch connection to be created every time a secret is read internally. Eftersom det här beteendet sker med jämna mellanrum kan du titta på anslutningar snabbt och på så vis få API-servern att bli överbelastad oavsett skalnings mönstret.Because this behavior happens at a regular interval, watch connections quickly accumulate, and eventually cause the API Server to become overloaded no matter the scaling pattern. https://github.com/istio/istio/issues/19481https://github.com/istio/istio/issues/19481
  • Har du många versioner av dina Helm-distributioner?Do you have many releases in your helm deployments? Det här scenariot kan orsaka att båda till att använda för mycket minne på noderna, samt en stor mängd configmaps , vilket kan orsaka onödiga toppar på API-servern.This scenario can cause both tiller to use too much memory on the nodes, as well as a large amount of configmaps, which can cause unnecessary spikes on the API server. Överväg att konfigurera --history-maxhelm init och utnyttja den nya Helm 3.Consider configuring --history-max at helm init and leverage the new Helm 3. Mer information om följande problem:More details on the following issues:
  • Är intern trafik mellan noder blockerade?Is internal traffic between nodes being blocked?

Jag får TCP timeouts , till exempel dial tcp <Node_IP>:10250: i/o timeoutI'm receiving TCP timeouts, such as dial tcp <Node_IP>:10250: i/o timeout

Dessa tids gränser kan vara relaterade till intern trafik mellan noder som blockeras.These timeouts may be related to internal traffic between nodes being blocked. Kontrol lera att trafiken inte blockeras, till exempel av nätverks säkerhets grupper på under nätet för klustrets noder.Verify that this traffic is not being blocked, such as by network security groups on the subnet for your cluster's nodes.

Jag försöker aktivera Kubernetes-rollbaserad åtkomst kontroll (Kubernetes RBAC) i ett befintligt kluster.I'm trying to enable Kubernetes role-based access control (Kubernetes RBAC) on an existing cluster. Hur kan jag göra det?How can I do that?

Att aktivera Kubernetes-rollbaserad åtkomst kontroll (Kubernetes RBAC) i befintliga kluster stöds inte för tillfället, det måste anges när du skapar nya kluster.Enabling Kubernetes role-based access control (Kubernetes RBAC) on existing clusters isn't supported at this time, it must be set when creating new clusters. Kubernetes RBAC är aktiverat som standard när du använder CLI, Portal eller en API-version senare än 2020-03-01 .Kubernetes RBAC is enabled by default when using CLI, Portal, or an API version later than 2020-03-01.

Jag kan inte hämta loggar med kubectl-loggar eller så kan jag inte ansluta till API-servern.I can't get logs by using kubectl logs or I can't connect to the API server. Jag får "fel från servern: fel vid uppringning av Server del: slå TCP...".I'm getting "Error from server: error dialing backend: dial tcp…". Vad ska jag göra?What should I do?

Se till att portarna 22, 9000 och 1194 är öppna för att ansluta till API-servern.Ensure ports 22, 9000 and 1194 are open to connect to the API server. Kontrol lera om tunnelfront eller aks-link Pod körs i Kube-systemets namnrymd med kubectl get pods --namespace kube-system kommandot.Check whether the tunnelfront or aks-link pod is running in the kube-system namespace using the kubectl get pods --namespace kube-system command. Om den inte är det, kan du framtvinga borttagning av Pod och startas om.If it isn't, force deletion of the pod and it will restart.

Jag får "tls: client offered only unsupported versions" från min klient när jag ansluter till AKS-API: et.I'm getting "tls: client offered only unsupported versions" from my client when connecting to AKS API. Vad ska jag göra?What should I do?

Den lägsta TLS-version som stöds i AKS är TLS 1,2.The minimum supported TLS version in AKS is TLS 1.2.

Jag försöker uppgradera eller skala och får ett "Changing property 'imageReference' is not allowed" fel meddelande.I'm trying to upgrade or scale and am getting a "Changing property 'imageReference' is not allowed" error. Hur gör jag för att åtgärda det här problemet?How do I fix this problem?

Du kan få det här felet eftersom du har ändrat taggarna i agent-noderna i AKS-klustret.You might be getting this error because you've modified the tags in the agent nodes inside the AKS cluster. Ändra eller ta bort taggar och andra egenskaper för resurser i resurs gruppen MC_ * kan leda till oväntade resultat.Modify or delete tags and other properties of resources in the MC_* resource group can lead to unexpected results. Att ändra resurserna under MC_ *-gruppen i AKS-klustret delar service nivå målet (service nivå mål).Altering the resources under the MC_* group in the AKS cluster breaks the service-level objective (SLO).

Jag får fel meddelanden om att mitt kluster är i felaktigt tillstånd och uppgradering eller skalning fungerar inte förrän det har åtgärd ATSI'm receiving errors that my cluster is in failed state and upgrading or scaling will not work until it is fixed

Den här fel söknings hjälpen riktas mot https://aka.ms/aks-cluster-failedThis troubleshooting assistance is directed from https://aka.ms/aks-cluster-failed

Felet uppstår när kluster anger ett felaktigt tillstånd av flera orsaker.This error occurs when clusters enter a failed state for multiple reasons. Följ stegen nedan för att lösa ett tillstånd för misslyckad kluster innan du försöker igen den tidigare misslyckade åtgärden:Follow the steps below to resolve your cluster failed state before retrying the previously failed operation:

  1. Tills klustret är i ett tillstånd där det inte går att utföra failed upgrade scale åtgärder.Until the cluster is out of failed state, upgrade and scale operations won't succeed. Vanliga problem och lösningar för roten är:Common root issues and resolutions include:
    • Skalning med otillräcklig beräknings kvot (CRP).Scaling with insufficient compute (CRP) quota. För att lösa problemet måste du först skala klustret till ett stabilt mål tillstånd inom kvoten.To resolve, first scale your cluster back to a stable goal state within quota. Följ sedan de här stegen för att begära en ökad beräknings kvot innan du försöker skala upp igen utöver de inledande kvot gränserna.Then follow these steps to request a compute quota increase before trying to scale up again beyond initial quota limits.
    • Skala ett kluster med avancerade nätverk och otillräckliga undernät (nätverks resurser).Scaling a cluster with advanced networking and insufficient subnet (networking) resources. För att lösa problemet måste du först skala klustret till ett stabilt mål tillstånd inom kvoten.To resolve, first scale your cluster back to a stable goal state within quota. Följ sedan de här stegen för att begära en resurs kvot ökning innan du försöker skala upp igen utöver de inledande kvot gränserna.Then follow these steps to request a resource quota increase before trying to scale up again beyond initial quota limits.
  2. När den underliggande orsaken till uppgraderings felet har lösts bör klustret ha statusen klar.Once the underlying cause for upgrade failure is resolved, your cluster should be in a succeeded state. När en lyckad status har verifierats kan du försöka utföra den ursprungliga åtgärden igen.Once a succeeded state is verified, retry the original operation.

Jag får fel meddelanden när jag försöker uppgradera eller skala det tillstånd mitt kluster uppgraderas eller har inte uppgraderatsI'm receiving errors when trying to upgrade or scale that state my cluster is being upgraded or has failed upgrade

Den här fel söknings hjälpen riktas mot https://aka.ms/aks-pending-upgradeThis troubleshooting assistance is directed from https://aka.ms/aks-pending-upgrade

Det går inte att ha ett kluster eller en Node-pool samtidigt för uppgradering och skalning.You can't have a cluster or node pool simultaneously upgrade and scale. I stället måste varje åtgärds typ slutföras på mål resursen före nästa förfrågan på samma resurs.Instead, each operation type must complete on the target resource before the next request on that same resource. Det innebär att åtgärder begränsas när aktiva uppgraderingar eller skalnings åtgärder inträffar eller görs.As a result, operations are limited when active upgrade or scale operations are occurring or attempted.

För att diagnostisera problemet kan az aks show -g myResourceGroup -n myAKSCluster -o table du Hämta detaljerad status för klustret.To help diagnose the issue run az aks show -g myResourceGroup -n myAKSCluster -o table to retrieve detailed status on your cluster. Baserat på resultatet:Based on the result:

  • Om klustret aktivt uppgraderas väntar du tills åtgärden har slutförts.If cluster is actively upgrading, wait until the operation finishes. Om det lyckades, gör om den tidigare misslyckade åtgärden igen.If it succeeded, retry the previously failed operation again.
  • Om det inte går att uppgradera klustret följer du stegen som beskrivs i föregående avsnitt.If cluster has failed upgrade, follow steps outlined in previous section.

Kan jag flytta mitt kluster till en annan prenumeration eller min prenumeration med mitt kluster till en ny klient?Can I move my cluster to a different subscription or my subscription with my cluster to a new tenant?

Om du har flyttat ditt AKS-kluster till en annan prenumeration eller klustrets prenumeration till en ny klient fungerar inte klustret på grund av saknade behörigheter för kluster identiteten.If you've moved your AKS cluster to a different subscription or the cluster's subscription to a new tenant, the cluster won't function because of missing cluster identity permissions. AKS stöder inte flytt av kluster mellan prenumerationer eller klienter på grund av den här begränsningen.AKS doesn't support moving clusters across subscriptions or tenants because of this constraint.

Jag får fel meddelanden vid försök att använda funktioner som kräver skalnings uppsättningar för virtuella datorerI'm receiving errors trying to use features that require virtual machine scale sets

Den här fel söknings hjälpen dirigeras från aka.ms/aks-vmss-enablementThis troubleshooting assistance is directed from aka.ms/aks-vmss-enablement

Du får fel meddelanden som anger att ditt AKS-kluster inte finns på en skal uppsättning för virtuella datorer, till exempel följande exempel:You may receive errors that indicate your AKS cluster isn't on a virtual machine scale set, such as the following example:

Agentpoolegenskap <agentpoolname> har ställt in automatisk skalning som aktive rad men inte på Virtual Machine Scale SetsAgentPool <agentpoolname> has set auto scaling as enabled but isn't on Virtual Machine Scale Sets

Funktioner som till exempel klustrets autoskalning eller flera noder kräver skalnings uppsättningar för virtuella datorer som vm-set-type .Features such as the cluster autoscaler or multiple node pools require virtual machine scale sets as the vm-set-type.

Följ stegen innan du börjar i rätt dokument för att skapa ett AKS-kluster på rätt sätt:Follow the Before you begin steps in the appropriate doc to correctly create an AKS cluster:

Vilka namngivnings begränsningar tillämpas för AKS-resurser och parametrar?What naming restrictions are enforced for AKS resources and parameters?

Den här fel söknings hjälpen dirigeras från aka.ms/aks-naming-rulesThis troubleshooting assistance is directed from aka.ms/aks-naming-rules

Namngivnings begränsningar implementeras av både Azure-plattformen och AKS.Naming restrictions are implemented by both the Azure platform and AKS. Om ett resurs namn eller en parameter delar någon av dessa begränsningar returneras ett fel som uppmanar dig att ange en annan Indatatyp.If a resource name or parameter breaks one of these restrictions, an error is returned that asks you provide a different input. Följande rikt linjer gäller för namngivning:The following common naming guidelines apply:

  • Kluster namn måste innehålla 1-63 tecken.Cluster names must be 1-63 characters. De enda tillåtna tecknen är bokstäver, siffror, bindestreck och under streck.The only allowed characters are letters, numbers, dashes, and underscore. Det första och sista tecknet måste vara en bokstav eller en siffra.The first and last character must be a letter or a number.
  • AKS nod/MC_ resurs grupp namn kombinerar resurs grupps namn och resurs namn.The AKS Node/MC_ resource group name combines resource group name and resource name. Den automatiskt genererade syntaxen för MC_resourceGroupName_resourceName_AzureRegion får inte vara större än 80 tecken.The autogenerated syntax of MC_resourceGroupName_resourceName_AzureRegion must be no greater than 80 chars. Om det behövs kan du minska längden på resurs gruppens namn eller AKS kluster namn.If needed, reduce the length of your resource group name or AKS cluster name. Du kan också Anpassa resurs grupps namnet för nodenYou may also customize your node resource group name
  • DnsPrefix måste börja och sluta med alfanumeriska värden och måste vara mellan 1-54 tecken.The dnsPrefix must start and end with alphanumeric values and must be between 1-54 characters. Giltiga tecken är alfanumeriska värden och bindestreck (-).Valid characters include alphanumeric values and hyphens (-). DnsPrefix får inte innehålla specialtecken, till exempel en punkt (.).The dnsPrefix can't include special characters such as a period (.).
  • AKS måste bestå av gemener och 1-11 tecken för Linux-nodkonfigurationer och 1-6-tecken för Windows-nodkonfigurationer.AKS Node Pool names must be all lowercase and be 1-11 characters for linux node pools and 1-6 characters for windows node pools. Namnet måste börja med en bokstav och de enda tillåtna tecknen är bokstäver och siffror.The name must start with a letter and the only allowed characters are letters and numbers.
  • Admin-username, som anger administratörs användar namnet för Linux-noder, måste börja med en bokstav, får bara innehålla bokstäver, siffror, bindestreck och under streck och har högst 64 tecken.The admin-username, which sets the administrator username for Linux nodes, must start with a letter, may only contain letters, numbers, hyphens, and underscores, and has a maximum length of 64 characters.

Jag får fel meddelanden när jag försöker skapa, uppdatera, skala, ta bort eller uppgradera kluster, den åtgärden är inte tillåten eftersom en annan åtgärd pågår.I'm receiving errors when trying to create, update, scale, delete or upgrade cluster, that operation is not allowed as another operation is in progress.

Den här fel söknings hjälpen dirigeras från aka.ms/aks-pending-operationThis troubleshooting assistance is directed from aka.ms/aks-pending-operation

Kluster åtgärder är begränsade när en tidigare åtgärd fortfarande pågår.Cluster operations are limited when a previous operation is still in progress. Om du vill hämta en detaljerad status för klustret använder du az aks show -g myResourceGroup -n myAKSCluster -o table kommandot.To retrieve a detailed status of your cluster, use the az aks show -g myResourceGroup -n myAKSCluster -o table command. Använd din egen resurs grupp och AKS kluster namn efter behov.Use your own resource group and AKS cluster name as needed.

Baserat på utdata från klustrets status:Based on the output of the cluster status:

Tog emot ett fel som säger att mitt huvud namn inte hittades eller är ogiltigt när jag försöker skapa ett nytt kluster.Received an error saying my service principal wasn't found or is invalid when I try to create a new cluster.

När du skapar ett AKS-kluster kräver det ett huvud namn för tjänsten eller en hanterad identitet för att skapa resurser för din räkning.When creating an AKS cluster, it requires a service principal or managed identity to create resources on your behalf. AKS kan automatiskt skapa ett nytt huvud namn för tjänsten när klustret skapas eller ta emot ett befintligt.AKS can automatically create a new service principal at cluster creation time or receive an existing one. När du använder en automatiskt skapad måste Azure Active Directory sprida den till varje region så att skapandet lyckas.When using an automatically created one, Azure Active Directory needs to propagate it to every region so the creation succeeds. Om spridningen tar för lång tid kommer klustret inte att verifieras för att skapa eftersom det inte går att hitta ett tillgängligt huvud namn för tjänsten.When the propagation takes too long, the cluster will fail validation to create as it can't find an available service principal to do so.

Använd följande lösningar för det här problemet:Use the following workarounds for this issue:

  • Använd ett befintligt huvud namn för tjänsten som redan har spridits över regioner och som finns för att skicka in till AKS vid klustrets skapande tid.Use an existing service principal, which has already propagated across regions and exists to pass into AKS at cluster create time.
  • Om du använder Automation-skript kan du lägga till tids fördröjningar mellan skapande av tjänstens huvud namn och AKS-kluster.If using automation scripts, add time delays between service principal creation and AKS cluster creation.
  • Om du använder Azure Portal återgår du till kluster inställningarna när du skapar och försöker sedan att köra verifierings sidan igen efter några minuter.If using Azure portal, return to the cluster settings during create and retry the validation page after a few minutes.

Jag får "AADSTS7000215: Invalid client secret is provided." när jag använder AKS-API.I'm getting "AADSTS7000215: Invalid client secret is provided." when using AKS API. Vad ska jag göra?What should I do?

Det här problemet beror på att autentiseringsuppgifterna för tjänstens huvud namn har gått ut.This issue is due to the expiration of service principal credentials. Uppdatera autentiseringsuppgifterna för ett AKS-kluster.Update the credentials for an AKS cluster.

Jag kan inte komma åt mitt kluster-API från min Automation/dev Machine/verktygs uppsättning när du använder tillåtna IP-intervall för API-servern.I can't access my cluster API from my automation/dev machine/tooling when using API server authorized IP ranges. Hur gör jag för att åtgärda det här problemet?How do I fix this problem?

För att lösa det här problemet, se till att --api-server-authorized-ip-ranges inkludera de IP-adresser eller IP-intervall för Automation/dev/verktygs system som används.To resolve this issue, ensure --api-server-authorized-ip-ranges includes the IP(s) or IP range(s) of automation/dev/tooling systems being used. Se avsnittet "så här hittar du min IP" i säker åtkomst till API-servern med hjälp av behöriga IP-adressintervall.Refer section 'How to find my IP' in Secure access to the API server using authorized IP address ranges.

Jag kan inte Visa resurser i Kubernetes Resource Viewer i Azure Portal för mitt kluster konfigurerat med tillåtna IP-intervall för API-servern.I'm unable to view resources in Kubernetes resource viewer in Azure portal for my cluster configured with API server authorized IP ranges. Hur gör jag för att åtgärda det här problemet?How do I fix this problem?

Kubernetes Resource Viewer måste --api-server-authorized-ip-ranges innehålla åtkomst till den lokala klient datorn eller IP-adressintervallet (från vilken portalen bläddras).The Kubernetes resource viewer requires --api-server-authorized-ip-ranges to include access for the local client computer or IP address range (from which the portal is being browsed). Se avsnittet "så här hittar du min IP" i säker åtkomst till API-servern med hjälp av behöriga IP-adressintervall.Refer section 'How to find my IP' in Secure access to the API server using authorized IP address ranges.

Jag får fel efter att ha begränsat utgående trafikI'm receiving errors after restricting egress traffic

Vid begränsning av utgående trafik från ett AKS-kluster krävs och valfria rekommenderade utgående portar/nätverks regler och FQDN/applikations regler för AKS.When restricting egress traffic from an AKS cluster, there are required and optional recommended outbound ports / network rules and FQDN / application rules for AKS. Om inställningarna är i konflikt med någon av dessa regler kubectl fungerar inte vissa kommandon som de ska.If your settings are in conflict with any of these rules, certain kubectl commands won't work correctly. Du kan också se fel när du skapar ett AKS-kluster.You may also see errors when creating an AKS cluster.

Kontrol lera att inställningarna inte står i konflikt med några av de obligatoriska eller valfria rekommenderade utgående portarna/nätverks reglerna och reglerna för FQDN/program.Verify that your settings aren't conflicting with any of the required or optional recommended outbound ports / network rules and FQDN / application rules.

Jag får fel meddelanden om "429-för många begär Anden"I'm receiving "429 - Too Many Requests" errors

När ett Kubernetes-kluster på Azure (AKS eller No) ofta skalar upp/ned eller använder kluster autoskalning (CA), kan dessa åtgärder resultera i ett stort antal HTTP-anrop som i sin tur överskrider den tilldelade prenumerations kvoten som leder till fel.When a kubernetes cluster on Azure (AKS or no) does a frequent scale up/down or uses the cluster autoscaler (CA), those operations can result in a large number of HTTP calls that in turn exceed the assigned subscription quota leading to failure. Felen kommer att se ut somThe errors will look like

Service returned an error. Status=429 Code=\"OperationNotAllowed\" Message=\"The server rejected the request because too many requests have been received for this subscription.\" Details=[{\"code\":\"TooManyRequests\",\"message\":\"{\\\"operationGroup\\\":\\\"HighCostGetVMScaleSet30Min\\\",\\\"startTime\\\":\\\"2020-09-20T07:13:55.2177346+00:00\\\",\\\"endTime\\\":\\\"2020-09-20T07:28:55.2177346+00:00\\\",\\\"allowedRequestCount\\\":1800,\\\"measuredRequestCount\\\":2208}\",\"target\":\"HighCostGetVMScaleSet30Min\"}] InnerError={\"internalErrorCode\":\"TooManyRequestsReceived\"}"}

Dessa begränsnings fel beskrivs i detalj här och härThese throttling errors are described in detail here and here

Rekommendationen från AKS Engineering team är att se till att du kör version minst 1.18. x, som innehåller många förbättringar.The recommendation from AKS Engineering Team is to ensure you are running version at least 1.18.x, which contains many improvements. Mer information finns i dessa förbättringar här .More details can be found on these improvements here and here.

Med tanke på att dessa begränsnings fel mäts på prenumerations nivå kan de fortfarande inträffa om:Given these throttling errors are measured at the subscription level, they might still happen if:

  • Det finns program från tredje part som gör GET-begäranden (till exempel övervakning av program och så vidare).There are 3rd party applications making GET requests (for example, monitoring applications, and so on). Rekommendationen är att minska frekvensen för dessa anrop.The recommendation is to reduce the frequency of these calls.
  • Det finns flera AKS-kluster/Node-pooler som använder virtuella datorers skalnings uppsättningar.There are numerous AKS clusters / node pools using virtual machine scale sets. Försök att dela antalet kluster i olika prenumerationer, i synnerhet om du förväntar dig att de ska vara mycket aktiva (till exempel en aktiv kluster autoskalning) eller har flera klienter (till exempel rancher, terraform och så vidare).Try to split your number of clusters into different subscriptions, in particular if you expect them to be very active (for example, an active cluster autoscaler) or have multiple clients (for example, rancher, terraform, and so on).

Mitt klusters etablerings status har ändrats från klar till misslyckades med eller utan att jag utför en åtgärd.My cluster's provisioning status changed from Ready to Failed with or without me performing an operation. Vad ska jag göra?What should I do?

Om klustrets etablerings status ändras från klar till misslyckad eller utan att du utför några åtgärder, men programmen i klustret fortsätter att köras, kan det här problemet lösas automatiskt av tjänsten och dina program påverkas inte.If your cluster's provisioning status changes from Ready to Failed with or without you performing any operations, but the applications on your cluster are continuing to run, this issue may be resolved automatically by the service and your applications should not be affected.

Skicka en supportbegäranom klustrets etablerings status är kvar som misslyckad eller om programmen i klustret slutar fungera.If your cluster's provisioning status remains as Failed or the applications on your cluster stop working, submit a support request.

Min Watch är inaktuell eller Azure AD Pod Identity NMI returnerar status 500My watch is stale or Azure AD Pod Identity NMI is returning status 500

Om du använder Azure-brandväggen som i det här exempletkan du stöta på det här problemet eftersom de långsamma TCP-anslutningarna via brand vägg som använder program regler för närvarande har ett fel (som ska lösas i Q1CY21) som gör att go keepalives avslutas i brand väggen.If you're using Azure Firewall like on this example, you may encounter this issue as the long lived TCP connections via firewall using Application Rules currently have a bug (to be resolved in Q1CY21) that causes the Go keepalives to be terminated on the firewall. Tills det här problemet har lösts kan du minska genom att lägga till en nätverks regel (i stället för program regel) till IP-AKS för API-servern.Until this issue is resolved, you can mitigate by adding a Network rule (instead of application rule) to the AKS API server IP.

Azure Storage-och AKS-felsökningAzure Storage and AKS Troubleshooting

Det gick inte att ställa in UID och GID i mountOptions för Azure diskFailure when setting uid and GID in mountOptions for Azure Disk

Azure-disken använder ext4, xfs-filsystem som standard och mountOptions, till exempel UID = x, GID = x kan inte ställas in vid monterings tiden.Azure Disk uses the ext4,xfs filesystem by default and mountOptions such as uid=x,gid=x can't be set at mount time. Om du till exempel försökte ange mountOptions UID = 999, GID = 999, ser du ett fel som:For example if you tried to set mountOptions uid=999,gid=999, would see an error like:

Warning  FailedMount             63s                  kubelet, aks-nodepool1-29460110-0  MountVolume.MountDevice failed for volume "pvc-d783d0e4-85a1-11e9-8a90-369885447933" : azureDisk - mountDevice:FormatAndMount failed with mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m436970985 --scope -- mount -t xfs -o dir_mode=0777,file_mode=0777,uid=1000,gid=1000,defaults /dev/disk/azure/scsi1/lun2 /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m436970985
Output: Running scope as unit run-rb21966413ab449b3a242ae9b0fbc9398.scope.
mount: wrong fs type, bad option, bad superblock on /dev/sde,
       missing codepage or helper program, or other error

Du kan åtgärda problemet genom att göra något av alternativen:You can mitigate the issue by doing one the options:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Anteckning

Eftersom GID och UID monteras som rot eller 0 som standard.Since gid and uid are mounted as root or 0 by default. Om GID eller UID anges som icke-rot, till exempel 1000, används Kubernetes för chown att ändra alla kataloger och filer under den disken.If gid or uid are set as non-root, for example 1000, Kubernetes will use chown to change all directories and files under that disk. Den här åtgärden kan ta lång tid och kan göra det mycket långsamt att montera disken.This operation can be time consuming and may make mounting the disk very slow.

  • Använd chown i initContainers för att ange GID och UID .Use chown in initContainers to set GID and UID. Exempel:For example:
initContainers:
- name: volume-mount
  image: busybox
  command: ["sh", "-c", "chown -R 100:100 /data"]
  volumeMounts:
  - name: <your data volume>
    mountPath: /data

Det gick inte att koppla från Azure-disken till ett potentiellt problem med konkurrens villkoret och ogiltig data disk listaAzure Disk detach failure leading to potential race condition issue and invalid data disk list

När en Azure-disk inte kan kopplas tillbaka, kommer den att försöka igen om till sex gånger för att koppla bort disken från exponentiellt.When an Azure Disk fails to detach, it will retry up to six times to detach the disk using exponential back off. Det kommer också att innehålla ett lås på radnivå på data disk listan i ungefär 3 minuter.It will also hold a node-level lock on the data disk list for about 3 minutes. Om disk listan uppdateras manuellt under den tiden kommer den att orsaka att disk listan hålls kvar av låset på nodens nivå för att bli inaktuell och orsakar instabilitet på noden.If the disk list is updated manually during that time, it will cause the disk list held by the node-level lock to be obsolete and cause instability on the node.

Det här problemet har åtgärd ATS i följande versioner av Kubernetes:This issue has been fixed in the following versions of Kubernetes:

Kubernetes-versionKubernetes version Fast versionFixed version
1.121.12 1.12.9 eller senare1.12.9 or later
1.131.13 1.13.6 eller senare1.13.6 or later
1,141.14 1.14.2 eller senare1.14.2 or later
1,15 och senare1.15 and later SaknasN/A

Om du använder en version av Kubernetes som inte har korrigeringen för det här problemet och noden har en föråldrad disk lista kan du minska genom att koppla bort alla icke-befintliga diskar från den virtuella datorn som en Mass åtgärd.If you're using a version of Kubernetes that doesn't have the fix for this issue and your node has an obsolete disk list, you can mitigate by detaching all non-existing disks from the VM as a bulk operation. En separat från koppling av icke-befintliga diskar kan Miss lyckas.Individually detaching non-existing disks may fail.

Ett stort antal Azure-diskar orsakar långsam anslutning/från kopplingLarge number of Azure Disks causes slow attach/detach

När antalet åtgärder för att koppla/koppla från Azure-disk som är mål för en enskild nod är större än 10, eller större än 3 när du använder en pool för en enskild virtuell dators skalnings uppsättning, kan de vara långsammare än förväntat när de görs i tur och ordning.When the numbers of Azure Disk attach/detach operations targeting a single node VM is larger than 10, or larger than 3 when targeting single virtual machine scale set pool they may be slower than expected as they are done sequentially. Det här problemet är en känd begränsning och det finns inga lösningar för tillfället.This issue is a known limitation and there are no workarounds at this time. Röst objekt för användare som stöder parallell anslutning/från koppling utöver nummer...User voice item to support parallel attach/detach beyond number..

Det gick inte att koppla från Azure-disken till en möjlig nods VM i felaktigt tillståndAzure Disk detach failure leading to potential node VM in failed state

I vissa fall kan en Azure disk-från koppling delvis Miss lyckas och lämna noden VM i ett felaktigt tillstånd.In some edge cases, an Azure Disk detach may partially fail and leave the node VM in a failed state.

Det här problemet har åtgärd ATS i följande versioner av Kubernetes:This issue has been fixed in the following versions of Kubernetes:

Kubernetes-versionKubernetes version Fast versionFixed version
1.121.12 1.12.10 eller senare1.12.10 or later
1.131.13 1.13.8 eller senare1.13.8 or later
1,141.14 1.14.4 eller senare1.14.4 or later
1,15 och senare1.15 and later SaknasN/A

Om du använder en version av Kubernetes som inte har korrigeringen för det här problemet och noden är i ett felaktigt tillstånd kan du minska genom att manuellt uppdatera VM-statusen med hjälp av någon av följande:If you're using a version of Kubernetes that doesn't have the fix for this issue and your node is in a failed state, you can mitigate by manually updating the VM status using one of the below:

  • För ett tillgänglighets uppsättnings kluster:For an availability set-based cluster:

    az vm update -n <VM_NAME> -g <RESOURCE_GROUP_NAME>
    
  • För ett VMSS-baserat kluster:For a VMSS-based cluster:

    az vmss update-instances -g <RESOURCE_GROUP_NAME> --name <VMSS_NAME> --instance-id <ID>
    

Azure Files-och AKS-felsökningAzure Files and AKS Troubleshooting

Kubernetes-versionKubernetes version Rekommenderad versionRecommended version
1.121.12 1.12.6 eller senare1.12.6 or later
1.131.13 1.13.4 eller senare1.13.4 or later
1,141.14 1.14.0 eller senare1.14.0 or later

Vad är standard-mountOptions när du använder Azure Files?What are the default mountOptions when using Azure Files?

Rekommenderade inställningar:Recommended settings:

Kubernetes-versionKubernetes version fileMode-och dirMode-värdefileMode and dirMode value
1.12.0 - 1.12.11.12.0 - 1.12.1 07550755
1.12.2 och senare1.12.2 and later 07770777

Monterings alternativ kan anges för objektet lagrings klass.Mount options can be specified on the storage class object. I följande exempel anges 0777:The following example sets 0777:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azurefile
provisioner: kubernetes.io/azure-file
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=1000
  - gid=1000
  - mfsymlinks
  - nobrl
  - cache=none
parameters:
  skuName: Standard_LRS

Några ytterligare användbara mountOptions -inställningar:Some additional useful mountOptions settings:

  • mfsymlinks kommer att göra Azure Files montering (CIFS) stöder symboliska länkarmfsymlinks will make Azure Files mount (cifs) support symbolic links
  • nobrl förhindrar överföring av byte intervall lås begär anden till servern.nobrl will prevent sending byte range lock requests to the server. Den här inställningen är nödvändig för vissa program som slutar med en CIFS-format som är obligatoriska byte intervall lås.This setting is necessary for certain applications that break with cifs style mandatory byte range locks. De flesta CIFS-servrar har ännu inte stöd för begäran om att låsa byte intervall lås.Most cifs servers don't yet support requesting advisory byte range locks. Om du inte använder nobrl kan program som slutar med CIFS-format som är obligatoriska byte intervall lås orsaka fel meddelanden som liknar:If not using nobrl, applications that break with cifs style mandatory byte range locks may cause error messages similar to:
    Error: SQLITE_BUSY: database is locked
    

Fel "Det gick inte att ändra behörigheter" vid användning av Azure FilesError "could not change permissions" when using Azure Files

När du kör PostgreSQL på Azure Files-plugin-programmet kan du se ett fel som liknar följande:When running PostgreSQL on the Azure Files plugin, you may see an error similar to:

initdb: could not change permissions of directory "/var/lib/postgresql/data": Operation not permitted
fixing permissions on existing directory /var/lib/postgresql/data

Det här felet orsakas av Azure Files-plugin-programmet som använder CIFS/SMB-protokollet.This error is caused by the Azure Files plugin using the cifs/SMB protocol. När du använder CIFS/SMB-protokollet, kunde inte fil-och katalog behörigheter ändras efter montering.When using the cifs/SMB protocol, the file and directory permissions couldn't be changed after mounting.

Lös problemet genom att använda subPath tillsammans med Azures disk-plugin-programmet.To resolve this issue, use subPath together with the Azure Disk plugin.

Anteckning

För ext3/4-disk typen finns en förlorad + found katalog efter att disken formaterats.For ext3/4 disk type, there is a lost+found directory after the disk is formatted.

Azure Files har hög latens jämfört med Azure disk vid hantering av många små filerAzure Files has high latency compared to Azure Disk when handling many small files

I vissa fall, t. ex. hantering av många små filer, kan du uppleva hög fördröjning när du använder Azure Files jämfört med Azure disk.In some case, such as handling many small files, you may experience high latency when using Azure Files when compared to Azure Disk.

Fel vid aktivering av inställningen Tillåt åtkomst Tillåt åtkomst från valt nätverk på lagrings kontotError when enabling "Allow access allow access from selected network" setting on storage account

Om du aktiverar Tillåt åtkomst från det valda nätverket på ett lagrings konto som används för dynamisk etablering i AKS får du ett fel när AKS skapar en fil resurs:If you enable allow access from selected network on a storage account that's used for dynamic provisioning in AKS, you'll get an error when AKS creates a file share:

persistentvolume-controller (combined from similar events): Failed to provision volume with StorageClass "azurefile": failed to create share kubernetes-dynamic-pvc-xxx in account xxx: failed to create file share, err: storage: service returned error: StatusCode=403, ErrorCode=AuthorizationFailure, ErrorMessage=This request is not authorized to perform this operation.

Det här felet beror på att Kubernetes -persistentvolume inte finns på nätverket som valdes när du ställer in Tillåt åtkomst från det valda nätverket.This error is because of the Kubernetes persistentvolume-controller not being on the network chosen when setting allow access from selected network.

Du kan åtgärda problemet genom att använda statisk etablering med Azure Files.You can mitigate the issue by using static provisioning with Azure Files.

Azure Files kan inte montera om i Windows PodAzure Files fails to remount in Windows pod

Om en Windows-Pod med en Azure Files-montering tas bort och sedan schemaläggs för att återskapas på samma nod, kommer monteringen att Miss sen.If a Windows pod with an Azure Files mount is deleted and then scheduled to be recreated on the same node, the mount will fail. Det här felet beror på att New-SmbGlobalMapping kommandot Miss lyckas eftersom Azure Files Mount redan har monterats på noden.This failure is because of the New-SmbGlobalMapping command failing since the Azure Files mount is already mounted on the node.

Du kan till exempel se ett fel som liknar:For example, you may see an error similar to:

E0118 08:15:52.041014    2112 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/azure-file/42c0ea39-1af9-11e9-8941-000d3af95268-pvc-d7e1b5f9-1af3-11e9-8941-000d3af95268\" (\"42c0ea39-1af9-11e9-8941-000d3af95268\")" failed. No retries permitted until 2019-01-18 08:15:53.0410149 +0000 GMT m=+732.446642701 (durationBeforeRetry 1s). Error: "MountVolume.SetUp failed for volume \"pvc-d7e1b5f9-1af3-11e9-8941-000d3af95268\" (UniqueName: \"kubernetes.io/azure-file/42c0ea39-1af9-11e9-8941-000d3af95268-pvc-d7e1b5f9-1af3-11e9-8941-000d3af95268\") pod \"deployment-azurefile-697f98d559-6zrlf\" (UID: \"42c0ea39-1af9-11e9-8941-000d3af95268\") : azureMount: SmbGlobalMapping failed: exit status 1, only SMB mount is supported now, output: \"New-SmbGlobalMapping : Generic failure \\r\\nAt line:1 char:190\\r\\n+ ... ser, $PWord;New-SmbGlobalMapping -RemotePath $Env:smbremotepath -Cred ...\\r\\n+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\\r\\n    + CategoryInfo          : NotSpecified: (MSFT_SmbGlobalMapping:ROOT/Microsoft/...mbGlobalMapping) [New-SmbGlobalMa \\r\\n   pping], CimException\\r\\n    + FullyQualifiedErrorId : HRESULT 0x80041001,New-SmbGlobalMapping\\r\\n \\r\\n\""

Det här problemet har åtgärd ATS i följande versioner av Kubernetes:This issue has been fixed in the following versions of Kubernetes:

Kubernetes-versionKubernetes version Fast versionFixed version
1.121.12 1.12.6 eller senare1.12.6 or later
1.131.13 1.13.4 eller senare1.13.4 or later
1,14 och senare1.14 and later SaknasN/A

Azure Files monteringen Miss lyckas på grund av att lagrings konto nyckeln har ändratsAzure Files mount fails because of storage account key changed

Om din lagrings konto nyckel har ändrats kan du se Azure Files Mount-felen.If your storage account key has changed, you may see Azure Files mount failures.

Du kan åtgärda problemet genom att manuellt uppdatera azurestorageaccountkey fältet manuellt i en Azure-filhemlighet med din base64-kodade lagrings konto nyckel.You can mitigate by manually updating the azurestorageaccountkey field manually in an Azure file secret with your base64-encoded storage account key.

Du kan använda för att koda lagrings konto nyckeln i base64 base64 .To encode your storage account key in base64, you can use base64. Exempel:For example:

echo X+ALAAUgMhWHL7QmQ87E1kSfIqLKfgC03Guy7/xk9MyIg2w4Jzqeu60CVw2r/dm6v6E0DWHTnJUEJGVQAoPaBc== | base64

Om du vill uppdatera din Azure-hemlig fil använder du kubectl edit secret .To update your Azure secret file, use kubectl edit secret. Exempel:For example:

kubectl edit secret azure-storage-account-{storage-account-name}-secret

Efter några minuter kommer agent-noden att försöka montera Azure-filen igen med den uppdaterade lagrings nyckeln.After a few minutes, the agent node will retry the Azure File mount with the updated storage key.

Det gick inte att skala kluster autoskalning med felet kunde inte åtgärda grupp storlekarnaCluster autoscaler fails to scale with error failed to fix node group sizes

Om klustrets autoskalning inte skalar upp/ned och du ser ett fel som det nedan på loggarna för klustrets autoskalning.If your cluster autoscaler isn't scaling up/down and you see an error like the below on the cluster autoscaler logs.

E1114 09:58:55.367731 1 static_autoscaler.go:239] Failed to fix node group sizes: failed to decrease aks-default-35246781-vmss: attempt to delete existing nodes

Det här felet beror på ett konkurrens villkor för en överordnad kluster autoskalning.This error is because of an upstream cluster autoscaler race condition. I sådana fall slutar kluster autoskalning med ett annat värde än det som faktiskt finns i klustret.In such a case, cluster autoscaler ends with a different value than the one that is actually in the cluster. Inaktivera och återaktivera klustrets autoskalningför att komma ur det här läget.To get out of this state, disable and re-enable the cluster autoscaler.

Långsam disk bilaga, GetAzureDiskLun tar 10 till 15 minuter och du får ett fel meddelandeSlow disk attachment, GetAzureDiskLun takes 10 to 15 minutes and you receive an error

På Kubernetes-versioner som är äldre än 1.15.0 kan du få ett fel meddelande som fel WaitForAttach inte kan hitta LUN för disk.On Kubernetes versions older than 1.15.0, you may receive an error such as Error WaitForAttach Cannot find Lun for disk. Lösningen på det här problemet är att vänta cirka 15 minuter och försöka igen.The workaround for this issue is to wait approximately 15 minutes and retry.

Varför fungerar inte uppgraderingar av Kubernetes 1,16 när du använder Node-etiketter med ett kubernetes.io-prefixWhy do upgrades to Kubernetes 1.16 fail when using node labels with a kubernetes.io prefix

Från och med Kubernetes 1,16 kan endast en definierad delmängd av etiketter med Kubernetes.io-prefix användas av kubelet till noder.As of Kubernetes 1.16 only a defined subset of labels with the kubernetes.io prefix can be applied by the kubelet to nodes. AKS kan inte ta bort aktiva etiketter för din räkning utan medgivande, eftersom det kan orsaka avbrott i arbets belastningar som påverkas.AKS cannot remove active labels on your behalf without consent, as it may cause downtime to impacted workloads.

Det innebär att du kan åtgärda problemet genom att:As a result, to mitigate this issue you can:

  1. Uppgradera ditt kluster kontroll plan till 1,16 eller högreUpgrade your cluster control plane to 1.16 or higher
  2. Lägg till en ny nodepoool på 1,16 eller högre utan de kubernetes.io-etiketter som inte stödsAdd a new nodepoool on 1.16 or higher without the unsupported kubernetes.io labels
  3. Ta bort den äldre Node-poolenDelete the older node pool

AKS undersöker kapaciteten för att ligga över aktiva etiketter i en Node-pool för att förbättra den här lösningen.AKS is investigating the capability to mutate active labels on a node pool to improve this mitigation.