Sidecar VPN memerlukan peraturan mula dan peraturan gagal

Satu pod memulakan bekas terowong sebelum aplikasi dan permintaan pertama berjaya, dan itulah tepat kes yang menyembunyikan masalah. Urutan membaiki satu perlumbaan dan tidak berkata apa-apa tentang trafik yang aplikasi mulakan empat jam kemudian, selepas terowong gagal. Itu dua keputusan berasingan. Biasanya hanya satu direka bentuk.

Urutan hanya menyekat permintaan pertama

Kubernetes menyokong kitaran hayat sidecar yang dibina daripada bekas init yang boleh dimulakan semula. Dalam model itu, probe permulaan boleh menahan langkah permulaan seterusnya sehingga terowong melaporkan kesediaan. Itu peningkatan sebenar, dan ia wajar digunakan secara sengaja bukannya menambah sleep pada skrip titik masuk. Gerbang hanya sebaik keadaan yang diujinya.

Di luar model itu, semantik urutan tergolong dalam runtime atau sistem kebergantungan yang anda gunakan, dan ia tidak semestinya sepadan. Penggunaan yang disalin dari platform lain mungkin kelihatan menunggu terowong kerana aplikasi kebetulan bermula perlahan. Itu bukan jaminan yang sama, dan ia gagal di bawah beban.

Nyatakan apa yang diperhatikan gerbang: proses wujud, antara muka wujud, handshake selesai. Setiap satu adalah dakwaan yang lebih lemah daripada “laluan data ke destinasi yang diperlukan pod ini berfungsi”.

Kuatkuasakan laluan data dan bukan menganggapnya

Probe ialah pemeriksaan pada satu saat dan firewall ialah sifat yang terpakai antara saat. Jika keperluannya ialah trafik aplikasi tidak pernah keluar di luar terowong, ia mesti dinyatakan dalam ruang nama rangkaian kongsi sebagai peraturan terima-atau-buang. Urutan mula bekas tidak boleh membawa keperluan itu. Hanya peraturan boleh.

Bekas dalam satu pod berkongsi ruang nama itu, jadi titik penguatkuasaan ialah ruang nama itu sendiri. Apa pun yang anda tulis, ia mesti membiarkan sambungan luar terowong itu sendiri tersedia, kerana menyekatnya untuk melindungi aplikasi memotong laluan yang diperlukan aplikasi.

Tentukan dasar kegagalan secara eksplisit: patutkah trafik aplikasi berhenti sepenuhnya apabila terowong tidak sihat, atau terus berjalan dan ditanda sebagai tidak dilindungi? Kedua-duanya boleh dipertahankan, dan tiada satu pun ialah apa yang anda dapat dengan memulakan bekas dalam urutan tertentu.

Uji trafik yang anda tidak nyatakan

Ambil permintaan baharu semasa kegagalan terowong terkawal dan lihat sama ada ia keluar. Kemudian ulangi pemeriksaan untuk laluan yang tidak pernah disentuh ujian alamat keluar: penyelesaian DNS di dalam kluster, destinasi IPv6, dan perkhidmatan yang dicapai melalui alamat dalaman kluster dan bukan internet awam. Itulah laluan yang terus berfungsi secara senyap selepas terowong mati.

Halaman alamat keluar membuktikan bahawa satu permintaan pergi ke tempat yang anda jangkakan pada saat itu. Ia tidak boleh menyenaraikan laluan lain, dan jurang antara apa yang anda uji dan apa yang pod boleh capai ialah tempat kegagalan yang menarik tinggal.

Ulangi ujian selepas sidecar dimulakan semula dan bukan hanya selepas permulaan bersih. Bekas terowong yang dimulakan semula boleh meninggalkan ruang nama dengan laluan dan dasar dalam keadaan pertengahan.

Tulis rekod penggunaan

Tiga fakta tergolong dalam nota penggunaan: ujian kesediaan dan apa yang diperhatikannya, tindakan pemulihan apabila ujian itu gagal, dan peraturan penguatkuasaan yang mengawal keluar. Dokumentasi bekas sidecar merangkumi mekanik kitaran hayat dan menyerahkan keputusan dasar itu kepada anda. Pembahagian itu betul, dan itulah juga sebabnya dasar itu biasanya tiada.

Pemeriksaan kesihatan yang disalah anggap sebagai perlindungan ialah jenis penunjuk hijau yang paling mahal, kerana ia menghentikan orang daripada bertanya. Menamakannya dengan tepat dalam dokumentasi berharga satu ayat dan menghalangnya.

Akhir sekali, uji laluan pemulihan sekali dengan aplikasi berjalan. Reka bentuk yang memerlukan pod dicipta semula untuk memulihkan keluar ialah keputusan, dan ia sepatutnya keputusan yang anda buat, bukan yang anda temui.