Kubernetes Exit Kodları ve Nasıl Hesaplanır
Kubernetes üzerinde bir Pod restart olduğunda, troubleshooting sırasında baktığımız ilk bilgilerden biri container’ın Exit Code’u oluyor. Peki bu sayılar gerçekten ne anlatıyor?
Exit Code’ları hızlı okumak için
Linux’ta signal kaynaklı termination durumlarında genel mantık:
Exit Code = 128 + Signal NumberÖrneğin:
- SIGINT = 2 → 130
- SIGKILL = 9 → 137
- SIGSEGV = 11 → 139
- SIGTERM = 15 → 143
Bu mantığı öğrendiğinizde Kubernetes’te gördüğünüz bazı “anlamsız” sayılar daha mantıklı gelmeye başlayacak.
Peki neden özellikle 128?
Çünkü Unix shell’lerinde 0–127 aralığı normal exit status için, 128 ve üzeri ise signal kaynaklı termination’ı temsil etmek için geleneksel olarak kullanılmıştır.
Buradaki iki kavramı birbirinden ayırmak önemli:
- Signal = Process’e gönderilen Linux mesajı
- Exit Code = Process’in nasıl sonlandığını raporlayan sayı
Örneğin:
- SIGTERM → “Kapanmanı istiyorum, düzgünce kapan.”
- SIGKILL → “HEMEN KAPAN!”
- SIGINT → “Interrupt edildi.”
- SIGSEGV → “Geçersiz memory erişimi oldu.”
En kritik 4 Exit Code
- 137 → SIGKILL → çoğunlukla OOMKilled
- 143 → SIGTERM → graceful termination
- 139 → SIGSEGV → segmentation fault
- 1 → Application error
Exit code sonucu söyler, nedeni değil
Exit code size container’ın nasıl sonlandığını söyler — neden sonlandığını değil. Asıl teşhis kubectl describe pod çıktısındaki Reason alanında ve --previous bayrağıyla aldığınız önceki container loglarındadır.
137’nin her zaman OOMKilled anlamına gelmediği de burada devreye girer. Exit code’ları adım adım teşhise çevirme sırası için Kubernetes Pod Debug Cheat Sheet yazısına bakın.
Bu tür teşhisleri gerçek cluster’lar üzerinde uygulamalı çalıştığımız bir DevOps eğitim programımız var — komutu ezberlemek değil, çıktıyı okumak üzerine kurulu. Müfredat ve başvuru: kubeatlas.com/egitimler/devops-egitimi