Granska nodens och poddhälsan

Den här artikeln ingår i en serie. Börja med översikten.

Om klustret kontrollerar att du utförde i föregående steg är avmarkerat kontrollerar du hälsotillståndet för Azure Kubernetes Service-arbetsnoderna (AKS). Följ de sex stegen i den här artikeln för att kontrollera hälsotillståndet för noder, fastställa orsaken till en nod som inte är felfri och lösa problemet.

Steg 1: Kontrollera hälsotillståndet för arbetsnoder

Olika faktorer kan bidra till noder som inte är felfria i ett AKS-kluster. En vanlig orsak är uppdelningen av kommunikationen mellan kontrollplanet och noderna. Den här felkommunikationen orsakas ofta av felkonfigurationer i routnings- och brandväggsregler.

När du konfigurerar aks-klustret för användardefinierad routning måste du konfigurera utgående sökvägar via en virtuell nätverksinstallation (NVA) eller en brandvägg, till exempel en Azure-brandvägg. För att åtgärda ett felkonfigurationsproblem rekommenderar vi att du konfigurerar brandväggen för att tillåta nödvändiga portar och fullständigt kvalificerade domännamn (FQDN) i enlighet med riktlinjerna för utgående AKS-trafik.

En annan orsak till felaktiga noder kan vara otillräckliga beräknings-, minnes- eller lagringsresurser som skapar kubelettryck. I sådana fall kan en skalning av resurserna effektivt lösa problemet.

I ett privat AKS-kluster kan DNS-lösningsproblem (Domain Name System) orsaka kommunikationsproblem mellan kontrollplanet och noderna. Du måste kontrollera att Kubernetes API-serverns DNS-namn matchar API-serverns privata IP-adress. Felaktig konfiguration av en anpassad DNS-server är en vanlig orsak till DNS-matchningsfel. Om du använder anpassade DNS-servrar kontrollerar du att du korrekt anger dem som DNS-servrar i det virtuella nätverk där noder etableras. Bekräfta också att den privata AKS-API-servern kan lösas via den anpassade DNS-servern.

När du har åtgärdat dessa potentiella problem som rör kontrollplanskommunikation och DNS-matchning kan du effektivt hantera och lösa problem med nodhälsa i AKS-klustret.

Du kan utvärdera hälsotillståndet för dina noder med någon av följande metoder.

Hälsovy för Azure Monitor-containrar

Följ dessa steg för att visa hälsotillståndet för noder, användarpoddar och systempoddar i AKS-klustret:

1. Gå till Azure Monitor i Azure-portalen.
2. I avsnittet Insikter i navigeringsfönstret väljer du Containrar.
3. Välj Övervakade kluster för en lista över DE AKS-kluster som övervakas.
4. Välj ett AKS-kluster i listan för att visa hälsotillståndet för noderna, användarpoddar och systempoddar.

Vyn AKS-noder

Följ dessa steg för att säkerställa att alla noder i AKS-klustret är i klart tillstånd:

1. I Azure-portalen går du till ditt AKS-kluster.
2. I avsnittet Inställningar i navigeringsfönstret väljer du Nodpooler.
3. Välj Noder.
4. Kontrollera att alla noder är i klart tillstånd.

Övervakning i kluster med Prometheus och Grafana

Om du har distribuerat Prometheus och Grafana i aks-klustret kan du använda K8-klusterinformationsinstrumentpanelen för att få insikter. Den här instrumentpanelen visar Prometheus-klustermått och visar viktig information, till exempel CPU-användning, minnesanvändning, nätverksaktivitet och filsystemanvändning. Den visar också detaljerad statistik för enskilda poddar, containrar och systembaserade tjänster.

På instrumentpanelen väljer du Nodvillkor för att se mått om hälsotillstånd och prestanda för klustret. Du kan spåra noder som kan ha problem, till exempel problem med deras schema, nätverk, disktryck, minnestryck, proportionellt derivattryck (PID) eller diskutrymme. Övervaka dessa mått så att du proaktivt kan identifiera och åtgärda eventuella problem som påverkar tillgängligheten och prestandan för ditt AKS-kluster.

Övervaka hanterad tjänst för Prometheus och Azure Managed Grafana

