Зашто GKE подови не стижу до локалних хостова преко VPN-а

Ping ради са чвора и не успева са пода, а локално не стиже ништа. Тунел и рута су у реду; изворна адреса на жици није. Ова два случаја разликује то шта пакет тврди да јесте када напусти кластер, а GKE има мишљење о томе. Механизам је листа masquerade изузетака, а за њено читање потребна је једна команда.

Прочитајте важећу листу пре него што било шта промените

GKE испоручује агента који по опсегу одредишта одлучује да ли ће се саобраћај подова при изласку преписати на адресу чвора. Његова испоручена конфигурација наводи три RFC1918 блока, 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16, као изузета одредишта. Зато све што пошаљете са пода на локални 10.x хост напушта чвор са још прикаченом адресом самог пода. Саобраћај самог чвора се не преписује, и управо зато његов ping ради.

Прочитајте предвиђену конфигурацију и инсталирана правила, јер она могу да се не слажу. 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-ју.

Сузите изузетак на pod CIDR

Подржана поправка сужава изузеће уместо да га уклони: задржите pod CIDR изузетим и одбаците остатак 10.x простора. Та листа живи у ConfigMap-у агента под nonMasqueradeCIDRs, а њена промена је измена после које следи распоређивање. Замените широки унос стварним опсегом подова кластера, задржите остале приватне блокове ако је саобраћају унутар кластера још потребан, и оставите resyncInterval на миру осим ако имате разлог. Примените, потврдите да су се подови агента поново покренули и потврдите да су се правила језгра променила.

Ово је промена на нивоу целог кластера са стварним радијусом дејства. Након што ступи на снагу, саобраћај који је раније задржавао своје порекло пода сада стиже преписан на чвор, па све што се ослањало на те адресе подова види другог пошиљаоца. Жртве су дневници, листе дозвола и локална firewall правила која наводе адресе подова, и она тихо отказују. Објавите промену као промену понашања, а не као поправку.

У кластеру са неколико пулова чворова проверите да ли је агент заказан на чворовима на којима погођени подови заиста раде. Пул без DaemonSet-а задржава своја стара правила, и ништа у ConfigMap-у то неће показати.

Алтернатива и њена цена

Друга опција оставља адресе подова нетакнуте и учи пут о њима. Pod CIDR улази у селекторе саобраћаја Cloud VPN-а, а локалној страни је потребна повратна рута за њега да би одговори знали куда иду. То чува идентитет пода, који неки безбедносни модели желе, и проширује и обим рутирања и обим firewall-а који супротна страна мора да прихвати.

Трговина је читљивост наспрам обима. Превођење чини да локална страна види једну адресу по чвору, што је лако ставити на листу дозвола и скрива који је под шта послао. Без превођења адреса пода остаје од краја до краја, што је боље за приписивање а горе за сваки уређај на путу који мора да научи нови опсег. Ниједна опција није дефект Docker-а или CNI-ја; обе су одлуке о рутирању са оперативним рачуном. Изаберите ону чији рачун ваш тим може да плати, и запишите зашто.

Проверите и вратите

Покрените исто снимање поново. Снимак на нивоу чвора који и после ваше измене штампа адресу пода значи да се правила никада нису променила, шта год ConfigMap говорио. Жица је чињеница; све остало је закључак.

Затим проверите супротан смер, јер се половина ових промена проверава само на излазу. Потврдите да одговор стиже до чвора или пода који је послао захтев и потврдите да је апликација завршила, а не само примила SYN. Снимак који показује захтев без одговора је проблем рутирања на супротној страни, не masquerade проблем на овој.

Враћање је претходни ConfigMap, примењен на исти начин, са истом потврдом да се агент поново покренуо и да су се правила променила. Сачувајте изворну адресу пре и после за један познати захтев у запису о промени, јер управо та једна линија доказује да је промена учинила оно што сте рекли. GKE водич за IP masquerade агента документује подразумеване вредности и поља ConfigMap-а. Ако изворна адреса после распоређивања остане непромењена, агент не ради на том чвору и никакво уређивање YAML-а то неће поправити.