Şəxsi GKE qovşaqları kubectl-in hansı API-dən istifadə etdiyini müəyyən etmir

Qovşaqlar şəxsidir, VPN onlara çatır, amma kubectl hələ də klasterlə danışa bilmir. Bu iki fakt bir-biri ilə əlaqəli deyil. kubectl-in istifadə etdiyi ünvan, etimadnamələr götürülərkən kubeconfig-də saxlanılan server URL-dən gəlir və əlavə etdiyiniz heç bir marşrut onu dəyişmir. Eyni zamanda, kubectl-in çatmağa çalışdığı şey qovşaqlar deyil.

Beş yoxlama, yeganə vacib dəyərdən başlayaraq.

Yoxlama 1: kubeconfig-də server URL-ni oxuyun

Etimadnamələri boşaltmadan son nöqtəni çap edin: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Bu bir sətir müştərinin IP ünvanına, DNS adına və ya nəzərdə tutmadığınız xarici ünvana yönəldiyini bildirir. Bu araşdırmadakı hər şey ondan irəli gəlir.

Əgər URL konfiqurasiya etdiyinizi düşündüyünüz son nöqtə deyilsə, diaqnozun qalan hissəsi diqqəti yayındırmaqdır.

Yoxlama 2: URL-ni son nöqtə növünə uyğunlaşdırın

Mövcud GKE həm IP əsaslı, həm də DNS əsaslı idarəetmə müstəvisi girişini dəstəkləyir və götürdüyünüz etimadnamələr birini seçir. gcloud container clusters get-credentials NAME --location REGION --internal-ip daxili IP son nöqtəsini yazır, --dns-endpoint isə DNS əsaslı girişi seçir. Heç bir bayraq şəbəkə marşrutu təmin etmir və bu, götürmənin bağlantını düzəldəcəyini gözləyənləri təəccübləndirir. Götürməni qəsdən yenidən edin və sonra URL-ni yenidən oxuyun.

URL-ni yenidən oxumadan bayraqları dəyişmək, noutbukun iki klasterin etimadnaməsi və bir çaşdırıcı xəta ilə qalmasına səbəb olur.

İcazə verilmiş şəbəkə qeydi xarici son nöqtəyə kimin çata biləcəyini müəyyən edir və daxili son nöqtəyə tətbiq olunmur. Şəxsi yolu yoxlamaq üçün onu genişləndirmək diaqnozunuzu deyil, məruz qalmanızı dəyişir.

Yoxlama 3: həmin son nöqtəyə yolu sübut edin

Əgər URL daxili IP-dirsə, marşrutu müştərinin faktiki olduğu şəbəkədən, icazə verilən mənbə diapazonundan və klasterin regional və ya qlobal giriş ayarından yoxlayın. İdarəetmə müstəvisi diapazonu və qovşaq alt şəbəkəsi eyni təyinat deyil, ona görə də qovşaqlara işləyən marşrut son nöqtə haqqında heç nə sübut etmir. DNS əsaslı giriş üçün yol, sənədləşdirilmiş Private Google Access quruluşu ilə Google API bağlantısıdır, işçi alt şəbəkəsinə marşrut deyil. kubectl-i günahlandırmadan əvvəl son nöqtəni adi TCP bağlantısı ilə yoxlayın.

Taymaut yol problemidir. 403 siyasət problemidir. Onların ortaq həlli yoxdur.

Yoxlama 4: logları və exec-i API çağırışlarından ayırın

Adi API sorğuları uğurludursa və kubectl logs və ya kubectl exec uğursuz olursa, siz artıq son nöqtə seçimini keçmisiniz. Bu əməliyyatlar uyğun Kubernetes icazələrini tələb edir və idarəetmə müstəvisindən qovşağa rabitədən asılıdır, uğursuzluq isə taymaut yerinə Forbidden cavabı ola bilər. Qovşağa SSH girişi tamamilə başqa xidməti yoxlayır və onları təsdiqləmir.

VPN biletini yenidən açmadan əvvəl xəta sinfini oxuyun, çünki iki sinif fərqli yerlərdə yaşayır.

Yoxlama 5: növbəti şəxs üçün üç müşahidə saxlayın

Seçilmiş API URL-ni, bir icazəli API sorğusunun işləyib-işləmədiyini və daha sonra hansı əməliyyatın uğursuz olduğunu xəta mətni ilə birlikdə qeyd edin. Bu üç sətir son nöqtə seçimini qovşaq girişindən ayırır və tamamilə yaxşı VPN marşrutunun heç daşımadığı sorğuya görə günahlandırılmasının qarşısını alır.

Növbəti mühəndis tunelin xarab olub-olmadığını soruşacaq. Qeydiniz artıq buna cavab verməlidir.