Container Service for Kubernetes:Troubleshoot pod issues

Hata mesajı

Açıklama

Çözüm

no nodes available to schedule pods.

Kümede pod zamanlaması için kullanılabilir düğüm yok.

1. Kümedeki düğümlerin herhangi birinin NotReady durumunda olup olmadığını kontrol edin. Bir düğüm NotReady durumundaysa, düğümü inceleyin ve onarın.

2. Pod'un bir nodeSelector, nodeAffinity veya taint tolerasyonu tanımlayıp tanımlamadığını kontrol edin. Böyle bir zamanlama kısıtlaması tanımlanmamışsa, düğüm havuzuna daha fazla düğüm eklemeyi düşünün.

• 0/x nodes are available: x Insufficient cpu.

• 0/x nodes are available: x Insufficient memory.

Kümede, pod'un CPU veya bellek kaynak isteklerini karşılayabilecek kullanılabilir düğüm yok.

Gerçek kullanım düşük olsa bile, toplam tahsis edilen requests değeri kapasiteye ulaştığında bir düğüm zamanlanamaz hale gelir.

Hedef kümenin ayrıntılar sayfasında Nodes > Nodes yolunu izleyin ve hedef düğüm için CPU veya bellek requests tahsis oranını kontrol edin. Belirli kaynak tahsis değerlerini görüntülemek için tahsis oranının üzerine gelin.

Ayrıntılı düğüm kaynak kullanımını görüntülemek için bkz. kubectl kullanarak düğüm kaynak kullanımını görüntüleme.

• Kaynak yapılandırmasını optimize edin:

  • Bir düğümün kaynak kullanımı sürekli olarak requests değerinden düşükse, kaynaklar boşa harcanıyor demektir. İş yükünün requests yapılandırmasını düşürün. Bkz. Bir konteyner için CPU ve bellek kaynak sınırlarını ayarlama.

    Önerilen requests yapılandırmasını elde etmek için kaynak profil oluşturma özelliğini etkinleştirebilirsiniz.

  • Yoğun olmayan saatlerde çoğaltmaları azaltmak için Yatay Pod Otomatik Ölçeklendirici (HPA) özelliğini etkinleştirin.

• Gereksiz iş yüklerini temizleyin: Gerekli olmayan pod'ları devre dışı bırakın veya ölçeğini küçültün.

• Düğüm havuzunu yatay olarak ölçeklendirin: Hedef düğümlerdeki kaynak kullanımı sürekli olarak yüksekse, düğümler doymuş durumdadır. Düğüm havuzunu yatay olarak ölçeklendirebilirsiniz.

x node(s) didn't match pod's node affinity/selector.

Mevcut düğümler, pod'un düğüm affinity ilkesiyle (nodeAffinity/nodeSelector) eşleşmiyor. Bkz. Assigning Pods to Nodes.

1. Bir düğümdeki tüm etiketleri görüntüleyin.

   Konsol

   1. Hedef kümenin ayrıntılar sayfasında Nodes > Nodes yolunu izleyin.

   2. Nodes sayfasında hedef düğümü bulun ve Actions sütununda More > Manage Labels and Taints seçeneğine tıklayarak etiketlerini görüntüleyin.

   Kubectl

   <YOUR_NODE_NAME> ifadesini gerçek düğüm adınızla değiştirin.

   kubectl get node <YOUR_NODE_NAME> --show-labels

2. İş yükü (deployment) için düğüm affinity kuralını kontrol edin ve ayarlayın.

   Konsol

   Yeni bir iş yükü oluştururken:

   1. Create Deployment oluşturma işlemi için Advanced sayfasında Scheduling bölümündeki Node Affinity öğesini bulun ve Add seçeneğine tıklayın.

   2. İş ihtiyaçlarınıza göre Required (katı affinity) veya Optional (yumuşak affinity) seçeneklerinden birini yapılandırın. Birden fazla Selector mantıksal VE ilişkisine sahipken, birden fazla Rule mantıksal VEYA ilişkisine sahiptir.

   Mevcut iş yükleri için:

   1. Nodes > Nodes sayfasında, hedef Deployment'ın Actions sütununda > Node Affinity seçeneğine tıklayın.

   2. Yapılandırma yöntemi yukarıda açıklandığı gibidir.

   YAML örneği

   NodeAffinity

   Affinity ilkeleri arasında karşılanması zorunlu olan katı affinity (requiredDuringSchedulingIgnoredDuringExecution) ve tercih ifade eden yumuşak affinity (preferredDuringSchedulingIgnoredDuringExecution) bulunur. Aşağıdaki örnekte katı affinity kullanılmaktadır.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: app-demo-node-affinity-deploy
     labels:
       app: demo-node-affinity
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: demo-node-affinity
     template:
       metadata:
         labels:
           app: demo-node-affinity
       spec:
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         affinity:
           nodeAffinity:
             # Hard affinity: The rule must be met.
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: disktype
                   operator: In
                   values:
                   - ssd
                   - nvme  # Logic: The node's 'disktype' label must be either 'ssd' or 'nvme'.

   NodeSelector

   Bu, basit bir tam eşleşme sağlar. Pod, yalnızca düğümün etiketleri koşulları karşılıyorsa zamanlanır.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: app-demo-node-selector-deploy
     labels:
       app: demo-node-selector
   spec:
     replicas: 2  
     selector:
       matchLabels:
         app: demo-node-selector  
     template:
       metadata:
         labels:
           app: demo-node-selector
       spec:
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         # The pod is scheduled only if the node has the label disktype=ssd.
         nodeSelector:
           disktype: ssd

