Pod, узел или кластер: что на самом деле перенаправляет sidecar VPN

Sidecar VPN в Pod Kubernetes выглядит как VPN уровня хоста с лучшими манерами, и сходство заканчивается на границе пространства имён. Контейнеры в одном Pod разделяют сетевое пространство имён, включая пространство адресов и портов, поэтому sidecar, устанавливающий маршруты и политику, действительно меняет, куда уходят пакеты приложения. Для остальных Pod на узле он не меняет ничего и не затрагивает собственный стек узла, если вы не настроите его так. Правильное понимание этой границы определяет и то, что можно развернуть, и то, что нужно проверить. Разделы ниже прослеживают это от пространства имён наружу.

Общее пространство имён, общие последствия

Два контейнера в Pod общаются через loopback и видят одни и те же интерфейсы, и именно поэтому шаблон sidecar вообще работает: приложению не нужно знать о существовании туннеля, потому что маршрут, который оно получает, установлен в том пространстве имён, которое оно использует. То же свойство означает, что ошибки sidecar — это ошибки приложения. Маршрут, который захватывает слишком много, или изменение DNS, указывающее на резолвер внутри туннеля, немедленно действует на каждый процесс в этом Pod. В общем пространстве имён нет маршрутизации по контейнерам, поэтому sidecar нельзя ограничить одним процессом.

Это механизм, который стоит держать в голове при проверке: радиус поражения — это Pod, а не узел и не кластер.

Куда sidecar не достаёт

Остальные Pod сохраняют свои пространства имён и свою маршрутизацию, поэтому нагрузке, которой нужен тот же выход, нужен тот же sidecar или, вместо этого, проект на уровне узла. Трафик узла тоже находится вне пространства имён Pod, а Pod с сетью хоста намеренно полностью отказываются от этой изоляции. Если вы запускаете sidecar с сетью хоста, чтобы добраться до чего-то удобного, вы расширили область с одного Pod на весь узел и должны сказать это вслух.

Трафик к сервисам кластера — другой частый сюрприз. Широкий маршрут по умолчанию внутри Pod может перехватить запросы, предназначенные серверу API или сервису ClusterIP, и они затем падают так, будто туннель сломан.

План маршрутов: диапазоны Pod, сервисов, узла и VPN

Запишите четыре диапазона и проверьте их на пересечение, прежде чем что-либо разворачивать: CIDR Pod, CIDR сервисов, адреса узла и назначения за VPN. Пересечение приватных диапазонов VPN с собственным пространством кластера не редкость, и маршрут по умолчанию — неправильное решение для этого. План маршрутов должен лежать в том же репозитории, что и манифест, потому что следующий кластер может выдать совсем другие диапазоны Pod и сервисов.

DNS — часть плана, а не отдельная забота. Sidecar, который переписывает конфигурацию резолвера, может сломать обнаружение сервисов внутри кластера, хотя внешние запросы работают идеально.

Запуск и отказ — это явные состояния

Работающий процесс sidecar — не политика выхода. Решите, какой трафик может идти до готовности туннеля и что произойдёт, если он умрёт после этого, затем реализуйте это решение: проба, которая придерживает контейнер приложения, сетевая политика, отклоняющая по умолчанию, или и то и другое. Без одного из этого приложение запускается, разрешает имена и отправляет трафик обычным путём узла, пока туннель ещё подключается.

Этот зазор короток в здоровом кластере и постоянен в сломанном, и именно это свойство предпочитает атакующий или случайная утечка данных.

Соедините порядок с тестом отказа. Убейте sidecar и убедитесь, что приложение теряет предназначенный выход, а не откатывается молча.

Возможности, политики и тестирование из контейнера приложения

Выдача возможностей, нужных для создания интерфейсов и изменения маршрутов, — это решение о привилегиях, и привилегия, подходящая для изолированного Pod, не обязательно подходит для стека узла. Используйте поддерживаемые кластером механизмы сетевой и security-политики и не предполагайте, что любая реализация CNI или политики обращается с VPN-интерфейсом одинаково; различия проявляются именно в тех случаях отказа, которые вам важны.

Тестируйте из настоящего контейнера приложения, с новыми запросами к приватному назначению, сервису кластера и публичному интернету. Тест из sidecar доказывает, что туннель работает, а не что приложение достигает нужного.

Задокументируйте сетевые допущения кластера рядом с конфигурацией VPN. Тогда перенос нагрузки в другой кластер — это упражнение в проверке плана маршрутов, а не изменение образа, которое молча перестаёт работать.