Sporadyczne przekroczenia limitu czasu lub problemy z serwerem podczas uzyskiwania dostępu do aplikacji w usłudze AKS
W tym artykule opisano sposób rozwiązywania sporadycznych problemów z łącznością, które mają wpływ na aplikacje hostowane w klastrze usługi Azure Kubernetes Service (AKS).
Wymagania wstępne
Narzędzie Adres URL klienta (cURL) lub podobne narzędzie wiersza polecenia.
Narzędzie Kubernetes kubectl lub podobne narzędzie do nawiązywania połączenia z klastrem. Aby zainstalować narzędzie kubectl przy użyciu interfejsu wiersza polecenia platformy Azure, uruchom polecenie az aks install-cli.
Symptomy
Po uruchomieniu polecenia cURL od czasu do czasu jest wyświetlany komunikat o błędzie "Przekroczono limit czasu". Dane wyjściowe mogą przypominać następujący 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
Przyczyna
Sporadyczne przekroczenia limitu czasu sugerują problemy z wydajnością składników, w przeciwieństwie do problemów z siecią.
W tym scenariuszu ważne jest sprawdzenie użycia i kondycji składników. Możesz użyć techniki wewnętrznej, aby sprawdzić stan zasobników. Uruchom polecenia kubectl top i kubectl get w następujący sposób:
$ 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
Dane wyjściowe pokazują, że bieżące użycie zasobników i węzłów wydaje się być akceptowalne.
Mimo że zasobnik jest w Running stanie, jedno ponowne uruchomienie następuje po pierwszych 108 sekundach działania zasobnika. To zdarzenie może wskazywać, że niektóre problemy mają wpływ na zasobniki lub kontenery uruchomione w zasobniku.
Jeśli problem będzie się powtarzać, stan zasobnika zmieni się po pewnym czasie:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-deployment-fc94b7f98-m9z2l 1/2 CrashLoopBackOff 42 3h53m
W tym przykładzie Ready pokazano, że stan został zmieniony i istnieje kilka ponownych uruchomień zasobnika. Jeden z kontenerów jest w CrashLoopBackOff stanie .
Taka sytuacja występuje, ponieważ kontener kończy się niepowodzeniem po uruchomieniu, a następnie platforma Kubernetes próbuje ponownie uruchomić kontener, aby wymusić jego działanie. Jeśli jednak problem będzie się powtarzać, aplikacja nadal kończy się niepowodzeniem po uruchomieniu przez jakiś czas. Platforma Kubernetes ostatecznie zmienia stan na CrashLoopBackOff.
Aby sprawdzić dzienniki dla zasobnika, uruchom następujące polecenia dzienników kubectl:
$ 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
Wpisy dziennika zostały wykonane wcześniej, gdy kontener został uruchomiony. Istnienie tych wpisów sugeruje, że aplikacja została uruchomiona, ale została zamknięta z powodu niektórych problemów.
Sprawdź usługę skojarzoną z wdrożeniem i spróbuj curl adres IP klastra usługi z poziomu klastra, aby zidentyfikować problem:
$ 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
Następnym krokiem jest sprawdzenie zdarzeń zasobnika przez uruchomienie polecenia 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
Obserwacje:
Kod zakończenia to 137. Aby uzyskać więcej informacji na temat kodów zakończenia, zobacz dokumentację uruchamiania platformy Docker i kody zakończenia ze specjalnymi znaczeniami.
Przyczyną zakończenia jest
OOMKilled.Limit pamięci określony dla kontenera to 500 Mi.
Możesz powiedzieć na podstawie zdarzeń, że kontener jest zabity, ponieważ przekracza limity pamięci. Po osiągnięciu limitu pamięci kontenera aplikacja staje się sporadycznie niedostępna, a kontener zostanie zabity i uruchomiony ponownie.
Uwaga 16.
Zalecamy skonfigurowanie sond na żywo, gotowości i uruchamiania w definicji zasobnika. W zależności od zachowania aplikacji ta konfiguracja może pomóc odzyskać aplikację z powodu nieoczekiwanych problemów. Należy zachować ostrożność podczas konfigurowania sond liveness.
Rozwiązanie
Możesz usunąć limit pamięci i monitorować aplikację, aby określić ilość pamięci, której faktycznie potrzebuje. Po zapoznaniu się z użyciem pamięci możesz zaktualizować limity pamięci w kontenerze. Jeśli użycie pamięci nadal rośnie, ustal, czy w aplikacji występuje wyciek pamięci.
Aby uzyskać więcej informacji na temat planowania zasobów dla obciążeń w usłudze Azure Kubernetes Service, zobacz Najlepsze rozwiązania dotyczące zarządzania zasobami.
Skontaktuj się z nami, aby uzyskać pomoc
Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.