Nid yw nodau GKE preifat yn penderfynu pa API y mae kubectl yn ei ddefnyddio

Mae'r nodau'n breifat, mae'r VPN yn eu cyrraedd, ac eto ni all kubectl siarad â'r clwstwr. Nid oes cysylltiad rhwng y ddau ffaith. Daw'r cyfeiriad y mae kubectl yn ei ddefnyddio o URL y gweinydd a storiwyd yn y kubeconfig pan godwyd y tystlythyrau, ac nid oes unrhyw lwybr yr ydych yn ei ychwanegu yn ei newid. Yn y cyfamser, nid y nodau yw'r hyn y mae kubectl yn ceisio ei gyrraedd o gwbl.

Pum gwiriad, gan ddechrau gyda'r un gwerth sy'n bwysig.

Gwirio 1: darllenwch URL y gweinydd yn y kubeconfig

Argraffwch y penbwynt heb ollwng y tystlythyrau: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Mae'r un llinyn hwnnw'n dweud wrthych a yw'r cleient yn pwyntio at gyfeiriad IP, enw DNS, neu gyfeiriad allanol nad oeddech yn bwriadu ei gael. Daw popeth arall yn yr ymchwiliad hwn ohono.

Os nad yw'r URL yn benbwynt y gwnaethoch chi feddwl i chi ei ffurfweddu, mae gweddill y diagnosis yn tynnu sylw.

Gwirio 2: cyfatebwch yr URL i fath y penbwynt

Mae GKE cyfredol yn cefnogi mynediad i'r plân rheoli ar sail IP ac ar sail DNS, a'r tystlythyrau a gewch sy'n dewis un. Mae gcloud container clusters get-credentials NAME --location REGION --internal-ip yn ysgrifennu penbwynt yr IP mewnol, tra bod --dns-endpoint yn dewis mynediad ar sail DNS. Nid yw'r naill faner na'r llall yn darparu llwybr rhwydwaith, sy'n syndod i bobl sy'n disgwyl i'r caffael drwsio cysylltedd. Ailadroddwch y caffael yn fwriadol a darllenwch yr URL eto wedyn.

Newid faneri heb ailddarllen yr URL yw'r ffordd y mae gliniadur yn gorffen gyda thystlythyrau dau glwstwr ac un gwall dryslyd.

Mae cofnod rhwydwaith awdurdodedig yn llywodraethu pwy sy'n cael cyrraedd penbwynt allanol ac nid yw'n gymwys i'r un mewnol. Mae ei ehangu i brofi llwybr preifat yn newid eich datguddiad, nid eich diagnosis.

Gwirio 3: profwch y llwybr i'r penbwynt hwnnw

Os yr URL yn IP mewnol, gwiriwch y llwybr o'r rhwydwaith lle mae'r cleient mewn gwirionedd, yr ystod ffynhonnell a ganiateir a gosodiad mynediad rhanbarthol neu fyd-eang y clwstwr. Nid ystod y plân rheoli a isrwydwaith y nodau yw'r un gyrchfan, felly nid yw llwybr sy'n gweithio i'r nodau'n profi dim am y penbwynt. Ar gyfer mynediad ar sail DNS, y llwybr yw cysylltedd API Google gyda'i drefniant Private Google Access dogfennol, nid llwybr i isrwydwaith y gweithwyr. Profwch y penbwynt gyda chysylltiad TCP plaen cyn beio kubectl.

Mae terfyn amser yn broblem llwybr. Mae 403 yn broblem polisi. Nid ydynt yn rhannu ateb.

Gwirio 4: gwahanwch logiau ac exec oddi wrth alwadau API

Os yw ceisiadau API cyffredin yn llwyddo ac mae kubectl logs neu kubectl exec yn methu, rydych chi eisoes wedi mynd heibio i ddewis y penbwynt. Mae'r gweithrediadau hynny angen y caniatadau Kubernetes cyfatebol ac maent yn dibynnu ar gyfathrebu'r plân rheoli â'r nodau, a gall y methiant fod yn ymateb Forbidden yn hytrach na therfyn amser. Mae mynediad SSH i nod yn profi gwasanaeth hollol wahanol ac nid yw'n eu sefydlu.

Darllenwch y dosbarth gwall cyn ailagor y tocyn VPN, oherwydd mae'r ddau ddosbarth yn byw mewn gwahanol leoedd.

Gwirio 5: cadwch dri arsylwad ar gyfer y person nesaf

Cofnodwch yr URL API a ddewiswyd, a yw un cais API awdurdodedig yn gweithio, a pha weithrediad diweddarach yn union sy'n methu, gyda thestun y gwall. Mae'r tair llinell hynny'n gwahanu dewis y penbwynt oddi wrth fynediad i nodau, ac maent yn atal llwybr VPN hollol dda rhag cael ei feio am gais na chludodd erioed.

Bydd y peiriannydd nesaf yn gofyn a yw'r twnnel wedi torri. Dylai eich nodyn fod eisoes yn ateb hynny.