Чаму поды GKE не дасягаюць лакальных хасцёў праз VPN

Пінг працуе з вузла і не працуе з пода, а на лакальны бок нічога не прыходзіць. Тунель і маршрут у парадку; адрас крыніцы на дроце — не. Гэтыя два выпадкі адрознівае тое, кім пакет сябе абвяшчае, калі пакідае кластар, і ў GKE на гэты конт ёсць меркаванне. Механізм — спіс выключэнняў masquerade, і каб яго прачытаць, патрэбна адна каманда.

Прачытайце дзейны спіс, перш чым нешта змяняць

GKE пастаўляе агента, які для кожнага дыяпазону прызначэння вырашае, ці будзе трафік подоў пры выхадзе перапісаны на адрас вузла. Яго пастаўленая канфігурацыя называе тры блокі RFC1918, 10.0.0.0/8, 172.16.0.0/12 і 192.168.0.0/16, як выключаныя прызначэнні. Таму ўсё, што вы адправіце з пода на лакальны хост 10.x, пакідае вузел з яшчэ прымацаваным адрасам самога пода. Трафік самога вузла не перапісваецца, і менавіта таму яго пінг працуе.

Прачытайце задуманую канфігурацыю і ўсталяваныя правілы, бо яны могуць не супадаць. kubectl -n kube-system get configmap ip-masq-agent -o yaml паказвае, што сказалі агенту, а kubectl -n kube-system get pods -l k8s-app=ip-masq-agent паказвае, ці нешта працуе, каб гэта ўжыць. На вузле iptables-save | grep -i masq паказвае правілы, якія сапраўды ёсць у ядры. Калі ConfigMap кажа адно, а правілы іншае, падазроны — агент, а не сетка.

Пацвердзіце адрас крыніцы перахопам

Зрабіце перахоп да таго, як змяняць спіс. Фільтр па адным прызначэнні пакідае вывад чытальным: tcpdump -ni any host 10.20.30.40.

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

Звужыце выключэнне да CIDR подоў

Падтрымліванае выпраўленне звужае выключэнне, а не выдаляе яго: пакіньце CIDR подоў выключаным і адкіньце астатнюю частку прасторы 10.x. Гэты спіс жыве ў ConfigMap агента пад ключом nonMasqueradeCIDRs, і яго змена — гэта праўка, за якой ідзе разгортванне. Замяніце шырокі запіс рэальным дыяпазонам подоў кластара, захавайце іншыя прыватныя блокі, калі трафіку ўнутры кластара яны яшчэ патрэбны, і не чапайце resyncInterval без прычыны. Ужывіце, пацвердзіце, што поды агента перазапусціліся, і пацвердзіце, што правілы ядра змяніліся.

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

У кластары з некалькімі пуламі вузлоў праверце, што агент запланаваны на вузлах, дзе сапраўды працуюць закранутыя поды. Пул без DaemonSet захоўвае свае старыя правілы, і нішто ў ConfigMap гэтага не пакажа.

Альтэрнатыва і яе цана

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

Абмен — чытальнасць супраць ахопу. Трансляцыя прымушае лакальны бок бачыць адзін адрас на вузел, што лёгка ўнесці ў спіс дазволаў і што хавае, які под што адправіў. Без трансляцыі адрас пода захоўваецца ад краю да краю, што лепш для атрыбуцыі і горш для кожнай прылады на шляху, якой трэба вывучыць новы дыяпазон. Ні адзін варыянт не з'яўляецца дэфектам Docker ці CNI; абодва — рашэнні пра маршрутызацыю з аперацыйным рахункам. Выберыце той, чый рахунак ваша каманда можа аплаціць, і запішыце чаму.

Праверце і адкаціце

Запусціце той жа перахоп зноў. Перахоп на ўзроўні вузла, які пасля вашай праўкі ўсё яшчэ друкуе адрас пода, азначае, што правілы так і не змяніліся, што б ні казаў ConfigMap. Дрог — гэта факт; усё астатняе — выснова.

Затым праверце зваротны кірунак, бо палова такіх змен правяраецца толькі на выхад. Пацвердзіце, што адказ даходзіць да вузла або пода, які адправіў запыт, і пацвердзіце, што праграма завяршылася, а не проста атрымала SYN. Перахоп, які паказвае запыт без адказу, — гэта праблема маршрутызацыі на тым баку, а не праблема masquerade на гэтым.

Адкат — гэта папярэдні ConfigMap, ужыты таксама, з тым жа пацверджаннем, што агент перазапусціўся і правілы змяніліся. Захавайце адрас крыніцы да і пасля для аднаго вядомага запыту ў запісе пра змену, бо менавіта гэты адзін радок даказвае, што змена зрабіла тое, што вы сказалі. Кіраўніцтва GKE па агенце IP masquerade апісвае прадвызначаныя значэнні і палі ConfigMap. Калі адрас крыніцы пасля разгортвання не змяніўся, агент не працуе на гэтым вузле, і ніякая праўка YAML гэтага не выправіць.