Mengapa pod GKE tidak dapat menjangkau host lokal melalui VPN

Ping berhasil dari node dan gagal dari pod, dan tidak ada yang sampai di jaringan lokal. Tunnel dan rutenya baik-baik saja; alamat sumber di kabel tidak. Yang membedakan kedua kasus itu adalah klaim paket tentang dirinya saat meninggalkan kluster, dan GKE punya pendapat soal itu. Mekanismenya adalah daftar pengecualian masquerade, dan membacanya hanya perlu satu perintah.

Baca daftar yang berlaku sebelum mengubah apa pun

GKE menyertakan agen yang memutuskan, per rentang tujuan, apakah lalu lintas pod ditulis ulang ke alamat node saat keluar. Konfigurasi bawaannya menyebut tiga blok RFC1918, 10.0.0.0/8, 172.16.0.0/12 dan 192.168.0.0/16, sebagai tujuan yang dikecualikan. Karena itu, apa pun yang Anda kirim dari pod ke host 10.x lokal meninggalkan node dengan alamat pod itu sendiri masih menempel. Lalu lintas node sendiri tidak ditulis ulang, dan itulah tepatnya sebab ping-nya berhasil.

Baca konfigurasi yang dimaksudkan dan aturan yang terpasang, karena keduanya bisa tidak sepakat. kubectl -n kube-system get configmap ip-masq-agent -o yaml menunjukkan apa yang dikatakan kepada agen, dan kubectl -n kube-system get pods -l k8s-app=ip-masq-agent menunjukkan apakah ada yang berjalan untuk menerapkannya. Di node, iptables-save | grep -i masq menunjukkan aturan yang benar-benar ada di kernel. Ketika ConfigMap mengatakan satu hal dan aturan mengatakan hal lain, tersangkanya adalah agen, bukan jaringan.

Konfirmasi alamat sumber dengan tangkapan

Lakukan tangkapan sebelum Anda mengubah daftar. Filter pada satu tujuan menjaga keluaran tetap terbaca: tcpdump -ni any host 10.20.30.40.

Bandingkan itu dengan apa yang dilaporkan sisi jauh. Tangkapan di jaringan lokal yang menunjukkan alamat pod dan tidak ada balasan menutup lingkarannya: daftar pengecualian menjelaskan asimetri tanpa kesalahan tunnel apa pun. Dua pengamatan atas satu alamat sumber cukup untuk berhenti menebak tentang CNI.

Persempit pengecualian ke CIDR pod

Perbaikan yang didukung mempersempit pengecualian alih-alih menghapusnya: pertahankan CIDR pod tetap dikecualikan dan lepaskan sisa ruang 10.x. Daftar itu berada di ConfigMap agen di bawah nonMasqueradeCIDRs, dan mengubahnya adalah suntingan yang diikuti peluncuran. Ganti entri lebar dengan rentang pod sebenarnya milik kluster, pertahankan blok privat lain jika lalu lintas di dalam kluster masih membutuhkannya, dan biarkan resyncInterval apa adanya kecuali Anda punya alasan. Terapkan, pastikan pod agen sudah dimulai ulang, dan pastikan aturan kernel berubah.

Ini perubahan seluruh kluster dengan radius dampak nyata. Setelah berlaku, lalu lintas yang tadinya mempertahankan sumber pod kini tiba ditulis ulang ke node, sehingga apa pun yang bergantung pada alamat pod itu melihat pengirim yang berbeda. Korbannya adalah log, daftar izin, dan aturan firewall lokal yang menyebut alamat pod, dan semuanya gagal secara diam-diam. Umumkan perubahan ini sebagai perubahan perilaku, bukan sebagai perbaikan.

Pada kluster dengan beberapa pool node, periksa apakah agen dijadwalkan pada node tempat pod yang terdampak benar-benar berjalan. Pool tanpa DaemonSet mempertahankan aturan lamanya, dan tidak ada yang di ConfigMap akan menunjukkan itu.

Alternatif dan biayanya

Opsi lain membiarkan alamat pod utuh dan mengajarkan jalurnya tentang alamat itu. CIDR pod masuk ke pemilih lalu lintas Cloud VPN, dan sisi lokal memerlukan rute balik untuknya agar balasan tahu ke mana harus pergi. Itu mempertahankan identitas pod, yang diinginkan beberapa model keamanan, dan memperluas cakupan perutean sekaligus cakupan firewall yang harus diterima sisi jauh.

Pertukarannya adalah keterbacaan melawan cakupan. Penerjemahan membuat sisi lokal melihat satu alamat per node, yang mudah dimasukkan ke daftar izin dan menyembunyikan pod mana yang mengirim apa. Tanpa penerjemahan, alamat pod dipertahankan dari ujung ke ujung, yang lebih baik untuk atribusi dan lebih buruk bagi setiap perangkat di jalur yang harus mempelajari rentang baru. Tidak ada opsi yang merupakan cacat Docker atau CNI; keduanya keputusan perutean dengan tagihan operasional. Pilih yang tagihannya bisa dibayar tim Anda, dan tuliskan alasannya.

Verifikasi dan kembalikan

Jalankan tangkapan yang sama lagi. Tangkapan di tingkat node yang masih mencetak alamat pod setelah suntingan Anda berarti aturannya tidak pernah berubah, apa pun kata ConfigMap. Kabel adalah faktanya; sisanya adalah simpulan.

Lalu periksa arah sebaliknya, karena separuh perubahan ini hanya diverifikasi untuk arah keluar. Pastikan balasan sampai ke node atau pod yang mengirim permintaan, dan pastikan aplikasinya selesai, bukan sekadar menerima SYN. Tangkapan yang menunjukkan permintaan tanpa balasan adalah masalah perutean di sisi jauh, bukan masalah masquerade di sisi ini.

Mengembalikan berarti ConfigMap sebelumnya, diterapkan dengan cara yang sama, dengan konfirmasi yang sama bahwa agen dimulai ulang dan aturannya berubah. Simpan alamat sumber sebelum dan sesudah untuk satu permintaan yang diketahui di catatan perubahan, karena satu baris itulah yang membuktikan perubahan melakukan apa yang Anda katakan. Panduan agen masquerade IP GKE mendokumentasikan nilai bawaan dan bidang ConfigMap. Jika alamat sumber tidak berubah setelah peluncuran, agen tidak berjalan di node itu dan tidak ada penyuntingan YAML yang akan memperbaikinya.