Du kan använda fördefinierade instrumentpaneler för att visualisera och analysera Prometheus-mått. För att göra det måste du konfigurera DITT AKS-kluster för att samla in Prometheus-mått i Övervaka hanterad tjänst för Prometheus och ansluta din Monitor-arbetsyta till en Azure Managed Grafana-arbetsyta . Dessa instrumentpaneler ger en omfattande vy över kubernetes-klustrets prestanda och hälsa.

Instrumentpanelerna etableras i den angivna Azure Managed Grafana-instansen i mappen Managed Prometheus . Några instrumentpaneler är:

• Kubernetes/Beräkningsresurser/Kluster
• Kubernetes/Beräkningsresurser/Namnområde (poddar)
• Kubernetes/Beräkningsresurser/Nod (poddar)
• Kubernetes/Beräkningsresurser/Podd
• Kubernetes/Beräkningsresurser/Namnområde (arbetsbelastningar)
• Kubernetes/Beräkningsresurser/Arbetsbelastning
• Kubernetes/Kubelet
• Nodexportör/USE-metod/Nod
• Nodexportör/noder
• Kubernetes/Beräkningsresurser/Kluster (Windows)
• Kubernetes/Beräkningsresurser/Namnområde (Windows)
• Kubernetes/Beräkningsresurser/Podd (Windows)
• Kubernetes/USE-metod/Kluster (Windows)
• Kubernetes/USE-metod/Nod (Windows)

Dessa inbyggda instrumentpaneler används ofta i communityn med öppen källkod för övervakning av Kubernetes-kluster med Prometheus och Grafana. Använd dessa instrumentpaneler för att se mått, till exempel resursanvändning, poddhälsa och nätverksaktivitet. Du kan också skapa anpassade instrumentpaneler som är skräddarsydda för dina övervakningsbehov. Instrumentpaneler hjälper dig att effektivt övervaka och analysera Prometheus-mått i ditt AKS-kluster, vilket gör att du kan optimera prestanda, felsöka problem och säkerställa en smidig drift av dina Kubernetes-arbetsbelastningar.

Du kan använda instrumentpanelen Kubernetes/Compute Resources/Node (Pods) för att se mått för dina Linux-agentnoder. Du kan visualisera CPU-användning, CPU-kvot, minnesanvändning och minneskvot för varje podd.

Om klustret innehåller Windows-agentnoder kan du använda Instrumentpanelen Kubernetes/USE-metod/Nod (Windows) för att visualisera Prometheus-måtten som samlas in från dessa noder. Den här instrumentpanelen ger en omfattande vy över resursförbrukning och prestanda för Windows-noder i klustret.

Dra nytta av dessa dedikerade instrumentpaneler så att du enkelt kan övervaka och analysera viktiga mått som rör CPU, minne och andra resurser i både Linux- och Windows-agentnoder. Med den här synligheten kan du identifiera potentiella flaskhalsar, optimera resursallokering och säkerställa effektiv drift i aks-klustret.

Steg 2: Verifiera kontrollplanets och arbetsnodanslutningen

Om arbetsnoderna är felfria bör du undersöka anslutningen mellan det hanterade AKS-kontrollplanet och klusterarbetsnoderna. AKS möjliggör kommunikation mellan Kubernetes API-servern och enskilda nod-kubelets via en säker tunnelkommunikationsmetod. Dessa komponenter kan kommunicera även om de finns i olika virtuella nätverk. Tunneln skyddas med MTLS-kryptering (Mutual Transport Layer Security). Den primära tunneln som AKS använder kallas Konnectivity (kallades tidigare apiserver-network-proxy). Se till att alla nätverksregler och FQDN:er följer de nödvändiga Azure-nätverksreglerna.

Om du vill verifiera anslutningen mellan det hanterade AKS-kontrollplanet och klusterarbetsnoderna i ett AKS-kluster kan du använda kommandoradsverktyget kubectl .

Kör följande kommando för att säkerställa att Konnectivity-agentpoddarna fungerar korrekt:

kubectl get deploy konnectivity-agent -n kube-system

Kontrollera att poddarna är i ett redo tillstånd.

Om det finns ett problem med anslutningen mellan kontrollplanet och arbetsnoderna upprättar du anslutningen när du har sett till att de nödvändiga AKS-reglerna för utgående trafik tillåts.

Kör följande kommando för att starta om konnectivity-agent poddarna:

kubectl rollout restart deploy konnectivity-agent -n kube-system

