Kubernetes'te hata ayıklama: pod durumundan kök nedene

Sorun gidermeye sistematik başlamak

Kubernetes'te bir şey çalışmadığında en büyük hata, tahminle komut denemeye başlamaktır. Sistem katmanlıdır: uygulama, konteyner, pod, iş yükü denetleyicisi (Deployment gibi), servis, ağ, depolama, düğüm ve kontrol düzlemi. Sorun bu katmanların birinde yaşar ve doğru katmanı bulmak çözümün büyük kısmıdır.

Yöntem basittir: dıştan içe veya içten dışa tek bir yönde ilerleyin. Önce belirti nedir (pod hiç başlamıyor mu, başlayıp çöküyor mu, çalışıyor ama erişilemiyor mu?), sonra ilgili nesnenin durumu ve olayları, ardından günlükler, en sonda düğüm ve küme bileşenleri. Her adımda tek bir hipotez kurup onu doğrulayın; birden çok değişikliği aynı anda yapmak neyin işe yaradığını gizler.

Temel komutlar: durumu, olayları ve günlüğü okumak

Çoğu sorun birkaç komutla teşhis edilir.

• kubectl get pods: Pod durumunu gösterir. Durum sütunu (Pending, Running, CrashLoopBackOff, ImagePullBackOff gibi) ilk ipucudur.
• kubectl describe pod: Pod'un olaylarını (events) listeler. Zamanlanamama nedeni, imaj çekme hatası, probe başarısızlığı, bellek yetersizliği burada yazar.
• kubectl logs: Konteyner günlüğünü gösterir. Çöken konteyner için önceki çalışmanın günlüğü --previous seçeneğiyle alınır.
• kubectl exec: Çalışan konteynerin içinde komut çalıştırır; ağ ve yapılandırma testi için kullanılır.
• kubectl get events: Ad alanı veya küme genelindeki olayları zamana göre sıralar.
• kubectl debug: Kabuk veya hata ayıklama araçları olmayan konteynerlerde geçici bir hata ayıklama konteyneri eklemeye ya da pod'un kopyası üzerinde çalışmaya izin verir.

Alışkanlık edinin: önce describe ile olayları, sonra logs ile uygulama çıktısını okuyun.

Pod durumuna göre teşhis

Pending: Pod henüz bir düğüme yerleşememiştir. Olaylarda genellikle neden yazar: yetersiz CPU veya bellek, düğümlerin taint'leri, node selector veya affinity kuralı, bağlanamayan bir kalıcı birim. Kaynak isteklerini (requests), düğüm kapasitesini ve taint-tolerasyon eşleşmesini kontrol edin.

ImagePullBackOff veya ErrImagePull: İmaj çekilemiyor. İmaj adı ve etiketi yanlış olabilir, özel kayıt defteri için pull secret eksik olabilir, ağ erişimi veya kayıt defteri kimlik doğrulaması sorunlu olabilir.

CrashLoopBackOff: Konteyner başlıyor ama sürekli çöküyor. Önce logs --previous ile uygulama hatasına bakın: yapılandırma eksikliği, bağlanılamayan bir veritabanı, hatalı başlangıç komutu. Liveness probe'un fazla agresif ayarlanması da sağlıklı konteyneri öldürebilir.

OOMKilled: Konteyner bellek sınırını aştığı için öldürülmüştür. Sınırı artırmak geçici çözümdür; asıl soru uygulamanın neden o kadar bellek tükettiğidir.

CreateContainerConfigError: Başvurulan bir ConfigMap veya Secret bulunamıyor. Adı ve ad alanını doğrulayın.

Running ama hazır değil: Readiness probe başarısız. Probe yolu, portu ve uygulamanın başlangıç süresi uyuşmayabilir.

Çalışıyor ama erişilemiyor: servis ve ağ sorunları

Pod'lar sağlıklı görünürken uygulamaya ulaşılamıyorsa servis katmanına bakın. Servisin seçici (selector) etiketleri pod etiketleriyle birebir eşleşmiyorsa servis hiçbir pod'a yönlenmez; kubectl get endpoints ile servisin arkasında gerçekten adres olup olmadığına bakın. Boşsa genellikle etiket uyuşmazlığı veya hazır olmayan pod vardır.

