Node GKE privat tidak menentukan API mana yang dipakai kubectl

Node-nya privat, VPN menjangkaunya, dan kubectl tetap tidak bisa berbicara dengan klaster. Kedua fakta itu tidak saling terkait. Alamat yang dipakai kubectl berasal dari URL server yang disimpan di kubeconfig saat kredensial diambil, dan tidak ada rute yang Anda tambahkan yang mengubahnya. Sementara itu, node bukanlah yang hendak dijangkau kubectl sejak awal.

Lima pemeriksaan, dimulai dengan satu-satunya nilai yang penting.

Pemeriksaan 1: baca URL server di kubeconfig

Cetak endpoint tanpa membocorkan kredensial: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Satu string itu memberi tahu Anda apakah klien mengarah ke alamat IP, nama DNS, atau alamat eksternal yang tidak Anda maksud. Semua hal lain dalam penyelidikan ini mengikuti darinya.

Jika URL bukan endpoint yang Anda kira telah dikonfigurasi, sisa diagnosisnya hanyalah pengalih perhatian.

Pemeriksaan 2: cocokkan URL dengan jenis endpoint

GKE saat ini mendukung akses bidang kendali berbasis IP maupun DNS, dan kredensial yang Anda ambil memilih salah satunya. gcloud container clusters get-credentials NAME --location REGION --internal-ip menulis endpoint IP internal, sedangkan --dns-endpoint memilih akses berbasis DNS. Tidak satu pun flag menyediakan jalur jaringan, yang mengejutkan orang yang mengharapkan pengambilan kredensial memperbaiki konektivitas. Ulangi pengambilan dengan sengaja lalu baca URL-nya lagi setelahnya.

Mengubah flag tanpa membaca ulang URL adalah cara laptop berakhir dengan kredensial dua klaster dan satu galat yang membingungkan.

Entri jaringan yang diizinkan menentukan siapa yang boleh menjangkau endpoint eksternal dan tidak berlaku untuk yang internal. Melebarkannya untuk menguji jalur privat mengubah eksposur Anda, bukan diagnosis Anda.

Pemeriksaan 3: buktikan jalur ke endpoint itu

Jika URL adalah IP internal, verifikasi rute dari jaringan tempat klien benar-benar berada, rentang sumber yang diizinkan, dan setelan akses regional atau global klaster. Rentang bidang kendali dan subnet node bukan tujuan yang sama, jadi rute yang berfungsi ke node tidak membuktikan apa pun tentang endpoint. Untuk akses berbasis DNS, jalurnya adalah konektivitas Google API dengan pengaturan Private Google Access yang terdokumentasi, bukan rute ke subnet pekerja. Uji endpoint dengan koneksi TCP biasa sebelum menyalahkan kubectl.

Timeout adalah masalah jalur. 403 adalah masalah kebijakan. Keduanya tidak berbagi perbaikan.

Pemeriksaan 4: pisahkan log dan exec dari panggilan API

Jika permintaan API biasa berhasil dan kubectl logs atau kubectl exec gagal, Anda sudah melewati pemilihan endpoint. Operasi itu memerlukan izin Kubernetes yang sesuai dan bergantung pada komunikasi bidang kendali ke node, dan kegagalannya bisa berupa respons Forbidden alih-alih timeout. Akses SSH ke node menguji layanan yang sama sekali berbeda dan tidak menetapkannya.

Baca kelas galatnya sebelum membuka kembali tiket VPN, karena kedua kelas itu tinggal di tempat berbeda.

Pemeriksaan 5: simpan tiga pengamatan untuk orang berikutnya

Catat URL API yang dipilih, apakah satu permintaan API yang diizinkan berhasil, dan tepatnya operasi berikutnya mana yang gagal, beserta teks galatnya. Tiga baris itu memisahkan pemilihan endpoint dari akses node, dan mencegah rute VPN yang sepenuhnya baik disalahkan atas permintaan yang tidak pernah dibawanya.

Insinyur berikutnya akan bertanya apakah terowongannya rusak. Catatan Anda seharusnya sudah menjawabnya.