Om det inte går att åtgärda anslutningen genom att starta om poddarna kontrollerar du om det finns några avvikelser i loggarna. Kör följande kommando för att visa loggarna för konnectivity-agent poddarna:

kubectl logs -l app=konnectivity-agent -n kube-system --tail=50

Loggarna bör visa följande utdata:

I1012 12:27:43.521795       1 options.go:102] AgentCert set to "/certs/client.crt".
I1012 12:27:43.521831       1 options.go:103] AgentKey set to "/certs/client.key".
I1012 12:27:43.521834       1 options.go:104] CACert set to "/certs/ca.crt".
I1012 12:27:43.521837       1 options.go:105] ProxyServerHost set to "sethaks-47983508.hcp.switzerlandnorth.azmk8s.io".
I1012 12:27:43.521841       1 options.go:106] ProxyServerPort set to 443.
I1012 12:27:43.521844       1 options.go:107] ALPNProtos set to [konnectivity].
I1012 12:27:43.521851       1 options.go:108] HealthServerHost set to
I1012 12:27:43.521948       1 options.go:109] HealthServerPort set to 8082.
I1012 12:27:43.521956       1 options.go:110] AdminServerPort set to 8094.
I1012 12:27:43.521959       1 options.go:111] EnableProfiling set to false.
I1012 12:27:43.521962       1 options.go:112] EnableContentionProfiling set to false.
I1012 12:27:43.521965       1 options.go:113] AgentID set to b7f3182c-995e-4364-aa0a-d569084244e4.
I1012 12:27:43.521967       1 options.go:114] SyncInterval set to 1s.
I1012 12:27:43.521972       1 options.go:115] ProbeInterval set to 1s.
I1012 12:27:43.521980       1 options.go:116] SyncIntervalCap set to 10s.
I1012 12:27:43.522020       1 options.go:117] Keepalive time set to 30s.
I1012 12:27:43.522042       1 options.go:118] ServiceAccountTokenPath set to "".
I1012 12:27:43.522059       1 options.go:119] AgentIdentifiers set to .
I1012 12:27:43.522083       1 options.go:120] WarnOnChannelLimit set to false.
I1012 12:27:43.522104       1 options.go:121] SyncForever set to false.
I1012 12:27:43.567902       1 client.go:255] "Connect to" server="e9df3653-9bd4-4b09-b1a7-261f6104f5d0"

Kommentar

När ett AKS-kluster har konfigurerats med en integrering av ett virtuellt API-servernätverk och antingen ett Azure-containernätverksgränssnitt (CNI) eller ett Azure CNI med dynamisk podd-IP-tilldelning behöver du inte distribuera Konnectivity-agenter. De integrerade API-serverpoddarna kan upprätta direkt kommunikation med klusterarbetsnoderna via privata nätverk.

Men när du använder integrering av virtuella API-servrar med Azure CNI Overlay eller BYOCNI (Bring Your Own CNI) distribueras Konnectivity för att underlätta kommunikationen mellan API-servrarna och podd-IP-adresserna. Kommunikationen mellan API-servrarna och arbetsnoderna förblir direkt.

Du kan också söka i containerloggarna i loggnings- och övervakningstjänsten för att hämta loggarna. Ett exempel som söker efter aks-link-anslutningsfel finns i Frågeloggar från containerinsikter.

Kör följande fråga för att hämta loggarna:

ContainerLogV2 
| where _ResourceId =~ "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<cluster-ID>" // Use the IDs and names of your resources for these values.
| where ContainerName has "aks-link"
| project LogSource,LogMessage, TimeGenerated, Computer, PodName, ContainerName, ContainerId
| order by TimeGenerated desc
| limit 200

Kör följande fråga för att söka efter containerloggar efter en misslyckad podd i ett specifikt namnområde:

let KubePodInv = KubePodInventory
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where _ResourceId =~ "<cluster-resource-ID>" // Use your resource ID for this value.
    | where Namespace == "<pod-namespace>" // Use your target namespace for this value.
    | where PodStatus == "Failed"
    | extend ContainerId = ContainerID
    | summarize arg_max(TimeGenerated, *)  by  ContainerId, PodStatus, ContainerStatus
    | project ContainerId, PodStatus, ContainerStatus;

    KubePodInv
    | join
    (
        ContainerLogV2
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where PodNamespace == "<pod-namespace>" //update with target namespace
    ) on ContainerId
    | project TimeGenerated, PodName, PodStatus, ContainerName, ContainerId, ContainerStatus, LogMessage, LogSource

