Technical Tutorials

Üretim ortamında konteyner çalıştırmak bir şeydir; onları güvenilir şekilde çalışır tutmak başka. Orta ve ileri düzey geliştiriciler için, Kubernetes kümesinde çöken veya yanıt vermeyen bir podla karşılaşmak sadece bir rahatsızlık değil, hızlı ve sistematik bir çözüm gerektiren kritik bir olaydır. İster CrashLoopBackOff hatalarıyla, ister imaj çekme başarısızlıklarıyla veya ağ zaman aşımı sorunlarıyla uğraşıyor olun, hata ayıklama için sistematik bir yaklaşıma sahip olmak esastır.

Bu rehber, temel sözdiziminin ötesine geçerek yaygın Kubernetes pod sorunlarını teşhis etme ve düzeltme pratiğine odaklanır. Sonunda, konteyner yaşam döngüsü içindeki hataları izole etmek için sağlam bir zihinsel modele sahip olacaksınız.

Adım 1: Pod Durumunu ve Olayları Doğrulayın

Herhangi bir sorun giderme oturumundaki ilk adım, iş yükünün mevcut durumunu anlamaktır. Podun mevcut durumuna neden girdiğini bilmeden doğrudan günlüklere (logs) dalmayın. kubectl get pods komutu size genel durumu verir, ancak derinlemesine teşhis için genellikle yetersiz kalır.

Bunun yerine, bu komutu her zaman kubectl describe pod ile eşleştirin. Bu komut, podun olaylarını içeren detaylı bir çıktı sağlar; bu olaylar, planlayıcının eylemlerini ve başarısızlık nedenlerini anlamak için hayati önem taşır.

# 'default' ad alanındaki podların genel durumunu kontrol edin
kubectl get pods -n default

# Olaylar dahil olmak üzere belirli bir pod hakkında ayrıntılı bilgi alın
kubectl describe pod my-app-pod-xyz123 -n default

Çıktının altındaki Olaylar bölümüne dikkatlice bakın. FailedScheduling görüyor musunuz? Bu genellikle kaynak kısıtlamalarına (CPU/Bellek istekleri) veya düğüm yakınlığı sorunlarına işaret eder. ImagePullBackOff görüyor musunuz? Bu, kayıt defteri kimlik doğrulama sorunu veya imaj etiketindeki bir yazım hatası olduğunu gösterir. Bu katman bir sorunları ele almak, uygulama günlüklerine dalmaktan genellikle daha hızlıdır.

Adım 2: Konteyner Günlüklerini İnceleyin

Podun çalışır durumda olduğunu (veya yeni çöktüğünü) doğruladıktan sonra, bir sonraki mantıklı adım uygulama çıktısını incelemektir. Kubernetes, konteyner giriş noktasından gelen stdout ve stderr'i erişilebilir günlüklere toplar.

Günlükleri akış olarak görüntülemek veya dışa aktarmak için kubectl logs kullanın. Bir pod CrashLoopBackOff durumunda ise, bu konteynerin başladığını, bir hatayla karşılaştığını ve çıktığını gösterir. Konteynerin önceki örneğinin günlüklerini kontrol etmeniz gerekir.

# Şu anda çalışan örneğin günlüklerini görüntüleyin
kubectl logs my-app-pod -n default

# Konteyner çöktüyse önceki konteyner örneğinin günlüklerini görüntüleyin
kubectl logs my-app-pod --previous -n default

Bu günlükleri analiz ederken yığın izleri (stack traces), ölümcül hatalar veya yapılandırma istisnaları arayın. Günlükler boşsa, konteyner sonsuz bir döngüde takılmış olabilir veya bir sinyal bekliyor olabilir; bu durum exec aracılığıyla daha fazla araştırma gerektirir.

Adım 3: Exec ile Etkileşimli Hata Ayıklama

Bazen günlükler yeterli değildir. Dosya sistemini incelemeniz, ortam değişkenlerini kontrol etmeniz veya konteyner bağlamı içinde ağ bağlantısını test etmeniz gerekebilir. İşte burada kubectl exec en güçlü aracınız haline gelir.

# Çalışan konteynerde bir bash kabuğu açın
kubectl exec -it my-app-pod -- /bin/bash

# Ortam değişkenlerini kontrol edin
printenv

# Harici bir hizmete veya veritabanına bağlantıyı test edin
curl -v http://internal-service:8080/health

# Yapılandırma haritalarının doğru şekilde bağlanıp bağlanmadığını kontrol etmek için dosyaları listele
ls -la /etc/config

Etkileşimli oturumlar, özellikle hacim bağlama sorunlarını teşhis etmek için kullanışlıdır. Uygulamanız, bir ConfigMap veya Secret'te bulunan bir yapılandırma dosyasını bulamıyorsa, exec aracılığıyla bağlanmış dizini kontrol etmek, yolun yanlış olup olmadığını veya izinlerin yanlış olup olmadığını anında ortaya çıkaracaktır.

Adım 4: Kaynak Kısıtlamalarını Kontrol Edin

Sessiz pod ölümlerinin en yaygın nedenlerinden biri, kaynak limitlerine takılmaktır. Bir konteyner CPU veya bellek limitlerini aşarsa, Linux çekirdeğinin Bellek Dışı (OOM) öldürücüsü, uygulama günlüklerinde çok fazla bağlam sağlamadan onu sonlandırabilir.

Kaynak kullanımını şu komutla kontrol edin:

kubectl top pod my-app-pod

Raporlanan kullanımı, YAML manifestonuzda tanımlanan resources.limits ile karşılaştırın. Kullanım sürekli olarak limite yakınsa, yatay olarak ölçeklendirmanız veya limitleri ayarlamanız gerekebilir. Ayrıca, pod sık sık yeniden başlatılıyorsa, OOM öldürücü mesajları için alt düğümün sistem günlüklerini (journalctl kullanarak Linux düğümlerinde) kontrol edin.

Sonuç

Kubernetes podlarını sorun giderme, komutları ezberlemekten çok daha çok mantıksal bir teşhis yolunu izlemektir: Durum → Olaylar → Günlükler → İç İnceleme → Kaynaklar. Bu dört adımı ustalaşarak hataları verimli bir şekilde izole edebilir, ortalama çözüm süresini (MTTR) azaltabilir ve konteynerleştirilmiş uygulamalarınızın istikrarını koruyabilirsiniz. Unutmayın, Kubernetes ihtiyacınız olan tüm araçları sağlar; sadece bunları sırayla nasıl kullanacağınızı bilmeniz gerekir.