Jo sette in Pod mei de namme vpn-gateway yn, wize in testkliïnt nei syn adres en sjogge de pakketten ferdwine. Neat yn it manifest is ferkeard en de kubelet hat neat om oer te kleien. De reden is struktureel ynstee fan konfiguraasjoneel: Kubernetes jout elke Pod syn eigen netwurknammeromte, dus in namme, in label of in dielde API-nammerkromte feroaret neat oan wêr’t de pakketten geane. It beslút hoe’t VPN-ferkear it cluster ferlit, begjint dêrom mei in fraach oer eigendom, net oer containerbylden.

Twa meganismen dekke de measte echte ymplemintaasjes, en se binne net útwikselber. De iene set de tunnel yn ’e eigen netwurknammeromte fan ’e wurklêst. De oare freget it CNI om selekteare ferkear troch in oanwiisde poarteknooppunt te stjoeren. Se mislearje oars, skaalje oars en hearre by oare teams, en dêrom leveret de containerfraach meastentiids diskusjes op dy’t nea besljochte wurde.

In Pod-grins is in nammeromte, gjin springhost

In Linux-netwurknammeromte besit syn ynterfaces, adressen, rûtes en firewallregels, en elke Pod krijt ien. Containers yn dy Pod slute har dêrby oan, en dat is krekt wêrom’t in helpcontainer rûtes oanskriuwe kin dy’t de applikaasje dêrnei folget. In oanbuorjende Pod hat in itselde útsjende mar folslein aparte stipe. D’r is gjin dielde tabel dy’t in poarte-Pod ervje kin, en gjin ymplisite oerdracht fan ferkear fan ’e iene nammeromte nei de oare.

Dat is ek wêrom’t it poarte-Pod-patroan pas wurket as wat streamop wier pakketten derhinne stjoert: in Service, in statyske rûte op ’e knooppunt of stjoerbelied yn it CNI. In adres allinnich lûkt neat.

Wat in tunnel per Pod keapet, en wat it kostet

In tunnel dy’t yn ’e nammeromte fan ’e wurklêst rint, jout dy wurklêst syn eigen kliïntidentiteit, dy’t in protte remote-access-tsjinsten freegje foardat se in sesje autorisearje of ferantwurdzje. De skaderadius bliuwt ek lokaal: in brutsen tunnel skeakelet ien Deployment út ynstee fan it dielde paad dat alles brûkt. Hoe’t er rint hinget fan ’e ymplemintaasje ôf, en dêr riddenminske minsken ferkeard.

In opset dy’t allinnich kernelsteat nedich hat, kin yn in init-container einigje en ôfslute. In brûkersromte-daemon dy’t it hiele libben fan ’e Pod libje moat, hat de werstartbere init-containerfoarm nedich dy’t as native sidecar yn Kubernetes 1.29 yntrodusearre waard, en dat ûnderskie komt út ’e tunnelimplimintaasje, net út smaak. De kosten fan dit model binne dûbeling: elke replika autentisearret, krijt syn eigen tunneladres en beset in remote-sesjeplak, sadat in autoskaleringsbarren in kapasiteitsbarren oan ’e oare kant fan ’e ferbining wurdt. Ien bewiis fan identiteit nei alle replika’s kopiearje hellet dy kosten net fuort, it hellet it auditspoar fuort. Foech fertsjinnet deselde toets, want in tunnel dy’t NET_ADMIN yn syn eigen nammeromte wol, hat gjin reden om it gesach oer de hiele host fan in foarbyld mei privileged: true te ervjen.

Wannear’t it CNI de útgong besit

As it CNI it stipet, kiest in útgongspoarte ferkear op basis fan wurklêst en bestimmingsberik, en stjoert it dan fia keazen knooppunten ûnder ien foarsisber boarneadres. De ferzje fan Cilium is de gewoane referinsje, en syn dokumintaasje is dúdlik dat de funksje in spesifike Cilium-konfiguraasje freget plus poarteknooppunten mei de rjochte ynterfaces en adressen. It neamt ek in begjinperioade nei it oanmeitsjen fan ’e Pod wêryn’t stjoering noch net hanthavene wurdt, wat in ûntwerpynput is en gjin fuotnoot.

Lês dy fertraging tsjin jo eigen tasizzing. As de regel is dat gjin ferkear oer in oar paad fuortgean mei, hat in nije Pod dy’t yn ’e gat stjoert dy al brutsen, dus de opstartsekwinsje hat syn eigen antwurd nedich: hâld de applikaasje tsjin oant it belied jildt, of akseptearje it finster en dokumintearje it.

Hâld de bewearing smel. In útgongspoarte kiest en oerset in paad. It beëiniget gjin VPN, en it makket it cluster net ta in kliïnt fan jo remote netwurk sûnder in stipe ferbining derachter.

QuestionPer-Pod tunnelCNI egress gateway
Who holds the client identityEach workloadThe gateway, shared
What scaling changesEnrollment and sessions per replicaThroughput and capacity per node
What the remote side seesDistinct addressesOne translated source
Failure scopeOne DeploymentEvery workload behind the gateway

Oersetting feroaret stil wat de fiere kant sjocht

Sadree’t de poarte de boarne oanskriuwt, binne de adressen per Pod fuort, dus in tasteanlist basearre op identiteit wurdt in list basearre op ien dield adres. Dat is in ruil, gjin defekt: minder regels te ûnderhâlden, gruttere taskriuwing as der wat misgiet.

Autentikaasje op applikaasjenivo en oanfraachlogging moatte drage wat it netwurk net mear rapportearret. Behannelje poartekapasiteit en -ferfanging as dielde ynfrastruktuer, want in inkeld knooppuntwerstart ûnderbrekt no elke wurklêst derachter, en kontrolearje it werompaad betiid: it fiere ein moat witte hoe’t it it oersette adres berikt, meastentiids fia in rûte of NAT dy’t in minske, net in manifest, besitte moat. Adresplanning heart hjir ek by, want oerlappende cluster- en fiere berikken brekke beide modellen en it oannimmen fan IPv6 ferûntskuldiget gjin tsjinstridich plan.

Beslút op eigendom, en test dan de mislearring dy’t jo tasein hawwe

Kies de tunnel per Pod as de fiere tsjinst yndividuele wurklêsten autentisearret, as mar in pear Deployment de ferbining nedich hat en as in mislearring lokaal bliuwe moat. Kies de poarte as in netwurkteam it paad al besit, as in protte wurklêsten ien bestimming diele en as in stabel boarneadres it hiele doel fan ’e oefening is.

Hoe dan ek, ferifiearje it eigenskip dat jo ferkocht hawwe, net de stabile steat. Meitsje in Pod, lit it daliks stjoere en sjoch de earste sekonden as de tasizzing wie dat neat út ’e tunnel ûntkomt. Skaalje nei fiif replika’s en tel de sesjes dy’t it fiere ein rapportearret as de tasizzing identiteit per wurklêst wie. Dy twa kontrôles lizze de grinzen fan it meganisme folle rapper bleat as in resin fan it manifest, en se fertelle jo hokker team it folgjende ynsidint besit.

Relatearre artikelen