VPN по Pod-у у Kubernetes-у наспрам излазне капије: коме припада тунел?

Постављате Pod са именом vpn-gateway, усмеравате тест клијента на његову адресу и гледате како пакети нестају. Ништа у манифесту није погрешно и kubelet нема шта да замери. Разлог је структурни, а не конфигурациони: Kubernetes даје сваком Pod-у сопствени мрежни простор имена, па име, ознака или заједнички API простор имена не мењају ништа у томе куда пакети иду. Зато одлука о томе како VPN саобраћај напушта кластер почиње питањем о власништву, а не о сликама контејнера.

Два механизма покривају већину стварних распоређивања и нису заменљиви. Један ставља тунел у сопствени мрежни простор имена радног оптерећења. Други тражи од CNI-ја да усмери изабрани саобраћај кроз одређени чвор капије. Они не успевају на различите начине, скалирају се различито и одговарају различитим тимовима, због чега питање контејнера обично ствара расправе које се никада не завршавају.

Граница Pod-а је простор имена, а не хост за скок

Мрежни простор имена Linux-а поседује своје интерфејсе, адресе, руте и правила заштитног зида, и сваки Pod добија један. Контејнери у том Pod-у му се придружују, и управо зато помоћни контејнер може да препише руте које апликација затим прати. Суседни Pod има идентично изгледајући, али потпуно одвојен стек. Нема заједничке табеле коју би Pod капије могао да наследи, ни имплицитног предаје саобраћаја из једног простора имена у други.

Зато образац Pod-а капије ради само када нешто узводно заиста шаље пакете ка њему: Service, статична рута на чвору или политика усмеравања у CNI-ју. Сама адреса не привлачи ништа.

Шта тунел по Pod-у доноси и колико кошта

Тунел који ради у простору имена радног оптерећења даје том оптерећењу сопствени идентитет клијента, који многе услуге даљинског приступа захтевају пре него што одобре или обрачунају сесију. Радијус штете такође остаје локалан: покварен тунел избацује један Deployment уместо заједничке путање коју користи све. Како ради зависи од имплементације, и управо ту људи погрешно нагађају.

Подешавање које захтева само стање језгра може да се заврши у init контејнеру и изађе. Демон у корисничком простору који мора да остане жив током целог живота Pod-а захтева рестартабилну форму init контејнера уведену као нативни бочни контејнер у Kubernetes 1.29, и та разлика долази из имплементације тунела, а не из укуса. Цена овог модела је дупликација: свака реплика се аутентификује, добија сопствену адресу тунела и заузима место даљинске сесије, па догађај аутоматског скалирања постаје догађај капацитета на другој страни везе. Копирање једног акредитива у све реплике не уклања ту цену, оно уклања траг ревизије. И дозволе заслужују исту проверу, јер тунел који жели NET_ADMIN у сопственом простору имена нема разлога да наследи власт над целим хостом из примера са privileged: true.

Када CNI поседује излаз

Ако CNI то подржава, излазна капија бира саобраћај према радном оптерећењу и опсегу одредишта, а затим га шаље кроз изабране чворове под једном предвидивом изворном адресом. Верзија Cilium-а је уобичајена референца, и њена документација јасно каже да функција захтева посебну Cilium конфигурацију плус чворове капије опремљене правим интерфејсима и адресама. Она такође напомиње почетни период после стварања Pod-а када усмеравање још није примењено, што је пројектни улаз, а не фуснота.

Прочитајте то кашњење наспрам свог обећања. Ако је правило да никакав саобраћај не сме да изађе другим путем, нови Pod који емитује током празнине већ га је прекршио, па низ за покретање треба сопствени одговор: задржите апликацију док се политика не примени, или прихватите прозор и документујте га.

Држите тврдњу уском. Излазна капија бира и преводи путању. Она не завршава VPN и не претвара кластер у клијента ваше даљинске мреже без подржане везе иза ње.

Превод тихо мења оно што даљинска страна види

Када капија препише извор, адресе по Pod-у нестају, па листа дозвољених заснована на идентитету постаје листа заснована на једној заједничкој адреси. То је замена, а не дефект: мање правила за одржавање, грубље приписивање када се нешто понаша лоше.

Аутентификација на нивоу апликације и евидентирање захтева морају да носе оно што мрежа више не извештава. Третирајте капацитет и замену капије као заједничку инфраструктуру, јер рестартовање једног чвора сада прекида свако радно оптерећење иза њега, и проверите повратни пут рано: даљински крај мора да зна како да стигне до преведене адресе, обично кроз руту или NAT који треба да поседује човек, а не манифест. И планирање адреса припада овде, јер опсези кластера и даљинске мреже који се преклапају кваре оба модела и усвајање IPv6 не оправдава противречан план.

Одлучите по власништву, затим тестирајте обећани неуспех

Изаберите тунел по Pod-у када даљинска услуга аутентификује појединачна радна оптерећења, када је веза потребна само неколицини Deployment-а и када неуспех треба да остане локалан. Изаберите капију када мрежни тим већ поседује путању, када много оптерећења дели једно одредиште и када је стабилна изворна адреса цео смисао вежбе.

Како год, проверите својство које сте продали, а не стабилно стање. Направите Pod, пустите га да одмах емитује и гледајте прве секунде ако је обећање било да ништа не бежи из тунела. Скалирајте на пет реплика и избројте сесије које даљински крај извештава ако је обећање био идентитет по радном оптерећењу. Ове две провере откривају границе механизма много брже од прегледа манифеста, и кажу вам ком тиму припада следећи инцидент.