Боковому контейнеру VPN нужны правило запуска и правило отказа

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

Порядок закрывает только первый запрос

Kubernetes поддерживает жизненный цикл sidecar, построенный из перезапускаемых init-контейнеров. В этой модели стартовая проба может задерживать следующий шаг инициализации, пока туннель не сообщит о готовности. Это настоящее улучшение, и его стоит применять осознанно, а не добавлять sleep в скрипт точки входа. Шлюз хорош ровно настолько, насколько хорошо условие, которое он проверяет.

Вне этой модели семантика порядка принадлежит той среде выполнения или системе зависимостей, которую вы используете, и они не обязаны совпадать. Развёртывание, скопированное с другой платформы, может выглядеть ожидающим туннель, потому что приложение случайно стартует медленно. Это не та же гарантия, и под нагрузкой оно отказывает.

Скажите, что наблюдает шлюз: процесс существует, интерфейс существует, рукопожатие завершено. Каждое из этого — более слабое утверждение, чем «путь данных к местам назначения, нужным этому pod, работает».

Принудительно задайте путь данных, а не предполагайте его

Проба — это проверка в один момент, а межсетевой экран — свойство, действующее между моментами. Если требование состоит в том, чтобы трафик приложения никогда не выходил за пределы туннеля, его нужно выразить в общем сетевом пространстве имён как правило «принять или отбросить». Порядок запуска контейнеров это требование нести не может. Только правило может.

Контейнеры в одном pod разделяют это пространство имён, поэтому точка принуждения — само пространство имён. Что бы вы ни написали, оно должно оставлять доступным собственное внешнее соединение туннеля, ведь его блокировка ради защиты приложения обрезает путь, нужный приложению.

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

Проверьте трафик, о котором вы не упомянули

Сделайте новый запрос во время управляемого отказа туннеля и посмотрите, выходит ли он. Затем повторите проверку для путей, которых тест адреса выхода никогда не касается: разрешение DNS внутри кластера, назначения IPv6 и сервисы, доступные через внутренние адреса кластера, а не через публичный интернет. Это те пути, которые тихо продолжают работать после смерти туннеля.

Страница адреса выхода доказывает, что один запрос в тот момент пошёл туда, куда вы ожидали. Она не может перечислить остальные пути, и разрыв между тем, что вы проверили, и тем, до чего pod может дотянуться, — это место, где живут интересные отказы.

Повторите тест после перезапуска sidecar, а не только после чистого старта. Перезапущенный контейнер туннеля может оставить пространство имён с маршрутами и политикой в промежуточном состоянии.

Запишите запись о развёртывании

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

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

Наконец, один раз проверьте путь восстановления при работающем приложении. Проект, требующий пересоздать pod для восстановления выхода, — это решение, и оно должно быть принято вами, а не обнаружено.