Введение в Istio и Service Mesh

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

1. Зачем нужен Service Mesh? (Ingress vs Service Mesh)

До появления Service Mesh мы использовали два основных способа направить трафик в кластер:

  • NodePort / LoadBalancer: Создает внешний IP для каждого сервиса. Это сложно масштабировать, когда сервисов сотни (управление сотнями IP и DNS-записей становится кошмаром).
  • Ingress Controller (например, Nginx): Единая точка входа. Работает на уровне L7 (HTTP/HTTPS), позволяет делать роутинг по доменам и путям.

Почему этого мало? Ingress-контроллер управляет только входящим (North-South) трафиком. Он не видит, что происходит внутри (East-West) кластера между самими подами. Service Mesh (Istio) берет под контроль всё: и вход (Ingress), и выход (Egress), и взаимодействие между микросервисами внутри.

2. Архитектура Istio: Sidecar и Control Plane

Istio работает по принципу Sidecar-контейнера. В каждый под рядом с вашим приложением подселяется "сосед" — прокси-контейнер (Envoy).

  • Data Plane (Envoy Proxy): Все запросы в под и из пода проходят через этот прокси. Он перехватывает трафик с помощью правил iptables, которые настраиваются специальным init-контейнером при старте пода.
  • Control Plane (istiod): "Мозг" системы. Он хранит конфигурации и рассылает их всем прокси-контейнерам в кластере.

Как происходит перехват трафика?

  1. Init-контейнер: Настраивает iptables внутри сетевого пространства (network namespace) пода.
  2. Mutating Webhook: Специальный компонент Kubernetes, который видит запрос на создание пода в "помеченном" namespace и автоматически добавляет в YAML пода описание контейнера istio-proxy.

3. Основные возможности Istio

Функция Описание
Traffic Management Канареечные релизы (Canary), Blue-Green деплой, разделение трафика по процентам (например, 90% на старую версию, 10% на новую).
Observability Полная визуализация трафика. С помощью инструментов Kiali и Jaeger можно увидеть карту зависимостей всех микросервисов и время ответа каждого из них.
Security (mTLS) Автоматическое шифрование трафика между всеми подами. Даже если злоумышленник попадет внутрь кластера, он не сможет "прослушать" данные.
Resilience Повторные попытки (Retries), тайм-ауты и Circuit Breakers (предохранители), чтобы один упавший сервис не обрушил всю систему.

4. Установка и компоненты визуализации

Установка чаще всего выполняется через бинарный файл istioctl с использованием профилей (например, demo, default).

После установки в namespace istio-system появляются важные инструменты (Add-ons):

  • Prometheus: Собирает метрики (кол-во запросов, ошибки).
  • Kiali: Визуальный интерфейс для просмотра графа трафика кластера.
  • Jaeger: Инструмент для трассировки (просмотр пути конкретного запроса через все сервисы).

5. Настройка трафика: Gateway и VirtualService

В Istio вместо стандартного Ingress используются свои ресурсы (CRD):

  1. Gateway: Описывает "входную дверь" — порты (80, 443), протоколы и хосты, которые должен слушать Istio Ingress Gateway.
  2. VirtualService: Описывает логику маршрутизации — куда именно отправить запрос, пришедший на конкретный хост (на какой внутренний Service).
# Пример связи ресурсов
Gateway (слушает хост app.com) -> VirtualService (направляет на сервис app-svc)

Практические заметки:

  • Включение Istio: Чтобы в поды начал добавляться sidecar, нужно пометить namespace меткой: kubectl label namespace default istio-injection=enabled
  • Tracing: Если в Kiali вы видите "Unknown" источник трафика, значит запрос пришел в обход Istio Gateway (например, через NodePort). Для полной видимости трафик должен входить через Ingress Gateway.
Retrieved from "https://wiki.baghirzade.pro/index.php?title=Введение_в_Istio_и_Service_Mesh&oldid=218"