Kubernetes’te Pod VPN’i mi, çıkış ağ geçidi mi: tünel kimin?

vpn-gateway adlı bir Pod dağıtıyor, bir test istemcisini onun adresine yönlendiriyor ve paketlerin kaybolduğunu görüyorsunuz. Manifestte yanlış bir şey yok ve kubelet’in bir şikayeti yok. Nedeni yapısal, yapılandırma değil: Kubernetes her Pod’a kendi ağ ad alanını verir, bu yüzden bir ad, etiket veya paylaşılan API ad alanı paketlerin nereye gittiğini değiştirmez. Bu nedenle VPN trafiğinin kümeden nasıl çıkacağına karar vermek sahiplik sorusuyla başlar, konteyner imajlarıyla değil.

İki mekanizma gerçek dağıtımların çoğunu kapsar ve birbirlerinin yerine geçmezler. Biri tüneli iş yükünün kendi ağ ad alanına koyar. Diğeri CNI’den seçilen trafiği belirlenmiş bir ağ geçidi düğümünden geçirmesini ister. Farklı şekillerde başarısız olurlar, farklı şekilde ölçeklenirler ve farklı ekiplere bağlıdırlar, bu yüzden konteyner sorusu genellikle hiç kapanmayan tartışmalar üretir.

Pod sınırı bir ad alanıdır, atlama sunucusu değil

Bir Linux ağ ad alanı kendi arayüzlerine, adreslerine, yollarına ve güvenlik duvarı kurallarına sahiptir ve her Pod bir tane alır. O Pod içindeki konteynerler ona katılır ve tam olarak bu yüzden bir yardımcı konteyner, uygulamanın sonra izlediği yolları yeniden yazabilir. Komşu Pod aynı görünen ama tamamen ayrı bir yığına sahiptir. Bir ağ geçidi Pod’unun devralabileceği ortak bir tablo yoktur ve trafiğin bir ad alanından diğerine örtük devri yoktur.

Bu yüzden ağ geçidi-Pod deseni yalnızca yukarı akışta bir şey gerçekten ona paket gönderdiğinde çalışır: bir Service, düğümde statik bir yol veya CNI’de yönlendirme politikası. Yalnızca bir adres hiçbir şeyi çekmez.

Pod başına tünel ne alır ve neye mal olur

İş yükünün ad alanında çalışan bir tünel, o iş yüküne kendi istemci kimliğini verir; birçok uzaktan erişim hizmeti oturumu yetkilendirmeden veya hesaplamadan önce bunu ister. Hasar yarıçapı da yerel kalır: bozuk bir tünel, her şeyin kullandığı ortak yol yerine bir Deployment’ı devre dışı bırakır. Nasıl çalıştığı uygulamaya bağlıdır ve insanlar tam burada yanlış tahmin eder.

Yalnızca çekirdek durumuna ihtiyaç duyan bir kurulum bir init konteynerinde bitip çıkabilir. Pod’un tüm ömrü boyunca yaşaması gereken bir kullanıcı alanı arka plan programı, Kubernetes 1.29’da yerel bir sidecar olarak sunulan yeniden başlatılabilir init konteyner biçimine ihtiyaç duyar ve bu fark zevkten değil tünelin uygulanmasından gelir. Bu modelin maliyeti çoğaltmadır: her replika kimlik doğrular, kendi tünel adresini alır ve bir uzak oturum yuvasını tüketir, böylece bir otomatik ölçeklendirme olayı bağlantının diğer ucunda bir kapasite olayına dönüşür. Tek bir kimlik bilgisini tüm replikalara kopyalamak bu maliyeti ortadan kaldırmaz, denetim izini ortadan kaldırır. Yetkiler de aynı incelemeyi hak eder, çünkü kendi ad alanında NET_ADMIN isteyen bir tünelin privileged: true örneğindeki tüm ana bilgisayar yetkisini devralmak için hiçbir nedeni yoktur.

Çıkışı CNI sahiplendiğinde

CNI bunu destekliyorsa, bir çıkış ağ geçidi trafiği iş yüküne ve hedef aralığına göre seçer, sonra seçilen düğümler üzerinden öngörülebilir tek bir kaynak adresi altında gönderir. Cilium’un sürümü yaygın referanstır ve belgeleri bu özelliğin belirli bir Cilium yapılandırması ile doğru arayüz ve adreslerle hazırlanmış ağ geçidi düğümleri gerektirdiğini açıkça söyler. Ayrıca Pod oluşturulduktan sonra yönlendirmenin henüz uygulanmadığı bir başlangıç döneminden söz eder; bu bir dipnot değil tasarım girdisidir.

Bu gecikmeyi kendi vaadinize karşı okuyun. Kural, hiçbir trafiğin başka bir yoldan çıkamayacağı ise, boşluk sırasında gönderen yeni Pod onu zaten ihlal etmiştir, bu yüzden başlatma dizisinin kendi yanıtı gerekir: politika uygulanana kadar uygulamayı tutun ya da pencereyi kabul edip belgeleyin.

İddiayı dar tutun. Bir çıkış ağ geçidi bir yolu seçer ve çevirir. Bir VPN’i sonlandırmaz ve arkasında desteklenen bir bağlantı olmadan kümeyi uzak ağınızın istemcisi yapmaz.

Çeviri, uzak tarafın gördüğünü sessizce değiştirir

Ağ geçidi kaynağı yeniden yazdığında Pod başına adresler kaybolur, bu yüzden kimliğe dayalı izin listesi tek bir ortak adrese dayalı listeye dönüşür. Bu bir kusur değil takastır: bakımı daha az kural, bir şey kötü davrandığında daha kaba atıf.

Uygulama düzeyinde kimlik doğrulama ve istek günlüğü, ağın artık bildirmediğini taşımalıdır. Ağ geçidi kapasitesini ve değişimini ortak altyapı olarak görün, çünkü tek bir düğümün yeniden başlatılması artık arkasındaki her iş yükünü kesintiye uğratır, ve dönüş yolunu erken kontrol edin: uzak uç, çevrilen adrese nasıl ulaşacağını bilmelidir, genellikle bir yönlendirici veya NAT üzerinden, ki bunu manifest değil bir insan sahiplenmelidir. Adres planlaması da buraya aittir, çünkü çakışan küme ve uzak aralıklar iki modeli de bozar ve IPv6 benimsemek çelişkili bir planı mazur göstermez.

Sahiplikle karar verin, sonra vaat ettiğiniz arızayı test edin

Uzak hizmet bireysel iş yüklerini doğruladığında, bağlantıya yalnızca birkaç Deployment ihtiyaç duyduğunda ve arıza yerel kalması gerektiğinde Pod başına tüneli seçin. Bir ağ ekibi yolu zaten sahiplendiğinde, birçok iş yükü tek bir hedefi paylaştığında ve kararlı bir kaynak adresi tüm alıştırmanın amacı olduğunda ağ geçidini seçin.

Her durumda, satılan özelliği doğrulayın, kararlı durumu değil. Bir Pod oluşturun, hemen göndermesine izin verin ve vaat tünelden hiçbir şeyin kaçmaması idiyse ilk saniyeleri izleyin. Beş replikaya ölçekleyin ve vaat iş yükü başına kimlik idiyse uzak ucun bildirdiği oturumları sayın. Bu iki kontrol mekanizmanın sınırlarını manifest incelemesinden çok daha hızlı ortaya çıkarır ve bir sonraki olayın hangi ekibe ait olduğunu söyler.