GKE pod'ları VPN üzerinden yerel ana bilgisayarlara neden ulaşamıyor

Ping düğümden çalışıyor, pod'dan başarısız oluyor ve yerel tarafa hiçbir şey ulaşmıyor. Tünel ve yol doğru; kablodaki kaynak adresi değil. Bu iki durumu ayıran şey, paketin kümeden çıkarken kendini ne olarak beyan ettiğidir ve GKE'nin bu konuda bir görüşü var. Mekanizma bir masquerade istisna listesidir ve onu okumak tek komut alır.

Bir şeyi değiştirmeden önce yürürlükteki listeyi okuyun

GKE, her hedef aralığı için pod trafiğinin çıkışta düğüm adresine yeniden yazılıp yazılmayacağına karar veren bir ajan sağlar. Sağlanan yapılandırması, üç RFC1918 bloğunu, 10.0.0.0/8, 172.16.0.0/12 ve 192.168.0.0/16, istisna tutulan hedefler olarak adlandırır. Bu yüzden bir pod'dan yerel bir 10.x ana bilgisayara gönderdiğiniz her şey, pod'un kendi adresi hâlâ üzerindeyken düğümden çıkar. Düğümün kendi trafiği yeniden yazılmaz ve ping'inin çalışmasının nedeni tam olarak budur.

Amaçlanan yapılandırmayı ve kurulu kuralları okuyun, çünkü uyuşmayabilirler. kubectl -n kube-system get configmap ip-masq-agent -o yaml ajana ne söylendiğini gösterir, kubectl -n kube-system get pods -l k8s-app=ip-masq-agent bunu uygulamak için bir şeyin çalışıp çalışmadığını gösterir. Bir düğümde iptables-save | grep -i masq çekirdekte gerçekten var olan kuralları gösterir. ConfigMap birini söylerken kurallar diğerini söylüyorsa şüpheli ağ değil, ajandır.

Kaynak adresini bir yakalamayla doğrulayın

Bir listeyi değiştirmeden önce yakalama yapın. Tek hedefe uygulanan filtre çıktıyı okunabilir tutar: tcpdump -ni any host 10.20.30.40.

Bunu karşı tarafın bildirdikleriyle karşılaştırın. Yerel tarafta pod adresini gösteren ve yanıt olmayan bir yakalama döngüyü kapatır: istisna listesi asimetriyi herhangi bir tünel arızası olmadan açıklar. Tek bir kaynak adresinin iki gözlemi, CNI hakkında tahmin yürütmeyi bırakmak için yeterlidir.

İstisnayı pod CIDR'sine daraltın

Desteklenen onarım istisnayı kaldırmak yerine daraltır: pod CIDR'sini istisna tutun ve 10.x alanının geri kalanını bırakın. Bu liste ajanın ConfigMap'inde nonMasqueradeCIDRs altında bulunur ve değiştirmek bir düzenleme ve ardından bir dağıtımdır. Geniş girdiyi kümenin gerçek pod aralığıyla değiştirin, küme içi trafik hâlâ ihtiyaç duyuyorsa diğer özel blokları koruyun ve bir nedeniniz yoksa resyncInterval öğesine dokunmayın. Uygulayın, ajanın pod'larının yeniden başladığını ve çekirdek kurallarının değiştiğini doğrulayın.

Bu, gerçek bir etki yarıçapına sahip küme genelinde bir değişikliktir. Yürürlüğe girdikten sonra, önceden pod kaynağını koruyan trafik artık düğüme yeniden yazılmış olarak gelir, böylece o pod adreslerine bağlı olan her şey farklı bir gönderen görür. Kurbanlar, pod adreslerini adlandıran günlükler, izin listeleri ve yerel güvenlik duvarı kurallarıdır ve sessizce başarısız olurlar. Değişikliği bir düzeltme olarak değil, davranış değişikliği olarak duyurun.

Birden çok düğüm havuzu olan bir kümede, ajanın etkilenen pod'ların gerçekten çalıştığı düğümlere zamanlandığını kontrol edin. DaemonSet'i olmayan bir havuz eski kurallarını korur ve ConfigMap'te hiçbir şey bunu göstermez.

Alternatif ve maliyeti

Diğer seçenek pod adreslerini bozulmadan bırakır ve yola onları öğretir. Pod CIDR'si Cloud VPN trafik seçicilerine girer ve yerel tarafın yanıtların nereye gideceğini bilmesi için ona bir dönüş yolu gerekir. Bu, bazı güvenlik modellerinin istediği pod kimliğini korur ve karşı tarafın kabul etmesi gereken hem yönlendirme hem de güvenlik duvarı kapsamını genişletir.

Takas, okunabilirlik ile kapsam arasındadır. Çeviri, yerel tarafın düğüm başına tek adres görmesini sağlar; bu izin listesine eklemek kolaydır ve hangi pod'un ne gönderdiğini gizler. Çeviri olmadığında pod adresi uçtan uca korunur; bu atıf için daha iyi, yeni bir aralığı öğrenmesi gereken yoldaki her cihaz için daha kötüdür. Hiçbir seçenek Docker veya CNI kusuru değildir; ikisi de operasyonel faturası olan yönlendirme kararlarıdır. Ekibinizin ödeyebileceği faturaya sahip olanı seçin ve nedenini yazın.

Doğrulayın ve geri alın

Aynı yakalamayı tekrar çalıştırın. Düzenlemenizden sonra düğüm düzeyindeki yakalama hâlâ pod adresini yazdırıyorsa, ConfigMap ne derse desin kurallar hiç değişmemiştir. Kablo gerçektir; geri kalan her şey çıkarımdır.

Sonra ters yönü kontrol edin, çünkü bu değişikliklerin yarısı yalnızca giden yönde doğrulanır. Yanıtın isteği gönderen düğüme veya pod'a ulaştığını ve uygulamanın yalnızca SYN almakla kalmayıp tamamlandığını doğrulayın. Yanıtsız bir istek gösteren yakalama, karşı taraftaki bir yönlendirme sorunudur; bu taraftaki bir masquerade sorunu değildir.

Geri alma, önceki ConfigMap'in aynı şekilde uygulanmasıdır; ajanın yeniden başladığına ve kuralların değiştiğine dair aynı doğrulamayla. Değişiklik kaydında bilinen bir istek için önceki ve sonraki kaynak adresini saklayın, çünkü değişikliğin söylediğinizi yaptığını kanıtlayan tam olarak o tek satırdır. GKE IP masquerade ajan kılavuzu varsayılanları ve ConfigMap alanlarını belgeler. Dağıtımdan sonra kaynak adresi değişmediyse ajan o düğümde çalışmıyordur ve hiçbir YAML düzenlemesi bunu düzeltmez.