Yksityiset GKE-solmut eivät päätä, mitä API:a kubectl käyttää

Solmut ovat yksityisiä, VPN tavoittaa ne, ja silti kubectl ei voi puhua klusterin kanssa. Nämä kaksi tosiasiaa eivät liity toisiinsa. Osoite, jota kubectl käyttää, tulee palvelimen URL:sta, joka tallennettiin kubeconfigiin tunnistetietoja noudettaessa, eikä mikään lisäämäsi reitti muuta sitä. Sillä välin solmut eivät ole lainkaan se, mitä kubectl yrittää tavoittaa.

Viisi tarkistusta, alkaen ainoasta merkityksellisestä arvosta.

Tarkistus 1: lue palvelimen URL kubeconfigista

Tulosta päätepiste vuotamatta tunnistetietoja: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Tuo yksi merkkijono kertoo, osoittaako asiakas IP-osoitteeseen, DNS-nimeen vai ulkoiseen osoitteeseen, jota et tarkoittanut. Kaikki muu tässä tutkinnassa seuraa siitä.

Jos URL ei ole se päätepiste, jonka luulit määrittäneesi, muu diagnoosi on harhautusta.

Tarkistus 2: sovita URL päätepistetyyppiin

Nykyinen GKE tukee sekä IP-pohjaista että DNS-pohjaista hallintatason käyttöä, ja noudetut tunnistetiedot valitsevat niistä toisen. gcloud container clusters get-credentials NAME --location REGION --internal-ip kirjoittaa sisäisen IP:n päätepisteen, kun taas --dns-endpoint valitsee DNS-pohjaisen käytön. Kumpikaan lippu ei luo verkkoreittiä, mikä yllättää ne, jotka odottavat noudon korjaavan yhteyden. Toista nouto tarkoituksella ja lue URL sen jälkeen uudelleen.

Lippujen vaihtaminen lukematta URL:aa uudelleen on se tapa, jolla kannettavaan jää kahden klusterin tunnistetiedot ja yksi hämmentävä virhe.

Valtuutetun verkon merkintä määrää, kuka saa tavoittaa ulkoisen päätepisteen, eikä päde sisäiseen. Sen laajentaminen yksityisen reitin testaamiseksi muuttaa altistustasi, ei diagnoosiasi.

Tarkistus 3: todista reitti tuohon päätepisteeseen

Jos URL on sisäinen IP, tarkista reitti verkosta, jossa asiakas todella sijaitsee, sallittu lähdealue ja klusterin alueellinen tai globaali käyttöasetus. Hallintatason alue ja solmujen aliverkko eivät ole sama kohde, joten toimiva reitti solmuihin ei todista päätepisteestä mitään. DNS-pohjaisessa käytössä reitti on yhteys Google API:in ja sen dokumentoitu Private Google Access -järjestely, ei reitti työntekijöiden aliverkkoon. Testaa päätepiste tavallisella TCP-yhteydellä ennen kuin syytät kubectlia.

Aikakatkaisu on reittiongelma. 403 on käytäntöongelma. Niillä ei ole yhteistä korjausta.

Tarkistus 4: erota lokit ja exec API-kutsuista

Jos tavalliset API-pyynnöt onnistuvat ja kubectl logs tai kubectl exec epäonnistuu, olet jo ohittanut päätepisteen valinnan. Ne toiminnot tarvitsevat vastaavat Kubernetes-oikeudet ja riippuvat hallintatason ja solmujen välisestä viestinnästä, ja epäonnistuminen voi olla Forbidden-vastaus aikakatkaisun sijaan. SSH-käyttö solmuun testaa täysin toista palvelua eikä vahvista niitä.

Lue virheluokka ennen kuin avaat VPN-lipun uudelleen, koska kaksi luokkaa elävät eri paikoissa.

Tarkistus 5: jätä kolme havaintoa seuraavalle henkilölle

Kirjaa valittu API-URL, toimiiko yksi valtuutettu API-pyyntö ja mikä myöhempi toiminto tarkalleen epäonnistuu, virhetekstin kanssa. Ne kolme riviä erottavat päätepisteen valinnan solmujen käytöstä ja estävät täysin hyvää VPN-reittiä tulemasta syytetyksi pyynnöstä, jota se ei koskaan kuljettanut.

Seuraava insinööri kysyy, onko tunneli rikki. Muistiinpanosi pitäisi jo vastata siihen.