Kubernetes konteynerleri doğrudan çalıştırmaz. En küçük dağıtım birimi pod’dur ve bu, ilk bakışta gereksiz bir ara katman gibi görünür. Ama bir tasarım tercihidir ve nedeni açıktır.
Neden konteyner değil de pod
Bazı bileşenler gerçekten ayrılamaz. Bir uygulama ile onun günlüklerini toplayan yardımcı, ya da bir uygulama ile önüne konan vekil — aynı makinede, aynı ağ arayüzünde ve aynı diski görerek çalışmalıdır.
Bunu her seferinde elle kurmak yerine Kubernetes bir sarmal tanımlar: pod. İçindeki konteynerler her zaman aynı düğümde çalışır, birlikte planlanır ve birlikte sonlanır.
Yani pod, “birlikte yaşaması gereken konteynerler” grubudur. Çoğu podda tek konteyner bulunur; bu normaldir ve sarmal yine de gereklidir.
Neyi paylaşırlar
Aynı poddaki konteynerler iki şeyi paylaşır.
Ağ ad alanı. Tek bir IP adresleri vardır ve birbirlerine localhost üzerinden ulaşırlar. Bu, aralarındaki iletişimi ağdan geçirmeden yapmalarını sağlar. Aynı zamanda port çakışması anlamına gelir: iki konteyner aynı portu dinleyemez.
Depolama birimleri. Poda tanımlanan birimler, içindeki konteynerlerin hepsine bağlanabilir. Bir konteynerin yazdığını diğeri okuyabilir.
Süreç ad alanı ise öntanımlı olarak ayrıdır — birbirlerinin süreçlerini görmezler, ama istenirse paylaştırılabilir.
Konteynerin kendisinin nasıl çalıştığı konteyner nedir yazısında.
Init konteynerleri
Bir pod, asıl konteynerler başlamadan önce çalışıp biten init konteynerleri içerebilir.
Sırayla çalışırlar ve her biri başarıyla bitmeden sonraki başlamaz. Hepsi bittiğinde asıl konteynerler ayağa kalkar.
Kullanım yerleri nettir: veritabanı şemasını hazırlamak, bir bağımlılığın hazır olmasını beklemek, yapılandırma dosyası indirmek ya da izinleri düzeltmek.
Ana uygulama imajını bu işlerle şişirmemek için iyi bir yoldur — init konteyneri farklı bir imaj kullanabilir.
Yan araç konteynerleri
Asıl konteynerle birlikte çalışan yardımcılara yan araç denir: günlük toplayıcı, metrik dışa aktarıcı, hizmet ağı vekili.
Buradaki klasik tuzak, bir podun ancak tüm konteynerleri çalışırken sağlıklı sayılmasıdır. Bir yan araç sürekli çöküyorsa asıl uygulama sağlıklı olsa bile pod sorunlu görünür.
Ters durum da vardır: kısa ömürlü bir iş yürüten podlarda, asıl konteyner bitse bile yan araç çalışmayı sürdürürse pod hiç tamamlanmaz.
Yaşam döngüsü
Bir podun durumu birkaç aşamadan geçer ve teşhis sırasında hangi aşamada takıldığı doğrudan nedeni söyler.
Pending bir düğüme yerleştirilemediğini gösterir — kaynak, taint ya da birim sorunu. ContainerCreating yerleşti ama konteyner kurulamıyor demektir. Running çalışıyor, Succeeded düzgün bitti, Failed hata ile bitti anlamına gelir.
CrashLoopBackOff ise ayrı bir durumdur: konteyner başlıyor ve ölüyor, Kubernetes de yeniden başlatma aralığını kademeli olarak uzatıyor.
Her durumun teşhis sırası pod başlamıyor rehberinde ayrıntılı.
Yoklamalar
Üç tür sağlık denetimi vardır ve karıştırıldıklarında zararlı olabilirler.
Hazırlık yoklaması (readiness) “bu pod trafik alabilir mi” sorusunu yanıtlar. Geçmezse pod servisten çıkarılır ama öldürülmez.
Canlılık yoklaması (liveness) “bu pod hâlâ hayatta mı” sorusunu yanıtlar. Geçmezse konteyner öldürülür ve yeniden başlatılır.
Başlangıç yoklaması (startup) yavaş açılan uygulamalar içindir; o geçene kadar canlılık yoklaması hiç çalışmaz.
En yaygın hata, canlılık yoklamasını çok erken başlatmaktır: uygulama açılırken öldürülür ve sonsuz döngüye girer. İkinci hata, hazırlık yoklamasında bağımlılıkları da sınamaktır — veritabanının kısa bir kesintisi tüm podları aynı anda trafikten düşürür ve küçük bir sorunu tam kesintiye çevirir.
Aynı denge yük dengeleyicilerde de geçerlidir; yük dengeleme nedir yazısında ele alınıyor.
Podlar geçicidir
Pod’lar tek başına yönetilmez. Silinirler, yeniden oluşturulurlar ve IP adresleri değişir.
Bu yüzden pod’a doğrudan bağlanılmaz; araya bir Service girer ve kalıcı bir ad sağlar. Erişim katmanlarının elenmesi Service, Ingress ve NetworkPolicy rehberinde.
Aynı nedenle pod’ları elle oluşturmak yerine bir Deployment tanımlanır; o da istenen kopya sayısını korur ve güncellemeleri yönetir.
Kaynak istekleri pod düzeyinde toplanır
Her konteynerin isteği ayrı yazılır, ama zamanlayıcı podun toplamına bakar. Init konteynerlerinde ise en büyüğü esas alınır, toplam değil.
Bellek sınırı aşıldığında yalnızca ilgili konteyner öldürülür — pod tamamen gitmez. Ama sonuç genelde aynıdır, çünkü asıl uygulama zaten o konteynerdir.
Değerlerin nasıl seçileceği istek ve sınır rehberinde, hesap için Kubernetes kaynak planlayıcı aracı var.
Kısaca
Pod, birlikte yaşaması gereken konteynerlerin sarmalıdır: aynı düğümde çalışır, aynı IP’yi ve birimleri paylaşırlar.
Çoğu podda tek konteyner olur; init ve yan araç konteynerleri belirli işler için eklenir. Ve pod geçicidir — kalıcı adres Service’ten, kopya yönetimi Deployment’tan gelir.