Mengapa pod GKE tidak dapat mencapai hos setempat melalui VPN

Ping berfungsi dari nod dan gagal dari pod, dan tiada apa-apa sampai di premis. Terowong dan laluan baik; alamat sumber pada wayar tidak. Yang membezakan kedua-dua kes ini ialah apa yang paket dakwa dirinya apabila meninggalkan kluster, dan GKE mempunyai pendapat tentangnya. Mekanismenya ialah senarai pengecualian masquerade, dan membacanya memerlukan satu arahan.

Baca senarai berkuat kuasa sebelum mengubah apa-apa

GKE menyertakan ejen yang memutuskan, bagi setiap julat destinasi, sama ada trafik pod ditulis semula ke alamat nod semasa keluar. Konfigurasi bawaannya menamakan tiga blok RFC1918, 10.0.0.0/8, 172.16.0.0/12 dan 192.168.0.0/16, sebagai destinasi yang dikecualikan. Oleh itu apa-apa yang anda hantar dari pod ke hos 10.x setempat meninggalkan nod dengan alamat pod itu sendiri masih terlekat. Trafik nod itu sendiri tidak ditulis semula, dan itulah sebab pingnya berfungsi.

Baca konfigurasi yang dimaksudkan dan peraturan yang dipasang, kerana kedua-duanya mungkin tidak sepadan. kubectl -n kube-system get configmap ip-masq-agent -o yaml menunjukkan apa yang diberitahu kepada ejen, dan kubectl -n kube-system get pods -l k8s-app=ip-masq-agent menunjukkan sama ada ada sesuatu yang berjalan untuk melaksanakannya. Pada nod, iptables-save | grep -i masq menunjukkan peraturan yang benar-benar wujud dalam kernel. Apabila ConfigMap berkata satu perkara dan peraturan berkata lain, suspeknya ialah ejen, bukan rangkaian.

Sahkan alamat sumber dengan tangkapan

Buat tangkapan sebelum anda menukar senarai. Penapis pada satu destinasi mengekalkan output boleh dibaca: tcpdump -ni any host 10.20.30.40.

Bandingkan dengan apa yang dilaporkan oleh sebelah sana. Tangkapan di premis yang menunjukkan alamat pod dan tiada balasan menutup bulatan: senarai pengecualian menjelaskan asimetri tanpa sebarang kerosakan terowong. Dua pemerhatian satu alamat sumber cukup untuk berhenti meneka tentang CNI.

Sempitkan pengecualian kepada CIDR pod

Pembaikan yang disokong menyempitkan pengecualian dan bukannya membuangnya: kekalkan CIDR pod dikecualikan dan lepaskan baki ruang 10.x. Senarai itu tinggal dalam ConfigMap ejen di bawah nonMasqueradeCIDRs, dan menukarnya ialah suntingan diikuti pelancaran. Gantikan entri luas dengan julat pod sebenar kluster, kekalkan blok peribadi lain jika trafik dalam kluster masih memerlukannya, dan biarkan resyncInterval kecuali anda mempunyai sebab. Laksanakannya, sahkan pod ejen dimulakan semula, dan sahkan peraturan kernel berubah.

Ini perubahan seluruh kluster dengan jejari kesan yang sebenar. Selepas ia dilaksanakan, trafik yang dahulunya mengekalkan sumber pod kini tiba ditulis semula ke nod, jadi apa-apa yang bergantung pada alamat pod itu melihat penghantar yang berbeza. Mangsanya ialah log, senarai benaran dan peraturan firewall di premis yang menamakan alamat pod, dan semuanya gagal secara senyap. Umumkan perubahan ini sebagai perubahan tingkah laku, bukan pembaikan.

Pada kluster dengan beberapa kolam nod, periksa sama ada ejen dijadualkan pada nod tempat pod yang terjejas benar-benar berjalan. Kolam tanpa DaemonSet mengekalkan peraturan lamanya, dan tiada apa dalam ConfigMap akan menunjukkan perkara itu.

Alternatif dan kosnya

Pilihan lain membiarkan alamat pod utuh dan mengajar laluan tentangnya. CIDR pod masuk ke pemilih trafik Cloud VPN, dan sebelah premis memerlukan laluan balik untuknya supaya balasan tahu ke mana hendak pergi. Ini mengekalkan identiti pod, yang dikehendaki oleh sesetengah model keselamatan, dan meluaskan skop penghalaan serta skop firewall yang perlu diterima oleh sebelah sana.

Pertukarannya ialah kebolehan membaca berbanding skop. Penterjemahan membuat sebelah premis melihat satu alamat bagi setiap nod, yang mudah dimasukkan ke senarai benaran dan menyembunyikan pod mana yang menghantar apa. Tanpa penterjemahan, alamat pod dikekalkan dari hujung ke hujung, yang lebih baik untuk atribusi dan lebih buruk bagi setiap peranti di laluan yang perlu mempelajari julat baharu. Kedua-dua pilihan bukan kecacatan Docker atau CNI; kedua-duanya keputusan penghalaan dengan bil operasi. Pilih yang bilnya mampu dibayar oleh pasukan anda, dan tuliskan sebabnya.

Sahkan dan gulung balik

Jalankan tangkapan yang sama sekali lagi. Tangkapan pada peringkat nod yang masih mencetak alamat pod selepas suntingan anda bermakna peraturan tidak pernah berubah, apa pun kata ConfigMap. Wayar ialah fakta; yang lain hanyalah inferens.

Kemudian periksa arah sebaliknya, kerana separuh daripada perubahan ini hanya disahkan secara keluar. Sahkan balasan sampai ke nod atau pod yang menghantar permintaan, dan sahkan aplikasi selesai dan bukan sekadar menerima SYN. Tangkapan yang menunjukkan permintaan tanpa balasan ialah masalah penghalaan di sebelah sana, bukan masalah masquerade di sebelah sini.

Gulung balik ialah ConfigMap sebelumnya, dilaksanakan dengan cara yang sama, dengan pengesahan yang sama bahawa ejen dimulakan semula dan peraturan berubah. Simpan alamat sumber sebelum dan selepas untuk satu permintaan yang diketahui dalam rekod perubahan, kerana baris tunggal itulah yang membuktikan perubahan itu melakukan apa yang anda katakan. Panduan ejen masquerade IP GKE mendokumenkan nilai lalai dan medan ConfigMap. Jika alamat sumber tidak berubah selepas pelancaran, ejen tidak berjalan pada nod itu dan tiada penyuntingan YAML akan membaikinya.