In-nodi privati ta’ GKE ma jiddeċidux liema API juża kubectl

In-nodi huma privati, il-VPN jilħqilhom, u xorta kubectl ma jistax jitkellem mal-cluster. Dawn iż-żewġ fatti mhumiex relatati. L-indirizz li juża kubectl ġej mill-URL tas-server maħżun fil-kubeconfig meta nġabu l-kredenzjali, u l-ebda rotta li żżid ma tibdlu. Sadanittant, in-nodi mhumiex dak li kubectl qed jipprova jilħaq minn bidu.

Ħames verifiki, nibdew mill-unika valur li jgħodd.

Verifika 1: aqra l-URL tas-server fil-kubeconfig

Ipprintja l-endpoint mingħajr ma tferra’ l-kredenzjali: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Dak is-sekwenza waħda tgħidlek jekk il-klijent huwiex qed jindika lejn indirizz IP, isem DNS jew indirizz estern li ma kellokx f’moħħok. Kull ħaġa oħra f’din l-investigazzjoni toħroġ minnha.

Jekk l-URL mhuwiex l-endpoint li ħsibt li kkonfigurajt, il-bqija tad-dijanjosi hija distrazzjoni.

Verifika 2: qabbel l-URL mat-tip ta’ endpoint

Il-GKE attwali jappoġġja kemm aċċess għall-pjan ta’ kontroll ibbażat fuq IP kif ukoll fuq DNS, u l-kredenzjali li ġġib jagħżlu wieħed minnhom. gcloud container clusters get-credentials NAME --location REGION --internal-ip jikteb l-endpoint tal-IP interna, filwaqt li --dns-endpoint jagħżel aċċess ibbażat fuq DNS. L-ebda waħda mill-flags ma tipprovdi mogħdija tan-netwerk, li tħawwad lil dawk li jistennew li l-ġbir jissewwi l-konnettività. Erġa’ agħmel il-ġbir b’mod intenzjonat u mbagħad erġa’ aqra l-URL wara.

Li tbiddel il-flags mingħajr ma terġa’ taqra l-URL huwa kif laptop jispiċċa b’kredenzjali ta’ żewġ clusters u żball wieħed konfuż.

Entrata fin-netwerk awtorizzat tiddetermina min jista’ jilħaq endpoint estern u ma tapplikax għal dak intern. Li twessagħha biex tittestja mogħdija privata tbiddel l-espożizzjoni tiegħek, mhux id-dijanjosi tiegħek.

Verifika 3: ipprova l-mogħdija lejn dak l-endpoint

Jekk l-URL hija IP interna, ivverifika r-rotta min-netwerk li fih il-klijent verament qiegħed, il-firxa tas-sors permessa u s-setting tal-aċċess reġjonali jew globali tal-cluster. Il-firxa tal-pjan ta’ kontroll u s-subnet tan-nodi mhumiex l-istess destinazzjoni, għalhekk rotta li taħdem lejn in-nodi ma tipprovax xejn dwar l-endpoint. Għall-aċċess ibbażat fuq DNS, il-mogħdija hija l-konnettività mal-Google API bl-arranġament dokumentat Private Google Access, mhux rotta lejn is-subnet tal-ħaddiema. Ittestja l-endpoint b’konnessjoni TCP sempliċi qabel ma tagħti l-ħtija lil kubectl.

Timeout huwa problema ta’ mogħdija. 403 hija problema ta’ politika. Ma jaqsmux l-istess soluzzjoni.

Verifika 4: aqsam il-logs u l-exec mis-sejħiet API

Jekk it-talbiet API normali jirnexxu u kubectl logs jew kubectl exec ifalli, int diġà għaddejt mill-għażla tal-endpoint. Dawk l-operazzjonijiet jeħtieġu l-permessi Kubernetes korrispondenti u jiddependu fuq komunikazzjoni mill-pjan ta’ kontroll lejn in-nodi, u l-falliment jista’ jkun risposta Forbidden minflok timeout. L-aċċess SSH lejn nod jittestja servizz kompletament ieħor u ma jistabbilixxihomx.

Aqra l-klassi tal-iżball qabel ma terġa’ tiftaħ it-ticket tal-VPN, għax iż-żewġ klassijiet jgħixu f’postijiet differenti.

Verifika 5: żomm tliet osservazzjonijiet għall-persuna li jmiss

Innota l-URL tal-API magħżul, jekk talba API awtorizzata waħda taħdimx, u eżattament liema operazzjoni sussegwenti tfalli, mat-test tal-iżball. Dawk it-tliet linji jifirdu l-għażla tal-endpoint mill-aċċess għan-nodi, u jwaqqfu mogħdija VPN tajba ħafna milli tiġi akkużata b’talba li qatt ma ġarret.

L-inġinier li jmiss se jistaqsi jekk it-tunnel huwiex miksur. In-nota tiegħek għandha diġà twieġeb għal dan.