minikube tidak menjangkau API privat? Periksa driver dulu

Host, node, dan Pod masing-masing punya rute dan resolver sendiri. Sebutkan driver-nya, uji endpoint yang sama dari ketiganya, lalu perbaiki konteks yang gagal.

Sebuah API privat menjawab dari laptop Anda dan Pod di minikube tidak dapat menjangkaunya. Sebelum mengubah apa pun di host, sebutkan driver di balik profil aktif, karena fakta tunggal ini menentukan dari jaringan mana permintaan benar-benar keluar. Lalu uji endpoint yang sama dari host, dari node, dan dari Pod. Hanya satu dari ketiganya yang gagal, dan tebakan yang salah menghabiskan satu sore.

Langkah 0: sebutkan driver dan asalnya

Tanyakan kepada minikube profil mana yang aktif dan bagaimana ia berjalan. Driver container menempatkan node di dalam container pada mesin Anda, driver VM menempatkannya di mesin virtual, dan driver jarak jauh menempatkannya di tempat yang sama sekali lain.

minikube profile list
minikube status
kubectl config current-context

Dari situ, catat dari mana permintaan berasal. Jawabannya menentukan resolver siapa dan rute mana yang penting, dan itu tidak selalu milik host. Dua profil pada laptop yang sama bisa berperilaku sangat berbeda untuk URL yang sama.

ContextWhat has to work
Host processHost resolver and host route to the private destination
minikube nodeThe node's own resolver and its outbound path
PodPod DNS through cluster services plus the cluster network path

Langkah 1: uji endpoint yang sama tiga kali

Gunakan satu endpoint yang tidak berbahaya dan jaga nama host, port, serta keluarga alamat tetap identik di ketiga pengujian. Mengubah salah satunya antar-eksekusi membuat hasil tidak dapat dibandingkan.

curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
  curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health

Penarikan image yang berhasil oleh node tidak membuktikan apa pun tentang resolusi nama untuk host privat. Permintaan publik yang berhasil membuktikan lebih sedikit lagi. Pisahkan hasil per konteks, karena pola pada tiga baris adalah diagnosis dan kegagalan tunggal adalah petunjuk.

Jika baris host juga gagal, berhenti. Anda punya masalah jaringan host dan cluster hanyalah pengalih perhatian.

Langkah 2: pertahankan jalur host ke cluster

Ada arah kedua yang orang lupakan: host harus tetap menjangkau API dan layanan milik cluster itu sendiri. Klien VPN dapat memasang rute yang bersaing dengan prefiks yang dipakai minikube untuk jaringan node, rentang layanan, dan rentang pod-nya.

Ketika itu terjadi, gejalanya membingungkan, karena tunnel berfungsi dan kubectl berhenti merespons atau NodePort menolak koneksi. Ini terlihat seperti kesalahan cluster padahal kesalahan perutean laptop.

Periksa tabel perutean host terhadap rentang minikube sebelum menyalahkan tunnel atas hal lain. Tumpang tindih biasanya terlihat sebagai rute yang lebih spesifik yang menunjuk ke antarmuka tunnel untuk prefiks yang dianggap milik cluster.

Langkah 3: selesaikan tumpang tindih tanpa menonaktifkan VPN

Buku pegangan VPN dan proxy milik minikube sendiri membahas konflik ini dan memperlakukan rentang contohnya sebagai hal yang perlu diperiksa, bukan daftar universal. Bacalah bersama profil yang benar-benar Anda miliki.

Di tempat tumpang tindih nyata ada, jawaban yang didukung adalah rentang yang tidak tumpang tindih atau kebijakan akses lokal yang disengaja dan disetujui oleh pemilik VPN. Mengubah rentang layanan tidak sama dengan mengubah rentang pod, dan keduanya tidak sama dengan mengubah jaringan node.

Menonaktifkan tunnel korporat agar cluster lokal berfungsi bukanlah jalan pintas; itu keputusan kebijakan yang harus diambil orang lain. Bawalah ke orang itu alih-alih melakukannya diam-diam setelah semua orang pulang. Jika Anda sudah melakukannya, kembalikan sebelum bertanya.

Langkah 4: pisahkan proxy, DNS, dan empat bentuk kegagalan

Jika proxy diperlukan, tentukan konteks mana yang membutuhkannya. Pengaturan browser di host tidak mengonfigurasi proses di dalam node, dan Pod memerlukan variabel lingkungan atau konfigurasi proxy tingkat cluster.

Lalu klasifikasikan kegagalannya alih-alih mendeskripsikannya. Nama yang tidak ter-resolve adalah DNS. Nama yang ter-resolve dan menolak koneksi adalah perutean atau listener. Koneksi yang terbentuk dan gagal pada identitas adalah TLS. Koneksi berhasil dengan isi kesalahan adalah aplikasi.

Masing-masing dari empat itu termasuk perbaikan berbeda, dan hanya satu yang tentang VPN. Catat mana yang Anda amati di setiap konteks, dan orang berikutnya mewarisi bukti alih-alih cerita.

Artikel terkait