Service Mesh в Kubernetes: Istio и Linkerd на практике

⚙️ Теория

🧩 Что такое Service Mesh

Service Mesh это инфраструктурный слой для управления сервис-сервис трафиком внутри кластера (east-west).
Обычно mesh закрывает:

mTLS между workload;
traffic policy (timeouts, retries, routing rules);
телеметрию запросов/ошибок/latency;
policy enforcement на уровне сервиса.

🛡️ mTLS как базовая функция

В mesh mTLS строится на взаимной аутентификации workload-сертификатами.
Практический результат:

сервисы могут шифровать трафик автоматически внутри mesh;
identity сервиса становится частью модели авторизации.

В Istio это управляется через PeerAuthentication/AuthorizationPolicy (режим STRICT нужен для обязательного mTLS); в Linkerd mTLS включается автоматически для meshed-трафика.

🚦 Traffic Management: retries/timeouts/circuit breaking

Mesh дает централизованный контроль сетевого поведения:

timeout ограничивает время ожидания;
retry помогает пережить краткие сетевые флапы;
circuit breaking/connection limits защищают backend от лавины запросов.

Критично: retry без бюджета и без таймаутов может усугубить инцидент.

⚖️ Istio vs Linkerd: операционный trade-off

Istio:

широкая функциональность (детальная traffic policy, security policy, расширяемость);
выше операционная сложность.

Linkerd:

более компактная модель и быстрый старт;
меньший функциональный охват по сравнению с "полным" Istio-подходом.

Выбор зависит от требуемой глубины контроля и зрелости команды эксплуатации.

❓ Что нужно уметь объяснить

Почему mesh не заменяет архитектурные практики приложения?

Mesh помогает на сетевом слое, но не исправляет:

неидемпотентные операции;
плохую обработку ошибок;
отсутствующие SLO и capacity planning.

Когда mesh действительно оправдан?

Когда в кластере много сервисов и требуется единая политика mTLS/traffic/security.
Для небольших систем цена эксплуатации mesh может превышать пользу.

Главная ошибка при внедрении?

Включение сложных retries/routing без нагрузочных проверок.
Сначала нужен baseline latency/error, потом поэтапное включение политик.

🧪 Практика

1. Istio: базовая проверка control plane

istioctl version
kubectl get pods -n istio-system

2. Istio: traffic policy на уровне сервиса

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - my-app
  http:
    - timeout: 2s
      retries:
        attempts: 2
        perTryTimeout: 1s
      route:
        - destination:
            host: my-app

3. Linkerd: проверка meshed workload

linkerd check
linkerd viz stat deploy -n default

4. Guardrails для production rollout

включать policy поэтапно (observe -> enforce);
держать жесткие лимиты на retries/timeouts;
проверять p95/p99 latency до и после включения mesh-policy;
иметь rollback-процедуру для policy-изменений.

🧾 Вывод

Service mesh полезен как единый control layer для east-west трафика, безопасности и наблюдаемости.
Практическая ценность достигается только при дисциплине rollout и при ясных SLO, иначе mesh легко становится дополнительной точкой сложности.