Self-Healing Konteynerler: Teoride Güzel, Pratikte Sınırlı

Kubernetes'e başladığında self-healing özelliğinden çok etkilenmiştim. Konteyner çöktü mü, otomatik yeniden başlat. Pod öldü mü, yerine yeni bir tane koy. Sunucu kaynakları biterse pod'u başka node'a taşı. Teoride mükemmel. Fakat üretim ortamında çalıştırınca gerçek daha karmaşık.

Self-healing'in işe yaradığı durumlar sınırlı. Eğer konteyneriniz geçici bir bellek sızıntısı veya bağlantı timeout'u yüzünden kapanıyorsa, restart policy otomatik onarım sağlar. Liveness probe'u doğru ayarlarsan, donmuş uygulamaları yakalarsan, sistem kendini toparlar. Bu kısım gerçekten çalışır.

Ama sorunlar başlıyor işte orada. Konteyner bir infinite loop'ta takılıp kalmışsa, restart sonsuz döngüye girer. Uygulama bellek tükettikçe çökerse, yeni pod da aynı şekilde çöker. Veri tabanı bağlantı stringi yanlışsa, self-healing hiçbir şey yapmaz. Pod başarısız başlıyorsa, Kubernetes onu kaldırmaya başlar; backoff süresi uzar ve hizmet offline kalır.

Yani self-healing aslında şu işi yapıyor: geçici, belirsiz hatalardan kurtul. Kalıcı, sistematik sorunları gizle. Çoğu zaman da gizleme işini başarıyla yapıyor. Bir saat sonra alert geldiğinde, pod'un yüzlerce defa restart ettiğini görüyorsun.

Problemi çözmek için orchestration'a değil, monitöring ve logging'e yatırım yapmak gerekiyor. Self-healing'e güvenip hata log'larını ihmal etmek, kötü bir strateji. Restart'ları yakala, event'leri topla, anomali tespiti kur. Pod'u ölüm kalım çevriminden kurtarmak için önce neden öldüğünü bilmen lazım.

Self-healing'in değeri burada: seni manuel müdahale yapmaktan kurtarması. Ama sorunu çözmesi değil. Fark etmek önemli. Kubernetes'i bir terapist gibi düşünme, asistan gibi düşün. Sorunu sen bulacaksın, sistem sadece tepki verecek.

Bu yüzden self-healing'i yalnız başına başarı ölçütü olarak görme. Monitoring, alerting ve iyi bir deployment stratejisiyle birlikte kullan. O zaman gerçekten işe yarar.