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

Makale
10/15/2024

Bu makalede, Azure Kubernetes Service (AKS) kümesinde barındırılan uygulamalarınızı etkileyen aralıklı bağlantı sorunlarının nasıl giderilebileceği açıklanı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. Çıktı aşağıdaki metne benzeyebilir:

$ # 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 sistem durumunu denetlemek önemlidir. Podların durumunu denetlemek için iç dış 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 şu durumda olsa da Running , podun çalıştırılmasının ilk 108 saniyesinin ardından bir yeniden başlatma gerçekleşir. Bu durum bazı sorunların podda çalışan podları veya kapsayıcıları etkilediğini gösterebilir.

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 durumun değiştirildiği ve podun birkaç yeniden başlatması olduğu gösterilmektedir Ready . Kapsayıcılardan biri durumunda CrashLoopBackOff .

Bu durumun nedeni kapsayıcının başlatıldıktan sonra başarısız olması ve Kubernetes'in kapsayıcıyı yeniden başlatarak çalışmaya zorlamasıdır. Ancak sorun devam ederse uygulama bir süre çalıştıktan sonra 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 girdileri, kapsayıcının çalıştırıldığı önceki zaman yapılmıştır. Bu girdilerin varlığı uygulamanın başlatıldığını, ancak bazı sorunlar nedeniyle kapandığını gösterir.

Dağıtımla ilişkili hizmeti denetleyin ve sorunu belirlemek için kümenin içinden hizmetin küme IP'sini kıvrılmaya çalışın:

$ 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

Sonraki adım kubectl describe komutunu çalıştırarak podun 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 anlamlara sahip çı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.

Not

Pod tanımınızda canlılık, hazır olma ve başlatma yoklamalarını yapılandırmanızı öneririz. Uygulamanızın davranışına bağlı olarak, bu yapılandırma uygulamanın beklenmeyen sorunlardan kurtarılmasında yardımcı olabilir. Canlılık yoklamalarını yapılandırırken dikkatli olun.

Çö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ı öğrendikkten sonra 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'te 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ş