• x node(s) didn't match pod affinity rules.

• x node(s) didn't match pod anti-affinity rules.

• Affinity kuralı uyumsuzluğu. Pod'da bir pod affinity kuralı (örneğin, belirli bir etiket gerektiren) vardır ancak eşleşen etikete sahip bir pod barındıran düğüm olmadığından zamanlama engellenir.

• Anti-affinity çakışması. Pod'da bir pod anti-affinity kuralı (örneğin, başka bir uygulama ile birlikte bulunamama) vardır ancak mevcut tüm düğümler zaten çakışan bir pod barındırdığından zamanlama engellenir.

1. Bir düğümdeki pod etiketlerini görüntüleyin.

   Konsol

   1. Hedef kümenin ayrıntılar sayfasında Nodes > Nodes yolunu izleyin.

   2. Nodes sayfasında, ayrıntılar sayfasını görüntülemek için hedef düğümün adına tıklayın. Farklı pod'ların etiket değerlerini Label sütununda görüntülemek için aşağı kaydırın ve Pods bölümüne gidin.

   Kubectl

   • Belirli bir düğümdeki pod'ları ve etiketlerini görüntüleme: <YOUR_NODE_NAME> ifadesini ad alanı adınızla ve <YOUR_NODE_NAME> ifadesini gerçek düğüm adınızla değiştirin.

     kubectl get pods -n <YOUR_NAMESPACE> --field-selector spec.nodeName=<YOUR_NODE_NAME> -o custom-columns=NAME:.metadata.name,LABELS:.metadata.labels

   • Etikete göre pod sorgulama: <LABEL> ifadesini gerçek etiket anahtar-değer çiftiyle (örneğin, app=nginx) değiştirin.

     kubectl get pods -A -l <LABEL> -o wide

2. İş yükü (deployment) için pod affinity kuralını kontrol edin ve ayarlayın.

   Konsol

   1. Yeni bir iş yükü oluştururken, Create Deployment'ın Advanced sayfasında Pod Affinity bölümündeki Pod Affinity/Pod Anti-affinity öğesini bulun ve Add seçeneğine tıklayın.

   2. İş ihtiyaçlarınıza göre Required (katı affinity) veya Optional (yumuşak affinity) seçeneklerinden birini yapılandırın. Birden fazla Selector mantıksal VE ilişkisine sahipken, birden fazla Add Rule mantıksal VEYA ilişkisine sahiptir.

   YAML örneği

   Affinity ilkeleri katı affinity (requiredDuringSchedulingIgnoredDuringExecution) ve yumuşak affinity (preferredDuringSchedulingIgnoredDuringExecution) olarak sınıflandırılır. Katı affinity kuralları karşılanmalıdır, yumuşak affinity kuralları ise tercihen uygulanır. Aşağıdaki örnek, gerekli bir pod affinity yapılandırmasını göstermektedir.

   Pod anti-affinity yapılandırmak için podAffinity ifadesini podAntiAffinity ile değiştirmeniz yeterlidir.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: app-demo-podaffinity-deploy
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: demo-podaffinity
     template:
       metadata:
         labels:
           app: demo-podaffinity
       spec:
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         affinity:
           podAffinity:
             # Hard affinity: Pod must be co-located with a pod that has the 'app: nginx' label.
             requiredDuringSchedulingIgnoredDuringExecution:
             - labelSelector:
                 matchExpressions:
                 - key: app
                   operator: In
                   values:
                   - nginx
               # Topology domain scope: host-level isolation.
               topologyKey: kubernetes.io/hostname

0/x nodes are available: x node(s) had volume node affinity conflict.

