Kubernetesin Pod-VPN vai lähtöyhdyskäytävä: kenelle tunneli kuuluu?

Julkaiset Podin nimeltä vpn-gateway, osoitat testiasiakkaan sen osoitteeseen ja näet pakettien katoavan. Manifestissa ei ole mitään väärää eikä kubeletilla ole valittamista. Syy on rakenteellinen, ei konfiguraatioon liittyvä: Kubernetes antaa jokaiselle Podille oman verkkonimiavaruutensa, joten nimi, tunniste tai jaettu API-nimiavaruus ei muuta mitään siinä, minne paketit menevät. Päätös siitä, miten VPN-liikenne poistuu klusterista, alkaa siis omistajuutta koskevasta kysymyksestä, ei kontti-imagoista.

Kaksi mekanismia kattaa useimmat todelliset käyttöönotot, eivätkä ne ole vaihdettavissa. Toinen sijoittaa tunnelin työkuorman omaan verkkonimiavaruuteen. Toinen pyytää CNI:tä ohjaamaan valitun liikenteen määrätyn yhdyskäytäväsolmun kautta. Ne epäonnistuvat eri tavoin, skaalautuvat eri tavoin ja vastaavat eri tiimeille, minkä vuoksi konttikysymys tuottaa yleensä väittelyitä, jotka eivät koskaan ratkea.

Podin raja on nimiavaruus, ei hyppykone

Linuxin verkkonimiavaruus omistaa rajapintansa, osoitteensa, reittinsä ja palomuurisääntönsä, ja jokainen Pod saa yhden. Sen Podin sisällä olevat kontit liittyvät siihen, ja juuri siksi apukontti voi kirjoittaa uudelleen reittejä, joita sovellus sitten seuraa. Viereisellä Podilla on samannäköinen mutta täysin erillinen pino. Ei ole jaettua taulukkoa, jonka yhdyskäytävä-Pod voisi periä, eikä liikenteen implisiittistä siirtoa nimiavaruudesta toiseen.

Siksi yhdyskäytävä-Podin malli toimii vasta, kun jokin ylävirrassa todella lähettää paketteja sille: Service, solmun staattinen reitti tai CNI:n ohjauskäytäntö. Pelkkä osoite ei houkuttele mitään.

Mitä tunnelia Podia kohden ostaa ja mitä se maksaa

Työkuorman nimiavaruudessa toimiva tunneli antaa kyseiselle työkuormalle oman asiakasidentiteettinsä, jota monet etäkäyttöpalvelut vaativat ennen istunnon valtuuttamista tai laskentaa. Vaikutusalue pysyy myös paikallisena: rikki mennyt tunneli poistaa yhden Deploymentin jaetun polun sijaan, jota kaikki käyttävät. Miten se toimii, riippuu toteutuksesta, ja tässä ihmiset arvaavat väärin.

Asennus, joka tarvitsee vain ytimen tilaa, voi päättyä init-kontissa ja poistua. Käyttäjätilan taustaprosessi, jonka on pysyttävä elossa Podin koko elinkaaren, tarvitsee uudelleenkäynnistettävän init-kontin muodon, joka esiteltiin natiivina sivukonttina Kubernetes 1.29:ssä, ja tämä ero tulee tunnelin toteutuksesta, ei mausta. Tämän mallin hinta on kahdentuminen: jokainen replika todentaa, saa oman tunneliosoitteensa ja vie etäistuntopaikan, joten automaattisen skaalauksen tapahtumasta tulee kapasiteettitapahtuma linkin toisella puolella. Yhden tunnistetiedon kopioiminen kaikkiin replikoihin ei poista tätä hintaa, se poistaa auditointijäljen. Käyttöoikeudet ansaitsevat saman tarkastelun, koska tunnelilla, joka haluaa NET_ADMIN omassa nimiavaruudessaan, ei ole syytä periä koko isännän valtaa privileged: true-esimerkistä.

Kun CNI omistaa lähdön

Jos CNI tukee sitä, lähtöyhdyskäytävä valitsee liikenteen työkuorman ja kohdealueen mukaan ja lähettää sen sitten valittujen solmujen kautta yhden ennustettavan lähdeosoitteen alla. Ciliumin versio on tavallinen viite, ja sen dokumentaatio sanoo selvästi, että ominaisuus vaatii tietyn Cilium-konfiguraation sekä yhdyskäytäväsolmut, joihin on provisionoitu oikeat rajapinnat ja osoitteet. Se mainitsee myös alkujakson Podin luomisen jälkeen, jolloin ohjausta ei vielä valvota, mikä on suunnittelusyöte eikä alaviite.

Lue tämä viive omaa lupaustasi vasten. Jos sääntö on, ettei mikään liikenne saa poistua toista polkua, uusi Pod, joka lähettää aukon aikana, on jo rikkonut sen, joten käynnistysjärjestys tarvitsee oman vastauksensa: pidätä sovellusta, kunnes käytäntö astuu voimaan, tai hyväksy ikkuna ja dokumentoi se.

Pidä väite kapeana. Lähtöyhdyskäytävä valitsee ja kääntää polun. Se ei lopeta VPN:ää eikä tee klusterista etäverkkosi asiakasta ilman tuettua yhteyttä sen takana.

Kääntäminen muuttaa hiljaa sitä, mitä etäpuoli näkee

Kun yhdyskäytävä kirjoittaa lähteen uudelleen, Podikohtaiset osoitteet katoavat, joten identiteettiin perustuvasta sallittujen luettelosta tulee yhteen jaettuun osoitteeseen perustuva luettelo. Se on vaihtokauppa, ei vika: vähemmän sääntöjä ylläpidettäväksi, karkeampi kohdistus, kun jokin käyttäytyy huonosti.

Sovellustason todentamisen ja pyyntölokien on kannettava se, mitä verkko ei enää raportoi. Kohtele yhdyskäytävän kapasiteettia ja korvaamista jaettuna infrastruktuurina, koska yhden solmun uudelleenkäynnistys keskeyttää nyt jokaisen työkuorman sen takana, ja tarkista paluupolku varhain: etäpään on tiedettävä, miten käännettyyn osoitteeseen päästään, yleensä reitin tai NAT:n kautta, jonka ihminen, ei manifesti, omistaa. Osoitesuunnittelu kuuluu myös tänne, sillä päällekkäiset klusterin ja etäverkon alueet rikkovat kumman tahansa mallin eikä IPv6:n käyttöönotto oikeuta ristiriitaista suunnitelmaa.

Päätä omistajuuden mukaan ja testaa sitten lupaamasi vika

Valitse tunnelia Podia kohden, kun etäpalvelu todentaa yksittäisiä työkuormia, kun vain harvat Deploymentit tarvitsevat linkin ja kun vian pitäisi pysyä paikallisena. Valitse yhdyskäytävä, kun verkkotiimi omistaa polun jo, kun monet työkuormat jakavat yhden kohteen ja kun vakaa lähdeosoite on koko harjoituksen tarkoitus.

Kummin tahansa, varmista myymäsi ominaisuus, älä vakaata tilaa. Luo Pod, päästä se lähettämään heti ja katso ensimmäiset sekunnit, jos lupaus oli, ettei mikään karkaa tunnelista. Skaalaa viiteen replikaan ja laske istunnot, jotka etäpää raportoi, jos lupaus oli identiteetti työkuormaa kohden. Nämä kaksi tarkistusta paljastavat mekanismin rajat paljon nopeammin kuin manifestin läpikäynti, ja ne kertovat, mikä tiimi omistaa seuraavan tapahtuman.