Einkahnísir GKE ákveða ekki hvaða API kubectl notar

Hnísarnir eru einkareknir, VPN-ið nær til þeirra, og samt getur kubectl ekki talað við klasann. Þessar tvær staðreyndir tengjast ekki. Vistfangið sem kubectl notar kemur úr URL netþjónsins sem var vistað í kubeconfig þegar skírteinin voru sótt, og engin leið sem þú bætir við breytir því. Á meðan eru hnísarnir alls ekki það sem kubectl er að reyna að ná í.

Fimm athuganir, byrjað á eina gildinu sem skiptir máli.

Athugun 1: lestu URL netþjónsins í kubeconfig

Prentaðu endapunktinn án þess að hella út skírteinunum: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Þessi eina strengur segir þér hvort biðlarinn bendir á IP-vistfang, DNS-nafn eða ytra vistfang sem þú ætlaðir þér ekki. Allt annað í þessari rannsókn leiðir af því.

Ef URL-ið er ekki endapunkturinn sem þú hélt að þú hefðir stillt, er restin af greiningunni truflun.

Athugun 2: paraðu URL-ið við tegund endapunktsins

Núverandi GKE styður bæði IP-tengdan og DNS-tengdan aðgang að stjórnlaginu, og skírteinin sem þú sækir velja annan hvorann. gcloud container clusters get-credentials NAME --location REGION --internal-ip skrifar innri IP-endapunktinn, en --dns-endpoint velur DNS-tengdan aðgang. Hvorugur fáninn útvegar netleið, sem kemur þeim á óvart sem búast við að sækja skírteinin laga tenginguna. Endurtaktu sækjuna viljandi og lestu URL-ið svo aftur.

Að breyta fánum án þess að lesa URL-ið aftur er leiðin sem fartölva endar með skírteini tveggja klasa og eina ruglingslega villu.

Færsla í leyfðu netinu ræður því hver má ná ytri endapunkti og á ekki við innri endapunktinn. Að víkka hana til að prófa einkaleið breytir útsetningunni þinni, ekki greiningunni.

Athugun 3: sannaðu leiðina að þeim endapunkti

Ef URL-ið er innra IP, staðfestu leiðina frá netinu sem biðlarinn er raunverulega á, leyft upprunasvið og svæðis- eða altæka aðgangsstillingu klasans. Svið stjórnlagsins og undirnet hnísanna eru ekki sami áfangastaður, svo leið sem virkar að hnísunum sannar ekkert um endapunktinn. Fyrir DNS-tengdan aðgang er leiðin Google API-tenging með skjalfestu Private Google Access fyrirkomulagi, ekki leið að undirneti vinnuhnísanna. Prófaðu endapunktinn með venjulegri TCP-tengingu áður en þú kennir kubectl um.

Tímamörk eru leiðarvandamál. 403 er stefnuvandamál. Þau eiga ekki sameiginlega lagfæringu.

Athugun 4: aðskildu skrár og exec frá API-köllum

Ef venjulegar API-beiðnir takast og kubectl logs eða kubectl exec mistekst, ertu þegar kominn fram hjá vali endapunktsins. Þessar aðgerðir þurfa samsvarandi Kubernetes-heimildir og byggja á samskiptum stjórnlagsins við hnísana, og mistökin geta verið Forbidden-svar í stað tímamarka. SSH-aðgangur að hnísi prófar allt aðra þjónustu og staðfestir þær ekki.

Lestu villuflokkinn áður en þú opnar VPN-miðann aftur, því flokkarnir tveir búa á mismunandi stöðum.

Athugun 5: geymdu þrjár athuganir fyrir næstu manneskju

Skráðu valið API-URL, hvort ein leyfð API-beiðni virkar og nákvæmlega hvaða síðari aðgerð mistekst, ásamt villutextanum. Þessar þrjár línur aðskilja val endapunktsins frá aðgangi að hnísunum, og þær koma í veg fyrir að fullkomlega góðri VPN-leið sé kennt um beiðni sem hún bar aldrei.

Næsti verkfræðingur mun spyrja hvort tunnillinn sé bilaður. Athugasemdin þín ætti þegar að svara því.