minikube özəl API-yə çatmır? Əvvəlcə drayveri yoxlayın
Host, düyün və Pod hər birinin öz marşrutları və öz resolver-i var. Drayveri adlandırın, eyni endpoint-i hər üçündən yoxlayın, sonra uğursuz olan konteksti düzəldin.
Ö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.
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod 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.