Onregelmatige time-outs of serverproblemen bij het openen van de toepassing op AKS
In dit artikel wordt beschreven hoe u onregelmatige verbindingsproblemen oplost die van invloed zijn op uw toepassingen die worden gehost op een AKS-cluster (Azure Kubernetes Service).
Voorwaarden
Het hulpprogramma Client-URL (cURL) of een vergelijkbaar opdrachtregelprogramma.
Het Kubernetes kubectl-hulpprogramma of een vergelijkbaar hulpprogramma om verbinding te maken met het cluster. Als u kubectl wilt installeren met behulp van Azure CLI, voert u de opdracht az aks install-cli uit.
Symptomen
Wanneer u een cURL-opdracht uitvoert, ontvangt u af en toe het foutbericht 'Time-out'. De uitvoer lijkt mogelijk op de volgende tekst:
$ # 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
Oorzaak
Onregelmatige time-outs stellen prestatieproblemen met onderdelen voor, in tegenstelling tot netwerkproblemen.
In dit scenario is het belangrijk om het gebruik en de status van de onderdelen te controleren. U kunt de inside-outtechniek gebruiken om de status van de pods te controleren. Voer de opdrachten kubectl top en kubectl get als volgt uit:
$ 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
In de uitvoer ziet u dat het huidige gebruik van de pods en knooppunten acceptabel lijkt te zijn.
Hoewel de pod de Running status heeft, wordt één herstart uitgevoerd na de eerste 108 seconden van de pod die wordt uitgevoerd. Deze gebeurtenis kan erop wijzen dat sommige problemen van invloed zijn op de pods of containers die in de pod worden uitgevoerd.
Als het probleem zich blijft voordoen, verandert de status van de pod na enige tijd:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-deployment-fc94b7f98-m9z2l 1/2 CrashLoopBackOff 42 3h53m
In dit voorbeeld ziet u dat de Ready status is gewijzigd en dat er verschillende herstarts van de pod zijn. Een van de containers heeft CrashLoopBackOff de status.
Deze situatie treedt op omdat de container mislukt na het starten en vervolgens probeert Kubernetes de container opnieuw op te starten om te forceren dat deze begint te werken. Als het probleem zich blijft voordoen, blijft de toepassing echter mislukken nadat deze enige tijd is uitgevoerd. Kubernetes wijzigt uiteindelijk de status in CrashLoopBackOff.
Voer de volgende kubectl-logboekopdrachten uit om de logboeken voor de pod te controleren:
$ 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
Logboekvermeldingen zijn gemaakt toen de container werd uitgevoerd. Het bestaan van deze vermeldingen suggereert dat de toepassing is gestart, maar deze is gesloten vanwege een aantal problemen.
Controleer de service die is gekoppeld aan de implementatie en probeer het IP-adres van de cluster van de service te krullen vanuit het cluster om het probleem te identificeren:
$ 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
De volgende stap is het controleren van de gebeurtenissen van de pod door de opdracht kubectl describe uit te voeren:
$ 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
Observaties:
De afsluitcode is 137. Zie de docker-uitvoeringsreferentie en afsluitcodes met speciale betekenissen voor meer informatie over afsluitcodes.
De reden voor beëindiging is
OOMKilled.De geheugenlimiet die is opgegeven voor de container is 500 Mi.
U kunt uit de gebeurtenissen zien dat de container wordt gedood omdat deze de geheugenlimieten overschrijdt. Wanneer de geheugenlimiet voor de container is bereikt, wordt de toepassing af en toe ontoegankelijk en wordt de container gedood en opnieuw opgestart.
Notitie
We raden u aan liveness, gereedheid en opstarttests in uw poddefinitie te configureren. Afhankelijk van het gedrag van uw toepassing kan deze configuratie helpen de toepassing te herstellen van onverwachte problemen. Wees voorzichtig bij het configureren van liveness-tests.
Oplossing
U kunt de geheugenlimiet verwijderen en de toepassing controleren om te bepalen hoeveel geheugen het daadwerkelijk nodig heeft. Nadat u het geheugengebruik hebt geleerd, kunt u de geheugenlimieten voor de container bijwerken. Als het geheugengebruik blijft toenemen, bepaalt u of er een geheugenlek in de toepassing is.
Zie best practices voor resourcebeheer voor meer informatie over het plannen van resources voor workloads in Azure Kubernetes Service.
Contacteer ons voor hulp
Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.