Birim düğüm affinity çakışması nedeniyle zamanlama başarısız olur. Bu genellikle bir cloud diskin farklı alanlar arasında bağlanamamasından kaynaklanır.

• Statik olarak sağlanan bir PV için, pod'un PV ile aynı alandaki bir düğüme zamanlanmasını sağlamak amacıyla pod'un düğüm affinity ayarını yapılandırın.

• Dinamik olarak sağlanan bir PV için, StorageClass'ın volumeBindingMode değerini WaitForFirstConsumer olarak ayarlayın. Bu, PV'nin yalnızca pod bir düğüme zamanlandıktan sonra oluşturulmasını sağlayarak cloud diskin pod'un düğümüyle aynı alanda oluşturulmasını garanti eder.

InvalidInstanceType.NotSupportDiskCategory

ECS örneği, belirtilen cloud disk türünü desteklemiyor.

ECS örneğiniz tarafından desteklenen cloud disk türlerini doğrulamak için bkz. Örnek aileleri. Bağlama sırasında, cloud disk türünü ECS örneği tarafından desteklenen bir türle güncelleyin.

0/x nodes are available: x node(s) had taints that the pod didn't tolerate.

Pod, düğümün taint'lerinden biri için tolerans içermediğinden bir düğüme zamanlanamıyor.

• Taint manuel olarak eklendiyse, taint'i kaldırın veya pod için bir tolerans yapılandırın. Bkz. Taints and Tolerations ve Düğüm etiketlerini ve taint'lerini yönetme.

• Taint sistem tarafından eklendiyse, aşağıdaki temel sorunu çözün ve yeniden zamanlamayı bekleyin.

  Sistem tarafından eklenen taint'leri görüntüleme

  • node.kubernetes.io/not-ready: Düğüm NotReady durumundadır.

  • node.kubernetes.io/unreachable: Düğüme düğüm denetleyicisinden ulaşılamıyor. Bu, düğümün Ready durumunun Unknown olmasıyla eşdeğerdir.

  • node.kubernetes.io/memory-pressure: Düğüm bellek baskısı altındadır.

  • node.kubernetes.io/disk-pressure: Düğüm disk baskısı altındadır.

  • node.kubernetes.io/pid-pressure: Düğüm PID baskısı altındadır.

  • node.kubernetes.io/network-unavailable: Düğümün ağı kullanılamıyor.

  • node.kubernetes.io/unschedulable: Düğüm, zamanlanamaz olarak işaretlenmiştir.

0/x nodes are available: x Insufficient ephemeral-storage.

Düğümde yeterli geçici depolama alanı yok.

1. Pod'un geçici depolama isteğini kontrol edin; bu değer, Pod YAML dosyasındaki spec.containers.resources.requests.ephemeral-storage değeridir. Değer çok yüksekse ve düğümün gerçek kullanılabilir kapasitesini aşarsa, Pod zamanlanamaz.

2. kubectl describe node | grep -A10 Capacity komutuyla her düğümdeki toplam geçici depolama kapasitesini kontrol edin. Yetersizse, düğümün diskini genişletin veya daha fazla düğüm ekleyin.

0/x nodes are available: pod has unbound immediate persistent volume claims.

Pod, kalıcı birim talebini (PVC) bağlayamadı.

Pod tarafından belirtilen PVC veya PV'nin oluşturulup oluşturulmadığını kontrol edin. Daha fazla tanılama için PVC ve PV olaylarını görüntülemek üzere kubectl describe pvc <pvc-name> veya kubectl describe pv <pv-name> komutunu çalıştırın. Bkz. Depolama SSS - CSI.

Hata mesajı

Açıklama

Önerilen çözüm

Failed to pull image "xxx": rpc error: code = Unknown desc = Error response from daemon: Get xxx: denied:

Pod oluşturulurken bir imagePullSecret belirtilmediği için görüntü deposuna erişim reddedildi.

İş yükünün YAML dosyasındaki spec.imagePullSecrets alanında belirtilen Secret'ın var olduğunu doğrulayın.

ACR kullanırken, parola olmadan görüntüleri çekmek için bir kimlik bilgisi yardımcısı kullanın. Bkz. Aynı hesaptan görüntüleri çekme.

Failed to pull image "xxxx:xxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxx/xxxxx/: dial tcp: lookup xxxxxxx.xxxxx: no such host

HTTPS üzerinden görüntü çekerken görüntü deposu adresi çözümlenemedi.

1. Pod'un YAML dosyasındaki spec.containers.image alanında bulunan görüntü deposu adresinin doğru olduğunu doğrulayın. Yanlışsa, adresi güncelleyin.

