VPN setiap Pod dalam Kubernetes lawan gerbang keluar: siapa pemilik terowong?

Anda menggunakan Pod bernama vpn-gateway, halakan klien ujian ke alamatnya dan lihat paket lenyap. Tiada apa yang salah dalam manifes dan kubelet tiada aduan. Puncanya struktur, bukan konfigurasi: Kubernetes memberikan setiap Pod ruang nama rangkaiannya sendiri, jadi nama, label atau ruang nama API dikongsi tidak mengubah ke mana paket pergi. Oleh itu keputusan tentang bagaimana trafik VPN keluar dari kluster bermula dengan soalan tentang pemilikan, bukan tentang imej kontena.

Dua mekanisme meliputi kebanyakan penggunaan sebenar, dan kedua-duanya tidak boleh ditukar ganti. Satu meletakkan terowong dalam ruang nama rangkaian beban kerja itu sendiri. Yang lain meminta CNI mengarahkan trafik terpilih melalui nod gerbang yang ditetapkan. Kedua-duanya gagal secara berbeza, berskala secara berbeza dan menjawab kepada pasukan berbeza, sebab itulah soalan kontena biasanya menghasilkan perdebatan yang tidak pernah selesai.

Sempadan Pod ialah ruang nama, bukan hos lompatan

Ruang nama rangkaian Linux memiliki antara muka, alamat, laluan dan peraturan firewallnya sendiri, dan setiap Pod menerima satu. Kontena dalam Pod itu menyertainya, dan itulah sebabnya kontena pembantu boleh menulis semula laluan yang kemudian diikuti aplikasi. Pod jiran mempunyai tindanan yang kelihatan serupa tetapi berasingan sepenuhnya. Tiada jadual dikongsi untuk diwarisi Pod gerbang, dan tiada penyerahan trafik secara tersirat dari satu ruang nama ke ruang nama lain.

Itulah sebabnya corak Pod gerbang hanya berfungsi apabila sesuatu di hulu benar-benar menghantar paket kepadanya: Service, laluan statik pada nod atau dasar pengarahan dalam CNI. Alamat sahaja tidak menarik apa-apa.

Apa yang dibeli terowong setiap Pod, dan apa kosnya

Terowong yang berjalan dalam ruang nama beban kerja memberikan beban kerja itu identiti kliennya sendiri, yang dituntut banyak perkhidmatan akses jauh sebelum membenarkan atau mengira sesi. Jejari kesan juga kekal setempat: terowong rosak mematikan satu Deployment dan bukannya laluan dikongsi yang digunakan semua. Cara ia berjalan bergantung pada pelaksanaan, dan di sinilah orang meneka dengan salah.

Persediaan yang hanya memerlukan keadaan kernel boleh selesai dalam kontena init dan keluar. Daemon ruang pengguna yang mesti kekal hidup sepanjang hayat Pod memerlukan bentuk kontena init boleh mula semula yang diperkenalkan sebagai sidecar asli dalam Kubernetes 1.29, dan perbezaan itu datang daripada pelaksanaan terowong dan bukan daripada citarasa. Kos model ini ialah pertindihan: setiap replika mengesahkan, menerima alamat terowongnya sendiri dan menggunakan satu slot sesi jauh, jadi peristiwa penskalaan automatik menjadi peristiwa kapasiti di sisi lain pautan. Menyalin satu kelayakan ke semua replika tidak menghapuskan kos itu, ia menghapuskan jejak audit. Keupayaan juga wajar dinilai sama, kerana terowong yang mahukan NET_ADMIN dalam ruang namanya sendiri tiada sebab mewarisi kuasa seluruh hos daripada contoh dengan privileged: true.

Apabila CNI memiliki keluar

Jika CNI menyokongnya, gerbang keluar memilih trafik mengikut beban kerja dan julat destinasi, kemudian menghantarnya melalui nod terpilih di bawah satu alamat sumber yang boleh diramal. Versi Cilium ialah rujukan biasa, dan dokumentasinya menyatakan dengan jelas bahawa ciri itu memerlukan konfigurasi Cilium tertentu serta nod gerbang yang dilengkapi antara muka dan alamat yang betul. Ia juga menyebut tempoh awal selepas Pod dicipta apabila pengarahan belum dikuatkuasakan, yang merupakan input reka bentuk dan bukan nota kaki.

Baca kelewatan itu terhadap janji anda sendiri. Jika peraturannya tiada trafik boleh keluar melalui laluan lain, Pod baharu yang menghantar semasa jurang itu sudah melanggarnya, jadi urutan permulaan memerlukan jawapannya sendiri: tahan aplikasi sehingga dasar terpakai, atau terima tetingkap itu dan dokumentasikannya.

Kekalkan dakwaan itu sempit. Gerbang keluar memilih dan menterjemah laluan. Ia tidak menamatkan VPN, dan ia tidak menjadikan kluster sebagai klien rangkaian jauh anda tanpa sambungan yang disokong di belakangnya.

Penterjemahan secara senyap mengubah apa yang dilihat oleh sisi jauh

Sebaik sahaja gerbang menulis semula sumber, alamat setiap Pod hilang, jadi senarai kebenaran yang berasaskan identiti menjadi senarai berasaskan satu alamat dikongsi. Ini pertukaran dan bukan kecacatan: lebih sedikit peraturan untuk dijaga, atribusi lebih kasar apabila sesuatu berkelakuan buruk.

Pengesahan peringkat aplikasi dan log permintaan mesti memikul apa yang tidak lagi dilaporkan oleh rangkaian. Anggap kapasiti dan penggantian gerbang sebagai infrastruktur dikongsi, kerana but semula satu nod kini mengganggu setiap beban kerja di belakangnya, dan periksa laluan balik lebih awal: hujung jauh mesti tahu cara mencapai alamat terjemahan, biasanya melalui laluan atau NAT yang perlu dimiliki oleh manusia, bukan manifes. Perancangan alamat juga termasuk di sini, kerana julat kluster dan jauh yang bertindih merosakkan kedua-dua model dan penggunaan IPv6 tidak memaafkan pelan yang bercanggah.

Putuskan mengikut pemilikan, kemudian uji kegagalan yang anda janjikan

Pilih terowong setiap Pod apabila perkhidmatan jauh mengesahkan beban kerja individu, apabila hanya beberapa Deployment memerlukan pautan itu, dan apabila kegagalan harus kekal setempat. Pilih gerbang apabila pasukan rangkaian sudah memiliki laluan, apabila banyak beban kerja berkongsi satu destinasi, dan apabila alamat sumber yang stabil ialah seluruh tujuan latihan ini.

Apa pun pilihannya, sahkan sifat yang anda jual dan bukan keadaan mantap. Cipta Pod, biarkan ia menghantar serta-merta dan perhatikan saat-saat pertama jika janjinya tiada apa yang terlepas dari terowong. Skalakan kepada lima replika dan kira sesi yang dilaporkan hujung jauh jika janjinya identiti setiap beban kerja. Kedua-dua pemeriksaan itu mendedahkan had mekanisme jauh lebih cepat daripada semakan manifes, dan ia memberitahu pasukan mana yang memiliki insiden seterusnya.