minikube özel bir API'ye ulaşamıyor mu? Önce sürücüyü kontrol edin

Host, düğüm ve Pod'un her birinin kendi rotaları ve kendi resolver'ı vardır. Sürücüyü adlandırın, aynı endpoint'i üçünden de test edin, sonra başarısız olan bağlamı düzeltin.

Özel bir API dizüstü bilgisayarınızdan yanıt veriyor ve minikube içindeki bir Pod ona ulaşamıyor. Host üzerinde herhangi bir şeyi değiştirmeden önce etkin profilin arkasındaki sürücüyü adlandırın, çünkü bu tek gerçek isteğin gerçekte hangi ağdan çıktığını belirler. Ardından aynı endpoint'i host'tan, düğümden ve Pod'dan test edin. Bu üçünden yalnızca biri başarısız olan şeydir ve yanlış tahmin bir öğleden sonraya mal olur.

Adım 0: sürücüyü ve kaynağı adlandırın

minikube'a hangi profilin etkin olduğunu ve nasıl çalıştığını sorun. Bir konteyner sürücüsü düğümü makinenizdeki bir konteynere koyar, bir VM sürücüsü onu bir sanal makineye koyar ve uzak bir sürücü onu tamamen başka bir yere koyar.

minikube profile list
minikube status
kubectl config current-context

Bundan isteğin nereden kaynaklandığını yazın. Cevap, hangi resolver'ın ve hangi rotaların önemli olduğunu belirler ve bu her zaman host'unki değildir. Aynı dizüstü bilgisayardaki iki profil aynı URL için tamamen farklı davranabilir.

ContextWhat has to work
Host processHost resolver and host route to the private destination
minikube nodeThe node's own resolver and its outbound path
PodPod DNS through cluster services plus the cluster network path

Adım 1: aynı endpoint'i üç kez test edin

Zararsız bir endpoint kullanın ve ana bilgisayar adını, bağlantı noktasını ve adres ailesini üç testte de aynı tutun. Bunlardan herhangi birini çalıştırmalar arasında değiştirirseniz sonuçlar karşılaştırılamaz olur.

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

Düğüm tarafından başarılı bir image çekme işlemi, özel bir host için ad çözümlemesi hakkında hiçbir şey kanıtlamaz. Başarılı bir genel istek daha da azını kanıtlar. Sonuçları bağlama göre ayrı tutun, çünkü üç satırda bir örüntü teşhistir ve tek bir başarısızlık bir ipucudur.

Host satırı da başarısız olursa durun. Bir host ağ sorununuz var ve cluster bir dikkat dağıtıcıdır.

Adım 2: host'un cluster'a giden yolunu koruyun

İnsanların unuttuğu ikinci bir yön vardır: host, cluster'ın kendi API'sine ve hizmetlerine ulaşmaya devam etmelidir. Bir VPN istemcisi, minikube'un düğüm ağı, hizmet aralığı ve pod aralığı için kullandığı öneklerle rekabet eden rotalar kurabilir.

Bu olduğunda belirti kafa karıştırıcıdır, çünkü tünel çalışır ve kubectl yanıt vermeyi bırakır ya da bir NodePort bağlantıları reddeder. Bir cluster arızası gibi görünür ve aslında bir dizüstü bilgisayar yönlendirme arızasıdır.

Tüneli başka herhangi bir şey için suçlamadan önce host'un yönlendirme tablosunu minikube'un aralıklarıyla karşılaştırın. Çakışma genellikle cluster'ın sahip olmayı beklediği bir önek için tünel arayüzüne işaret eden daha spesifik bir rota olarak görünür.

Adım 3: VPN'i devre dışı bırakmadan çakışmayı çözün

minikube'un kendi VPN ve proxy el kitabı bu çakışmaları ele alır ve örnek aralıklarını evrensel bir liste olarak değil, incelenecek şeyler olarak değerlendirir. Onu gerçekten sahip olduğunuz profille birlikte okuyun.

Gerçek bir çakışmanın olduğu yerde desteklenen yanıt, çakışmayan bir aralık veya VPN'in sahibi tarafından onaylanmış kasıtlı bir yerel erişim politikasıdır. Hizmet aralığını değiştirmek pod aralığını değiştirmekle aynı şey değildir ve hiçbiri düğüm ağını değiştirmekle aynı şey değildir.

Yerel bir cluster'ın çalışması için kurumsal tüneli devre dışı bırakmak bir geçici çözüm değildir; başka birinin vermesi gereken bir politika kararıdır. Herkes eve gittikten sonra sessizce yapmak yerine bu kişiye götürün. Zaten yaptıysanız sormadan önce geri alın.

Adım 4: proxy, DNS ve dört arıza biçimini ayırın

Bir proxy gerekliyse hangi bağlamın ona ihtiyacı olduğunu belirleyin. Host'taki bir tarayıcı ayarı düğüm içindeki bir süreci yapılandırmaz ve bir Pod'un ortam değişkenlerine veya cluster düzeyinde bir proxy yapılandırmasına ihtiyacı vardır.

Ardından arızayı tarif etmek yerine sınıflandırın. Çözülemeyen bir ad DNS'tir. Çözülen ve bağlantıyı reddeden bir ad yönlendirme veya bir listener'dır. Kurulan ve kimlikte başarısız olan bir bağlantı TLS'tir. Hata gövdesiyle başarılı bir bağlantı uygulamadır.

Bu dördünün her biri farklı bir düzeltmeye aittir ve yalnızca biri VPN ile ilgilidir. Her bağlamda hangisini gözlemlediğinizi yazın ve sonraki kişi bir hikâye yerine kanıt devralır.

İlgili makaleler