2. Adres doğruysa, pod'un çalıştığı düğümden görüntü deposuna ağ bağlantısını doğrulayın. Düğüme bağlanın (daha fazla bilgi için bkz. ECS uzaktan bağlantı yöntemi seçme) ve adresin erişilebilir olup olmadığını kontrol etmek için curl -kv https://xxxxxx/xxxxx/ komutunu çalıştırın. Hata oluşursa, yanlış ağ yapılandırması, güvenlik duvarı kuralları veya DNS çözümleme sorunları gibi olası ağ sorunlarını araştırın.

Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "xxxxxxxxx": Error response from daemon: mkdir xxxxx: no space left on device

Düğümde yeterli disk alanı yok.

Düğüme bağlanın (bkz. ECS uzaktan bağlantı yöntemi seçme) ve disk alanını kontrol etmek için df -h komutunu çalıştırın. Disk doluysa, boyutunu artırın. Bkz. Adım 1: Cloud disk boyutunu artırma.

Failed to pull image "xxx": rpc error: code = Unknown desc = error pulling image configuration: xxx x509: certificate signed by unknown authority

Üçüncü taraf görüntü deposu, bilinmeyen veya güvenli olmayan bir Sertifika Yetkilisi (CA) tarafından imzalanmış bir sertifika kullanıyor.

1. Üçüncü taraf depo, güvenilir bir CA tarafından verilen bir sertifika kullanmalıdır.

2. Özel görüntü deposu kullanıyorsanız, bkz. Özel görüntü deposundan uygulama oluşturma.

3. Sertifikayı değiştiremiyorsanız, düğümü güvensiz sertifika kullanan bir depodan görüntü çekmeye ve itmeye izin verecek şekilde yapılandırabilirsiniz. Bu yöntemin yalnızca test ortamlarında kullanılması önerilir çünkü düğümdeki diğer pod'ları etkileyebilir.

Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled

İşlem iptal edildi; bu durum muhtemelen görüntü dosyasının çok büyük olmasından kaynaklanır. Kubernetes'in görüntüleri çekmek için varsayılan bir zaman aşımı süresi vardır. Çekme işlemi belirli bir süre boyunca ilerleme kaydetmezse, Kubernetes işlemin başarısız olduğunu veya yanıt vermediğini varsayar ve görevi iptal eder.

1. Pod'un YAML dosyasında imagePullPolicy değerinin IfNotPresent olarak ayarlandığını doğrulayın.

2. Pod'un çalıştığı düğüme bağlanın (daha fazla bilgi için bkz. ECS uzaktan bağlantı yöntemi seçme) ve görüntünün çekilip çekilemeyeceğini kontrol etmek için docker pull veya crictl pull komutunu çalıştırın.

Failed to pull image "xxxxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxxx: xxxxx/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Ağ sorunları nedeniyle görüntü deposuna bağlanılamıyor.

1. Pod'un çalıştığı düğüme bağlanın (daha fazla bilgi için bkz. ECS uzaktan bağlantı yöntemi seçme) ve adresin erişilebilir olup olmadığını kontrol etmek için curl https://xxxxxx/xxxxx/ komutunu çalıştırın. Hata oluşursa, yanlış ağ yapılandırması, güvenlik duvarı kuralları veya DNS çözümleme sorunları gibi olası ağ sorunlarını araştırın.

