AKS'de uygulamaya erişirken aralıklı zaman aşımları veya sunucu sorunları

Makale
04/12/2024

Bu makalede, bir Azure Kubernetes Service (AKS) kümesinde barındırılan uygulamalarınızı etkileyen aralıklı bağlantı sorunlarını giderme adımları açıklanmaktadır.

Önkoşullar

İstemci URL'si (cURL) aracı veya benzer bir komut satırı aracı.
Kubernetes kubectl aracı veya kümeye bağlanmak için benzer bir araç. Azure CLI kullanarak kubectl yüklemek için az aks install-cli komutunu çalıştırın.

Belirtiler

Bir cURL komutu çalıştırdığınızda, bazen "Zaman aşımına uğradı" hata iletisi alırsınız. Çıkış aşağıdaki metne benzer olabilir:

$ # 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

Neden

Aralıklı zaman aşımları, ağ sorunlarının aksine bileşen performans sorunlarını önerir.

Bu senaryoda, bileşenlerin kullanımını ve durumunu denetlemek önemlidir. Podların durumunu denetlemek için iç dışarı tekniğini kullanabilirsiniz. kubectl top ve kubectl get komutlarını aşağıdaki gibi çalıştırın:

$ 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

Çıktı, podların ve düğümlerin geçerli kullanımının kabul edilebilir gibi göründüğünü gösterir.

Pod durumunda olsa da Running , podun çalıştığı ilk 108 saniyenin ardından bir yeniden başlatma gerçekleşir. Bu durum bazı sorunların podda çalışan podları veya kapsayıcıları etkilediğine işaret edebilir.

Sorun devam ederse podun durumu bir süre sonra değişir:

$ kubectl get pods
NAME                            READY   STATUS             RESTARTS   AGE
my-deployment-fc94b7f98-m9z2l   1/2     CrashLoopBackOff   42         3h53m

Bu örnekte, durumunun Ready değiştirildiği ve podun birkaç yeniden başlatma işlemi olduğu gösterilmektedir. Kapsayıcılardan biri durumunda CrashLoopBackOff .

Bu durum, kapsayıcı başlatıldıktan sonra başarısız olduğundan ve Kubernetes kapsayıcıyı yeniden başlatarak çalışmaya başlamaya zorlamaya çalıştığından oluşur. Ancak sorun devam ederse uygulama bir süre çalıştıktan sonra da başarısız olur. Kubernetes sonunda durumunu olarak CrashLoopBackOffdeğiştirir.

Pod günlüklerini denetlemek için aşağıdaki kubectl logs komutlarını çalıştırın:

$ 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

Günlük girişleri, kapsayıcının çalıştırıldığı önceki zaman yapılmıştı. Bu girdilerin varlığı, uygulamanın başlatıldığını ancak bazı sorunlar nedeniyle kapandığını gösterir.

Sonraki adım kubectl describe komutunu çalıştırarak pod olaylarını denetlemektir:

$ 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

Gözlem:

Çıkış kodu 137'dir. Çıkış kodları hakkında daha fazla bilgi için bkz. Docker çalıştırma başvurusu ve Özel anlamlarla çıkış kodları.
Sonlandırma nedeni şeklindedir OOMKilled.
Kapsayıcı için belirtilen bellek sınırı 500 Mi'dir.

Olaylardan kapsayıcının bellek sınırlarını aştığı için öldürüldüğünü anlayabilirsiniz. Kapsayıcı bellek sınırına ulaşıldığında, uygulama aralıklı olarak erişilemez hale gelir ve kapsayıcı öldürülür ve yeniden başlatılır.

Çözüm

Bellek sınırını kaldırabilir ve gerçekten ne kadar belleğe ihtiyaç duyduğunu belirlemek için uygulamayı izleyebilirsiniz. Bellek kullanımını öğrendikte kapsayıcıdaki bellek sınırlarını güncelleştirebilirsiniz. Bellek kullanımı artmaya devam ederse uygulamada bellek sızıntısı olup olmadığını belirleyin.

Azure Kubernetes Service'da iş yükleri için kaynakları planlama hakkında daha fazla bilgi için bkz. kaynak yönetimi en iyi yöntemleri.

Yardım için bize ulaşın

Sorularınız veya yardıma ihtiyacınız varsa bir destek isteği oluşturun veya Azure topluluk desteği isteyin. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.

Aracılığıyla paylaş