Pod, nod atau kluster: apa yang sebenarnya dialih semula oleh sidecar VPN

Sidecar VPN dalam Pod Kubernetes kelihatan seperti VPN peringkat hos dengan tatasusila yang lebih baik, dan persamaannya berhenti di sempadan ruang nama. Kontena dalam satu Pod berkongsi ruang nama rangkaian, termasuk ruang alamat dan port, jadi sidecar yang memasang laluan dan dasar benar-benar mengubah ke mana paket aplikasi pergi. Ia tidak mengubah apa-apa bagi Pod lain pada nod itu, dan ia tidak menyentuh tindanan nod itu sendiri melainkan anda mengkonfigurasinya begitu. Memahami sempadan itu dengan betul menentukan apa yang boleh anda gunakan dan apa yang mesti anda uji. Bahagian di bawah mengikutinya dari ruang nama ke luar.

Ruang nama dikongsi, akibat dikongsi

Dua kontena dalam satu Pod bercakap melalui loopback dan melihat antara muka yang sama, dan itulah sebabnya corak sidecar berfungsi sama sekali: aplikasi tidak perlu tahu terowong wujud, kerana laluan yang diselesaikannya dipasang dalam ruang nama yang digunakannya. Sifat yang sama bermakna kesilapan sidecar ialah kesilapan aplikasi. Laluan yang menangkap terlalu banyak, atau perubahan DNS yang menunjuk kepada penyelesai di dalam terowong, terpakai serta-merta kepada setiap proses dalam Pod itu. Dalam ruang nama dikongsi tiada penghalaan mengikut kontena, jadi sidecar tidak boleh dihadkan kepada satu proses.

Inilah mekanisme yang perlu diingati semasa semakan: jejari kesan ialah Pod, bukan nod dan bukan kluster.

Apa yang tidak dicapai oleh sidecar

Pod lain mengekalkan ruang nama dan penghalaan mereka sendiri, jadi beban kerja yang memerlukan keluar yang sama memerlukan sidecar yang sama atau, sebaliknya, reka bentuk peringkat nod. Trafik nod juga berada di luar ruang nama Pod, dan Pod dengan rangkaian hos sengaja menarik diri sepenuhnya daripada pengasingan ini. Jika anda menjalankan sidecar dengan rangkaian hos untuk mencapai sesuatu yang mudah, anda telah meluaskan skop daripada satu Pod kepada seluruh nod dan patut menyatakannya dengan kuat.

Trafik ke perkhidmatan kluster ialah kejutan biasa yang lain. Laluan lalai yang lebar di dalam Pod boleh menangkap permintaan yang ditujukan kepada pelayan API atau perkhidmatan ClusterIP, yang kemudian gagal dengan cara yang kelihatan seperti terowong rosak.

Pelan laluan: julat Pod, perkhidmatan, nod dan VPN

Tuliskan keempat-empat julat dan periksa pertindihannya sebelum menggunakan apa-apa: CIDR Pod, CIDR perkhidmatan, alamat nod dan destinasi di belakang VPN. Pertindihan antara julat peribadi VPN dan ruang kluster itu sendiri tidak jarang, dan laluan lalai ialah penyelesaian yang salah untuknya. Pelan laluan tergolong dalam repositori yang sama dengan manifes, kerana kluster seterusnya mungkin memberikan julat Pod dan perkhidmatan yang sama sekali berbeza.

DNS ialah sebahagian daripada pelan dan bukan kebimbangan berasingan. Sidecar yang menulis semula konfigurasi penyelesai boleh merosakkan penemuan perkhidmatan di dalam kluster sambil menjadikan carian luaran berfungsi dengan sempurna.

Permulaan dan kegagalan ialah keadaan eksplisit

Proses sidecar yang berjalan bukanlah dasar keluar. Tentukan trafik apa yang boleh mengalir sebelum terowong sedia dan apa yang berlaku jika ia mati selepas itu, kemudian laksanakan keputusan itu: prob yang menggetkan kontena aplikasi, dasar rangkaian yang menolak secara lalai, atau kedua-duanya. Tanpa salah satunya, aplikasi bermula, menyelesaikan nama dan menghantar trafik keluar dari laluan biasa nod semasa terowong masih menyambung.

Jurang itu singkat dalam kluster sihat dan kekal dalam kluster rosak, dan itulah tepat sifat yang digemari penyerang atau kebocoran data tidak sengaja.

Pasangkan susunan dengan ujian kegagalan. Bunuh sidecar dan sahkan aplikasi kehilangan keluar yang dimaksudkan dan bukannya berundur secara senyap.

Keupayaan, dasar dan ujian dari kontena aplikasi

Memberikan keupayaan yang diperlukan untuk mencipta antara muka dan mengubah laluan ialah keputusan keistimewaan, dan keistimewaan yang sesuai untuk Pod terasing tidak semestinya sesuai pada tindanan nod. Gunakan mekanisme dasar rangkaian dan keselamatan yang disokong kluster, dan jangan andaikan setiap pelaksanaan CNI atau dasar memperlakukan antara muka VPN dengan cara yang sama; perbezaannya muncul tepat dalam kes kegagalan yang anda pedulikan.

Uji dari kontena aplikasi sebenar, dengan permintaan baharu ke destinasi peribadi, perkhidmatan kluster dan internet awam. Ujian dari sidecar membuktikan terowong berfungsi, bukan bahawa aplikasi mencapai apa yang diperlukannya.

Dokumenkan andaian rangkaian kluster di sebelah konfigurasi VPN. Memindahkan beban kerja ke kluster lain kemudiannya menjadi latihan memeriksa pelan laluan dan bukannya perubahan imej yang senyap berhenti berfungsi.