Miks GKE podid ei jõua VPN-i kaudu kohalike serveriteni

Ping töötab sõlmest ja ebaõnnestub podist ning kohapeale ei jõua midagi. Tunnel ja marsruut on korras; lähteaadress juhtmel ei ole. Nende kahe juhtumi erinevus on see, mida pakett väidab end olevat kobarast lahkudes, ja GKE-l on selle kohta oma arvamus. Mehhanism on masquerade-erandite loend ja selle lugemiseks kulub üks käsk.

Lugege kehtivat loendit enne, kui midagi muudate

GKE tarnib agendi, mis otsustab sihtvahemiku kaupa, kas podi liiklus kirjutatakse väljumisel ümber sõlme aadressile. Selle tarnitud konfiguratsioon nimetab kolme RFC1918 plokki, 10.0.0.0/8, 172.16.0.0/12 ja 192.168.0.0/16, erandlike sihtkohtadena. Seetõttu lahkub kõik, mida saadate podist kohalikku 10.x hosti, sõlmest podi enda aadressiga veel küljes. Sõlme enda liiklust ümber ei kirjutata ja täpselt seetõttu tema ping töötab.

Lugege kavandatud konfiguratsiooni ja paigaldatud reegleid, sest need võivad lahkneda. kubectl -n kube-system get configmap ip-masq-agent -o yaml näitab, mida agendile öeldi, ja kubectl -n kube-system get pods -l k8s-app=ip-masq-agent näitab, kas midagi jookseb, et seda rakendada. Sõlmes näitab iptables-save | grep -i masq reegleid, mis tuumades tegelikult olemas on. Kui ConfigMap ütleb üht ja reeglid teist, on kahtlusalune agent, mitte võrk.

Kinnitage lähteaadress püüdmisega

Tehke püüdmine enne, kui loendit muudate. Filter ühele sihtkohale hoiab väljundi loetavana: tcpdump -ni any host 10.20.30.40.

Võrrelge seda sellega, mida teine pool teatab. Kohapeal tehtud püüdmine, mis näitab podi aadressi ja vastust ei tule, sulgeb ringi: erandite loend seletab asümmeetriat ilma igasuguse tunneli rikketa. Ühe lähteaadressi kaks vaatlust on piisavad, et lõpetada CNI kohta oletamine.

Ahendage erand podi CIDR-ile

Toetatud parandus ahendab erandit, selle asemel et see eemaldada: jätke podi CIDR erandlikuks ja loobuge ülejäänud 10.x ruumist. See loend asub agendi ConfigMapis võtme nonMasqueradeCIDRs all ja selle muutmine on redigeerimine, millele järgneb juurutus. Asendage lai kirje kobar tegeliku podi vahemikuga, jätke muud privaatsed plokid alles, kui kobarasisene liiklus vajab neid endiselt, ja jätke resyncInterval rahule, kui teil pole põhjust. Rakendage see, kinnitage, et agendi podid taaskäivitusid, ja kinnitage, et tuuma reeglid muutusid.

See on muudatus üle kogu kobar reaalse mõjuraadiusega. Kui see jõustub, saabub liiklus, mis varem hoidis oma podi lähtekoha, nüüd sõlmele ümber kirjutatuna, nii et kõik, mis oli seotud nende podi aadressidega, näeb teist saatjat. Ohvriteks on logid, lubatud loendid ja kohalikud tulemüürireeglid, mis nimetavad podi aadresse, ja need ebaõnnestuvad vaikselt. Teatage muudatusest kui käitumise muutusest, mitte parandusest.

Mitme sõlmepooliga kobaras kontrollige, kas agent on planeeritud sõlmedele, kus mõjutatud podid tegelikult jooksevad. Pool ilma DaemonSetita hoiab oma vanu reegleid ja miski ConfigMapis ei näita seda.

Alternatiiv ja selle hind

Teine valik hoiab podi aadressid puutumatuna ja õpetab teed neist. Podi CIDR läheb Cloud VPN-i liiklusvalijatesse ja kohalik pool vajab selle jaoks tagasiteed, et vastused teaksid, kuhu minna. See säilitab podi identiteedi, mida mõned turvamudelid soovivad, ja laiendab nii marsruutimise kui ka tulemüüri ulatust, mille teine pool peab aktsepteerima.

Kauplemine on loetavus ulatuse vastu. Tõlkimine paneb kohaliku poole nägema ühte aadressi sõlme kohta, mida on lihtne lubatud loendisse panna ja mis varjab, milline pod mida saatis. Tõlkimata jätmine hoiab podi aadressi otsast otsani, mis on atributsiooni jaoks parem ja halvem iga seadme jaoks teel, mis peab uue vahemiku õppima. Kumbki valik pole Dockeri ega CNI defekt; mõlemad on marsruutimisotsused, millel on operatiivne arve. Valige see, mille arve teie meeskond suudab maksta, ja kirjutage üles, miks.

Kontrollige ja võtke tagasi

Käivitage sama püüdmine uuesti. Sõlmetasandi püüdmine, mis pärast teie redigeerimist ikka podi aadressi prindib, tähendab, et reeglid ei muutunud kunagi, mida iganes ConfigMap ütleb. Juhe on fakt; kõik muu on järeldus.

Seejärel kontrollige vastassuunda, sest pooled neist muudatustest kontrollitakse ainult väljuvas suunas. Kinnitage, et vastus jõuab sõlme või podini, mis päringu saatis, ja kinnitage, et rakendus lõpetas, mitte ainult ei saanud SYN-i. Püüdmine, mis näitab päringut ilma vastuseta, on marsruutimisprobleem teisel pool, mitte masquerade-probleem sellel pool.

Tagasivõtmine on eelmine ConfigMap, rakendatud samamoodi, sama kinnitusega, et agent taaskäivitus ja reeglid muutusid. Hoidke muudatuste kirjes ühe teadaoleva päringu lähteaadress enne ja pärast, sest just see üks rida tõestab, et muudatus tegi seda, mida te ütlesite. GKE IP masquerade agendi juhend dokumenteerib vaikeväärtused ja ConfigMapi väljad. Kui lähteaadress ei muutu pärast juurutust, ei jookse agent sellel sõlmel ja ükski YAML-i redigeerimine ei paranda seda.