Özel GKE düğümleri kubectl'in hangi API'yi kullandığını belirlemez

Düğümler özel, VPN onlara ulaşıyor ve kubectl yine de kümeyle konuşamıyor. Bu iki gerçeğin birbiriyle ilgisi yok. kubectl'in kullandığı adres, kimlik bilgileri alınırken kubeconfig'e kaydedilen sunucu URL'sinden gelir ve eklediğiniz hiçbir yol onu değiştirmez. Bu arada kubectl'in ulaşmaya çalıştığı şey baştan beri düğümler değil.

Beş kontrol, önemli olan tek değerle başlayarak.

Kontrol 1: kubeconfig'deki sunucu URL'sini okuyun

Kimlik bilgilerini dökmeden uç noktayı yazdırın: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Bu tek dize, istemcinin bir IP adresine, bir DNS adına veya amaçlamadığınız bir dış adrese mi işaret ettiğini söyler. Bu soruşturmadaki her şey bundan çıkar.

URL, yapılandırdığınızı düşündüğünüz uç nokta değilse, tanılamanın geri kalanı bir dikkat dağıtmadır.

Kontrol 2: URL'yi uç nokta türüyle eşleştirin

Güncel GKE hem IP tabanlı hem de DNS tabanlı kontrol düzlemi erişimini destekler ve aldığınız kimlik bilgileri bunlardan birini seçer. gcloud container clusters get-credentials NAME --location REGION --internal-ip iç IP uç noktasını yazar, --dns-endpoint ise DNS tabanlı erişimi seçer. Hiçbir bayrak bir ağ yolu sağlamaz; bu da kimlik bilgilerini almanın bağlantıyı düzelteceğini bekleyenleri şaşırtır. Almayı bilerek tekrarlayın ve ardından URL'yi yeniden okuyun.

URL'yi yeniden okumadan bayrakları değiştirmek, bir dizüstü bilgisayarın iki kümenin kimlik bilgileri ve kafa karıştırıcı tek bir hatayla kalmasının yoludur.

Yetkili ağ kaydı, dış uç noktaya kimin ulaşabileceğini belirler ve iç uç nokta için geçerli değildir. Özel bir yolu test etmek için onu genişletmek tanılamanızı değil, maruziyetinizi değiştirir.

Kontrol 3: o uç noktaya giden yolu kanıtlayın

URL iç IP ise, istemcinin gerçekten oturduğu ağdan giden yolu, izin verilen kaynak aralığını ve kümenin bölgesel veya küresel erişim ayarını doğrulayın. Kontrol düzlemi aralığı ile düğüm alt ağı aynı hedef değildir, bu nedenle düğümlere çalışan bir yol uç nokta hakkında hiçbir şey kanıtlamaz. DNS tabanlı erişimde yol, belgelenmiş Private Google Access düzeniyle Google API bağlantısıdır, çalışanların alt ağına giden bir yol değildir. kubectl'i suçlamadan önce uç noktayı sade bir TCP bağlantısıyla test edin.

Zaman aşımı bir yol sorunudur. 403 bir ilke sorunudur. Ortak bir çözümleri yoktur.

Kontrol 4: günlükleri ve exec'i API çağrılarından ayırın

Sıradan API istekleri başarılı olup kubectl logs veya kubectl exec başarısız olursa, uç nokta seçimini çoktan geçmişsinizdir. Bu işlemler ilgili Kubernetes izinlerini gerektirir ve kontrol düzleminden düğümlere iletişime bağlıdır; hata zaman aşımı yerine Forbidden yanıtı olabilir. Bir düğüme SSH erişimi tamamen başka bir hizmeti test eder ve bunları kurmaz.

VPN biletini yeniden açmadan önce hata sınıfını okuyun, çünkü iki sınıf farklı yerlerde yaşar.

Kontrol 5: sıradaki kişi için üç gözlem saklayın

Seçilen API URL'sini, bir yetkili API isteğinin çalışıp çalışmadığını ve tam olarak hangi sonraki işlemin başarısız olduğunu hata metniyle birlikte kaydedin. Bu üç satır, uç nokta seçimini düğüm erişiminden ayırır ve tamamen iyi bir VPN yolunun hiç taşımadığı bir istek için suçlanmasını önler.

Sıradaki mühendis tünelin bozuk olup olmadığını soracak. Notunuz bunu çoktan yanıtlamış olmalı.