Чому поди 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 цього не виправить.