Pod GKE kehilangan akses VPN setelah 1.14: dua cara memperbaiki sumbernya

Sebuah pembaruan tiba, dan sistem di seberang terowongan mulai menolak lalu lintas pod yang berfungsi pekan sebelumnya. Terowongan aktif, aturan firewall tidak tersentuh, dan tak ada yang menyunting kebijakan peer. Yang berubah tak terlihat di log klaster: alamat sumber yang kini dilihat sistem itu. Kesenjangan itu menjelaskan kegagalan yang tampak seperti gangguan jaringan dan berperilaku seperti masalah izin.

Ada dua jawaban sah, dan keduanya membawa Anda ke tempat berbeda. Pilih kontrak sumber sebelum menyunting ConfigMap.

Aturan bawaan yang berhenti dipasang

Rilis GKE sebelumnya memasang aturan masquerade yang mengganti sumber pod dengan alamat node setiap kali tujuan berada di luar 10.0.0.0/8. Gateway VPN di dalam rentang itu melihat alamat pod, sementara apa pun yang lebih jauh tampak berasal dari node. Peer membangun daftar izin dan rute balik di sekitar alamat node karena itulah yang mereka amati.

Rilis berikutnya berhenti memasang aturan bawaan itu. Lalu lintas pod kini tiba di gateway dengan alamat pod, apa pun tujuannya. Peer yang hanya merutekan alamat node membuang balasan, dan tak ada pihak yang menulis entri log berguna. Permintaan bahkan bisa berhasil di ujung jauh, dan itulah yang membuat kegagalan ini membingungkan untuk dilacak.

Tidak ada yang rusak dalam arti komponen mati. Kedua pihak hanya tidak sepakat soal sumber mana yang sah.

Pilih sumber yang seharusnya dilihat peer

Mempertahankan alamat pod adalah kontrak yang lebih akurat. Sisi jauh melihat beban kerja yang menghasilkan lalu lintas, log tetap jujur, dan kebijakan per pod menjadi mungkin. Harganya adalah peer harus membawa prefiks pod.

Mempertahankan alamat node adalah kontrak yang lebih murah. Nyalakan lagi masquerade untuk tujuan itu dan peer tetap melihat alamat yang sudah dipercayainya.

Satu pertanyaan menentukan di antara keduanya: apa yang dilakukan peer dengan sumber itu? Jika ia mencatat log, menerapkan kebijakan per sumber, atau menegakkan perutean balik yang sempit, alamat pod membenarkan konfigurasi tambahan. Jika ia hanya perlu mengirim balasan, masquerade lebih murah dan tidak meminta apa pun dari sisi lain. Pilihan mana pun dapat dipertahankan asalkan kedua tim menuliskannya.

Opsi ketiga biasanya keliru: masquerade semuanya dan kehilangan kemampuan mengatribusikan lalu lintas. Hindari kecuali peer benar-benar tidak bisa merutekan apa pun selain alamat node.

Arahkan nonMasqueradeCIDRs ke rentang sebenarnya

GKE menjalankan ip-masq-agent di kube-system, dan ConfigMap-nya mencantumkan tujuan yang melewati masquerade. Untuk mempertahankan sumber pod menuju terowongan, rentang pod, subnet node, dan prefiks lokal semuanya masuk ke daftar itu.

Ganti nilai contoh dengan rentang dari klaster Anda sendiri. Jangan membuat daftar lebih lebar daripada yang dibutuhkan, karena setiap entri tambahan mengubah apa yang dilihat tujuan lain. Tiga entri di bawah mewakili jaringan pod, subnet node, dan prefiks di balik terowongan:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

Entri 0.0.0.0/0 menonaktifkan masquerade untuk semua tujuan, yang mengubah bagaimana beban kerja tak terkait tampak bagi layanan luar dan jarang disengaja. Agen membaca ulang konfigurasinya pada resyncInterval, jadi mulai ulang biasanya tidak perlu. Periksa apakah pod agen berjalan, lalu buka berkas yang dipasang di dalamnya. Membaca berkas itulah yang membuktikan perubahan sudah sampai.

Jalur balasan adalah separuh lainnya

Masquerade mengubah sumber permintaan dan tidak yang lain. Apa pun sumber yang diterima peer, ia tetap butuh rute kembali ke sana, dan klaster tetap butuh rute menuju peer.

Tangkapan di gateway VPN memisahkan kedua kegagalan dengan cepat. Paket yang tiba dengan alamat pod dan tak pernah mendapat balasan berarti peer tidak punya rute untuk prefiks pod. Balasan yang muncul di gateway tetapi tak pernah mencapai klaster berarti rute lokal hilang. Tuliskan kontraknya di tiket bagaimanapun juga: sumber mana yang dilihat peer, dan prefiks mana yang dirutekan balik.

Periksa ulang setelah setiap pembaruan

Perilaku masquerade bawaan sudah berubah sekali, dan penggantian kumpulan node dapat mengatur ulang jaringan klaster. Perlakukan kontrak sumber sebagai sesuatu yang harus diverifikasi, bukan diasumsikan.

Setelah pembaruan, kirim satu permintaan dari pod ke layanan lokal dan baca sumber yang dicatat peer. Satu pengamatan itu menangkap regresi yang akan dengan senang hati dilaporkan halaman status terowongan sebagai sehat. Mengulanginya memakan satu menit dan menghemat satu malam bagi orang berikutnya.