Kubernetes-тегі Pod VPN немесе шығу қақпасы: туннель кімдікі?

Сіз vpn-gateway атындағы Pod орналастырасыз, сынақ клиентін оның мекенжайына бағыттайсыз және пакеттердің жоғалып жатқанын көресіз. Манифестте ештеңе дұрыс емес және kubelet-тің шағымы жоқ. Себебі конфигурациялық емес, құрылымдық: Kubernetes әр Pod-қа өзінің желілік атаулар кеңістігін береді, сондықтан атау, белгі немесе ортақ API кеңістігі пакеттердің қайда кететінін өзгертпейді. Сондықтан VPN трафигінің кластерден қалай шығатынын шешу меншік туралы сұрақтан басталады, контейнер бейнелерінен емес.

Екі механизм нақты орналастырулардың көбін қамтиды және олар бірін-бірі алмастырмайды. Біреуі туннельді жұмыс жүктемесінің өзінің желілік атаулар кеңістігіне орналастырады. Екіншісі CNI-ден таңдалған трафикті белгіленген қақпа түйіні арқылы өткізуді сұрайды. Олар әртүрлі сәтсіздікке ұшырайды, әртүрлі масштабталады және әртүрлі командаларға бағынады, сондықтан контейнер туралы сұрақ әдетте ешқашан шешілмейтін дау туғызады.

Pod шекарасы — бұл атаулар кеңістігі, секіру хосты емес

Linux желілік атаулар кеңістігі өзінің интерфейстеріне, мекенжайларына, маршруттарына және брандмауэр ережелеріне ие, және әр Pod біреуін алады. Сол Pod ішіндегі контейнерлер оған қосылады, сондықтан көмекші контейнер қолданба кейін ұстанатын маршруттарды қайта жаза алады. Көрші Pod ұқсас көрінетін, бірақ толығымен бөлек стекке ие. Қақпа Pod мұра ете алатын ортақ кесте жоқ және бір атаулар кеңістігінен екіншісіне трафиктің жасырын берілуі жоқ.

Сондықтан қақпа-Pod үлгісі жоғарыдағы бірдеңе оған шынымен пакеттер жібергенде ғана жұмыс істейді: Service, түйіндегі статикалық маршрут немесе CNI-дегі бағыттау саясаты. Жалғыз мекенжай ештеңені тартпайды.

Әр Pod үшін туннель не береді және қанша тұрады

Жұмыс жүктемесінің атаулар кеңістігінде жұмыс істейтін туннель сол жүктемеге өзінің клиенттік сәйкестігін береді, оны көптеген қашықтан қатынау қызметтері сессияны рұқсат ету немесе есепке алу алдында талап етеді. Зақым радиусы да жергілікті болып қалады: бұзылған туннель бәрі пайдаланатын ортақ жолдың орнына бір Deployment-ті өшіреді. Оның қалай жұмыс істейтіні іске асыруға байланысты, және дәл осы жерде адамдар қате болжайды.

Тек ядро күйін қажет ететін баптау init контейнерінде аяқталып, шыға алады. Pod-тың бүкіл өмірі бойы тірі болуы керек пайдаланушы кеңістігіндегі демонға Kubernetes 1.29-да жергілікті sidecar ретінде енгізілген қайта іске қосылатын init контейнер пішімі қажет, және бұл айырмашылық дәмнен емес, туннельдің іске асырылуынан келеді. Бұл модельдің құны — қайталау: әр реплика аутентификациядан өтеді, өзінің туннель мекенжайын алады және қашықтағы сессия орнын алады, сондықтан автоскейлинг оқиғасы байланыстың арғы жағында сыйымдылық оқиғасына айналады. Бір тіркелгі деректерін барлық репликаға көшіру бұл құнды жоймайды, ол аудит ізін жояды. Рұқсаттар да сол тексеруге лайық, өйткені өз кеңістігінде NET_ADMIN қалайтын туннельдің privileged: true мысалындағы бүкіл хост билігін мұра етуге ешқандай себебі жоқ.

