Pod VPN во Kubernetes наспроти излезна порта: чиј е тунелот?

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

Два механизми покриваат повеќето реални распоредувања и тие не се заменливи. Едниот го става тунелот во сопствениот мрежен именски простор на работното оптоварување. Другиот бара од CNI да го насочи избраниот сообраќај низ назначен јазол-порта. Тие не успеваат на различен начин, се скалираат различно и одговараат на различни тимови, поради што прашањето за контејнерите обично создава расправии што никогаш не се решени.

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

Мрежниот именски простор на Linux ги поседува своите интерфејси, адреси, рути и firewall правила, и секој 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, оставете го веднаш да праќа и гледајте ги првите секунди ако ветувањето беше дека ништо не избегува од тунелот. Скалирајте на пет реплики и избројте ги сесиите што ги известува далечинскиот крај ако ветувањето беше идентитет по работно оптоварување. Овие две проверки ги откриваат границите на механизмот многу побрзо од преглед на манифестот, и ви кажуваат кој тим го поседува следниот инцидент.