Miksi GKE-podit eivät tavoita paikallisia palvelimia VPN:n yli

Ping toimii solmusta ja epäonnistuu podista, eikä paikalliselle puolelle saavu mitään. Tunneli ja reitti ovat kunnossa; johdolla oleva lähdeosoite ei ole. Näiden kahden tapauksen ero on siinä, mitä paketti väittää olevansa lähtiessään klusterista, ja GKE:llä on siitä oma mielipiteensä. Mekanismi on masquerade-poikkeuslista, ja sen lukemiseen tarvitaan yksi komento.

Lue voimassa oleva lista ennen kuin muutat mitään

GKE toimittaa agentin, joka päättää kohdealueittain, kirjoitetaanko podien liikenne ulospäin mentäessä uudelleen solmun osoitteeksi. Sen toimittama kokoonpano nimeää kolme RFC1918-lohkoa, 10.0.0.0/8, 172.16.0.0/12 ja 192.168.0.0/16, poikkeuksina. Siksi kaikki, mitä lähetät podista paikalliseen 10.x-isäntään, lähtee solmusta podin oma osoite yhä kiinnitettynä. Solmun oma liikenne ei kirjoitu uudelleen, ja juuri siksi sen ping toimii.

Lue tarkoitettu kokoonpano ja asennetut säännöt, sillä ne voivat olla eri mieltä. kubectl -n kube-system get configmap ip-masq-agent -o yaml näyttää, mitä agentille sanottiin, ja kubectl -n kube-system get pods -l k8s-app=ip-masq-agent näyttää, onko jotain käynnissä sen soveltamiseksi. Solmussa iptables-save | grep -i masq näyttää säännöt, jotka ytimessä todella ovat. Kun ConfigMap sanoo yhtä ja säännöt toista, epäilty on agentti eikä verkko.

Vahvista lähdeosoite kaappauksella

Tee kaappaus ennen kuin muutat listaa. Suodatin yhteen kohteeseen pitää tulosteen luettavana: tcpdump -ni any host 10.20.30.40.

Vertaa sitä siihen, mitä toinen puoli raportoi. Paikallisella puolella tehty kaappaus, joka näyttää podin osoitteen eikä vastausta, sulkee kehän: poikkeuslista selittää epäsymmetrian ilman mitään tunnelivikaa. Kahdet havainnot yhdestä lähdeosoitteesta riittävät siihen, että CNI:stä voi lopettaa arvailun.

Kavenna poikkeus podin CIDR:ään

Tuettu korjaus kaventaa poikkeuksen sen sijaan, että poistaisi sen: pidä podin CIDR poikkeuksena ja pudota muu 10.x-avaruus. Lista on agentin ConfigMapissa avaimen nonMasqueradeCIDRs alla, ja sen muuttaminen on muokkaus ja sen perään käyttöönotto. Korvaa laaja merkintä klusterin todellisella podialueella, pidä muut yksityiset lohkot, jos klusterin sisäinen liikenne tarvitsee niitä yhä, ja jätä resyncInterval rauhaan, ellet ole syytä. Ota se käyttöön, vahvista että agentin podit käynnistyivät uudelleen ja vahvista että ytimen säännöt muuttuivat.

Tämä on koko klusterin laajuinen muutos, jolla on todellinen vaikutusalue. Kun se astuu voimaan, liikenne, joka ennen piti podin lähteen, saapuu nyt solmuun uudelleenkirjoitettuna, joten kaikki noihin podiosoitteisiin sidottu näkee eri lähettäjän. Uhreja ovat lokit, sallitut listat ja paikalliset palomuurisäännöt, jotka nimeävät podiosoitteita, ja ne epäonnistuvat hiljaa. Ilmoita muutos käyttäytymismuutoksena, älä korjauksena.

Jos klusterissa on useita solmupooleja, tarkista, että agentti on aikataulutettu solmuille, joilla asianomaiset podit todella ajavat. Pooli ilman DaemonSetiä pitää vanhat sääntönsä, eikä mikään ConfigMapissa näytä sitä.

Vaihtoehto ja sen hinta

Toinen vaihtoehto pitää podien osoitteet ehjinä ja opettaa reitille ne. Podin CIDR menee Cloud VPN:n liikennevalitsimiin, ja paikallinen puoli tarvitsee sille paluureitin, jotta vastaukset tietävät minne mennä. Se säilyttää podin identiteetin, jota jotkin turvamallit haluavat, ja se laajentaa sekä reitityksen että palomuurin laajuutta, jonka toisen puolen on hyväksyttävä.

Kauppa on luettavuus laajuutta vastaan. Kääntäminen saa paikallisen puolen näkemään yhden osoitteen solmua kohden, mikä on helppo lisätä sallittuun listaan ja kätkee, mikä podi lähetti mitä. Kääntämättä jättäminen pitää podin osoitteen päästä päähän, mikä on parempi attribuutiolle ja huonompi jokaiselle reitin laitteelle, jonka on opittava uusi alue. Kumpikaan vaihtoehto ei ole Dockerin tai CNI:n vika; molemmat ovat reitityspäätöksiä, joilla on operatiivinen lasku. Valitse se, jonka laskun tiimisi pystyy maksamaan, ja kirjoita perustelu ylös.

Vahvista ja peru

Aja sama kaappaus uudelleen. Solmutason kaappaus, joka yhä tulostaa podin osoitteen muokkauksesi jälkeen, tarkoittaa, että säännöt eivät koskaan muuttuneet, mitä ConfigMap sitten sanookin. Johto on tosiasia; kaikki muu on päättelyä.

Tarkista sitten vastakkaiseen suuntaan, koska puolet näistä muutoksista vahvistetaan vain lähtevään suuntaan. Vahvista, että vastaus tavoittaa pyynnön lähettäneen solmun tai podin, ja vahvista, että sovellus valmistui eikä vain vastaanottanut SYN:iä. Kaappaus, joka näyttää pyynnön ilman vastausta, on reititysongelma toisella puolella, ei masquerade-ongelma tällä puolella.

Peruutus on edellinen ConfigMap, samalla tavalla sovellettuna, samalla vahvistuksella siitä, että agentti käynnistyi uudelleen ja säännöt muuttuivat. Tallenna muutoskirjaan yhden tunnetun pyynnön lähdeosoite ennen ja jälkeen, sillä juuri se yksi rivi todistaa, että muutos teki sen, minkä sanoit. GKE:n IP-masquerade-agentin opas dokumentoi oletusarvot ja ConfigMap-kentät. Jos lähdeosoite ei muutu käyttöönoton jälkeen, agentti ei aja sillä solmulla eikä mikään YAML-muokkaus korjaa sitä.