Pod IP, ClusterIP або ўнутраны балансіроўшчык нагрузкі для карыстальнікаў VPN

З VPC CNI Pod можа атрымаць адрас з VPC, і карыстальнік VPN з правільным маршрутам можа дасягнуць яго напрамую. Таму прамы доступ да Pod здаецца самым простым варыянтам, і так яно і ёсць, пакуль Pod не заменяць. Адрас, які памятае карыстальнік, павінен належаць праграме, а не рэпліцы. Параўнанне трох пунктаў уваходу зводзіцца да таго, які аб’ект валодае адрасам і што павінна працягваць працаваць, калі нагрузка перамяшчаецца.

Выбірайце спачатку па жыццёвым цыкле, затым па тым, што сетка павінна зрабіць, каб пункт уваходу стаў дасягальным.

Тры пункты ўваходу, тры жыццёвыя цыклы

Pod IP належыць Pod: выдзяляецца разам з ім і вызваляецца пасля яго завяршэння. ClusterIP належыць Service і з’яўляецца віртуальным, ён мае сэнс толькі там, дзе існуе маршрутызацыя сэрвісаў кластара. Унутраным балансіроўшчыкам нагрузкі валодае хмарны рэсурс, які кантролер кластара праграмуе бэкэндамі. Гэтыя мадэлі валодання прадказваюць збой, які вы атрымаеце: састарэлы адрас, недасягальнае імя або састарэлы набор бэкэндаў.

Запішыце параўнанне перад выбарам. Калі ўладальнік і збой названыя, выбар звычайна робіцца сам.

Прамы доступ да Pod: карысны, часовы

Прамы доступ сапраўды карысны для кантраляванай праверкі: адзін адміністратар, адна кароткая сесія, адзін канкрэтны порт. Але гэта дрэнны дагавор для карыстальнікаў, бо адрас — гэта дэталь рэалізацыі, якая змяняецца пры кожным разгортванні. А запіс такога адраса ў вікі — гэта шлях, якім працоўны сэрвіс ператвараецца ў чутку.

Гэта таксама заахвочвае шырокія правілы. Дазвол аднаму адміністратару дасягаць аднаго Pod не ёсць дазволам для кожнага адраса ў падсетцы вузла, і менавіта другое звычайна запісваюць.

ClusterIP: абмежаваны кластарам па задуме

ClusterIP працуе, бо dataplane кластара праграмуе для яго маршрутызацыю ўнутры кластара. З ноўтбука ў VPN адрас нічога не значыць, пакуль нешта свядома не адкрые яго. Імя, якое заканчваецца на svc.cluster.local, належыць DNS кластара, таму капіраванне яго на кліент з іншым рэзалверам дае імя, якога не існуе, а не памылку маршрутызацыі.

ClusterIP застаецца правільным пунктам уваходу для выклікальнікаў унутры кластара, уключаючы іншыя нагрузкі. Ён проста не з’яўляецца механізмам публікацыі для карыстальнікоў па-за даменам маршрутызацыі кластара.

Унутраны балансіроўшчык нагрузкі: апублікаваны шлях

Унутраны балансіроўшчык нагрузкі дае стабільны прыватны адрас і імя, на якое можа паказваць ваша зона, а кантролер трымае набор бэкэндаў актуальным, як апісвае кіраўніцтва EKS па балансіроўцы нагрузкі. Гэта той пункт уваходу, які перажывае звычайную замену Pod без рэдагавання дакумента. Ён каштуе хмарны рэсурс, канфігурацыю кантролера і маршрут ад VPN, і менавіта гэтыя часткі людзі недаацэньваюць.

Выкарыстоўвайце мадэль кантролера, якую кластар фактычна запускае. Анатацыі, напісаныя для адной інтэграцыі, не прымяняюцца да іншай.

Хто з’яўляецца крыніцай адраса

Групы бяспекі бачаць крыніцу, якая прыходзіць на іх мяжу, і гэта можа быць падключаны кліент або трансляваны адрас у залежнасці ад шляху VPN і балансіроўкі нагрузкі. На вузлах на базе EC2 звычайныя Pod VPC CNI па змаўчанні атрымліваюць групы ENI вузла, а падтрымоўваныя канфігурацыі могуць далучаць групы, спецыфічныя для Pod. Пішыце правілы для дакументаванага шляху, а не для меркаванага адраса ноўтбука.

Трымайце ўласны слухач праграмы і аўтэнтыфікацыю як асобныя сродкі кантролю. Сеткавае правіла, якое дазваляе паток, не з’яўляецца рашэннем аб аўтарызацыі, і абыходзіцца з ім так нельга.

Што перадаць карыстальнікам

Дайце карыстальнікам імя сэрвіса, а не адрас. Апублікуйце імя ў прыватнай зоне, накіруйце яго на ўнутраны пункт уваходу, а затым праверце, замяніўшы бэкэнд-Pod, пакуль кліент трымае тое ж імя адкрытым. Гэта практыкаванне правярае ўласцівасць, якая мае значэнне: дасягненне той жа праграмы пасля звычайнага разгортвання.

Трымайце прамы доступ да Pod як дакументаванае аперацыйнае выключэнне з уласным ахопам, далёка ад інструкцый для карыстальнікоў.