Felsöka fel vid distribution av AKS-klustertillägg
I den här artikeln beskrivs hur du felsöker fel som uppstår när du distribuerar klustertillägg för Microsoft Azure Kubernetes Service (AKS).
Fel vid skapande av tillägg
Fel: Det går inte att hämta ett svar från agenten i tid
Det här felet uppstår om Azure-tjänster inte får något svar från klustertilläggsagenten. Den här situationen kan inträffa eftersom AKS-klustret inte kan upprätta en anslutning till Azure.
Orsak 1: Klustertilläggsagenten och hanteringspoddarna initieras inte
Klustertilläggsagenten och chefen är viktiga systemkomponenter som ansvarar för att hantera livscykeln för Kubernetes-program. Initieringen av klustertilläggsagenten och hanteringspoddar kan misslyckas på grund av följande problem:
- Resursbegränsningar
- Principbegränsningar
- Nodtaints, till exempel
NoSchedule
Lösning 1: Kontrollera att klustertilläggsagenten och hanteringspoddarna fungerar korrekt
Lös problemet genom att se till att klustertilläggsagenten och hanteringspoddarna är korrekt schemalagda och kan starta. Om poddarna har fastnat i ett oläst tillstånd kontrollerar du poddbeskrivningen genom att köra följande kubectl describe pod kommando för att få mer information om de underliggande problemen (till exempel taints som förhindrar schemaläggning, otillräckligt minne eller principbegränsningar):
kubectl describe pod -n kube-system extension-operator-{id}
Här är ett kommandoutdataexempel:
kube-system extension-agent-55d4f4795f-sqx7q 2/2 Running 0 2d19h
kube-system extension-operator-56c8d5f96c-nvt7x 2/2 Running 0 2d19h
För ARC-anslutna kluster kör du följande kommando för att kontrollera poddbeskrivningen:
kubectl describe pod -n azure-arc extension-manager-{id}
Här är ett kommandoutdataexempel:
NAMESPACE NAME READY STATUS RESTARTS AGE
azure-arc cluster-metadata-operator-744f8bfbd4-7pssr 0/2 ImagePullBackOff 0 6d19h
azure-arc clusterconnect-agent-7557d99d5c-rtgqh 0/3 ImagePullBackOff 0 6d19h
azure-arc clusteridentityoperator-9b8b88f97-nr8hf 0/2 ImagePullBackOff 0 6d19h
azure-arc config-agent-6d5fd59b8b-khw2d 0/2 ImagePullBackOff 0 6d19h
azure-arc controller-manager-5bc97f7db6-rt2zs 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-events-collector-7596688867-sqzv2 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-manager-86bbb949-6s59q 0/3 ImagePullBackOff 0 6d19h
azure-arc flux-logs-agent-5f55888db9-wnr4c 0/1 ImagePullBackOff 0 6d19h
azure-arc kube-aad-proxy-646c475dcc-92b86 0/2 ImagePullBackOff 0 6d19h
azure-arc logcollector-5cbc659bfb-9v96d 0/1 ImagePullBackOff 0 6d19h
azure-arc metrics-agent-5794866b46-j9949 0/2 ImagePullBackOff 0 6d19h
azure-arc resource-sync-agent-6cf4cf7486-flgwc 0/2 ImagePullBackOff 0 6d19h
När klustertilläggsagenten och hanteringspoddarna är driftsdugliga och felfria upprättar de kommunikation med Azure-tjänster för att installera och hantera Kubernetes-program.
Orsak 2: Ett problem påverkar utgående block eller brandvägg
Om klustertilläggsagenten och hanteringspoddarna är felfria och du fortfarande stöter på felet "Det går inte att få ett svar från agenten i tid" finns förmodligen ett utgående block- eller brandväggsproblem. Det här problemet kan blockera klustertilläggsagenten och hanteringspoddar från att kommunicera med Azure.
Lösning 2: Kontrollera att nätverkskraven uppfylls
Lös problemet genom att se till att du följer de nätverkskrav som beskrivs i utgående nätverk och FQDN-regler för AKS-kluster (Azure Kubernetes Service).
Orsak 3: Trafiken är inte auktoriserad
Tilläggsagenten försöker utan framgång anropa tjänstslutpunkter för <region>.dp.kubernetesconfiguration.azure.com dataplanet. Det här felet genererar posten "Errorcode: 403, Message This traffic is not authorized" i poddloggarna för tilläggsagenten.
kubectl logs -n kube-system extension-agent-<pod-guid>
{ "Message": "2024/02/07 06:04:43 \"Errorcode: 403, Message This traffic is not authorized., Target /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/provider/managedclusters/clusters/<cluster-name>/configurations/getPendingConfigs\"", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>, "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
{ "Message": "2024/02/07 06:04:43 Failed to GET configurations with err : {\u003cnil\u003e}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
Det här felet uppstår om det finns ett befintligt PrivateLinkScope i ett tilläggs dataplan för Azure Arc-aktiverade Kubernetes och det virtuella nätverket (eller den privata DNS-servern) delas mellan Azure Arc-aktiverade Kubernetes och det AKS-hanterade klustret. Den här nätverkskonfigurationen gör att AKS utgående trafik från tilläggsdataplanet även dirigeras via samma privata IP-adress i stället för via en offentlig IP-adress.
Kör följande nslookup-kommando i AKS-klustret för att hämta den specifika privata IP-adress som dataplanets slutpunkt matchar:
PS D:\> kubectl exec -it -n kube-system extension-agent-<pod-guid> -- nslookup <region>.dp.kubernetesconfiguration.azure.com
Non-authoritative answer:
<region>.dp.kubernetesconfiguration.azure.com canonical name = <region>.privatelink.dp.kubernetesconfiguration.azure.com
Name: <region>.privatelink.dp.kubernetesconfiguration.azure.com
Address: 10.224.1.184
När du söker efter den privata IP-adressen i Azure Portal pekar sökresultaten på den exakta resursen: virtuellt nätverk, privat DNS-zon, privat DNS-server och så vidare. Den här resursen har en privat slutpunkt som har konfigurerats för tilläggsdataplanet för Azure Arc-aktiverade Kubernetes.
Lösning 3.1: (Rekommenderas) Skapa separata virtuella nätverk
För att lösa det här problemet rekommenderar vi att du skapar separata virtuella nätverk för Azure Arc-aktiverade Kubernetes- och AKS-beräkningar.
Lösning 3.2: Skapa en CoreDNS-åsidosättning
Om den rekommenderade lösningen inte är möjlig i din situation skapar du en CoreDNS-åsidosättning för att tilläggsdataplanets slutpunkt ska gå över det offentliga nätverket. Mer information om hur du anpassar CoreDNS finns i avsnittet "Hosts plugin" i "Anpassa CoreDNS med Azure Kubernetes Service".
Följ dessa steg för att skapa en CoreDNS-åsidosättning:
Hitta den offentliga IP-adressen för tilläggets dataplansslutpunkt genom att
nslookupköra kommandot . Se till att du ändrar regionen (till exempeleastus2euap) baserat på platsen för ditt AKS-kluster:nslookup <region>.dp.kubernetesconfiguration.azure.com Non-authoritative answer: Name: clusterconfig<region>.<region>.cloudapp.azure.com Address: 20.39.12.229 Aliases: <region>.dp.kubernetesconfiguration.azure.com <region>.privatelink.dp.kubernetesconfiguration.azure.com <region>.dp.kubernetesconfiguration.trafficmanager.netSkapa en säkerhetskopia av den befintliga coreDNS-konfigurationen:
kubectl get configmap -n kube-system coredns-custom -o yaml > coredns.backup.yamlÅsidosätt mappningen för den regionala (till exempel
eastus2euap) dataplanets slutpunkt till den offentliga IP-adressen. För att göra detta skapar du en YAML-fil med namnet corednsms.yaml och kopierar sedan följande exempelkonfiguration till den nya filen. (Se till att du uppdaterar adressen och värdnamnet med hjälp av värdena för din miljö.)apiVersion: v1 kind: ConfigMap metadata: name: coredns-custom # This is the name of the configuration map that you can overwrite with your changes. namespace: kube-system data: extensionsdp.override: | # You can select any name here, but it must have the .override file name extension. hosts { 20.39.12.229 <region>.dp.kubernetesconfiguration.azure.com fallthrough }Om du vill skapa ConfigMap kör
kubectl applydu kommandot och anger namnet på YAML-manifestfilen:kubectl apply -f corednsms.yamlOm du vill läsa in ConfigMap igen och göra det möjligt för Kubernetes Scheduler att starta om CoreDNS utan driftstopp kör du kommandot för kubectl-distributionsstart :
kubectl -n kube-system rollout restart deployment corednsnslookupKör kommandot igen för att se till att dataplanets slutpunkt matchar den angivna offentliga IP-adressen:kubectl exec -it -n kube-system extension-agent-55d4f4795f-nld9q -- nslookup [region].dp.kubernetesconfiguration.azure.com Name: <region>.dp.kubernetesconfiguration.azure.com Address: 20.39.12.229
Poddloggarna för tilläggsagenten bör inte längre logga felkod: 403, meddelande Den här trafiken är inte auktoriserad. I stället ska loggarna innehålla svarskoderna "200".
kubectl logs -n kube-system extension-agent-{id}
{ "Message": "GET configurations returned response code {200}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5" }
Fel: Tilläggspoddar kan inte schemaläggas om alla nodpooler i klustret är "CriticalAddonsOnly" fördärvade
När det här felet inträffar loggas följande post i tilläggsagentloggen:
Tilläggspoddfel: 0/2 noder är tillgängliga: 2 noder hade orörd taint {CriticalAddonsOnly: true}. preemption: 0/2 noder är tillgängliga: 2 Preemption är inte användbart för schemaläggning.
Orsak
Det här felet uppstår när du försöker aktivera tillägg (till exempel DAPR (Distributed Application Runtime) i ett AKS-kluster som har CriticalAddonsOnly fläckade nodpooler. I det här fallet schemaläggs inte tilläggspoddar på någon nod eftersom det inte finns någon tolerans för dessa taints.
Om du vill visa felsituationen granskar du tilläggspoddarna för att kontrollera att de har fastnat i ett väntande tillstånd:
kubectl get po -n {namespace-name} -l app.kubernetes.io/name={name}
NAME READY STATUS RESTARTS AGE
{podname} 0/2 Pending 0 2d6h
Beskriv poddarna för att se att de inte kan schemaläggas på grund av en taint som inte stöds:
kubectl describe po -n {namespace-name} {podname}
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 18s default-scheduler 0/2 nodes are available: 2 node(s) had untolerated taint {CriticalAddonsOnly: true}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
Kommentar
Vi rekommenderar att du inte installerar tillägg på
CriticalAddOnsOnlyfördärvade nodpooler såvida inte detta krävs för programarbetsbelastningar.Vi rekommenderar att du inte använder en taint på kluster med en
CriticalAddOnsOnlynodpool. Om du använder den tainten i ett kluster som bara har en nodpool kan du inte schemalägga programpoddar i klustret. Kontrollera att minst en nodpool i klustret inte har den här tainten. Mer information om när anteckningenCriticalAddonsOnlyska användas finns i Hantera systemnodpooler i Azure Kubernetes Service (AKS).
Lösning 1: Lägga till en nodpool i klustret
Lös problemet genom att lägga till ytterligare en nodpool som inte har en CriticalAddonsOnly taint. Den här åtgärden gör att tilläggspoddarna schemaläggs i den nya nodpoolen.
Lösning 2: Ta bort tainten "CriticalAddonsOnly"
Om det är möjligt och praktiskt kan du ta bort CriticalAddonsOnly taint för att installera tillägget i klustret.
Helm-fel
Du kan stöta på något av följande Helm-relaterade fel:
- Tidsgränsen gick ut i väntan på resursberedskap
- Det gick inte att ladda ned Helm-diagrammet från lagringsplatsens URL
- Helm-diagramåtergivning misslyckades med angivna värden
- Resursen finns redan i klustret
- Åtgärden pågår redan för Helm
Fel: Tidsgränsen för att vänta på resursberedskap
Installationen av ett Kubernetes-program misslyckas och följande felmeddelanden visas:
jobbet misslyckades: BackoffLimitExceeded
Tidsgränsen för att vänta på att resursen ska komma till ett färdigt/slutfört tillstånd.
Orsak
Det här problemet har följande vanliga orsaker:
Resursbegränsningar: Otillräckligt minne eller CPU-resurser i klustret kan förhindra en lyckad initiering av poddar, jobb eller andra Kubernetes-resurser. Så småningom leder den här situationen till att installationen överskrider tidsgränsen. Principbegränsningar eller nodtaints (till exempel
NoSchedule) kan också blockera resursinitiering.Arkitekturfel: Om du försöker schemalägga ett Linux-baserat program på en Windows-baserad nod (eller tvärtom) kan det orsaka fel i Kubernetes-resursinitiering.
Felaktiga konfigurationsinställningar: Felaktiga konfigurationsinställningar kan hindra poddar från att starta.
Lösning
Följ det här stegen för att lösa problemet:
Kontrollera resurser: Kontrollera att Kubernetes-klustret har tillräckligt med resurser och att poddschemaläggning tillåts på noderna (du bör överväga taints). Kontrollera att minne och CPU-resurser uppfyller kraven.
Granska händelser: Kontrollera händelserna i Kubernetes-namnområdet för att identifiera potentiella problem som kan hindra poddar, jobb eller andra Kubernetes-resurser från att nå ett klart tillstånd.
Kontrollera Helm-diagram och -konfigurationer: Många Kubernetes-program använder Helm-diagram för att distribuera resurser i klustret. Vissa program kan kräva användarindata via konfigurationsinställningar. Kontrollera att alla angivna konfigurationsvärden är korrekta och uppfyller installationskraven.
Fel: Det går inte att ladda ned Helm-diagrammet från lagringsplatsens URL
Det här felet orsakas av anslutningsproblem som uppstår mellan klustret och brandväggen utöver problem med utgående blockering. Information om hur du löser det här problemet finns i Utgående nätverk och FQDN-regler för AKS-kluster (Azure Kubernetes Service).
Fel: Helm-diagramåtergivningen misslyckades med angivna värden
Det här felet uppstår om Kubernetes-program förlitar sig på Helm-diagram för att distribuera resurser i Kubernetes-klustret. Dessa program kan kräva användarindata som tillhandahålls via konfigurationsinställningar som skickas som Helm-värden under installationen. Om någon av dessa viktiga konfigurationsinställningar saknas eller är felaktiga kanske Helm-diagrammet inte återges.
Lös problemet genom att läsa tilläggs- eller programdokumentationen för att avgöra om du utelämnade några obligatoriska värden eller angav felaktiga värden under programinstallationen. De här riktlinjerna kan hjälpa dig att åtgärda problem med Helm-diagramåtergivning som orsakas av saknade eller felaktiga konfigurationsvärden.
Fel: Resursen finns redan i klustret
Det här felet uppstår om det finns en konflikt mellan Kubernetes-resurserna i klustret och Kubernetes-resurserna som programmet försöker installera. Felmeddelandet anger vanligtvis namnet på den resurs som står i konflikt.
Om den resurs som står i konflikt är nödvändig och inte kan ersättas kanske du inte kan installera programmet. Om resursen inte är kritisk och kan tas bort tar du bort resursen som står i konflikt och försöker sedan installera igen.
Fel: Åtgärden pågår redan för Helm
Det här felet uppstår om det redan pågår en åtgärd för en viss version. Lös problemet genom att vänta 10 minuter och sedan försöka utföra åtgärden igen.
Kontakta oss för att få hjälp
Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.