Kümenin içinden test etmek için geçici bir pod açıp servis adına istek atın. Ad çözümlemesi başarısızsa CoreDNS pod'larını ve yapılandırmasını inceleyin. Bağlantı çözümleniyor ama kopuyorsa NetworkPolicy, port eşleşmesi (hedef port ve konteyner portu) ve ingress yapılandırmasını sorgulayın. Dış erişimde yük dengeleyici, güvenlik grubu veya güvenlik duvarı kuralları da küme dışı nedenler olabilir.

Depolama, düğüm ve kontrol düzlemi sorunları

Kalıcı birim talebi (PVC) Pending'de kalıyorsa uygun bir StorageClass tanımlı mı, dinamik hazırlama çalışıyor mu, erişim modu ve kapasite eşleşiyor mu diye bakın. Pod'un bulunduğu bölgeyle birimin bulunduğu bölge farklıysa pod zamanlanamayabilir.

Düğüm NotReady ise düğüme ulaşıp kubelet ve konteyner çalışma zamanı günlüklerini, disk, bellek ve ağ durumunu inceleyin. Disk doluluğu ve bellek baskısı pod tahliyelerine (evicted) yol açar. Kontrol düzlemi sorunları (API sunucusu yanıtsız, etcd sağlıksız, zamanlayıcı çalışmıyor) daha nadirdir ama etkisi geniştir; bu bileşenlerin günlükleri, sertifika geçerlilikleri ve etcd sağlığı ilk bakılacak yerlerdir. Yönetilen küme hizmetlerinde kontrol düzlemine doğrudan erişiminiz olmayabilir; bu durumda sağlayıcının durum paneli ve destek kanalı devreye girer.

Örnek senaryo: yeni sürüm sonrası uygulama ayağa kalkmıyor

Örneğin yeni sürümü dağıttıktan sonra pod'lar CrashLoopBackOff durumunda. Önce get pods ile durumu görürsünüz, ardından describe ile olaylara bakarsınız: probe hatası yok, imaj çekilmiş, konteyner başlayıp kapanıyor. logs --previous uygulamanın bir ortam değişkenini bulamadığını gösteriyor. Dağıtım tanımını incelediğinizde yeni sürümün başvurduğu bir Secret anahtarının eski ortamda tanımlı olmadığını fark edersiniz.

Çözüm anahtarı eklemek ve dağıtımı yeniden başlatmaktır; kalıcı önlem ise dağıtım öncesi yapılandırma doğrulaması eklemek ve gerekli değişkenlerin eksikliğinde uygulamanın açık bir hata mesajı vermesini sağlamaktır. Kök neden analizi bu yüzden son adımdır: sorunu çözmek yetmez, tekrar etmemesi için süreci düzeltmek gerekir.

Sık yapılan hatalar ve alışkanlıklar

• Olayları okumadan yeniden başlatmak: Pod'u silmek belirtiyi geçici gizler, nedeni silmez.
• Yalnızca son günlüğe bakmak: Çöken konteynerde önceki çalışmanın günlüğü kritiktir.
• Kaynak sınırlarını rastgele artırmak: Bellek sızıntısını veya yanlış yapılandırmayı maskeler.
• Probe ayarlarını göz ardı etmek: Başlangıç süresi uzun uygulamalarda agresif liveness probe döngü yaratır.
• Aynı anda çok değişiklik yapmak: Neyin işe yaradığı anlaşılmaz.
• Gözlemlenebilirliği sonradan düşünmek: Metrik, günlük toplama ve olay izleme sorunları sorun çıkmadan önce kurulmalıdır.
• Kök nedeni yazıya dökmemek: Aynı hata başka ekipte tekrar yaşanır.

Öğrenme yolu ve Mindset bağlamı

Önce Docker ve konteyner temellerini, ardından pod, deployment, servis gibi temel nesneleri öğrenin. Sorun giderme pratiği için bilerek bozuk uygulamalar kurup teşhis etmek verimli bir yöntemdir: yanlış imaj etiketi, eksik Secret, hatalı probe, yanlış servis seçici gibi senaryoları kendiniz yaratın.

Mindset'in Kubernetes Sorun Giderme ve Hata Ayıklama Pratikleri programı; sistematik teşhis yöntemi, pod yaşam döngüsü sorunları, çizelgeleme ve kaynak sorunları, ağ sorunlarının teşhisi, depolama ve kalıcı veri sorunları, control plane ve etcd teşhisi, gözlemlenebilirlik ile destekli teşhis ile kök neden analizi ve kalıcı önlem modüllerini içerir. Kubernetes Administrator (CKA) Hazırlık programında da sorun giderme ve teşhis ayrı bir modül olarak yer alır.