Om du inte kan hämta loggarna med hjälp av frågor eller kubectl-verktyget använder du SSH-autentisering (Secure Shell). Det här exemplet hittar podden tunnelfront när du har anslutit till noden via SSH.

kubectl pods -n kube-system -o wide | grep tunnelfront
ssh azureuser@<agent node pod is on, output from step above>
docker ps | grep tunnelfront
docker logs …
nslookup <ssh-server_fqdn>
ssh -vv azureuser@<ssh-server_fqdn> -p 9000
docker exec -it <tunnelfront_container_id> /bin/bash -c "ping bing.com"
kubectl get pods -n kube-system -o wide | grep <agent_node_where_tunnelfront_is_running>
kubectl delete po <kube_proxy_pod> -n kube-system

Steg 3: Verifiera DNS-matchning vid begränsning av utgående trafik

DNS-matchning är en viktig aspekt av ditt AKS-kluster. Om DNS-matchningen inte fungerar korrekt kan den orsaka kontrollplansfel eller pull-fel för containeravbildningar. Följ dessa steg för att säkerställa att DNS-matchningen till Kubernetes API-servern fungerar korrekt:

1. Kör kommandot kubectl exec för att öppna ett kommandogränssnitt i containern som körs i podden.

   kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
   

2. Kontrollera om nslookup- eller dig-verktygen är installerade i containern.

3. Om inget av verktygen är installerat i podden kör du följande kommando för att skapa en verktygspodd i samma namnområde.

   kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
   

4. Du kan hämta API-serveradressen från översiktssidan för ditt AKS-kluster i Azure-portalen, eller så kan du köra följande kommando.

   az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
   

5. Kör följande kommando för att försöka lösa AKS API-servern. Mer information finns i Felsöka DNS-matchningsfel inifrån podden men inte från arbetsnoden.

   nslookup myaks-47983508.hcp.westeurope.azmk8s.io
   

6. Kontrollera den överordnade DNS-servern från podden för att avgöra om DNS-matchningen fungerar korrekt. Kör till exempel kommandot för Azure DNS nslookup .

   nslookup microsoft.com 168.63.129.16
   

7. Om föregående steg inte ger insikter ansluter du till en av arbetsnoderna och försöker matcha DNS från noden. Det här steget hjälper dig att identifiera om problemet är relaterat till AKS eller nätverkskonfigurationen.

8. Om DNS-matchningen lyckas från noden men inte från podden kan problemet vara relaterat till Kubernetes DNS. Anvisningar för hur du felsöker DNS-matchning från podden finns i Felsöka DNS-matchningsfel.

   Om DNS-matchningen misslyckas från noden granskar du nätverkskonfigurationen för att säkerställa att lämpliga routningssökvägar och portar är öppna för att underlätta DNS-matchning.

Steg 4: Sök efter kubelet-fel

Kontrollera villkoret för kubelet-processen som körs på varje arbetsnod och se till att den inte är under någon press. Potentiellt tryck kan vara cpu, minne eller lagring. Om du vill verifiera statusen för enskilda nod-kubelets kan du använda någon av följande metoder.

AKS kubelet-arbetsbok

Följ dessa steg för att säkerställa att agentnodens kubelets fungerar korrekt:

1. Gå till ditt AKS-kluster i Azure-portalen.

2. I avsnittet Övervakning i navigeringsfönstret väljer du Arbetsböcker.

3. Välj Kubelet-arbetsboken.

   

4. Välj Åtgärder och se till att åtgärderna för alla arbetsnoder är slutförda.

   

Övervakning i kluster med Prometheus och Grafana

Om du har distribuerat Prometheus och Grafana i aks-klustret kan du använda Kubernetes/Kubelet-instrumentpanelen för att få insikter om hälsotillståndet och prestandan för enskilda nod-kubelets.

Övervaka hanterad tjänst för Prometheus och Azure Managed Grafana

Du kan använda den fördefinierade Kubernetes/Kubelet-instrumentpanelen för att visualisera och analysera Prometheus-måtten för kubelets för arbetsnoden. För att göra det måste du konfigurera DITT AKS-kluster för att samla in Prometheus-mått i Övervaka hanterad tjänst för Prometheus och ansluta din Monitor-arbetsyta till en Azure Managed Grafana-arbetsyta .

