İnsanlar Kubernetes'te YAML yazmak zor olduğu için zorlanmaz. Zorlanırlar, çünkü "bir istek geldi" ile "bir container onu işledi" arasında görünmez bir nesne zinciri vardır ve hiçbiri tek bir yerde değildir; bir Kubernetes ağ diyagramının çözdüğü sorun da budur. Kodu bir Pod çalıştırır, ama trafiği asla bir Pod'a yönlendirmezsin. Bir Service ona sabit bir isim verir, ama bir Service TLS sonlandırmaz. Bir Ingress ya da Gateway dış dünyayla ilgilenir, ama trafiği bir Service'e iletir; Service de Pod'ları seçer ve Pod'lar her an yer değiştirebilir. Tek bir halkayı kaçırırsan hiçbir şey çalışmaz ve hata mesajı nadiren hangi halka olduğunu söyler.
Bu zincirin bir diyagramı, manifestleri ne kadar tekrar okursan oku ondan daha değerlidir. Zihinsel modeli nesne nesne kuralım, sonra çizelim.
Pod'lar: kodun gerçekten çalıştığı yer
Pod, birlikte schedule edilen ve bir ağ kimliğini paylaşan bir ya da daha fazla container'dır. Sürecini çalıştıran birim odur. Bir diyagram için kritik gerçek şu: Pod'lar evcil hayvan değil, sürüdür. Sürekli oluşturulup yok edilirler, IP'leri değişir ve asla belirli birine güvenmemelisin. Üstlerindeki her şeyin var olma sebebi tam olarak bu: işaret edilecek sabit bir şey sağlamak.
Service'ler: hareket eden Pod'ların önünde sabit bir isim
Service, sabit bir sanal adres ve bir yük dengeleme kuralıdır. Arkasındaki Pod'ları bulmak için bir label selector kullanır ve trafiği o an hangileri varsa onlara dağıtır. Bir Pod ölüp yenisi başladığında Service sessizce güncellenir; çağıranlar hiç fark etmez. Diyagramında Service, diğer şeylerin bağlandığı kutudur; arkasında sürekli değişen bir Pod kümesine doğru örtük bir dağılım vardır.
Ingress ve Gateway API farkı: dışarıya açılan kapı
Tek başına bir Service seni dünyaya işe yarar bir şekilde açmaz. Bu, bir Ingress'in ya da yeni modelde bir Gateway'in işidir. Bu katman host ve path yönlendirmesini, TLS sonlandırmayı ve "bu host ve path için gelen istekler şu Service'e gider" diyen kuralları yönetir. Gateway API, eski Ingress'i sorumlulukların daha temiz ayrıldığı (gateway'in sahibi kim, route'ların sahibi kim) bir yapıyla genelleştirir; ama diyagramdaki şekil aynıdır: dışarıdan gelen her şeyin önce çarptığı ve Service'lere kurala göre ileten kenar kutusu.
Zinciri bir kez çiz, hatalar kendini açıklamaya başlar: bozuk bir selector, eksik bir route, hiçbir şeyi göstermeyen bir Service.
Neden çizmek yeniden okumaktan iyidir
Bir şeye ulaşılamadığında diyagram bir kontrol listesidir. Ingress kuralı doğru Service'i mi gösteriyor? Service'in selector'ı Pod'ların label'larıyla eşleşiyor mu? Hiç Pod var mı? Resimdeki her halka yanlış olabilecek bir şeydir ve onları yan yana görmek belirsiz bir "çalışmıyor"u somut bir "selector eşleşmiyor"a dönüştürür. Hata ayıklamakla tahmin yürütmek arasındaki fark budur.
Bırak manifestler çizsin
Bu kutuları elle yerleştirmen gerekmez. Manifestlerin tüm zinciri zaten kodluyor: Ingress kendi Service'ini adlandırır, Service selector'ını taşır, Deployment label'larını Pod'larına basar. YAML'ı yapıştır, ilişkiler senin için namespace'e göre gruplanmış hâlde çizilir; böylece resim cluster hakkındaki varsayımlarınla değil, cluster'ın kendisiyle örtüşür.
Sonra insanlar için not düş
Nesneler tuvale yerleştiğinde resmi öğretici hâle getir. Dış kenarı renklendir, namespace'e göre grupla, TLS'in nerede sonlandığını işaretle ve yük altındaki Service'in hangisi olduğunu not et. Yeni bir mühendis, tek bir YAML dosyası açmadan, internetten bir container'a kadar bir isteği parmağıyla izleyebilmeli. Saklamaya değer diyagram budur.
Manifestlerini yapıştır, Pod'ların, Service'lerin, Ingress ve gateway'lerin bağlandığını gör ve sonunda tüm istek yolunu aynı anda aklında tut.