CNI шығуды иеленгенде

Егер CNI мұны қолдаса, шығу қақпасы трафикті жұмыс жүктемесі мен межелі ауқым бойынша таңдайды, содан кейін оны таңдалған түйіндер арқылы бір болжамды бастау мекенжайының астында жібереді. Cilium нұсқасы — кәдімгі сілтеме, және оның құжаттамасы бұл мүмкіндік үшін нақты Cilium конфигурациясы мен дұрыс интерфейстер мен мекенжайлармен қамтамасыз етілген қақпа түйіндері қажет екенін анық айтады. Ол сондай-ақ Pod жасалғаннан кейінгі бастапқы кезеңді атап өтеді, ол кезде бағыттау әлі қолданылмайды, бұл ескертпе емес, дизайн кірісі.

Бұл кідірісті өз уәдеңізбен салыстырып оқыңыз. Егер ереже басқа жолмен ешбір трафик шықпауы керек деген болса, саңылау кезінде жіберген жаңа Pod оны әлдеқашан бұзған, сондықтан іске қосу реті өз жауабын қажет етеді: саясат қолданылғанша қолданбаны ұстап тұрыңыз немесе терезені қабылдап, құжаттаңыз.

Мәлімдемені тар ұстаңыз. Шығу қақпасы жолды таңдап, оны аударады. Ол VPN-ды тоқтатпайды және оның артында қолдау көрсетілген байланыс болмаса, кластерді қашықтағы желіңіздің клиентіне айналдырмайды.

Аударма қашықтағы жақтың көретінін байқатпай өзгертеді

Қақпа бастауды қайта жазғаннан кейін әр Pod-тың мекенжайлары жоғалады, сондықтан сәйкестікке негізделген рұқсат тізімі бір ортақ мекенжайға негізделген тізімге айналады. Бұл ақау емес, айырбас: күтуге азырақ ереже, бірдеңе дұрыс емес әрекет еткенде дөрекірек телу.

Қолданба деңгейіндегі аутентификация мен сұраныс журналы желі енді хабарламайтын нәрсені көтеруі керек. Қақпа сыйымдылығы мен оны ауыстыруды ортақ инфрақұрылым ретінде қарастырыңыз, өйткені бір түйінді қайта жүктеу қазір оның артындағы әрбір жүктемені үзеді, және қайтару жолын ерте тексеріңіз: қашықтағы жақ аударылған мекенжайға қалай жетуді білуі керек, әдетте адамға, манифестке емес, тиесілі маршрут немесе NAT арқылы. Мекенжайларды жоспарлау да осында жатады, өйткені қабаттасатын кластер мен қашықтағы ауқымдар екі модельді де бұзады және IPv6-ны қабылдау қарама-қайшы жоспарды ақтамайды.

Меншік бойынша шешіңіз, содан кейін уәде етілген ақауды сынаңыз

Әр Pod үшін туннельді қашықтағы қызмет жекелеген жүктемелерді аутентификациялағанда, байланыс тек бірнеше Deployment-ке қажет болғанда және ақау жергілікті қалуы керек болғанда таңдаңыз. Қақпаны желі командасы жолды әлдеқашан иеленгенде, көп жүктеме бір межені бөліскенде және тұрақты бастау мекенжайы бүкіл жаттығудың мәні болғанда таңдаңыз.

Қалай болса да, тұрақты күйді емес, сатқан қасиетіңізді тексеріңіз. Pod жасаңыз, оған бірден жіберуге рұқсат беріңіз және уәде туннельден ештеңе қашпайды деген болса, алғашқы секундтарды бақылаңыз. Бес репликаға дейін масштабтаңыз және уәде әр жүктеме үшін сәйкестік болса, қашықтағы жақ хабарлайтын сессияларды санаңыз. Бұл екі тексеру механизмнің шегін манифестті қараудан әлдеқайда жылдам ашады және келесі оқиға қай командаға тиесілі екенін айтады.