Pod, knooppunt of cluster: wat in VPN-sidecar eins omroutet

In VPN-sidecar yn in Kubernetes-Pod liket op in VPN op hostnivo mei bettere manieren, en de likenis hâldt op by de grins fan 'e nammeromte. Konteners yn ien Pod diele de netwurknammeromte, ynklusyf de adres- en poarteromte, dus in sidecar dy't rûtes en belied ynstallearret feroaret echt wêr't de pakketten fan 'e applikaasje hinne geane. It feroaret neat foar de oare Pods op it knooppunt, en it rekket de eigen stack fan it knooppunt net oan, útsein as jo it sa konfigurearje. Dy grins goed krije bepaalt sawol wat jo útrolle kinne as wat jo testen moatte. De seksjes hjirûnder folgje it fan 'e nammeromte nei bûten.

Dielde nammeromte, dielde gefolgen

Twa konteners yn in Pod prate oer loopback en sjogge deselde ynterfaces, en dêrom wurket it sidecar-patroan überhaupt: de applikaasje hoecht net te witten dat der in tunnel is, want de rûte dêr't it op útkomt waard ynstallearre yn 'e nammeromte dy't it brûkt. Deselde eigenskip betsjut dat de flaters fan 'e sidecar de flaters fan 'e applikaasje binne. In rûte dy't te folle fangt, of in DNS-feroaring dy't nei in resolver yn 'e tunnel wiist, jildt daliks foar elk proses yn dy Pod. Yn in dielde nammeromte is der gjin routing per kontener, dus in sidecar kin net ta ien proses beheind wurde.

Dit is it meganisme om by de resinsje yn gedachten te hâlden: de ympaktradius is de Pod, net it knooppunt en net it cluster.

Wat de sidecar net berikt

Oare Pods hâlde har eigen nammeromten en har eigen routing, dus in wurklast dy't deselde útgong nedich hat, hat deselde sidecar nedich of ynstee in ûntwerp op knooppuntnivo. Ek it ferkear fan it knooppunt is bûten de nammeromte fan 'e Pod, en Pods mei hostnetwurk kieze bewust om hielendal fan dizze isolaasje ôf te sjen. As jo de sidecar mei hostnetwurk draaie om iets handichs te berikken, hawwe jo it berik fan ien Pod nei it hiele knooppunt ferbrede en moatte jo dat lûd sizze.

Ferkear nei de tsjinsten fan it cluster is de oare gewoane ferrassing. In brede standertrûte yn 'e Pod kin fersiken fange dy't foar de API-tsjinner of in ClusterIP-tsjinst bedoeld binne, en dy mislearje dan op in manier dy't liket as is de tunnel stikken.

Rûteplan: Pod-, tsjinst-, knooppunt- en VPN-berikken

Skriuw de fjouwer berikken op en kontrolearje se op oerlaap foardat jo eat útrolle: Pod-CIDR, tsjinst-CIDR, adressen fan it knooppunt en de bestimmingen efter de VPN. Oerlaap tusken de privee-berikken fan 'e VPN en de eigen romte fan it cluster is net seldsum, en in standertrûte is de ferkearde oplossing dêrfoar. It rûteplan heart yn deselde repository as it manifest, want it folgjende cluster kin hiel oare Pod- en tsjinstberikken jaan.

DNS is diel fan it plan en net in aparte soarch. In sidecar dy't de resolver-konfiguraasje oerskriuwt kin tsjinstûntdekking yn it cluster brekke wylst eksterne sykjen perfekt wurkje.

Opstarten en falen binne eksplisite tastannen

In draaiend sidecar-proses is gjin útgongsbelied. Beskiede hokker ferkear streame mei foardat de tunnel klear is en wat der bart as er dêrnei deaget, en ymplementearje dan dat beslút: in probe dy't de applikaasjekontener bannet, in netwurkbelied dat standert wegeret, of beide. Sûnder ien fan dy begjint de applikaasje, lost op en stjoert ferkear bûten it normale paad fan it knooppunt wylst de tunnel noch ferbynt.

Dy kloof is koart yn in sûn cluster en permanint yn in stikken ien, en dat is krekt de eigenskip dy't in oanfaller of in tafallige datalek foarkomt.

Keppelje de oardering oan in falstest. Deadzje de sidecar en befêstigje dat de applikaasje syn bedoelde útgong ferliest ynstee fan stil werom te fallen.

Kapasiteiten, belied en testen fanút de app-kontener

It jaan fan 'e kapasiteiten dy't nedich binne om ynterfaces te meitsjen en rûtes te feroarjen is in privilezje-beslút, en in privilezje dat geskikt is foar in isolearre Pod is net automatysk geskikt op 'e stack fan it knooppunt. Brûk de netwurk- en feiligensbeliedsmeganismen dy't it cluster stipet, en nim net oan dat elke CNI- of beliedsimplemintaasje in VPN-ynterface itselde behannelet; de ferskillen komme krekt yn 'e falgefollen dy't jo wichtich fine.

Test fanút de echte applikaasjekontener, mei nije fersiken nei in privee bestimming, in clustertsjinst en it iepenbiere ynternet. In test fanút de sidecar bewiist dat de tunnel wurket, net dat de applikaasje berikt wat it nedich hat.

Dokumintearje de netwurkoannames fan it cluster njonken de VPN-konfiguraasje. De wurklast nei in oar cluster ferpleatsen is dan in oefening yn it kontrolearjen fan it rûteplan ynstee fan in byldferoaring dy't stil ophâldt te wurkjen.