Nod GKE peribadi tidak menentukan API mana yang digunakan kubectl

Nodnya peribadi, VPN mencapainya, namun kubectl masih tidak dapat bercakap dengan kluster. Kedua-dua fakta itu tidak berkaitan. Alamat yang digunakan kubectl datang daripada URL pelayan yang disimpan dalam kubeconfig semasa kredensial diambil, dan tiada laluan yang anda tambah mengubahnya. Sementara itu, nod bukanlah perkara yang kubectl cuba capai pada mulanya.

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

Pemeriksaan 1: baca URL pelayan dalam kubeconfig

Cetak titik akhir tanpa menumpahkan kredensial: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Satu rentetan itu memberitahu anda sama ada klien menuju alamat IP, nama DNS atau alamat luaran yang tidak anda maksudkan. Segala-galanya dalam penyiasatan ini berpunca daripadanya.

Jika URL bukan titik akhir yang anda sangka telah dikonfigurasikan, baki diagnosis hanyalah gangguan.

Pemeriksaan 2: padankan URL dengan jenis titik akhir

GKE semasa menyokong akses satah kawalan berasaskan IP dan berasaskan DNS, dan kredensial yang anda ambil memilih salah satu. gcloud container clusters get-credentials NAME --location REGION --internal-ip menulis titik akhir IP dalaman, manakala --dns-endpoint memilih akses berasaskan DNS. Kedua-dua bendera tidak menyediakan laluan rangkaian, yang mengejutkan mereka yang menjangka pengambilan akan membaiki kesambungan. Ulang pengambilan dengan sengaja dan kemudian baca URL itu semula.

Menukar bendera tanpa membaca semula URL ialah cara komputer riba berakhir dengan kredensial dua kluster dan satu ralat yang mengelirukan.

Entri rangkaian dibenarkan menentukan siapa boleh mencapai titik akhir luaran dan tidak terpakai kepada yang dalaman. Meluaskannya untuk menguji laluan peribadi mengubah pendedahan anda, bukan diagnosis anda.

Pemeriksaan 3: buktikan laluan ke titik akhir itu

Jika URL ialah IP dalaman, sahkan laluan dari rangkaian tempat klien benar-benar berada, julat sumber yang dibenarkan dan tetapan akses serantau atau global kluster. Julat satah kawalan dan subnet nod bukan destinasi yang sama, jadi laluan yang berfungsi ke nod tidak membuktikan apa-apa tentang titik akhir. Untuk akses berasaskan DNS, laluannya ialah kesambungan Google API dengan susunan Private Google Access yang didokumenkan, bukan laluan ke subnet pekerja. Uji titik akhir dengan sambungan TCP biasa sebelum menyalahkan kubectl.

Tamat masa ialah masalah laluan. 403 ialah masalah dasar. Kedua-duanya tidak berkongsi pembaikan.

Pemeriksaan 4: asingkan log dan exec daripada panggilan API

Jika permintaan API biasa berjaya dan kubectl logs atau kubectl exec gagal, anda sudah melepasi pemilihan titik akhir. Operasi itu memerlukan kebenaran Kubernetes yang berkaitan dan bergantung pada komunikasi satah kawalan ke nod, dan kegagalan itu boleh jadi respons Forbidden dan bukan tamat masa. Akses SSH ke nod menguji perkhidmatan yang sama sekali berbeza dan tidak menetapkannya.

Baca kelas ralat sebelum membuka semula tiket VPN, kerana kedua-dua kelas itu tinggal di tempat berlainan.

Pemeriksaan 5: simpan tiga pemerhatian untuk orang seterusnya

Catat URL API yang dipilih, sama ada satu permintaan API yang dibenarkan berfungsi, dan dengan tepat operasi susulan mana yang gagal, berserta teks ralat. Tiga baris itu memisahkan pemilihan titik akhir daripada akses nod, dan menghalang laluan VPN yang sempurna daripada dipersalahkan atas permintaan yang tidak pernah dibawanya.

Jurutera seterusnya akan bertanya sama ada terowong itu rosak. Nota anda sepatutnya sudah menjawabnya.