Özəl API noutbukdan cavab verir və minikube daxilindəki Pod ona çata bilmir. Hostda hər hansı bir şeyi dəyişməzdən əvvəl aktiv profilin arxasındakı drayveri adlandırın, çünki bu tək fakt sorğunun həqiqətən hansı şəbəkədən çıxdığını müəyyən edir. Sonra eyni endpoint-i hostdan, düyündən və Pod-dan yoxlayın. Bu üçündən yalnız biri uğursuz olan şeydir və yanlış təxmin bir günorta vaxtına başa gəlir.

Addım 0: drayveri və mənbəyi adlandırın

minikube-dan hansı profilin aktiv olduğunu və necə işlədiyini soruşun. Konteyner drayveri düyünü maşınınızdakı konteynerə qoyur, VM drayveri onu virtual maşına qoyur, uzaq drayver isə onu tamam başqa yerə qoyur.

minikube profile list
minikube status
kubectl config current-context

Bundan sorğunun haradan qaynaqlandığını yazın. Cavab hansı resolver-in və hansı marşrutların vacib olduğunu müəyyən edir və bu həmişə hostunki olmur. Eyni noutbukdakı iki profil eyni URL üçün tamam fərqli davrana bilər.

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

Addım 1: eyni endpoint-i üç dəfə yoxlayın

Zərərsiz bir endpoint istifadə edin və host adını, portu və ünvan ailəsini hər üç testdə eyni saxlayın. Bunlardan hər hansı birini işə salmalar arasında dəyişsəniz, nəticələr müqayisə oluna bilən olmaz.

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üyünün uğurlu image çəkməsi özəl host üçün ad həll etmə barədə heç nə sübut etmir. Uğurlu açıq sorğu daha da azını sübut edir. Nəticələri kontekstə görə ayrı saxlayın, çünki üç sətirdə bir nümunə diaqnozdur, tək uğursuzluq isə ipucudur.

Host sətri də uğursuz olursa, dayanın. Host şəbəkə probleminiz var və klaster diqqəti yayındırandır.

Addım 2: hostun klasterə gedən yolunu qoruyun

İnsanların unutduğu ikinci istiqamət var: host klasterin öz API-sinə və xidmətlərinə çatmağa davam etməlidir. VPN müştərisi minikube-un düyün şəbəkəsi, xidmət diapazonu və pod diapazonu üçün istifadə etdiyi prefikslərlə rəqabət edən marşrutlar quraşdıra bilər.

Bu baş verdikdə simptom çaşdırıcıdır, çünki tunel işləyir və kubectl cavab verməyi dayandırır ya da NodePort bağlantıları rədd edir. Klaster nasazlığı kimi görünür və əslində noutbukun marşrutlaşdırma nasazlığıdır.

Tuneli başqa bir şey üçün günahlandırmazdan əvvəl hostun marşrutlaşdırma cədvəlini minikube-un diapazonları ilə müqayisə edin. Üst-üstə düşmə adətən klasterin özünə aid gözlədiyi prefiks üçün tunel interfeysinə işarə edən daha spesifik marşrut kimi görünür.

Addım 3: VPN-i söndürmədən üst-üstə düşməni həll edin

minikube-un öz VPN və proxy kitabçası bu konfliktləri müzakirə edir və nümunə diapazonlarını universal siyahı kimi deyil, yoxlanmalı şeylər kimi qəbul edir. Onu həqiqətən malik olduğunuz profillə birlikdə oxuyun.

Həqiqi üst-üstə düşmə olan yerdə dəstəklənən cavab üst-üstə düşməyən diapazon və ya VPN-in sahibi tərəfindən təsdiqlənmiş qəsdən yerli giriş siyasətidir. Xidmət diapazonunu dəyişmək pod diapazonunu dəyişməklə eyni şey deyil və heç biri düyün şəbəkəsini dəyişməklə eyni şey deyil.

Yerli klasterin işləməsi üçün korporativ tuneli söndürmək əyani yol deyil; bu, başqasının verməli olduğu siyasət qərarıdır. Hamı evə getdikdən sonra bunu sakitcə etmək əvəzinə bu şəxsə çatdırın. Əgər artıq etmisinizsə, soruşmazdan əvvəl geri qaytarın.

Addım 4: proxy, DNS və dörd nasazlıq formasını ayırın

Proxy tələb olunursa, hansı kontekstin ona ehtiyacı olduğunu müəyyən edin. Hostdakı brauzer ayarı düyün daxilindəki prosesi konfiqurasiya etmir və Pod mühit dəyişənlərinə və ya klaster səviyyəsində proxy konfiqurasiyasına ehtiyac duyur.

Sonra nasazlığı təsvir etmək əvəzinə təsnif edin. Həll olunmayan ad DNS-dir. Həll olunan və bağlantını rədd edən ad marşrutlaşdırma və ya listener-dir. Qurulan və kimlikdə uğursuz olan bağlantı TLS-dir. Xəta gövdəsi ilə uğurlu bağlantı tətbiqdir.

Bu dördün hər biri fərqli düzəlişə aiddir və yalnız biri VPN ilə bağlıdır. Hər kontekstdə hansını müşahidə etdiyinizi yazın və növbəti şəxs hekayə əvəzinə sübut miras alır.

Əlaqəli məqalələr