Tillfälliga tidsgränser eller serverproblem vid åtkomst till programmet i AKS
I den här artikeln beskrivs hur du felsöker tillfälliga anslutningsproblem som påverkar dina program som finns i ett AKS-kluster (Azure Kubernetes Service).
Förutsättningar
Verktyget Klient-URL (cURL) eller ett liknande kommandoradsverktyg.
Kubernetes kubectl-verktyget eller ett liknande verktyg för att ansluta till klustret. Om du vill installera kubectl med hjälp av Azure CLI kör du kommandot az aks install-cli .
Symptom
När du kör ett cURL-kommando får du ibland felmeddelandet "Timeout". Utdata kan likna följande text:
$ # One connection is successful, which results in a HTTP 200 response.
$ curl -Iv http://20.62.x.x
* Trying 20.62.x.x:80...
* Connected to 20.62.x.x (20.62.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
$ # Another connection is unsuccessful, because it gets timed out.
$ curl -Iv http://20.62.x.x
* Trying 20.62.x.x:80...
* connect to 20.62.x.x port 80 failed: Timed out
* Failed to connect to 20.62.x.x port 80 after 21050 ms: Timed out
* Closing connection 0
curl: (28) Failed to connect to 20.62.x.x port 80 after 21050 ms: Timed out
$ # Then the next connection is again successful.
$ curl -Iv http://20.62.x.x
* Trying 20.62.x.x:80...
* Connected to 20.62.x.x (20.62.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
Orsak
Tillfälliga timeouter tyder på problem med komponentprestanda, till skillnad från nätverksproblem.
I det här scenariot är det viktigt att kontrollera komponenternas användning och hälsa. Du kan använda inifrån och ut-tekniken för att kontrollera statusen för poddarna. Kör kommandona kubectl top och kubectl get enligt följande:
$ kubectl top pods # Check the health of the pods and the nodes.
NAME CPU(cores) MEMORY(bytes)
my-deployment-fc94b7f98-m9z2l 1m 32Mi
$ kubectl top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
aks-agentpool-42617579-vmss000000 120m 6% 2277Mi 49%
$ kubectl get pods # Check the state of the pod.
NAME READY STATUS RESTARTS AGE
my-deployment-fc94b7f98-m9z2l 2/2 Running 1 108s
Utdata visar att den aktuella användningen av poddar och noder verkar vara acceptabel.
Även om podden är i Running tillståndet sker en omstart efter de första 108 sekunderna av podden som körs. Den här förekomsten kan tyda på att vissa problem påverkar poddar eller containrar som körs i podden.
Om problemet kvarstår ändras poddens status efter en tid:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-deployment-fc94b7f98-m9z2l 1/2 CrashLoopBackOff 42 3h53m
Det här exemplet visar att Ready tillståndet har ändrats och att det finns flera omstarter av podden. En av containrarna är i CrashLoopBackOff tillstånd.
Den här situationen beror på att containern misslyckas när den har startats, och sedan försöker Kubernetes starta om containern för att tvinga den att börja fungera. Men om problemet kvarstår fortsätter programmet att misslyckas efter att det har körts under en tid. Kubernetes ändrar slutligen statusen till CrashLoopBackOff.
Om du vill kontrollera loggarna för podden kör du följande kubectl logs-kommandon :
$ kubectl logs my-deployment-fc94b7f98-m9z2l
error: a container name must be specified for pod my-deployment-fc94b7f98-m9z2l, choose one of: [webserver my-app]
$ # Since the pod has more than one container, the name of the container has to be specified.
$ kubectl logs my-deployment-fc94b7f98-m9z2l -c webserver
[...] [mpm_event:notice] [pid 1:tid 140342576676160] AH00489: Apache/2.4.52 (Unix) configured -- resuming normal operations
[...] [core:notice] [pid 1:tid 140342576676160] AH00094: Command line: 'httpd -D FOREGROUND'
10.244.0.1 - - ... "GET / HTTP/1.1" 200 45
10.244.0.1 - - ... "GET /favicon.ico HTTP/1.1" 404 196
10.244.0.1 - - ... "-" 408 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "POST /boaform/admin/formLogin HTTP/1.1" 404 196
$ # The webserver container is running fine. Check the logs for other container (my-app).
$ kubectl logs my-deployment-fc94b7f98-m9z2l -c my-app
$ # No logs observed. The container could be starting or be in a transition phase.
$ # So logs for the previous execution of this container can be checked using the --previous flag:
$ kubectl logs my-deployment-fc94b7f98-m9z2l -c my-app --previous
<Some Logs from the container>
..
..
Started increasing memory
Loggposter gjordes föregående gång containern kördes. Förekomsten av dessa poster tyder på att programmet startade, men det stängdes på grund av vissa problem.
Kontrollera tjänsten som är associerad med distributionen och försök att curla klustrets IP-adress inifrån klustret för att identifiera problemet:
$ kubectl get svc # Check the service associated with deployment
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 3h21m
my-deployment-service LoadBalancer 10.0.136.71 20.62.x.x 80:30790/TCP 21m
Nästa steg är att kontrollera händelserna i podden genom att köra kommandot kubectl describe :
$ kubectl describe pod my-deployment-fc94b7f98-m9z2l
Name: my-deployment-fc94b7f98-m9z2l
Namespace: default
...
...
Labels: app=my-pod
...
...
Containers:
webserver:
...
...
my-app:
Container ID: containerd://a46e5062d53039d0d812c57c76b740f8d1ffb222de35203575bf8e4d10d6b51e
Image: my-repo/my-image:latest
Image ID: docker.io/my-repo/my-image@sha256:edcc4bedc7b...
State: Running
Started: <Start Date>
Last State: Terminated
Reason: OOMKilled
Exit Code: 137
Ready: True
Restart Count: 44
Limits:
memory: 500Mi
Requests:
cpu: 250m
memory: 500Mi
...
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulling 49m (x37 over 4h4m) kubelet Pulling image "my-repo/my-image:latest"
Warning BackOff 4m10s (x902 over 4h2m) kubelet Back-off restarting failed container
Observationer:
Slutkoden är 137. Mer information om slutkoder finns i Docker-körningsreferensen och Slutkoder med särskilda betydelser.
Uppsägningsorsaken är
OOMKilled.Den angivna minnesgränsen för containern är 500 Mi.
Du kan se från händelserna att containern avlivas eftersom den överskrider minnesgränserna. När gränsen för containerminne har nåtts blir programmet tillfälligt otillgängligt och containern avlivas och startas om.
Kommentar
Vi rekommenderar att du konfigurerar live-, beredskaps- och startavsökningar i podddefinitionen. Beroende på programmets beteende kan den här konfigurationen hjälpa dig att återställa programmet från oväntade problem. Var försiktig när du konfigurerar liveness-avsökningar.
Lösning
Du kan ta bort minnesgränsen och övervaka programmet för att avgöra hur mycket minne det faktiskt behöver. När du har lärt dig minnesanvändningen kan du uppdatera minnesgränserna för containern. Om minnesanvändningen fortsätter att öka avgör du om det finns en minnesläcka i programmet.
Mer information om hur du planerar resurser för arbetsbelastningar i Azure Kubernetes Service finns i metodtips för resurshantering.
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.