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, дазвольце яму перадаваць адразу і глядзіце першыя секунды, калі абяцанне было, што нішто не ўцячэ з тунеля. Масштабуйце да пяці рэплік і палічыце сесіі, якія паведамляе аддалены бок, калі абяцаннем была ідэнтычнасць для кожнай нагрузкі. Гэтыя дзве праверкі выкрываюць межы механізма значна хутчэй за агляд маніфеста, і яны кажуць, якая каманда валодае наступным інцыдэнтам.