2. SNAT girişleri ve bağlı Elastic IP Adresleri (EIP'ler) için yapılandırmalar dahil olmak üzere düğümün genel ağ ilkesini doğrulayın.

Failed to pull image "xxxx:xxx": failed to pull and unpack image "xxxx:xxx": failed to resolve reference "xxxx:xxx": failed to do request: Head "xxxx:xxx": dial tcp xxx.xxx.xx.x:xxx: i/o timeout

Denizaşırı bir depodan görüntü çekerken ağ sorunları nedeniyle bağlantı zaman aşımına uğradı.

Docker Hub gibi denizaşırı depolardan görüntü çekmek, taşıyıcı ağlarının kararsızlığı nedeniyle ACK kümelerinde başarısız olabilir. Bu sorunu çözmek için aşağıdaki çözümleri düşünün:

• Container Registry kullanarak denizaşırı kaynak görüntülere abone olun. Talimatlar için bkz. Yapıt aboneliği kullanarak görüntüleri senkronize etme.

• Doğrudan global hızlandırma ağını kullanarak görüntüleri çekmek için bir Global Accelerator (GA) örneği oluşturun. Ayrıntılar için bkz. GA ile bölgeler arası ACK görüntü çekmelerini hızlandırma.

Too Many Requests.

Docker Hub, görüntü çekme isteklerine oran sınırlamaları uygular.

Görüntüyü Container Registry (ACR) adresine yükleyin ve bir ACR görüntü deposundan çekin.

Pulling image durumu sürekli olarak görüntüleniyor

Kubelet'in görüntü çekme oranı sınırlama mekanizması tetiklenmiş olabilir.

Düğüm havuzu kubelet yapılandırmalarını özelleştirme özelliğini kullanarak registryPullQPS (görüntü deposu için maksimum QPS) ve registryBurst (maksimum ani görüntü çekme sayısı) değerlerini ayarlayın.

Hata mesajı

Açıklama

Çözüm

Init:N/M durumunda takılı kalıyor

Pod'da M init konteyneri bulunur; N tanesi tamamlandı, ancak kalan M-N tanesi başlatılamadı.

1. kubectl describe pod -n <ns> <pod name> komutuyla pod'un olaylarını ve init konteyneri sorunlarını kontrol edin.

2. kubectl logs -n <ns> <pod name> -c <container name> komutuyla başlatılmayan init konteynerlerinin günlüklerini kontrol edin.

3. Init konteynerlerinin doğru yapılandırıldığını emin olmak için pod'un yapılandırmasını (örneğin, sağlık kontrolü ayarlarını) gözden geçirin.

Bkz. Debug init containers.

Init:Error durumunda takılı kalıyor

Pod'daki bir init konteyneri başlatılamadı.

Init:CrashLoopBackOff durumunda takılı kalıyor

Pod'daki bir init konteyneri başlatılamadı ve yeniden başlatma döngüsünde.

Hata mesajı

Açıklama

Çözüm

failed to allocate for range 0: no IP addresses available in range set: xx.xxx.xx.xx-xx.xx.xx.xx

Bu durum, Flannel ağ eklentisinin tasarımı nedeniyle beklenen bir davranıştır.

Flannel bileşenini v0.15.1.11-7e95fe23-aliyun veya üzeri bir sürüme yükseltin. Bkz. Flannel.

Kubernetes 1.20'den önceki bir sürümü çalıştıran kümelerde, bir pod tekrar tekrar yeniden başlatılırsa veya bir CronJob'a ait pod'lar görevlerini tamamlayıp hızlı bir şekilde çıkarsa IP adresi sızıntısı meydana gelebilir.

Kümeyi Kubernetes 1.20 veya üzeri bir sürüme (en son sürüm önerilir) yükseltin. Bkz. Kümeyi manuel olarak yükseltme.

Bu sorun, containerd ve runC'deki hatalardan kaynaklanır.

Acil düzeltme için bkz. Pod'um neden "no IP addresses available in range" hatasıyla başlatılamıyor?

error parse config, can't found dev by mac 00:16:3e:01:c2:e8: not found

Terway ağ eklentisi, esnek ağ arayüzlerini (ENI'ler) izlemek ve yönetmek için düğümde dahili bir veritabanı tutar. Veritabanı durumu gerçek ağ cihazı yapılandırmasıyla tutarsız olduğunda bu hata oluşur ve ENI tahsisi başarısız olur.

1. Ağ arayüzleri eşzamansız olarak yüklenir. CNI yapılandırması sırasında arayüz hala yükleniyor olabilir ve bu durum otomatik bir CNI yeniden denemesini tetikler. Bu süreç, nihai ENI tahsisini etkilemez. Başarıyı doğrulamak için pod'un nihai durumunu kontrol edin.

2. Pod oluşturma işlemi hala başarısız oluyorsa ve bu hata devam ediyorsa, sürücü yüksek seviyeli bellek yetersizliği nedeniyle ENI'yi yükleyemedi demektir. Bu sorunu çözmek için ECS örneğini yeniden başlatın.

• cmdAdd: error alloc ip rpc error: code = DeadlineExceeded desc = context deadline exceeded

• cmdAdd: error alloc ip rpc error: code = Unknown desc = error wait pod eni info, timed out waiting for the condition

Terway ağ eklentisi, vSwitch'ten bir IP adresi isteyememiş olabilir.

1. ENI tahsis sürecini kontrol etmek için düğümdeki Terway bileşeni pod'unda bulunan Terway konteynerinin günlüklerini görüntüleyin.

2. kubectl logs -n kube-system  <terwayPodName > -c terway | grep <podName> komutuyla Terway pod'u için ENI bilgilerini görüntüleyin. İstek Kimliğini ve OpenAPI hata mesajını alın.

3. Başarısızlığı araştırmak için İstek Kimliğini ve hata mesajını kullanın.

Hata mesajı

Açıklama

Çözüm

Günlükte exit(0) bulunuyor.

1. Anormal iş yükünün dağıtıldığı düğüme bağlanın.

2. Kontrol etmek için docker ps -a | grep $podName komutunu kullanın. Konteynerde kalıcı bir işlem yoksa, durum kodu 0 ile çıkar.

Pod'un olaylarında Liveness probe failed: ... gösteriliyor.

Liveness probu başarısız oldu ve uygulamanın yeniden başlatılmasına neden oldu.

• Liveness probu yapılandırması: Hedef Workloads kaynağının Edit sayfasında, sağlık kontrolü istek yolunun (örneğin, /healthz) ve bağlantı noktasının uygulamanın sunduğu değerlerle eşleştiğini doğrulayın. Liveness probunun yalnızca uygulama tamamen başlatıldıktan sonra başlamasını sağlamak için Initial Delay (s) değerini artırın.

  Liveness probunu geçici olarak devre dışı bırakabilirsiniz. Ardından, pod terminaline veya ana makine düğümüne erişin ve curl gibi bir komut kullanarak sağlık kontrolü yönteminin doğru çalıştığını doğrulayın.

• Uygulama sorunlarını giderin: Pod'un Events ve Logs bölümlerini kontrol ederek sorunu araştırın. Show the log of the last container exit seçeneğini belirleyin.

Pod'un olaylarında Startup probe failed: ... gösteriliyor.

Startup probu başarısız oldu ve uygulamanın yeniden başlatılmasına neden oldu.

• Startup probu yapılandırması: Hedef Edit kaynağının Workloads sayfasında, sağlık kontrolü istek yolunun (örneğin, /healthz) ve bağlantı noktasının uygulamanın sunduğu değerlerle eşleştiğini doğrulayın. Uygulamanın başlaması uzun sürüyorsa, erken yeniden başlatmaları önlemek için Unhealthy Threshold değerini artırın.

  Startup probunu geçici olarak devre dışı bırakabilirsiniz. Ardından, pod terminaline veya ana makine düğümüne erişin ve curl gibi bir komut kullanarak sağlık kontrolü yönteminin doğru çalıştığını doğrulayın.

• Uygulama sorunlarını giderin: Pod'un Events ve Logs bölümlerini kontrol ederek sorunu araştırın. Show the log of the last container exit seçeneğini belirleyin.

Pod günlüğünde no space left on device bulunuyor.

Yetersiz cloud disk alanı.

• Cloud disk boyutunu artırın.

• Disk alanını boşaltmak için gereksiz görüntüleri temizleyin ve düğümdeki görüntü çöp toplama eşiğini ayarlamak için imageGCHighThresholdPercent değerini yapılandırın.

Olay bilgisi olmadan başlatma başarısız oluyor.

Bu sorun, bir konteynerin bildirilen sınırlarından daha fazla kaynak gerektirdiğinde ve bu nedenle başarısız olduğunda ortaya çıkar.

Pod'un kaynak yapılandırmasının doğru olup olmadığını kontrol edin. Konteyner için önerilen Request ve Limit yapılandırmalarını almak için kaynak profil oluşturma özelliğini etkinleştirebilirsiniz.

Pod günlüğünde Address already in use gösteriliyor.

Aynı pod içindeki konteynerler arasında bir bağlantı noktası çakışması var.

1. Pod'un hostNetwork: true olarak yapılandırılıp yapılandırılmadığını kontrol edin. Bu ayar, pod içindeki konteynerlerin ana makinenin ağ ad alanını ve bağlantı noktası alanını paylaşmasına neden olur. Bu gerekmiyorsa, değeri hostNetwork: false olarak değiştirin.

2. Pod hostNetwork: true gerektiriyorsa, aynı çoğaltma kümesindeki pod'ların farklı düğümlere zamanlanmasını sağlamak için pod anti-affinity yapılandırın.

3. Aynı düğümde başka hiçbir pod'un bu bağlantı noktasını kullanmadığını doğrulayın.

Pod günlüğünde container init caused "setenv: invalid argument": unknown gösteriliyor.

İş yükü bir Secret'ı bağlar ancak Secret'taki değer Base64 kodlu değildir.

• Secret'ı konsolda oluşturun (değerler otomatik olarak Base64 kodlanır). Bkz. Secret'ları yönetme.

• Secret'ı bir YAML dosyasından oluşturun ve echo -n "xxxxx" | base64 komutunu çalıştırarak değeri manuel olarak Base64 kodlayın.

Uygulamaya özel sorun.

Sorunu gidermek için pod günlüklerini inceleyin.

Hata mesajı

Açıklama

Çözüm

Pod'un olaylarında Readiness probe failed: ... gösteriliyor.

Hazırlık probu başarısız oldu ve hedef pod'un trafik almasını engelledi.

• Hazırlık probu yapılandırması: Hedef Edit kaynağının Workloads sayfasında, sağlık kontrolü yolunun (örneğin, /healthz) ve bağlantı noktasının uygulamanın sunduğu değerlerle eşleştiğini doğrulayın. Uygulama yavaş başlıyorsa, erken başarısızlıkları önlemek için Unhealthy Threshold değerini artırın.

  Readiness probunu geçici olarak devre dışı bırakın, ardından pod terminalinden veya ana makineden curl kullanarak sağlık kontrolü uç noktasını doğrulayın.

• Uygulama sorunlarını giderin: Pod'un Events ve Logs bölümlerini kontrol ederek sorunu araştırın. Show the log of the last container exit seçeneğini belirleyin.

Pod durumu yukarıdakiyle aynı. Pod'un olaylarında Startup probe failed: ... gösteriliyor.

Başarısız bir startup probu, konteynerin yeniden başlatılmasına neden olur. Bu hata, kalıcı bir Running/NotReady durumu yerine 'CrashLoopBackOff' durumuyla sonuçlanmalıdır.

Startup probu için "Pod başlatılamıyor (CrashLoopBackOff)" bölümünde açıklandığı gibi bu sorunu giderin.

OOM düzeyi

Açıklama

Önerilen çözüm

İşletim sistemi düzeyi

Pod'un düğümünde /var/log/messages konumundaki kernel günlüğünü kontrol edin. Günlükte sonlandırılan bir işlem gösteriliyor ancak cgroup günlükleri içermiyorsa, OOM olayı işletim sistemi düzeyinde gerçekleşmiştir.

• Düğüm belleğini artırın veya iş yüklerini daha fazla düğüme dağıtın. Bkz. Düğüm kaynaklarını ölçeklendirme ve Uygulamaları belirli düğümlere zamanlama.

• Düğümdeki yüksek bellek kullanan Pod'ları belirleyin ve uygun bellek sınırları ayarlayın.

cgroup düzeyi

Pod'un düğümünde /var/log/messages konumundaki kernel günlüğünü kontrol edin. Günlükte Task in /kubepods.slice/xxxxx killed as a result of limit of /kubepods.slice/xxxx benzeri bir hata mesajı varsa, OOM olayı cgroup düzeyinde gerçekleşmiştir.

• Pod'un bellek sınırlarını artırın. Gerçek kullanımı sınırların %80'inin altında tutun. Bkz. Pod'ları yönetme ve Düğüm kaynaklarını ölçeklendirme.

• Önerilen konteyner istek ve sınır yapılandırmaları için kaynak profil oluşturma özelliğini etkinleştirin.

Olası neden

Açıklama

Önerilen çözüm

Düğüm NotReady durumundadır.

Düğüm NotReady durumundan kurtulduktan sonra pod otomatik olarak silinir.

Pod finalizer'larla yapılandırılmış.

Bir pod finalizer'larla yapılandırılmışsa, Kubernetes pod'u silmeden önce finalizer'lar tarafından belirtilen temizleme işlemlerini gerçekleştirir. Bir temizleme işlemi yanıt veremezse, pod Terminating durumunda kalır.

kubectl get pod -n <ns> <pod name> -o yaml komutuyla pod'un finalizer yapılandırmasını kontrol edin ve nedeni araştırın.

Pod'un preStop hook'u geçersiz veya takılı.

Pod için bir preStop hook yapılandırılmışsa, Kubernetes konteyneri sonlandırmadan önce hook'u yürütür. Hook çalışırken pod Terminating durumunda kalır.

kubectl get pod -n <ns> <pod name> -o yaml komutuyla pod'un preStop hook yapılandırmasını kontrol edin ve nedeni araştırın.

Pod için zarif kapatma süresi yapılandırılmış.

Bir Pod zarif kapatma süresi (terminationGracePeriodSeconds) ile yapılandırılmışsa, Pod kubectl delete pod <pod_name> gibi bir sonlandırma komutu aldığında Terminating durumuna girer. Kubernetes, Pod'un terminationGracePeriodSeconds içinde belirtilen süre dolduktan veya konteyner çıktıktan sonra başarılı bir şekilde kapatıldığını kabul eder.

Kubernetes, konteyner zarif bir şekilde kapandıktan sonra pod'u otomatik olarak siler.

Konteyner yanıt vermiyor.

Bir pod'u durdurmayı veya silmeyi istediğinizde, Kubernetes pod içindeki konteynerlere bir SIGTERM sinyali gönderir. Bir konteyner sonlandırma sırasında SIGTERM sinyalini doğru şekilde işlemezse, pod Terminating durumunda kalabilir.

1. kubectl delete pod <pod-name> --grace-period=0 --force komutuyla pod'u zorla silin.

2. Daha fazla araştırma yapmak için pod'un düğümündeki containerd veya Docker günlüklerini kontrol edin.

Olası neden

Açıklama

Önerilen çözüm

Düğüm, bellek veya disk kullanımı gibi faktörlerden kaynaklanan kaynak baskısı altında.

Düğüm bellek baskısı, disk baskısı veya PID baskısı yaşıyor olabilir.

• kubectl describe node <node name> | grep Taints komutuyla düğüm taint'lerini kontrol edin. Çıktıda şunlar bulunabilir:

  • Bellek baskısı: Düğümde node.kubernetes.io/memory-pressure taint'i bulunur.

  • Disk baskısı: Düğümde node.kubernetes.io/disk-pressure taint'i bulunur.

  • PID baskısı: Düğümde node.kubernetes.io/pid-pressure taint'i bulunur.

• Pod durumu aşağıdakilerden biridir:

  • Evicted

  • ContainerStatusUnknown ve pod'un YAML dosyasındaki reason alanında Evicted gösterilir.

• Bellek baskısı:

  • İş ihtiyaçlarınıza göre pod'un kaynak yapılandırmasını ayarlayın. Bkz. Pod'ları yönetme.

  • Düğümü yükseltin. Bkz. Düğüm kaynaklarını ölçeklendirme.

• Disk baskısı:

  • Disk alanını boşaltmak için düğümdeki pod'lardaki uygulama günlüklerini periyodik olarak temizleyin.

  • Düğümün diskini genişletin. Bkz. Adım 1: Cloud disk boyutunu artırma.

• PID baskısı: Pod'un kaynak yapılandırmasını ayarlayın. Bkz. Process ID Limits and Reservations.

Beklenmedik bir tahliye gerçekleşiyor.

Pod'un düğümüne manuel olarak eklenen bir NoExecute taint'i, beklenmedik bir tahliyeye neden oldu.

kubectl describe node <node name> | grep Taints komutuyla NoExecute taint'i olup olmadığını kontrol edin. Varsa, kaldırın.

Tahliye beklendiği gibi ilerlemiyor.

• --pod-eviction-timeout: Başarısız bir düğümdeki pod'lar bu zaman aşımı süresinden sonra tahliye edilir. Varsayılan değer 5 dakikadır.

• --node-eviction-rate: Bir düğümden saniyede tahliye edilen pod sayısı. Varsayılan değer 0,1'dir; yani bir düğümden en fazla 10 saniyede bir pod tahliye edilir.

• --secondary-node-eviction-rate: İkincil düğüm tahliye oranı. Kümede çok fazla düğüm başarısız olursa, tahliye oranı bu değere düşürülür. Varsayılan değer 0,01'dir.

• --unhealthy-zone-threshold: Sağlıksız kullanılabilirlik alanı eşiği. Varsayılan değer 0,55'tir. Bir kullanılabilirlik alanındaki başarısız düğümlerin oranı bu eşiği aştığında, alan sağlıksız olarak kabul edilir.

• --large-cluster-size-threshold: Büyük küme boyutu eşiği. Varsayılan değer 50'dir. Bir küme, 50'den fazla düğümü olduğunda büyük olarak kabul edilir.

Küçük bir kümede (50 düğüm veya daha az), düğümlerin %55'inden fazlası başarısız olursa pod tahliyesi durur. Bkz. Rate limits on eviction.

Büyük bir kümede (50'den fazla düğüm), sağlıksız düğümlerin oranı --unhealthy-zone-threshold (varsayılan 0,55) değerini aşarsa, tahliye oranı --secondary-node-eviction-rate (varsayılan saniyede 0,01 pod) değerine düşer. Bkz. Rate limits on eviction.

Bir pod, tahliye edildikten sonra sık sık orijinal düğümüne yeniden zamanlanıyor.

Kubelet, pod'ları gerçek kaynak kullanımına göre tahliye ederken, zamanlayıcı pod'ları kaynak isteklerine göre yerleştirir. Tahliye kaynakları serbest bıraktığından, istekleri hala uyuyorsa zamanlayıcı bir pod'u aynı düğüme yeniden zamanlayabilir.

Pod'un kaynak isteklerini düğümün atanabilir kaynaklarına uyacak şekilde ayarlayın. Bkz. Bir konteyner için CPU ve bellek kaynaklarını ayarlama. Önerilen istek ve sınır değerlerini almak için kaynak profil oluşturma özelliğini etkinleştirin.