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 түзүңүз, ага дароо жиберүүгө уруксат бериңиз жана убада туннелден эч нерсе качпайт деген болсо, алгачкы секунддарды байкаңыз. Беш репликага чейин масштабдаңыз жана убада ар бир жүктөм үчүн инсандык болсо, алыскы тарап билдирген сессияларды санаңыз. Бул эки текшерүү механизмдин чектерин манифестти карап чыгуудан алда канча тез ачат жана кийинки окуя кайсы командага таандык экенин айтат.