Продвинутый Istio — TLS, Canary и Troubleshooting

From wiki.baghirzade.pro
Jump to navigation Jump to search

1. Как работает Sidecar (глубокое погружение)

Istio внедряет в под два вспомогательных контейнера:

  • Istio-init: Привилегированный контейнер, который запускается первым. Его задача — настроить правила iptables внутри пода, чтобы весь входящий и исходящий трафик перенаправлялся на прокси.
  • Istio-proxy (Envoy): Основной рабочий контейнер. Он слушает порты (например, 15001 для исходящего и 15006 для входящего трафика) и применяет правила маршрутизации, безопасности и сбора метрик.

2. Настройка HTTPS и режимы TLS в Gateway

Для защиты трафика на входе в кластер (Ingress) в ресурсе Gateway настраивается блок TLS. Существует три основных режима:

Режим Описание Когда использовать
Simple Стандартный HTTPS. Istio терминирует (расшифровывает) трафик и передает его внутрь кластера по HTTP. Самый частый сценарий.
Pass-through Трафик передается в под в зашифрованном виде без расшифровки на шлюзе. Если само приложение внутри пода ожидает HTTPS.
Mutual (mTLS) Двусторонняя проверка. И сервер, и клиент должны предъявить сертификаты. Для сверхзащищенных соединений между партнерами.

Важно: Секреты (сертификаты) для Gateway должны храниться в namespace istio-system, чтобы Ingress Gateway мог их прочитать.

3. Автоматизация сертификатов: Cert-Manager

Чтобы не обновлять сертификаты (особенно 90-дневные от Let's Encrypt) вручную, используется Cert-Manager.

  • Issuer/ClusterIssuer: Ресурсы, описывающие, у кого просить сертификат (например, Let's Encrypt).
  • Certificate: Ресурс, который запрашивает сертификат для конкретного домена. Cert-Manager проходит "вызов" (HTTP-01 или DNS-01), получает сертификат и кладет его в Kubernetes Secret.

4. Управление трафиком в Kiali (Canary и Shifting)

Через интерфейс Kiali можно визуально настраивать сложные стратегии деплоя без ручного написания YAML:

  • Traffic Shifting: Распределение трафика между версиями приложения (например, 80% на V1 и 20% на V2).
  • Fault Injection: Искусственное внесение задержек (Delay) или ошибок (Abort), чтобы проверить отказоустойчивость системы.
  • Mirroring: Дублирование трафика на новую версию. Живой трафик идет на V1, а его копия — на V2 (ответ V2 игнорируется, это нужно только для тестов под нагрузкой).

Новые ресурсы:

  • DestinationRule: Определяет "подмножества" (subsets) подов (например, разделение по метке version: v1 и version: v2) и настройки балансировки.

5. Troubleshooting и отладка (istioctl)

Если трафик идет не туда или возникают ошибки 503/404, используйте:

  1. istioctl analyze: Проверяет конфигурацию кластера на наличие ошибок в Gateway, VirtualService и других ресурсах.
  2. istioctl proxy-config log <pod-name> --level debug: Переводит прокси-контейнер конкретного пода в режим расширенного логирования. Это позволяет увидеть, почему Envoy отклоняет запрос.

Главные выводы:

  • mTLS между подами в Istio включен по умолчанию в режиме PERMISSIVE (разрешает и зашифрованный, и открытый трафик). Для безопасности лучше переходить в STRICT.
  • VirtualService нужен не только для внешнего доступа, но и для любого изменения поведения трафика внутри кластера.
  • Всегда используйте метку version в подах — без неё Istio не сможет корректно отображать и разделять трафик по версиям.

Статистика использования Service Mesh (2024-2025): По данным опросов CNCF, Istio остается самым популярным решением, охватывая более 45% компаний, внедривших Service Mesh, благодаря глубокой интеграции с инструментами мониторинга.

Retrieved from "https://wiki.baghirzade.pro/index.php?title=Продвинутый_Istio_—_TLS,_Canary_и_Troubleshooting&oldid=220"