VPN per Pod di Kubernetes versus gerbang egress: siapa pemilik terowongan?

Anda men-deploy Pod bernama vpn-gateway, mengarahkan klien uji ke alamatnya, dan melihat paket menghilang. Tidak ada yang salah di manifes dan kubelet tidak punya keluhan. Alasannya struktural, bukan konfigurasi: Kubernetes memberi setiap Pod ruang nama jaringannya sendiri, jadi nama, label, atau ruang nama API bersama tidak mengubah apa pun tentang ke mana paket pergi. Karena itu, memutuskan bagaimana lalu lintas VPN keluar dari klaster dimulai dengan pertanyaan tentang kepemilikan, bukan tentang image kontainer.

Dua mekanisme mencakup sebagian besar deployment nyata, dan keduanya tidak dapat dipertukarkan. Satu menempatkan terowongan di dalam ruang nama jaringan beban kerja itu sendiri. Yang lain meminta CNI mengarahkan lalu lintas terpilih melalui node gerbang yang ditunjuk. Keduanya gagal dengan cara berbeda, berskala berbeda, dan menjawab kepada tim berbeda, itulah sebabnya pertanyaan kontainer biasanya menghasilkan perdebatan yang tidak pernah selesai.

Batas Pod adalah ruang nama, bukan host lompatan

Ruang nama jaringan Linux memiliki antarmuka, alamat, rute, dan aturan firewall-nya sendiri, dan setiap Pod mendapatkannya. Kontainer di dalam Pod itu bergabung dengannya, dan itulah sebabnya kontainer pembantu dapat menulis ulang rute yang kemudian diikuti aplikasi. Pod tetangga memiliki tumpukan yang tampak identik tetapi sepenuhnya terpisah. Tidak ada tabel bersama yang dapat diwarisi Pod gerbang, dan tidak ada pengalihan lalu lintas secara implisit dari satu ruang nama ke ruang nama lain.

Itu juga sebabnya pola Pod gerbang hanya bekerja setelah sesuatu di hulu benar-benar mengirim paket ke sana: sebuah Service, rute statis pada node, atau kebijakan pengarahan di CNI. Alamat saja tidak menarik apa pun.

Apa yang dibeli terowongan per Pod, dan berapa biayanya

Terowongan yang berjalan di ruang nama beban kerja memberi beban kerja itu identitas kliennya sendiri, yang dibutuhkan banyak layanan akses jarak jauh sebelum mengizinkan atau menagih sesi. Radius dampaknya juga tetap lokal: terowongan rusak melumpuhkan satu Deployment alih-alih jalur bersama yang dipakai semuanya. Cara kerjanya bergantung pada implementasi, dan di sinilah orang salah menebak.

Penyiapan yang hanya membutuhkan status kernel dapat selesai di kontainer init lalu keluar. Daemon ruang pengguna yang harus tetap hidup selama masa hidup Pod membutuhkan bentuk kontainer init yang dapat dimulai ulang yang diperkenalkan sebagai sidecar asli di Kubernetes 1.29, dan perbedaan itu berasal dari implementasi terowongan, bukan dari selera. Biaya model ini adalah duplikasi: setiap replika mengautentikasi, menerima alamat terowongannya sendiri, dan memakai satu slot sesi jarak jauh, sehingga peristiwa autoscaling menjadi peristiwa kapasitas di sisi lain tautan. Menyalin satu kredensial ke semua replika tidak menghapus biaya itu, itu menghapus jejak audit. Kemampuan juga layak ditelaah sama, karena terowongan yang menginginkan NET_ADMIN di ruang namanya sendiri tidak punya alasan mewarisi otoritas seluruh host dari contoh privileged: true.

Saat CNI yang memiliki egress

Jika CNI mendukungnya, gerbang egress memilih lalu lintas berdasarkan beban kerja dan rentang tujuan, lalu mengirimnya melalui node terpilih di bawah satu alamat sumber yang dapat diprediksi. Versi Cilium adalah rujukan umum, dan dokumentasinya menegaskan bahwa fitur ini membutuhkan konfigurasi Cilium tertentu plus node gerbang yang disediakan dengan antarmuka dan alamat yang tepat. Dokumen itu juga mencatat periode awal setelah Pod dibuat ketika pengarahan belum ditegakkan, yang merupakan masukan desain, bukan catatan kaki.

Baca keterlambatan itu terhadap janji Anda sendiri. Jika aturannya bahwa tidak ada lalu lintas yang boleh keluar lewat jalur lain, Pod baru yang mengirim selama celah itu sudah melanggarnya, jadi urutan start-up perlu jawabannya sendiri: tahan aplikasi sampai kebijakan berlaku, atau terima jendela itu dan dokumentasikan.

Jaga klaimnya tetap sempit. Gerbang egress memilih dan menerjemahkan jalur. Ia tidak mengakhiri VPN, dan tidak menjadikan klaster sebagai klien jaringan jarak jauh Anda tanpa koneksi yang didukung di belakangnya.

Terjemahan diam-diam mengubah apa yang dilihat sisi jauh

Setelah gerbang menulis ulang sumber, alamat per Pod hilang, sehingga daftar izin yang berbasis identitas menjadi daftar izin yang berbasis satu alamat bersama. Itu pertukaran, bukan cacat: lebih sedikit aturan untuk dirawat, atribusi lebih kasar saat ada yang berperilaku buruk.

Autentikasi tingkat aplikasi dan pencatatan permintaan harus memikul apa yang tidak lagi dilaporkan jaringan. Perlakukan kapasitas dan penggantian gerbang sebagai infrastruktur bersama, karena reboot satu node kini mengganggu setiap beban kerja di belakangnya, dan periksa jalur balik lebih awal: ujung jauh harus tahu cara mencapai alamat yang diterjemahkan, biasanya melalui rute atau NAT yang harus dimiliki manusia, bukan manifes. Perencanaan alamat juga termasuk di sini, karena rentang klaster dan jarak jauh yang tumpang tindih merusak kedua model dan mengadopsi IPv6 tidak menjadi alasan untuk rencana yang bertentangan.

Putuskan berdasarkan kepemilikan, lalu uji kegagalan yang Anda janjikan

Pilih terowongan per Pod ketika layanan jarak jauh mengautentikasi beban kerja individual, ketika hanya beberapa Deployment membutuhkan tautan, dan ketika kegagalan harus tetap lokal. Pilih gerbang ketika tim jaringan sudah memiliki jalurnya, ketika banyak beban kerja berbagi satu tujuan, dan ketika alamat sumber yang stabil adalah seluruh maksud latihan ini.

Apa pun pilihannya, verifikasi properti yang Anda jual, bukan keadaan tunak. Buat Pod, biarkan mengirim segera, dan amati detik-detik pertama jika janjinya tidak ada yang lolos dari terowongan. Skalakan ke lima replika dan hitung sesi yang dilaporkan ujung jauh jika janjinya identitas per beban kerja. Dua pemeriksaan itu mengungkap batas mekanisme jauh lebih cepat daripada tinjauan manifes, dan memberi tahu tim mana yang memiliki insiden berikutnya.