Pod, solmu vai klusteri: mitä VPN-sidecar oikeasti reitittää uudelleen

VPN-sidecar Kubernetes-Podissa näyttää parempikäytöksiseltä VPN:ltä isäntätasolla, ja yhteys loppuu nimiavaruuden rajalle. Podissa olevat kontit jakavat verkon nimiavaruuden, mukaan lukien osoite- ja porttiavaruuden, joten reittejä ja käytäntöä asentava sidecar muuttaa todella sitä, minne sovelluksen paketit menevät. Se ei muuta mitään solmun muille Podeille eikä koske solmun omaan pinoon, ellet määritä sitä niin. Tuon rajan oikein saaminen ratkaisee sekä sen, mitä voit ottaa käyttöön, että sen, mitä sinun on testattava. Seuraavat osiot seuraavat sitä nimiavaruudesta ulospäin.

Jaettu nimiavaruus, jaetut seuraukset

Kaksi konttia Podissa puhuvat loopbackin kautta ja näkevät samat rajapinnat, ja siksi sidecar-malli ylipäätään toimii: sovelluksen ei tarvitse tietää tunnelista, koska reitti, johon se päätyy, asennettiin sen käyttämään nimiavaruuteen. Sama ominaisuus tarkoittaa, että sidecarin virheet ovat sovelluksen virheitä. Liikaa kaappaava reitti tai DNS-muutos, joka osoittaa tunnelin sisäiseen ratkaisijaan, koskee heti jokaista prosessia siinä Podissa. Jaetussa nimiavaruudessa ei ole konttikohtaista reititystä, joten sidecaria ei voi rajata yhteen prosessiin.

Tämä on mekanismi, joka kannattaa pitää mielessä katselmoinnissa: vaikutussäde on Pod, ei solmu eikä klusteri.

Mihin sidecar ei yllä

Muut Podit pitävät omat nimiavaruutensa ja oman reitityksensä, joten samaa uloskäyntiä tarvitseva työkuorma tarvitsee saman sidecarin tai sen sijaan solmutason suunnitelman. Myös solmun liikenne on Podin nimiavaruuden ulkopuolella, ja isäntäverkon Podit jättävät tämän eristyksen tarkoituksella kokonaan väliin. Jos ajat sidecarin isäntäverkolla päästäksesi johonkin kätevään, olet laajentanut laajuuden yhdestä Podista koko solmuun ja sinun pitäisi sanoa se ääneen.

Liikenne klusterin palveluihin on toinen yleinen yllätys. Podin sisäinen leveä oletusreitti voi kaapata pyyntöjä, jotka on tarkoitettu API-palvelimelle tai ClusterIP-palvelulle, ja ne epäonnistuvat sitten tavalla, joka näyttää rikkinäiseltä tunnelilta.

Reittisuunnitelma: Podin, palvelun, solmun ja VPN:n alueet

Kirjoita neljä aluetta muistiin ja tarkista ne päällekkäisyyden varalta ennen kuin otat mitään käyttöön: Podin CIDR, palvelun CIDR, solmun osoitteet ja VPN:n takana olevat kohteet. VPN:n yksityisten alueiden ja klusterin oman avaruuden päällekkäisyys ei ole harvinaista, ja oletusreitti on siihen väärä ratkaisu. Reittisuunnitelma kuuluu samaan repositorioon kuin manifesti, koska seuraava klusteri voi antaa täysin erilaiset Podien ja palvelujen alueet.

DNS on osa suunnitelmaa, ei erillinen huoli. Sidecar, joka kirjoittaa ratkaisijan kokoonpanon uudelleen, voi rikkoa palvelujen löytämisen klusterin sisällä, kun taas ulkoiset haut toimivat täydellisesti.

Käynnistys ja vikaantuminen ovat eksplisiittisiä tiloja

Käynnissä oleva sidecar-prosessi ei ole uloskäyntikäytäntö. Päätä, mikä liikenne saa virrata ennen tunnelin valmistumista ja mitä tapahtuu, jos se kuolee sen jälkeen, ja toteuta sitten päätös: sovelluskontin portittava probe, oletuksena kieltävä verkkokäytäntö tai molemmat. Ilman toista näistä sovellus käynnistyy, ratkaisee nimet ja lähettää liikennettä solmun tavallista polkua pitkin, kun tunneli vasta yhdistää.

Tuo aukko on terveessä klusterissa lyhyt ja rikkinäisessä pysyvä, ja juuri sitä ominaisuutta hyökkääjä tai tahaton tietovuoto suosii.

Yhdistä järjestys vikatestiin. Tapa sidecar ja varmista, että sovellus menettää aiotun uloskäyntinsä sen sijaan, että putoaisi hiljaa takaisin.

Oikeudet, käytännöt ja testaus sovelluskontista

Rajapintojen luomiseen ja reittien muuttamiseen tarvittavien oikeuksien myöntäminen on etuoikeuspäätös, eikä eristetylle Podille sopiva etuoikeus ole automaattisesti sopiva solmun pinossa. Käytä klusterin tukemia verkko- ja turvakäytäntöjen mekanismeja äläkä oleta, että jokainen CNI- tai käytäntötoteutus kohtelee VPN-rajapintaa samalla tavalla; erot näkyvät juuri niissä vikatapauksissa, joista välität.

Testaa todellisesta sovelluskontista tuoreilla pyynnöillä yksityiseen kohteeseen, klusterin palveluun ja julkiseen internetiin. Sidecarista tehty testi todistaa, että tunneli toimii, ei sitä että sovellus tavoittaa tarvitsemansa.

Dokumentoi klusterin verkko-oletukset VPN-kokoonpanon viereen. Työkuorman siirtäminen toiseen klusteriin on silloin reittisuunnitelman tarkistamisen harjoitus eikä image-muutos, joka lakkaa hiljaa toimimasta.