minikube tidak sampai ke API persendirian? Semak pemacu dahulu

API persendirian menjawab daripada komputer riba anda dan Pod dalam minikube tidak dapat mencapainya. Sebelum mengubah apa-apa pada hos, namakan pemacu di sebalik profil aktif, kerana fakta tunggal ini menentukan dari rangkaian mana permintaan benar-benar keluar. Kemudian uji endpoint yang sama daripada hos, daripada nod dan daripada Pod. Hanya satu daripada ketiga-tiganya ialah perkara yang gagal, dan tekaan yang salah menghabiskan satu petang.

Langkah 0: namakan pemacu dan asalnya

Tanya minikube profil mana yang aktif dan bagaimana ia berjalan. Pemacu kontena meletakkan nod di dalam kontena pada mesin anda, pemacu VM meletakkannya di dalam mesin maya, dan pemacu jauh meletakkannya di tempat yang sama sekali berbeza.

minikube profile list
minikube status
kubectl config current-context

Daripada itu, catat dari mana permintaan berasal. Jawapannya menentukan resolver siapa dan laluan mana yang penting, dan ia tidak selalunya milik hos. Dua profil pada komputer riba yang sama boleh berkelakuan sangat berbeza untuk URL yang sama.

Langkah 1: uji endpoint yang sama tiga kali

Gunakan satu endpoint yang tidak berbahaya dan kekalkan nama hos, port dan keluarga alamat yang sama dalam ketiga-tiga ujian. Menukar mana-mana daripadanya antara larian menjadikan keputusan tidak boleh 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

Tarik image yang berjaya oleh nod tidak membuktikan apa-apa tentang penyelesaian nama untuk hos persendirian. Permintaan awam yang berjaya membuktikan lebih sedikit lagi. Asingkan keputusan mengikut konteks, kerana corak pada tiga baris ialah diagnosis dan kegagalan tunggal ialah petunjuk.

Jika baris hos juga gagal, berhenti. Anda mempunyai masalah rangkaian hos dan kluster hanyalah pengalih perhatian.

Langkah 2: kekalkan laluan hos ke kluster

Ada arah kedua yang orang lupakan: hos mesti terus mencapai API dan perkhidmatan kluster itu sendiri. Klien VPN boleh memasang laluan yang bersaing dengan awalan yang digunakan minikube untuk rangkaian nod, julat perkhidmatan dan julat podnya.

Apabila itu berlaku, gejalanya mengelirukan, kerana terowong berfungsi dan kubectl berhenti bertindak balas atau NodePort menolak sambungan. Ia kelihatan seperti kerosakan kluster dan sebenarnya kerosakan penghalaan komputer riba.

Semak jadual penghalaan hos terhadap julat minikube sebelum menyalahkan terowong atas apa-apa lagi. Pertindihan biasanya kelihatan sebagai laluan yang lebih khusus yang menghala ke antara muka terowong untuk awalan yang dianggap milik kluster.

Langkah 3: selesaikan pertindihan tanpa mematikan VPN

Buku panduan VPN dan proxy minikube sendiri membincangkan konflik ini dan menganggap julat contohnya sebagai perkara untuk diperiksa, bukan senarai universal. Bacalah bersama profil yang benar-benar anda miliki.

Di tempat pertindihan sebenar wujud, jawapan yang disokong ialah julat tidak bertindih atau dasar akses setempat yang disengajakan dan diluluskan oleh pemilik VPN. Menukar julat perkhidmatan tidak sama dengan menukar julat pod, dan kedua-duanya tidak sama dengan menukar rangkaian nod.

Mematikan terowong korporat supaya kluster setempat berfungsi bukan jalan pintas; ia keputusan dasar yang perlu diambil oleh orang lain. Bawa ia kepada orang itu daripada melakukannya secara senyap selepas semua orang pulang. Jika anda sudah melakukannya, pulihkan sebelum bertanya.

Langkah 4: asingkan proxy, DNS dan empat bentuk kegagalan

Jika proxy diperlukan, kenal pasti konteks mana yang memerlukannya. Tetapan pelayar pada hos tidak mengkonfigurasi proses di dalam nod, dan Pod memerlukan pemboleh ubah persekitaran atau konfigurasi proxy peringkat kluster.

Kemudian klasifikasikan kegagalan daripada menerangkannya. Nama yang tidak diselesaikan ialah DNS. Nama yang diselesaikan dan menolak sambungan ialah penghalaan atau listener. Sambungan yang terbentuk dan gagal pada identiti ialah TLS. Sambungan berjaya dengan badan ralat ialah aplikasi.

Setiap satu daripada empat itu tergolong dalam pembetulan berbeza, dan hanya satu daripadanya tentang VPN. Catat mana yang anda perhatikan dalam setiap konteks, dan orang seterusnya mewarisi bukti bukan cerita.