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, оставете го да предава веднага и наблюдавайте първите секунди, ако обещанието беше, че нищо не избягва от тунела. Мащабирайте до пет реплики и пребройте сесиите, които отдалеченият край докладва, ако обещанието беше идентичност за всяко натоварване. Тези две проверки разкриват границите на механизма много по-бързо от преглед на манифеста и ви казват кой екип притежава следващия инцидент.