Trycket ökar när en kubelet startar om och orsakar sporadiskt, oförutsägbart beteende. Kontrollera att antalet fel inte ökar kontinuerligt. Ett tillfälligt fel är acceptabelt, men en konstant tillväxt indikerar ett underliggande problem som du måste undersöka och lösa.

Steg 5: Använd verktyget för nodproblemidentifiering (NPD) för att kontrollera nodhälsan

NPD är ett Kubernetes-verktyg som du kan använda för att identifiera och rapportera nodrelaterade problem. Den fungerar som en systemtjänst på varje nod i klustret. Den samlar in mått och systeminformation, till exempel CPU-användning, diskanvändning och nätverksanslutningsstatus. När ett problem identifieras genererar NPD-verktyget en rapport om händelserna och nodvillkoret. I AKS används NPD-verktyget för att övervaka och hantera noder i ett Kubernetes-kluster som finns i Azure-molnet. Mer information finns i NPD i AKS-noder.

Steg 6: Kontrollera diskens I/O-åtgärder per sekund (IOPS) för begränsning

För att säkerställa att IOPS inte begränsas och påverkar tjänster och arbetsbelastningar i aks-klustret kan du använda någon av följande metoder.

I/O-arbetsbok för AKS-noddisk

Om du vill övervaka disk-I/O-relaterade mått för arbetsnoderna i AKS-klustret kan du använda noddiskens I/O-arbetsbok . Följ dessa steg för att komma åt arbetsboken:

1. Gå till ditt AKS-kluster i Azure-portalen.

2. I avsnittet Övervakning i navigeringsfönstret väljer du Arbetsböcker.

3. Välj I/O-arbetsboken för Noddisk.

   

4. Granska I/O-relaterade mått.

   

Övervakning i kluster med Prometheus och Grafana

Om du har distribuerat Prometheus och Grafana i AKS-klustret kan du använda instrumentpanelen USE-metoden/noden för att få insikter om disk-I/O för klusterarbetsnoderna.

Övervaka hanterad tjänst för Prometheus och Azure Managed Grafana

Du kan använda den fördefinierade instrumentpanelen Node Exporter/Nodes för att visualisera och analysera disk-I/O-relaterade mått från arbetsnoderna. För att göra det måste du konfigurera DITT AKS-kluster för att samla in Prometheus-mått i Övervaka hanterad tjänst för Prometheus och ansluta din Monitor-arbetsyta till en Azure Managed Grafana-arbetsyta .

IOPS- och Azure-diskar

Fysiska lagringsenheter har inbyggda begränsningar när det gäller bandbredd och det maximala antalet filåtgärder som de kan hantera. Azure-diskar används för att lagra operativsystemet som körs på AKS-noder. Diskarna omfattas av samma fysiska lagringsbegränsningar som operativsystemet.

Överväg begreppet dataflöde. Du kan multiplicera den genomsnittliga I/O-storleken med IOPS för att fastställa dataflödet i megabyte per sekund (Mbit/s). Större I/O-storlekar översätter till lägre IOPS på grund av diskens fasta dataflöde.

När en arbetsbelastning överskrider de maximala IOPS-tjänstgränser som tilldelats Azure-diskarna kan klustret inte svara och ange ett I/O-väntetillstånd. I Linux-baserade system behandlas många komponenter som filer, till exempel nätverksuttag, CNI, Docker och andra tjänster som är beroende av nätverks-I/O. Om disken inte kan läsas utökas därför felet till alla dessa filer.

Flera händelser och scenarier kan utlösa IOPS-begränsning, inklusive:

• Ett stort antal containrar som körs på noder, eftersom Docker I/O delar operativsystemdisken.

• Anpassade eller tredjepartsverktyg som används för säkerhet, övervakning och loggning, vilket kan generera ytterligare I/O-åtgärder på operativsystemdisken.

• Nodredundanshändelser och periodiska jobb som intensifierar arbetsbelastningen eller skalar antalet poddar. Den ökade belastningen ökar sannolikheten för begränsning av förekomster, vilket kan leda till att alla noder övergår till ett tillstånd som inte är klart förrän I/O-åtgärderna har slutförts.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Paolo Salvatori | Huvudkundtekniker
• Francis Simy Nasaret | Senior teknisk specialist

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Diskgränser för virtuella datorer
• Virtuella datorer och diskprestanda

Relaterade resurser

Övervaka distributioner av arbetsbelastningar