Istio Service Mesh в production: опыт внедрения для ПлатёжСервис

Istio состоит из двух плоскостей:

• Control Plane (istiod) — управляющий компонент. Получает конфигурацию из Kubernetes API, транслирует её в правила для Envoy и распространяет на все sidecar-прокси
• Data Plane (Envoy sidecars) — прокси-контейнеры, инжектируемые в каждый Pod. Перехватывают весь входящий и исходящий трафик

В каждом Pod рядом с Envoy работает istio-agent, который поддерживает соединение с Control Plane и транслирует состояние кластера в Envoy API.

Istio использует iptables правила для перенаправления трафика через sidecar:

# Правила iptables, создаваемые istio-init контейнером:
# Исходящий трафик → порт 15001 (Envoy outbound listener)
iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-port 15001

# Входящий трафик → порт 15006 (Envoy inbound listener)
iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-port 15006

Envoy использует флаг use_original_dst для определения реального адреса назначения до DNAT. Это позволяет ему применить правильные политики маршрутизации и безопасности.

Путь запроса: DNAT перехват → выбор listener по original_dst → обработка filter chain (TLS, авторизация, метрики) → выбор cluster → балансировка по endpoint → установка соединения.

Мы начали с PERMISSIVE mode, который принимает и шифрованный, и нешифрованный трафик — это позволило внедрять sidecar-ы постепенно, не ломая связность:

# Этап 1: PERMISSIVE mode (принимает оба варианта)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system  # Применяется ко всему mesh
spec:
  mtls:
    mode: PERMISSIVE

После того как все 87 сервисов получили sidecar-ы, мы переключились на STRICT mode:

# Этап 2: STRICT mode (только шифрованный трафик)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: mtls-strict
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

Критическая ошибка, которую мы предотвратили: PERMISSIVE mode некорректно работает с протоколами, где сервер отправляет первый пакет (FTP, SMTP, MySQL native protocol). Envoy ожидает пакет от клиента для определения типа шифрования, а сервер ожидает подключения клиента — deadlock. У ПлатёжСервис был MySQL, подключённый напрямую — мы вынесли его за mesh через exclusion annotation:

# Исключение MySQL Pod из mesh
apiVersion: v1
kind: Pod
metadata:
  annotations:
    sidecar.istio.io/inject: "false"
  labels:
    app: mysql-billing

Istio автоматически генерирует и ротирует X.509 сертификаты для каждого Pod. Время жизни сертификата — 24 часа по умолчанию (мы оставили). Ротация прозрачна для приложений.

Для аудита PCI DSS мы настроили DestinationRule с контролем outbound TLS:

# Управление исходящим TLS
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: payment-processor-tls
spec:
  host: payment-processor
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL  # Использовать сертификаты Istio
    portLevelSettings:
      - port:
          number: 8443
        tls:
          mode: ISTIO_MUTUAL

Мы установили политику «запрещено всё, что не разрешено явно» на уровне namespace:

# Deny-all по умолчанию для namespace payments
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: payments
spec:
  {}
  # Пустой spec без rules = deny all

После этого каждый сервис получил явную AuthorizationPolicy. Это трудоёмко (мы написали 87 политик), но обеспечивает полную микросегментацию — требование PCI DSS.

Outlier detection — это пассивный health check. Envoy отслеживает ответы каждого endpoint и временно исключает «нездоровые»:

• consecutive5xxErrors: 3 — после 3 последовательных 5xx ответов endpoint исключается
• interval: 30s — проверка каждые 30 секунд
• baseEjectionTime: 60s — минимальное время исключения (увеличивается с каждым повторным исключением)
• maxEjectionPercent: 50 — не более 50% endpoint-ов может быть исключено одновременно

Важное ограничение: Istio не поддерживает активные health check-и. Endpoint считается здоровым, пока не начнёт отвечать ошибками. Для критичных сервисов мы дополнили outlier detection Kubernetes readiness probes.

Параметр maxConnections задаёт лимит на один sidecar, а не на весь кластер. При 20 инстансах клиентского сервиса, каждый с лимитом 100 — суммарно до 2000 соединений к серверу. Мы столкнулись с этим, когда payment-gateway при автоскейлинге до 40 реплик создал 4000 соединений к payment-processor. Решение — пересчитать лимиты с учётом максимального количества реплик.

Istio предлагает два способа реализации canary:

Мы выбрали первый подход — отдельный Service для каждой canary-версии. Это проще в эксплуатации и позволяет видеть метрики каждой версии отдельно в Grafana.

Для внутренних инструментов мы использовали маршрутизацию по заголовкам:

# Маршрутизация /admin на отдельный сервис
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-router
  namespace: payments
spec:
  hosts:
    - api-gateway
  http:
    - match:
        - uri:
            prefix: "/admin"
      route:
        - destination:
            host: admin-service
    - route:
        - destination:
            host: api-gateway

Важный нюанс: VirtualService оперирует на стороне клиента. Правила маршрутизации не применяются к входящим запросам на сервер — только к исходящим от клиента. Это часто вызывает путаницу при настройке.

С 87 сервисами и ~400 Pod-ами мы столкнулись с высокой нагрузкой на Control Plane — istiod генерировал до 500 Mbps трафика при обновлении конфигурации, рассылая полное состояние кластера всем sidecar-ам.

Решение — Sidecar resource для ограничения видимости каждого namespace:

# Ограничение видимости для namespace payments
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: payments
spec:
  egress:
    - hosts:
        - "payments/*"       # Свой namespace
        - "istio-system/*"   # Istio infrastructure
        - "kafka/*"          # Kafka namespace
        - "monitoring/*"     # Prometheus, Grafana

Это сократило объём конфигурации, передаваемой каждому sidecar, на 70% и снизило CPU istiod с 4 ядер до 1.5.

При crash-е sidecar Envoy — Pod уходит в crash loop. Трафик перенаправляется на другие реплики через Kubernetes Service. Влияние — потеря только текущих запросов этого Pod (единицы).

Это самый критичный сценарий. Результаты тестирования:

• Существующие sidecar-ы продолжают работать на закэшированной конфигурации. Трафик не прерывается
• Новые Pod-ы не получат sidecar — остаются в состоянии Pending (если настроен webhook на always inject). Мы настроили failurePolicy: Ignore для webhook, чтобы Pod-ы запускались без sidecar, а не зависали
• Удалённые Pod-ы не убираются из endpoint-ов — outlier detection берёт на себя роль health check
• Новые политики не применяются до восстановления Control Plane

# Настройка webhook для graceful degradation при отказе istiod
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: istio-sidecar-injector
webhooks:
  - name: sidecar-injector.istio.io
    failurePolicy: Ignore  # Не блокировать запуск Pod при отказе istiod
    timeoutSeconds: 5

При потере связности между площадками каждый сегмент mesh продолжает работать автономно. Запросы к сервисам в недоступном сегменте обрабатываются outlier detection и retry policy.