GKE pod-дору VPN аркылуу жергиликтүү хостторго эмне үчүн жетпейт

Ping түйүндөн иштейт, podдон иштебейт, жана жергиликтүү тарапка эч нерсе жетпейт. Туннель менен маршрут тартибинде; зымдагы булак дареги андай эмес. Бул эки учурдун айырмасы — пакет кластерден чыкканда өзүн ким деп жарыялашында, жана GKEдин бул тууралуу өз пикири бар. Механизм — masquerade өзгөчөлүктөрүнүн тизмеси, аны окууга бир буйрук жетет.

Бир нерсени өзгөртүүдөн мурун күчүндөгү тизмени окуңуз

GKE ар бир багыт диапазону боюнча pod трафиги чыгууда түйүн дарегине кайра жазылабы, ошону чечкен агентти жеткирет. Анын демейки конфигурациясы үч RFC1918 блогун, 10.0.0.0/8, 172.16.0.0/12 жана 192.168.0.0/16, өзгөчөлүк багыттары катары атайт. Ошондуктан podдон жергиликтүү 10.x хостко жибергенин баары түйүндөн podдун өз дареги менен чыгат. Түйүндүн өз трафиги кайра жазылбайт, дал ошондуктан анын 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.

Муну каршы тарап билдирген менен салыштырыңыз. Жергиликтүү жерде pod дарегин көрсөткөн жана жообу жок кармоо чөйрөнү жабат: өзгөчөлүктөр тизмеси асимметрияны туннель бузулуусуз түшүндүрөт. Бир булак дарегинин эки байкоосу CNI тууралуу божомолдоону токтотууга жетет.

Өзгөчөлүктү pod CIDRине чейин тарылтыңыз

Колдоого алынган оңдоо өзгөчөлүктү жоюунун ордуна тарылтат: pod CIDRин өзгөчөлүк катары калтырып, 10.x мейкиндигинин калганын алып салыңыз. Ал тизме агенттин ConfigMapинде nonMasqueradeCIDRs астында турат, аны өзгөртүү — түзөтүү, андан кийин чыгаруу. Кенен жазууну кластердин чыныгы pod диапазону менен алмаштырыңыз, кластер ичиндеги трафикке дагы керек болсо башка жеке блокторду калтырыңыз, жана себебиңиз жок болсо resyncInterval параметрин өзгөртпөңүз. Колдонуңуз, агент podдору кайра башталганын жана ядро эрежелери өзгөргөнүн ырастаңыз.

Бул чыныгы таасир радиусу бар бүт кластерге тийиштүү өзгөртүү. Ал күчүнө киргенден кийин, мурун pod булагын сактаган трафик эми түйүнгө кайра жазылып келет, ошондуктан ошол pod даректерине байлангандын баары башка жиберүүчүнү көрөт. Курмандыктар — pod даректерин атаган журналдар, уруксат тизмелери жана жергиликтүү firewall эрежелери, жана алар үнсүз иштебей калат. Өзгөртүүнү оңдоо катары эмес, жүрүм-турум өзгөрүүсү катары жарыялаңыз.

Бир нече түйүн пулу бар кластерде агент жабыркаган podдор чындап иштеген түйүндөргө пландалганын текшериңиз. DaemonSet жок пул өзүнүн эски эрежелерин сактайт, жана ConfigMapде муну эч нерсе көрсөтпөйт.

Альтернатива жана анын баасы

Башка вариант pod даректерин бузулбай сактайт жана жолго аларды үйрөтөт. Pod CIDRи Cloud VPN трафик селекторлоруна кирет, ал эми жергиликтүү тарапка жооптор кайда барарын билиши үчүн ага кайтаруу маршруту керек. Бул кээ бир коопсуздук моделдери каалаган pod инсандыгын сактайт жана каршы тарап кабыл алышы керек болгон маршруттоо менен firewall аумагын кеңейтет.

Алмашуу — окулушу менен аумак. Которуу жергиликтүү тарапка түйүн сайын бир дарек көрсөтөт, аны уруксат тизмесине кошуу оңой жана кайсы pod эмнени жибергенин жашырат. Которбосо, pod дареги учтан учка чейин сакталат, бул атрибуция үчүн жакшы, ал эми жаңы диапазонду үйрөнүшү керек жолдогу ар бир түзмөк үчүн начар. Эки вариант тең Docker же CNI кемчилиги эмес; экөө тең операциялык эсеби бар маршруттоо чечимдери. Командаңыз төлөй алган эсеби бар вариантты тандаңыз жана себебин жазыңыз.

Текшериңиз жана кайтарыңыз

Ошол эле кармоону кайра иштетиңиз. Түзөтүүңүздөн кийин да pod дарегин басып чыгарган түйүн деңгээлиндеги кармоо эрежелер эч качан өзгөрбөгөнүн билдирет, ConfigMap эмне десе да. Факт — зым; калганынын баары корутунду.

Андан кийин карама-каршы багытты текшериңиз, анткени бул өзгөртүүлөрдүн жарымы гана сыртка карай текшерилет. Жооп сурам жиберген түйүнгө же podго жеткенин жана колдонмо SYN гана алып калбастан бүткөнүн ырастаңыз. Жоопсуз сурамды көрсөткөн кармоо — каршы тараптагы маршруттоо маселеси, бул тараптагы masquerade маселеси эмес.

Кайтаруу — мурунку ConfigMap, ошол эле ыкма менен колдонулган, агент кайра башталганы жана эрежелер өзгөргөнү тууралуу ошол эле ырастоо менен. Өзгөртүү жазуусунда бир белгилүү сурамдын булак дарегин мурун жана кийин сактаңыз, анткени дал ошол бир сап өзгөртүү айтканды жасаганын далилдейт. GKE IP masquerade агентинин колдонмосу демейки маанилерди жана ConfigMap талааларын документтейт. Эгер чыгарылгандан кийин булак дареги өзгөрбөсө, агент ошол түйүндө иштебейт жана YAMLды канча түзөтсөңүз да оңдолбойт.