Sidecar VPN butuh aturan mulai dan aturan gagal

Sebuah pod menjalankan kontainer terowongan sebelum aplikasi dan permintaan pertama berhasil, dan itulah tepat kasus yang menyembunyikan masalah. Urutan memperbaiki satu balapan dan tidak mengatakan apa pun tentang lalu lintas yang aplikasi mulai empat jam kemudian, setelah terowongan gagal. Itu dua keputusan terpisah. Biasanya hanya satu yang dirancang.

Urutan hanya menahan permintaan pertama

Kubernetes mendukung siklus hidup sidecar yang dibangun dari kontainer init yang dapat dimulai ulang. Dalam model itu, probe awal dapat menahan langkah inisialisasi berikutnya sampai terowongan melaporkan siap. Itu peningkatan nyata, dan layak dipakai dengan sengaja alih-alih menambahkan sleep ke skrip titik masuk. Gerbang hanya sebaik kondisi yang diujinya.

Di luar model itu, semantik urutan milik runtime atau sistem dependensi apa pun yang Anda pakai, dan keduanya tidak harus sama. Penerapan yang disalin dari platform lain dapat terlihat menunggu terowongan karena aplikasi kebetulan mulai lambat. Itu bukan jaminan yang sama, dan gagal di bawah beban.

Sebutkan apa yang diamati gerbang: ada proses, ada antarmuka, handshake selesai. Masing-masing klaim yang lebih lemah daripada “jalur data ke tujuan yang dibutuhkan pod ini berfungsi”.

Tegakkan jalur data alih-alih menganggapnya

Probe adalah pemeriksaan pada satu saat dan firewall adalah sifat yang berlaku di antara saat-saat. Jika persyaratannya adalah lalu lintas aplikasi tidak pernah keluar dari terowongan, itu harus dinyatakan di ruang nama jaringan bersama sebagai aturan terima-atau-buang. Urutan mulai kontainer tidak dapat membawa persyaratan itu. Hanya aturan yang bisa.

Kontainer dalam satu pod berbagi ruang nama itu, jadi titik penegakannya adalah ruang nama itu sendiri. Apa pun yang Anda tulis, itu harus membiarkan koneksi luar terowongan itu sendiri tetap tersedia, karena memblokirnya untuk melindungi aplikasi memotong jalur yang dibutuhkan aplikasi.

Putuskan kebijakan kegagalan secara eksplisit: haruskah lalu lintas aplikasi berhenti sepenuhnya saat terowongan tidak sehat, atau berlanjut dan ditandai sebagai tidak terlindungi? Keduanya dapat dipertahankan, dan tidak satu pun adalah yang Anda dapatkan dengan menjalankan kontainer dalam urutan tertentu.

Uji lalu lintas yang tidak Anda sebutkan

Ambil permintaan baru selama kegagalan terowongan yang terkendali dan lihat apakah ia keluar. Lalu ulangi pemeriksaan untuk jalur yang tidak pernah disentuh uji alamat keluar: resolusi DNS di dalam klaster, tujuan IPv6, dan layanan yang dijangkau melalui alamat internal klaster alih-alih internet publik. Itulah jalur yang diam-diam terus bekerja setelah terowongan mati.

Halaman alamat keluar membuktikan bahwa satu permintaan pergi ke tempat yang Anda harapkan pada saat itu. Halaman itu tidak dapat menginventarisasi jalur lain, dan celah antara apa yang Anda uji dan apa yang dapat dijangkau pod adalah tempat kegagalan yang menarik hidup.

Ulangi uji setelah sidecar dimulai ulang, bukan hanya setelah mulai bersih. Kontainer terowongan yang dimulai ulang dapat meninggalkan ruang nama dengan rute dan kebijakan dalam keadaan peralihan.

Tulis catatan penerapan

Tiga fakta termasuk dalam catatan penerapan: uji kesiapan dan apa yang diamatinya, tindakan pemulihan saat uji itu gagal, dan aturan penegakan yang mengatur egress. Dokumentasi kontainer sidecar mencakup mekanika siklus hidup dan menyerahkan keputusan kebijakan itu kepada Anda. Pembagian itu benar, dan itulah juga sebabnya kebijakan biasanya hilang.

Pemeriksaan kesehatan yang disalahartikan sebagai perlindungan adalah indikator hijau termahal, karena menghentikan orang bertanya. Menamainya dengan akurat dalam dokumentasi berbiaya satu kalimat dan mencegahnya.

Terakhir, uji jalur pemulihan sekali dengan aplikasi berjalan. Desain yang mengharuskan pod dibuat ulang untuk memulihkan egress adalah keputusan, dan seharusnya itu keputusan yang Anda ambil, bukan yang Anda temukan.