Container Service for Kubernetes:Troubleshooting node exceptions

Düğüm arızalarını tanılama

Bir düğüm başarısız olursa düğümü tanılamak için ACK Özel Durum Tanılama özelliğini kullanın.

1. ACK konsolu üzerinde oturum açın. Sol gezinme bölmesinde Clusters öğesini tıklayın.

2. Clusters sayfasında kümenizin adını tıklayın. Sol gezinme bölmesinde Node Pools > Nodes öğesini tıklayın.

3. Nodes sayfasında hedef düğümü bulun ve Actions sütununda More > Exception Diagnosis seçeneğini belirleyin.

4. Açılan panelde Create Diagnosis seçeneğini tıklayın. Ardından konsolda tanılama sonuçlarını ve düzeltme önerilerini görüntüleyin.

Düğüm ayrıntılarını kontrol etme

1. ACK konsolu üzerinde oturum açın. Sol gezinme bölmesinde Clusters öğesini tıklayın.

2. Clusters sayfasında kümenizin adını tıklayın. Sol gezinme bölmesinde Node Pools > Nodes öğesini tıklayın.

3. Nodes sayfasında hedef düğümün adını tıklayın veya ayrıntılarını görüntülemek için Actions sütunundaki Details seçeneğini tıklayın.

Düğüm durumunu kontrol etme

1. ACK konsolu üzerinde oturum açın. Sol gezinme bölmesinde Clusters öğesini tıklayın.

2. Clusters sayfasında kümenizin adını tıklayın. Sol gezinme bölmesinde Node Pools > Nodes öğesini tıklayın.

3. Nodes sayfasında düğümün durumunu görüntüleyin.

   • Düğüm durumu Ready ise düğüm beklendiği gibi çalışıyor demektir.

   • Düğüm durumu Ready değilse hedef düğümün adını tıklayın veya ayrıntılarını görüntülemek için Actions sütunundaki Details seçeneğini tıklayın.

     Not

     InodesPressure, DockerOffline ve RuntimeOffline gibi koşullara ilişkin bilgileri toplamak için kümenizde node-problem-detector yüklemeniz ve bir K8s Event Center oluşturmanız gerekir. Küme oluşturma sırasında K8s Event Center oluşturma seçeneği varsayılan olarak seçilir. Daha fazla bilgi için bkz. K8s olay merkezini oluşturma ve kullanma.

Düğüm olaylarını kontrol etme

1. ACK konsolu üzerinde oturum açın. Sol gezinme bölmesinde Clusters öğesini tıklayın.

2. Clusters sayfasında kümenizin adını tıklayın. Sol gezinme bölmesinde Node Pools > Nodes öğesini tıklayın.

3. Nodes sayfasında hedef düğümün adını tıklayın veya ayrıntılarını görüntülemek için Actions sütunundaki Details seçeneğini tıklayın.

   Düğüm olayları, ayrıntılar sayfasının altında görüntülenir.

Düğüm tanılama günlüklerini toplama

• Konsoldaki Container Intelligence Service kullanarak tanılama günlüklerini toplayın. Daha fazla bilgi için bkz. Düğüm tanılama.

• Tanılama günlüklerini toplamak için bir komut dosyası kullanın. Daha fazla bilgi için bkz. Bir Kubernetes kümesinin tanılama bilgilerini nasıl toplarım?.

Temel düğüm bileşenlerini kontrol etme

• kubelet

  • Kubelet durumunu kontrol edin

    Düğüme oturum açın ve kubelet durumunu kontrol etmek için aşağıdaki komutu çalıştırın:

    systemctl status kubelet

    Beklenen çıktı:

    [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status kubelet
    ● kubelet.service - kubelet: The Kubernetes Node Agent
       Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
      Drop-In: /etc/systemd/system/kubelet.service.d
               └─10-kubeadm.conf
       Active: active (running) since Thu 2025-06-12 13:18:45 CST; 28min ago
         Docs: http://kubernetes.io/docs/
     Main PID: 6171 (kubelet)
        Tasks: 12 (limit: 98626)
       Memory: 88.2M
       CGroup: /system.slice/kubelet.service
               └─6171 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --v=3 --authorization
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.250117    6171 prober.go:116] "Probe succeeded" probeType="Liveness" pod="kube-system/coredns-5b97654649-jkbtq" podUID="0530c82c-a012-4f
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.250144    6171 prober.go:116] "Probe succeeded" probeType="Readiness" pod="kube-system/coredns-5b97654649-jkbtq" podUID="0530c82c-a012-4
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.716032    6171 prober.go:116] "Probe succeeded" probeType="Liveness" pod="kube-system/csi-plugin-bqdjr" podUID="33fd9325-c75d-458d-adc3-
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.574947    6171 kubelet_pods.go:1151] "Clean up pod workers for terminated pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575713    6171 kubelet_pods.go:1201] "Clean up probes for terminated pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575724    6171 kubelet_pods.go:1205] "Clean up orphaned pod statuses"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575731    6171 kubelet_pods.go:1209] "Clean up orphaned pod user namespace allocations"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575736    6171 kubelet_pods.go:1221] "Clean up orphaned pod directories"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575775    6171 kubelet_pods.go:1232] "Clean up mirror pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575807    6171 kubelet_pods.go:1374] "Clean up orphaned pod cgroups"
    lines 1-22/22 (END)

  • Kubelet günlüklerini kontrol edin

    Düğüme oturum açın ve kubelet günlüklerini görüntülemek için aşağıdaki komutu çalıştırın. Kubelet günlüklerini görüntüleme hakkında daha fazla bilgi için bkz. Düğüm tanılama günlüklerini toplama.

    journalctl -u kubelet

  • Kubelet yapılandırmasını kontrol edin

    Düğüme oturum açın ve kubelet yapılandırmasını görüntülemek için aşağıdaki komutu çalıştırın:

    cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

• Runtime

  • dockerd'i kontrol edin

    • dockerd durumunu kontrol edin

      Düğüme oturum açın ve dockerd durumunu kontrol etmek için aşağıdaki komutu çalıştırın:

      systemctl status docker

      Beklenen çıktı:

      #systemctl status docker
      ● docker.service - Docker Application Container Engine
         Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: disabled)
         Active: active (running) since Wed 2022-03-02 15:11:46 CST; 5 days ago
           Docs: https://docs.docker.com
       Main PID: 4330 (dockerd)
          Tasks: 75
         Memory: 8.3G
         CGroup: /system.slice/docker.service
                 └─4330 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
      Mar 02 15:19:29 xxx                    dockerd[4330]: time="2022-03-02T15:19:29.418689546+08:00" level=info msg="Attempting next endpoint for pull a...eaders
      Mar 02 15:22:20 xxx                    dockerd[4330]: time="2022-03-02T15:22:20.888769038+08:00" level=warning msg="Error getting v2 registry: Get h...eaders
      Mar 02 15:22:20 xxx                    dockerd[4330]: time="2022-03-02T15:22:20.888912991+08:00" level=info msg="Attempting next endpoint for pull a...eaders
      Mar 02 15:23:25 xxx                    dockerd[4330]: time="2022-03-02T15:23:25.487947465+08:00" level=warning msg="Seccomp is not enabled in your k...rofile

    • dockerd günlüklerini kontrol edin

      Düğüme oturum açın ve dockerd günlüklerini görüntülemek için aşağıdaki komutu çalıştırın. Dockerd günlüklerini görüntüleme hakkında daha fazla bilgi için bkz. Düğüm tanılama günlüklerini toplama.

      journalctl -u docker

    • dockerd yapılandırmasını kontrol edin

      Düğüme oturum açın ve dockerd yapılandırmasını görüntülemek için aşağıdaki komutu çalıştırın:

      cat /etc/docker/daemon.json

  • containerd'yi kontrol edin

    • containerd durumunu kontrol edin

      Düğüme oturum açın ve containerd durumunu kontrol etmek için aşağıdaki komutu çalıştırın:

      systemctl status containerd

      Beklenen çıktı:

      [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status containerd
      ● containerd.service - containerd container runtime
         Loaded: loaded (/etc/systemd/system/containerd.service; enabled; vendor preset: disabled)
         Active: active (running) since Thu 2025-06-12 13:18:44 CST; 29min ago
           Docs: https://containerd.io
       Main PID: 5994 (containerd)
          Tasks: 153
         Memory: 3.5G
         CGroup: /system.slice/containerd.service
                 ├─ 5994 /usr/bin/containerd
                 ├─ 6589 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id b4ad8b28c61fa573e04bc641901bd64b15adb1d4a... xxx -address /run/containerd/containerd.sock
                 ├─ 6592 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id eb828cfb114bd404d7781f72b55ed4ee1e9743b7d... xxx -address /run/containerd/containerd.sock
                 ├─ 6666 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 92bf24db851fcaf65ed9c3ddc9210b61169623158... xxx -address /run/containerd/containerd.sock
                 ├─ 6726 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 96d44ff7503b876227e7d287a730cac5b50b5183f1... xxx -address /run/containerd/containerd.sock
                 ├─ 6727 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 3707c088fec2d14f9ec2c78beccf5f3e1f0a18a6b... xxx -address /run/containerd/containerd.sock
                 ├─ 6766 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id b390b71290b772958626a0cc943fb678c7fec4ef5... xxx -address /run/containerd/containerd.sock
                 ├─ 9501 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 40c0f850c4c003144bbc5a17bcb5b7f15ad121862... xxx -address /run/containerd/containerd.sock
                 ├─ 9567 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 3b07c32bf4fe84fde20177efdcffabd2cd93ac02a... xxx -address /run/containerd/containerd.sock
                 ├─ 9633 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id d181fcabeebca990b1298072f91da4fbb251b666c... xxx -address /run/containerd/containerd.sock
                 └─11643 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id f3744bcb95b522bc64a5a88dd4c49a231c082f5d79... xxx -address /run/containerd/containerd.sock
      Jun 12 13:19:53  containerd[5994]: time="2025-06-12T13:19:53.013508035+08:00" level=error msg="ContainerStatus for \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b83e7b280\""
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.708151565+08:00" level=info msg="ImageCreate event &ImageCreate{Name:registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcol..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.710172874+08:00" level=info msg="ImageCreate event &ImageCreate{Name:sha256:e705a85d376f9fdecd0f1b2ebce63d85f8392de70a9636..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.713591809+08:00" level=info msg="PullImage \"registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcollector:v3.0.11.0-915c655..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.713969883+08:00" level=info msg="ImageCreate event &ImageCreate{Name:registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcol..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.717628440+08:00" level=info msg="CreateContainer within sandbox \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.732237135+08:00" level=info msg="CreateContainer within sandbox \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.735512597+08:00" level=info msg="StartContainer for \"e7c6a20368f9c20900848fbcec81d5145d73caa8c4decaae660e0ea89dd64c28\""
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.771464238+08:00" level=info msg="StartContainer for \"e7c6a20368f9c20900848fbcec81d5145d73caa8c4decaae660e0ea89dd64c28\"..."
      Jun 12 13:20:47  containerd[5994]: time="2025-06-12T13:20:47.246563467+08:00" level=error msg="ContainerStatus for \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b83e7b280\""
      lines 1-30/30 (END)

    • containerd günlüklerini kontrol edin

      Düğüme oturum açın ve containerd günlüklerini görüntülemek için aşağıdaki komutu çalıştırın. Containerd günlüklerini görüntüleme hakkında daha fazla bilgi için bkz. Düğüm tanılama günlüklerini toplama.

      journalctl -u containerd

• NTP'yi kontrol etme

  • NTP hizmeti durumunu kontrol edin

    Düğüme oturum açın ve chronyd işleminin durumunu kontrol etmek için aşağıdaki komutu çalıştırın:

    systemctl status chronyd

    Beklenen çıktı:

    [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status chronyd
    ● chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
       Active: active (running) since Thu 2025-06-12 13:18:22 CST; 20min ago
         Docs: man:chronyd(8)
               man:chrony.conf(5)
     Main PID: 1603 (chronyd)
        Tasks: 1 (limit: 98626)
       Memory: 732.0K
       CGroup: /system.slice/chronyd.service
               └─1603 /usr/sbin/chronyd
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: chronyd.service: Succeeded.
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Stopped NTP client/server.
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Starting NTP client/server...
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: chronyd version 4.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: Frequency -35.639 +/- 2.058 ppm read from /var/lib/chrony/drift
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Started NTP client/server.
    Jun 12 13:18:23 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: System clock was stepped by 0.000000 seconds
    Jun 12 13:18:27 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: Selected source 100.100.61.88 (ntp.cloud.aliyuncs.com)
    Jun 12 13:18:27 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: System clock wrong by 1.476188 seconds
    xxx

  • NTP hizmeti günlüklerini kontrol edin

    Düğüme oturum açın ve NTP günlüklerini görüntülemek için aşağıdaki komutu çalıştırın:

    journalctl -u chronyd

Düğüm izleme verilerini kontrol etme

• Cloud Monitor

  ACK, CloudMonitor ile entegre olur. İlgili ECS örneklerinin temel izleme verilerini CloudMonitor konsolunda görüntüleyin. CloudMonitor ile düğümlerin izlenmesi hakkında daha fazla bilgi için bkz. Düğümleri izleme.

• Managed Service for Prometheus

  1. ACK konsolu üzerinde oturum açın. Sol gezinme bölmesinde Clusters öğesini tıklayın.

  2. Clusters sayfasında kümenizin adını tıklayın. Sol gezinme bölmesinde Operations > Prometheus Monitoring öğesini tıklayın.

  3. Prometheus Monitoring sayfasında Node Monitoring sekmesini ve ardından Nodes sekmesini tıklayın.

  4. Nodes sayfasında CPU, bellek ve disk kullanımı gibi izleme ölçümlerini görüntülemek için bir düğüm seçin.

Düğüm güvenlik gruplarını kontrol etme

Düğüm güvenlik gruplarının kontrol edilmesi hakkında daha fazla bilgi için bkz. Güvenlik grubuna genel bakış ve Küme güvenlik gruplarını yapılandırma.

Neden

Tipik nedenler arasında anormal bir Kubelet işlemi, bir konteyner çalışma zamanı özel durumu veya hatalı bir Kubelet yapılandırması bulunur.

Belirtiler

Kubelet durumu inactive olur.

Çözüm

1. Kubelet'i yeniden başlatmak için aşağıdaki komutu çalıştırın. Bu işlem, çalışan konteynerleri etkilemez.

   systemctl restart kubelet

2. Kubelet yeniden başladıktan sonra düğüme oturum açın ve durumunu kontrol etmek için aşağıdaki komutu çalıştırın.

   systemctl status kubelet

3. Kubelet durumu anormal olmaya devam ederse düğüme oturum açın ve günlüklerini görüntülemek için aşağıdaki komutu çalıştırın.

   journalctl -u kubelet

   • Günlükler belirli hata mesajları içeriyorsa sorunu gidermek için bu mesajlardan anahtar sözcükleri kullanın.

   • Kubelet yapılandırması yanlışsa bunu düzeltmek için aşağıdaki komutları çalıştırın.

     vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf   # Modify the Kubelet configuration.
     systemctl daemon-reload;systemctl restart kubelet         # Reload the configuration and restart Kubelet.

Neden

Yaygın nedenler arasında geçersiz bir dockerd yapılandırması, yüksek işlem yükü veya yüksek düğüm yükü bulunur.

Belirtiler

• dockerd durumu inactive olur.

• dockerd durumu active (running) olabilir ancak arka plan programı düzgün çalışmaz ve bu da bir düğüm özel durumuna neden olur. docker ps ve docker exec gibi komutlar başarısız olabilir.

• Düğümün RuntimeOffline koşulu True olur.

• Küme düğümü özel durumları için uyarı yapılandırdıysanız bir dockerd özel durumu uyarıyı tetikler. Uyarı kurallarının nasıl yapılandırılacağı hakkında daha fazla bilgi için bkz. ACK uyarı yönetimi.

Çözüm

1. dockerd'i yeniden başlatmak için aşağıdaki komutu çalıştırın:

   systemctl restart docker

2. Düğüme oturum açın ve dockerd durumunu kontrol etmek için aşağıdaki komutu çalıştırın:

   systemctl status docker

3. Durum anormal olmaya devam ederse dockerd günlüklerini kontrol edin:

   journalctl -u docker

Neden

Bu sorun genellikle geçersiz bir containerd yapılandırması, yüksek işlem yükü veya yüksek düğüm yükünden kaynaklanır.

• containerd durumu inactive olur.

• Düğümün RuntimeOffline koşulu True olur.

• Küme düğümü özel durumları için uyarı yapılandırıldıysa bir containerd özel durumu oluştuğunda bilgilendirilirsiniz. Daha fazla bilgi için bkz. ACK uyarı yönetimi.

Çözüm

1. containerd'yi yeniden başlatmak için aşağıdaki komutu çalıştırın:

   systemctl restart containerd

2. containerd yeniden başladıktan sonra düğüme oturum açın ve durumunu kontrol etmek için aşağıdaki komutu çalıştırın:

   systemctl status containerd

3. Yeniden başlatmadan sonra durum anormal olmaya devam ederse düğüme oturum açın ve containerd günlüklerini görüntülemek için aşağıdaki komutu çalıştırın:

   journalctl -u containerd

Neden

Bu soruna genellikle anormal bir NTP işlemi neden olur.

Belirtiler

• chronyd durumu inactive olur.

• NTPProblem düğüm koşulu True olur.

• Küme düğümü özel durumları için uyarı yapılandırdıysanız bir düğümün saat hizmeti anormal olduğunda bir uyarı alırsınız. Uyarıların nasıl yapılandırılacağı hakkında daha fazla bilgi için bkz. ACK uyarı yönetimi.

Çözüm

1. chronyd'yi yeniden başlatmak için aşağıdaki komutu çalıştırın:

   systemctl restart chronyd

2. chronyd yeniden başladıktan sonra düğüme oturum açın ve durumunun normal olduğunu doğrulamak için aşağıdaki komutu çalıştırın:

   systemctl status chronyd

3. Yeniden başlatmadan sonra durum hala anormal ise düğüme oturum açın ve chronyd günlüklerini görüntülemek için aşağıdaki komutu çalıştırın:

   journalctl -u chronyd

Neden

Pod Yaşam Döngüsü Olay Üreticisi (PLEG), konteyner başlatmaları ve sonlandırmaları gibi pod yaşam döngüsü boyunca olayları kaydeder. PLEG is not healthy özel durumu genellikle düğümdeki konteyner çalışma zamanıyla ilgili sorunlardan veya düğümün systemd sürümündeki bir hatadan kaynaklanır.

Belirtiler

• Düğüm durumu NotReady olur.

• kubelet günlükleri aşağıdaki girişi içerir.

  I0729 11:20:59.245243    9575 kubelet.go:1823] skipping pod synchronization - PLEG is not healthy: pleg was last seen active 3m57.138893648s ago; threshold is 3m0s.

• Küme düğümü özel durumları için uyarı yapılandırdıysanız bir PLEG özel durumu oluştuğunda uyarı alırsınız. Uyarıları yapılandırmak için bkz. ACK uyarı yönetimi.

Çözüm

1. Temel düğüm bileşenleri olan dockerd/containerd ve kubelet'i sırayla yeniden başlatın ve ardından düğümün kurtarıldığını kontrol edin.

2. Temel bileşenlerin yeniden başlatılması sorunu çözmezse düğümü yeniden başlatın. Talimatlar için bkz. bir örneği yeniden başlatma.

   Uyarı

   Düğümün yeniden başlatılması iş yüklerinizi kesintiye uğratabilir. Dikkatli ilerleyin.

3. Düğüm CentOS 7.6 çalıştırıyorsa bkz. "PLEG is not healthy" error in kubelet logs on CentOS 7.6"Reason:KubeletNotReady Message:PLEG is not healthy:" error in kubelet logs on CentOS 7.6.

Neden

Bu sorun genellikle kümedeki düğümlerin kaynaklarının yetersiz olması durumunda ortaya çıkar.

Belirtiler

Toplam kaynak istekleri düğümün kullanılabilir kaynaklarını (atanabilir eksi atanmış) aşarsa bir pod düğüme zamanlanmaz.

kubectl describe node [$nodeName]

Allocatable:
  cpu:                3900m
  ephemeral-storage:  114022843818
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             12601Mi
  pods:               60
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                725m (18%)  6600m (169%)
  memory             977Mi (7%)  16640Mi (132%)
  ephemeral-storage  0 (0%)      0 (0%)
  hugepages-1Gi      0 (0%)      0 (0%)
  hugepages-2Mi      0 (0%)      0 (0%)

Çözüm

Bu sorunu çözmek için aşağıdaki yöntemlerden birini kullanarak düğüm yükünü azaltın:

• Düğüm yükünü azaltmak için gereksiz pod'ları silin. Daha fazla bilgi için bkz. Pod'ları yönetme.

• İş gereksinimlerinize göre pod'larınızın kaynak yapılandırmasını ayarlayın. Daha fazla bilgi için bkz. Bir konteyner için CPU ve bellek isteklerini ve sınırlarını ayarlama.

• Kaynak kullanımının geçmiş verilerine dayalı olarak konteynerler için kaynak yapılandırma önerileri almak amacıyla ACK tarafından sağlanan kaynak profilleme özelliğini kullanabilirsiniz. Bu özellik, konteynerler için kaynak isteklerinin ve sınırlarının yapılandırılmasını basitleştirir. Daha fazla bilgi için bkz. Kaynak profilleme.

• Kümeye yeni düğümler ekleyin. Daha fazla bilgi için bkz. Düğüm havuzları oluşturma ve yönetme.

• Düğüm yapılandırmalarını yükseltin. Daha fazla bilgi için bkz. Bir worker düğümünün yapılandırmalarını yükseltme veya düşürme.

Daha fazla bilgi için bkz. Yetersiz düğüm CPU'su, Yetersiz düğüm belleği - MemoryPressure ve Yetersiz düğüm disk alanı - DiskPressure.

Neden

Bu soruna genellikle bir düğümde aşırı CPU kaynağı tüketen konteynerler neden olur.

Belirtiler

• Yetersiz CPU kaynakları düğümün durumunun anormal hale gelmesine neden olabilir.

• Küme düğümü özel durumları için uyarı yapılandırıldıysa düğüm CPU kullanımı %85'e ulaştığında veya aştığında bir uyarı tetiklenir. Uyarıların nasıl yapılandırılacağı hakkında daha fazla bilgi için bkz. ACK uyarı yönetimi.

Çözüm

• Özel durumun ne zaman meydana geldiğini ve düğümdeki hangi işlemlerin aşırı CPU kaynağı tükettiğini belirlemek için düğümün CPU kullanım eğrisini inceleyin. Daha fazla bilgi için bkz. Bir düğümün izleme verilerini kontrol etme.

• Düğüm üzerindeki yükü azaltın. Daha fazla bilgi için bkz. Zamanlama için yetersiz düğüm kaynakları.

• Gerekirse etkilenen düğümü yeniden başlatın. Daha fazla bilgi için bkz. Bir örneği yeniden başlatma.

  Uyarı

  Düğümün yeniden başlatılması hizmetlerinizi kesintiye uğratabilir. Dikkatli ilerleyin.

Neden

Bu sorun genellikle bir düğümdeki konteynerlerin aşırı bellek tüketmesi ve düğümde yeterli kullanılabilir bellek kalmaması durumunda ortaya çıkar.

Belirtiler

• Bir düğümün kullanılabilir belleği memory.available tarafından belirtilen eşiğin altına düştüğünde düğümün MemoryPressure koşulu True olarak ayarlanır ve düğümdeki konteynerler tahliye edilir. Düğüm tahliyesi hakkında daha fazla bilgi için bkz. Node-pressure Eviction.

• Bir düğümün belleği azaldığında aşağıdaki yaygın belirtileri gözlemleyebilirsiniz:

  • Düğümün MemoryPressure koşulu True olur.

  • Düğümdeki konteynerler tahliye edildiğinde:

    • Tahliye edilen konteynerler için olaylar The node was low on resource: memory mesajını içerir.

    • Düğüm olayları attempting to reclaim memory mesajını içerir.

  • Ayrıca bir Sistem OOM de gerçekleşebilir; bu durum, düğümün olaylarında System OOM mesajıyla belirtilir.

• Bir düğümün bellek kullanımı %85'e ulaştığında veya aştığında bilgilendirilmek için uyarıları yapılandırabilirsiniz. Nasıl yapılacağını öğrenmek için bkz. ACK uyarı yönetimi.

Çözüm

• Sorunun ne zaman meydana geldiğini tespit etmek ve bellek sızıntısı olan çalışan işlemleri incelemek için düğümün izleme verilerindeki bellek kullanım eğrisini analiz edin. Daha fazla bilgi için bkz. Bir düğümün izleme verilerini kontrol etme.

• Düğüm üzerindeki yükü azaltın. Daha fazla bilgi için bkz. Zamanlama için yetersiz düğüm kaynakları.

• Gerekirse etkilenen düğümü yeniden başlatın. Daha fazla bilgi için bkz. Bir örneği yeniden başlatma.

  Uyarı

  Dikkat: Bir düğümün yeniden başlatılması hizmetlerinizi kesintiye uğratabilir.

Neden

Bu sorun genellikle bir düğümdeki konteynerlerin aşırı inode tüketmesi durumunda ortaya çıkar.

Belirtiler

• Bir düğümdeki kullanılabilir inode sayısı inodesFree eşiğinin altına düştüğünde InodesPressure koşulu True olarak ayarlanır ve düğümdeki konteynerler tahliye edilir. Daha fazla bilgi için bkz. node-pressure eviction.

• Bir düğümün inode'ları azaldığında aşağıdaki yaygın hata mesajlarını görebilirsiniz:

  • Düğüm koşulu InodesPressure True olur.

  • Düğümdeki konteynerler tahliye edildiğinde:

    • Tahliye edilen konteynerler için olaylar şu mesajı içerir: The node was low on resource: inodes.

    • Düğümün olayları şu mesajı içerir: attempting to reclaim inodes.

• Kümenizdeki düğüm özel durumları için uyarı yapılandırdıysanız bir düğümün inode'ları azaldığında uyarı alırsınız. Uyarıların nasıl yapılandırılacağı hakkında daha fazla bilgi için bkz. ACK uyarı yönetimi.

Çözüm

• Özel durumun ne zaman meydana geldiğini belirlemek ve aşırı inode tüketen işlemleri tespit etmek için düğümün izleme verilerindeki inode kullanım eğrisini kontrol edin. Daha fazla bilgi için bkz. Düğümlerin izleme verilerini kontrol etme.

• Diğer ilgili sorunları gidermek için bkz. Linux'ta "no space left" sorunlarını çözme.

Neden

Bu sorun, bir düğümdeki konteynerlerin çok sayıda PID tüketmesi ve düğümün mevcut PID'lerini tüketmesi durumunda ortaya çıkar.

Belirtiler

• Bir düğümün mevcut PID'leri pid.available eşiğinin altına düştüğünde NodePIDPressure koşulu True olarak ayarlanır ve düğümdeki pod'lar tahliye edilir. Düğüm tahliyesi hakkında daha fazla bilgi için bkz. Node-pressure Eviction.

• Kümenizdeki düğüm özel durumları için uyarı yapılandırdıysanız bir düğümün PID'leri azaldığında uyarı alırsınız. Uyarıların nasıl yapılandırılacağı hakkında daha fazla bilgi için bkz. ACK uyarı yönetimi.

Çözüm

1. Düğümdeki maksimum PID sayısını ve şu anda kullanılan en yüksek PID'yi kontrol etmek için aşağıdaki komutları çalıştırın.

   sysctl kernel.pid_max  # Check the maximum number of PIDs.
   ps -eLf|awk '{print $2}' | sort -rn| head -n 1   # Check the current highest PID in use.

2. En çok PID tüketen beş işlemi belirlemek için aşağıdaki komutu çalıştırın.

   ps -elT | awk '{print $4}' | sort | uniq -c | sort -k1 -g | tail -5

   Beklenen çıktı:

   # The first column shows the number of PIDs used by a process. The second column shows the process ID.
   73 9743
   75 9316
   76 2812
   77 5726
   93 5691

3. İlgili işlemi ve pod'u bulmak için işlem kimliğini kullanın. İşlemin neden çok fazla PID tükettiğini analiz edin ve uygulama kodunu optimize edin.

4. Düğüm üzerindeki yükü azaltın. Daha fazla bilgi için bkz. Zamanlama için yetersiz düğüm kaynakları.

5. Gerekirse etkilenen düğümü yeniden başlatın. Daha fazla bilgi için bkz. Bir örneği yeniden başlatma.

   Uyarı

   Düğümün yeniden başlatılması hizmetlerinizi kesintiye uğratabilir. Dikkatli olun.

Neden

Genellikle bir düğüm, konteynerlerin aşırı disk alanı tüketmesi veya konteyner görüntülerinin çok büyük olması nedeniyle disk alanından yoksun kalır.

Belirtiler

• Bir düğümdeki konteyner görüntüleri için kullanılabilir disk alanı imagefs.available eşiğinin altına düştüğünde düğümün DiskPressure koşulu True olur.

• Düğümün kök dosya sistemindeki kullanılabilir disk alanı nodefs.available eşiğinin altına düştüğünde o düğümdeki tüm Pod'lar tahliye edilir. Düğüm baskısı tahliyesi hakkında daha fazla bilgi için bkz. node-pressure eviction.

• Bir düğüm disk alanından yoksun kaldığında genellikle aşağıdaki hata mesajlarını görürsünüz:

  • Düğümün DiskPressure koşulu True olur.

  • Görüntü çöp toplama işlemi çalıştıktan sonra disk alanı sağlık eşiğinin (varsayılan: %80) altında kalırsa düğüm olaylarında failed to garbage collect required amount of images anahtar sözcüğünü bulabilirsiniz.

  • Pod'lar düğümden tahliye edildiğinde:

    • Tahliye edilen Pod'ların olaylarında The node was low on resource: [DiskPressure] anahtar sözcüğünü bulabilirsiniz.

    • Düğüm olaylarında attempting to reclaim ephemeral-storage veya attempting to reclaim nodefs gibi anahtar sözcükleri bulabilirsiniz.

• Düğüm özel durumları için uyarı yapılandırdıysanız bir düğümün disk kullanımı %85 veya daha yüksek olduğunda uyarı alırsınız. Uyarıların nasıl yapılandırılacağı hakkında daha fazla bilgi için bkz. ACK uyarı yönetimi.

Çözüm

• Disk kullanım eğrisini görüntülemek için düğümün izleme verilerini kontrol edin. Bu, kullanımın ne zaman arttığını ve herhangi bir işlemin aşırı disk alanı tüketip tüketmediğini belirlemenize yardımcı olur. Daha fazla bilgi için bkz. Düğümlerin izleme verilerini kontrol etme.

• Alan açmak için diskten gerekli olmayan dosyaları silin. Talimatlar için bkz. Linux'ta "no space left" sorunlarını çözme.

• İş yükü gereksinimlerinize göre Pod spesifikasyonlarınızda ephemeral-storage için kaynak isteklerini ve sınırlarını ayarlayın. Daha fazla bilgi için bkz. Bir konteyner için CPU ve bellek kaynak sınırlarını ayarlama.

• hostPath birimleri yerine Alibaba Cloud depolama hizmetlerini kullanın. Daha fazla bilgi için bkz. Depolama.

• Düğümün disk boyutunu artırın.

• Düğüm yükünü azaltın. Daha fazla bilgi için bkz. Zamanlama için yetersiz düğüm kaynakları.

Neden

Bu sorun, bir düğümdeki aşırı sayıda konteynerin mevcut IP adreslerini tüketmesi durumunda ortaya çıkar.

Belirtiler

• Pod'lar başlatılamaz ve ContainerCreating durumunda takılı kalır. Pod günlükleri InvalidVSwitchId.IpNotEnough anahtar sözcüğünü içeren bir hata mesajı gösterir. Pod günlüklerini görüntüleme hakkında daha fazla bilgi için bkz. Pod özel durumlarını giderme.

  time="2020-03-17T07:03:40Z" level=warning msg="Assign private ip address failed: Aliyun API Error: RequestId: 2095E971-E473-4BA0-853F-0C41CF52651D Status Code: 403 Code: InvalidVSwitchId.IpNotEnough Message: The specified VSwitch \"vsw-AAA\" has not enough IpAddress., retrying"

• Kümeniz için uyarı yapılandırdıysanız bir düğümün IP adresleri tükendiğinde uyarı alırsınız. Uyarıların nasıl yapılandırılacağı hakkında daha fazla bilgi için bkz. ACK uyarı yönetimi.

Çözüm

Düğümdeki konteyner sayısını azaltın. Daha fazla bilgi için bkz. Zamanlama için yetersiz düğüm kaynakları. Diğer ilgili çözümler için bkz. Insufficient VSwitch IP addresses in a Terway network environmentWhat to do if a VSwitch provides insufficient IP addresses in a Terway cluster ve Terway modunda VSwitch CIDR bloklarını genişlettim ancak yine de Pod IP'leri atanamıyor. Ne yapmalıyım?.

Neden

Bu sorun genellikle anormal bir düğüm durumu, yanlış yapılandırılmış güvenlik grupları veya yüksek ağ yükünden kaynaklanır.

Belirtiler

• Düğüme oturum açamazsınız.

• Düğüm durumu Unknown olur.

• Küme düğümü özel durumları için uyarı yapılandırdıysanız düğümün giden İnternet bant genişliği kullanımı %85 veya daha yüksek olduğunda uyarı alırsınız. Daha fazla bilgi için bkz. ACK uyarı yönetimi.

Çözüm

• Düğüme oturum açamıyorsanız şu adımları izleyin:

  • Düğüm örneğinin Running durumunda olup olmadığını kontrol edin.

  • Düğümün güvenlik grubu yapılandırmasını kontrol edin. Daha fazla bilgi için bkz. Düğümlerin güvenlik gruplarını kontrol etme.

• Düğümün ağ yükü yüksekse şu adımları izleyin:

  • Aşırı ağ bant genişliği tüketen pod'ları belirlemek için izleme verilerindeki düğümün ağ kullanım eğrisini kontrol edin. Daha fazla bilgi için bkz. Düğümlerin izleme verilerini kontrol etme.

  • Pod trafiğini kontrol etmek için ağ ilkelerini kullanın. Daha fazla bilgi için bkz. ACK kümelerinde ağ ilkeleri.

Neden

Bu sorun genellikle anormal bir düğüm yükünden kaynaklanır.

Belirtiler

• Düğüm yeniden başlatılırken durumu NotReady olur.

• Küme düğümü özel durumları için uyarı yapılandırdıysanız bir düğüm beklenmedik şekilde yeniden başladığında uyarı alırsınız. Daha fazla bilgi için bkz. ACK uyarı yönetimi.

Çözüm

1. Düğümün yeniden başlatma zamanını kontrol etmek için aşağıdaki komutu çalıştırın.

   last reboot

   Beklenen çıktı:

   [root@iZoj203tgmxxx /root]
   #last reboot
   reboot   system boot  xxx  Tue Mar 22 06:26 - 11:49 (1+05:22)
   reboot   system boot  xxx  Fri Oct 15 05:27 - 11:49 (159+06:22)
   wtmp begins Fri Oct 15 05:27:03 2021

2. Yeniden başlatma zamanına göre kaynak anomalilerini araştırmak için düğümün izleme verilerini kontrol edin. Daha fazla bilgi için bkz. Düğümlerin izleme verilerini kontrol etme.

3. Yeniden başlatma zamanına karşılık gelen hata günlüklerini aramak için düğümün çekirdek günlüklerini kontrol edin. Daha fazla bilgi için bkz. Düğümlerin tanılama günlüklerini toplama.

Neden

Varsayılan olarak, bir kümedeki bazı mevcut düğümler Docker işlemlerini izleyen auditd kurallarıyla yapılandırılır. Bu düğümler Docker konteyner çalışma zamanını kullandığında kurallar sistemin Docker ile ilgili faaliyetler için denetim günlüklerini kaydetmesine neden olur. Sık konteyner yeniden başlatmaları, uygulamaların kısa sürede büyük miktarda dosya yazması veya çekirdek hataları gibi belirli koşullar altında sistem aşırı sayıda denetim günlüğü üretebilir. Bu durum, zaman zaman auditd işleminde yüksek disk G/Ç'sine veya sistem günlüğünde audit: backlog limit exceeded hatasına neden olabilir.

Belirtiler

Bu sorun yalnızca Docker konteyner çalışma zamanını kullanan düğümleri etkiler. Etkilenen bir düğümde aşağıdaki belirtiler görülebilir:

• iotop -o -d 1 komutunu çalıştırdığınızda çıktıda auditd işlemi için DISK WRITE değeri tutarlı olarak 1 MB/s veya daha yüksek kalır.

• dmesg -d komutunu çalıştırdığınızda çıktıda audit_printk_skb anahtar sözcüğünü içeren günlükler bulunur; örneğin audit_printk_skb: 100 callbacks suppressed.

• dmesg -d komutunu çalıştırdığınızda çıktıda audit: backlog limit exceeded anahtar sözcüğü bulunur.

Çözüm

Auditd yapılandırmasının nedene bağlı olduğunu doğrulamak için şu adımları izleyin:

1. Bir küme düğümüne oturum açın.

2. Denetim kurallarını kontrol etmek için aşağıdaki komutu çalıştırın.

   sudo auditctl -l | grep -- ' -k docker'

   Çıktı aşağıdaki satırı içeriyorsa auditd yapılandırması nedene bağlıdır.

   -w /var/lib/docker -k docker

Kontrol, bu sorunun küme düğümlerinizi etkilediğini doğrularsa aşağıdaki çözümlerden birini seçin.

• Kümeyi yükseltin

  Bu sorunu çözmek için kümenizi yükseltin. Daha fazla bilgi için bkz. Bir kümeyi manuel olarak yükseltme.

• containerd konteyner çalışma zamanını kullanın

  Yükseltemediğiniz kümeler için düğüm konteyner çalışma zamanını Docker'dan containerd'ye değiştirerek bu sorunu geçici olarak çözebilirsiniz. Docker konteyner çalışma zamanını kullanan her düğüm havuzu için aşağıdaki adımları gerçekleştirin:

  1. Mevcut düğüm havuzunu klonlayarak containerd kullanan yeni bir düğüm havuzu oluşturun. Yeni düğüm havuzunun yapılandırması, konteyner çalışma zamanı dışında orijinal havuzla aynı olmalıdır.

  2. Yoğun olmayan saatlerde orijinal düğüm havuzundaki düğümleri tek tek boşaltın.

• Düğümlerdeki auditd yapılandırmasını güncelleyin

  Kümeyi yükseltemiyor veya containerd'ye geçemiyorsanız etkilenen her düğümde auditd yapılandırmasını manuel olarak güncelleyerek sorunu geçici olarak çözün.

  1. Etkilenen düğüme oturum açın.

  2. Docker ile ilgili denetim kurallarını silmek için aşağıdaki komutları çalıştırın.

     sudo test -f /etc/audit/rules.d/audit.rules && sudo sed -i.bak '/ -k docker/d' /etc/audit/rules.d/audit.rules
     sudo test -f /etc/audit/audit.rules && sudo sed -i.bak '/ -k docker/d' /etc/audit/audit.rules

  3. Yeni denetim kurallarını uygulamak için aşağıdaki komutu çalıştırın.

     if service auditd status |grep running || systemctl status auditd |grep running; then
         sudo service auditd restart || sudo systemctl restart auditd
         sudo service auditd status || sudo systemctl status auditd
     fi