Kong Mesh и Service Mesh

Service Mesh решает проблему безопасной и наблюдаемой коммуникации между микросервисами в распределённых системах.

#1. Что такое Service Mesh

Проблема: В микросервисной архитектуре сервисы должны общаться друг с другом. Это создаёт проблемы:

Безопасность — как шифровать трафик между сервисами?
Наблюдаемость — как трассировать запросы через сервисы?
Надёжность — как обрабатывать сбои сервисов?
Управление трафиком — как делать canary-развёртывания?

Решение: Service Mesh — инфраструктурный слой для управления service-to-service коммуникацией.

┌─────────────────────────────────────────────────────────────┐
│                    Service Mesh Architecture                 │
└─────────────────────────────────────────────────────────────┘

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Service   │     │   Service   │     │   Service   │
│      A      │     │      B      │     │      C      │
│  ┌────────┐ │     │  ┌────────┐ │     │  ┌────────┐ │
│  │  App  │ │     │  │  App  │ │     │  │  App  │ │
│  └───┬────┘ │     │  └───┬────┘ │     │  └───┬────┘ │
│  ┌───┴────┐ │     │  ┌───┴────┐ │     │  ┌───┴────┐ │
│  │ Sidecar│ │     │  │ Sidecar│ │     │  │ Sidecar│ │
│  │ (Envoy)│ │     │  │ (Envoy)│ │     │  │ (Envoy)│ │
│  └────────┘ │     │  └────────┘ │     │  └────────┘ │
└─────────────┘     └─────────────┘     └─────────────┘
       │                   │                   │
       └───────────────────┼───────────────────┘
                           │
                  ┌────────▼────────┐
                  │  Control Plane  │
                  │  (Kong Mesh)    │
                  └─────────────────┘

Компоненты Service Mesh:

Sidecar proxy — Envoy в каждом pod, перехватывает весь трафик
Control Plane — управляет конфигурацией sidecar'ов
Data Plane — сами sidecar proxy, обрабатывают трафик

#2. Kong Gateway vs Kong Mesh

Проблема: Нужно понимать разницу между API Gateway и Service Mesh.

Решение: Они решают разные задачи и дополняют друг друга.

Характеристика	Kong Gateway	Kong Mesh
Тип трафика	North-South (клиент → сервис)	East-West (сервис → сервис)
Развёртывание	Центральный шлюз	Sidecar в каждом pod
Прокси	nginx	Envoy
Безопасность	TLS termination	mTLS между сервисами
Маршрутизация	По path/host к сервисам	Traffic splitting между версиями
Use case	Внешний API, аутентификация	Внутренняя коммуникация, шифрование

┌──────────────────────────────────────────────────────────────┐
│                        Полный стек                            │
└──────────────────────────────────────────────────────────────┘

    Интернет
       │
       ▼
┌──────────────┐
│ Kong Gateway │  ← North-South (API Gateway)
└──────┬───────┘
       │
       ▼
┌─────────────────────────────────────────┐
│          Kubernetes Cluster             │
│                                         │
│  ┌─────────┐    ┌─────────┐    ┌─────┐ │
│  │ Service │◄──►│ Service │◄──►│Svc  │ │
│  │ +Sidecar│    │ +Sidecar│    │+SC  │ │
│  └─────────┘    └─────────┘    └─────┘ │
│     ▲                                  │
│     └──────────────────────────────────┘ │
│              Kong Mesh                   │
│           (East-West)                    │
└─────────────────────────────────────────┘

#3. Установка Kong Mesh

Проблема: Нужно развернуть Kong Mesh в Kubernetes.

Решение: Helm chart для Kong Mesh.

#3.1. Предварительные требования

Kubernetes 1.19+
Helm 3+
kubectl настроен на кластер
4 CPU + 8 GB RAM минимум

#3.2. Установка Global Control Plane

# Добавляем репозиторий
helm repo add kong https://charts.konghq.com
helm repo update

# Создаём namespace
kubectl create namespace kong-mesh

# Установка Global Control Plane
helm install kong-mesh-global kong/kong-mesh-global \
  --namespace kong-mesh \
  --set controlPlane.environment=universal

#3.3. Установка Zone Control Plane

# Получение токена для зоны
kubectl get -n kong-mesh secret kong-mesh-global-zone-token -o jsonpath='{.data.token}' | base64 -d > zone-token

# Установка Zone Control Plane
helm install kong-mesh-zone kong/kong-mesh-zone \
  --namespace kong-mesh \
  --set controlPlane.environment=kubernetes \
  --set controlPlane.zoneToken=$(cat zone-token) \
  --set controlPlane.globalAddress=grpc://kong-mesh-global.kong-mesh:5685

#3.4. Включение mesh для namespace

# Добавление аннотации для автоматического injection sidecar
kubectl label namespace default kong-mesh-injection=enabled

#3.5. Развёртывание приложения

# app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: users-service
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: users-service
  template:
    metadata:
      labels:
        app: users-service
    spec:
      containers:
        - name: users-service
          image: users-service:latest
          ports:
            - containerPort: 8080

kubectl apply -f app.yaml

Проверка sidecar:

kubectl get pods
# NAME                              READY   STATUS
# users-service-xxxxxxxxx-xxxxx     2/2     Running  ← app + sidecar

#4. mTLS — взаимная TLS-аутентификация

Проблема: Нужно шифровать трафик между сервисами и аутентифицировать их.

Решение: Kong Mesh автоматически выдаёт сертификаты каждому сервису.

#4.1. Включение mTLS

# meshtrafficpermission.yaml
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
  name: default-mtls
  namespace: kong-mesh
spec:
  targetRef:
    kind: Mesh
  from:
    - targetRef:
        kind: Mesh
      default:
        action: Allow

kubectl apply -f meshtrafficpermission.yaml

#4.2. Как работает mTLS

┌─────────────────────────────────────────────────────────────┐
│                    mTLS Handshake                            │
└─────────────────────────────────────────────────────────────┘

Service A (sidecar)              Service B (sidecar)
      │                                 │
      │    1. ClientHello + cert A      │
      ├────────────────────────────────►│
      │                                 │
      │    2. ServerHello + cert B      │
      │       + CertificateRequest      │
      ◄─────────────────────────────────┤
      │                                 │
      │    3. Client cert A             │
      ├────────────────────────────────►│
      │                                 │
      │    4. Verify cert A             │
      │       Verify cert B             │
      │                                 │
      │    5. Зашифрованное соединение  │
      ◄────────────────────────────────►│

Процесс:

Sidecar A отправляет ClientHello + свой сертификат
Sidecar B отправляет ServerHello + свой сертификат + запрос сертификата клиента
Sidecar A отправляет свой сертификат
Обе стороны проверяют сертификаты (выданы ли доверенным CA, не истёк ли срок)
Устанавливается зашифрованное соединение

#4.3. Проверка mTLS

# Проверка статуса mTLS для сервиса
kubectl get meshtrafficpermission default-mtls -o yaml

# Проверка сертификатов sidecar
kubectl exec -it users-service-xxxxx -c kuma-sidecar -- \
  cat /var/run/secrets/kuma.io/tls/cert.pem

#5. Traffic Splitting — разделение трафика

Проблема: Нужно развернуть новую версию сервиса с постепенным накатом.

Решение: TrafficPermission и TrafficRoute политики Kong Mesh.

#5.1. Canary развёртывание (90/10)

# trafficroute.yaml
apiVersion: kuma.io/v1alpha1
kind: TrafficRoute
metadata:
  name: canary-route
  namespace: kong-mesh
spec:
  sources:
    - match:
        kuma.io/service: '*'
  destinations:
    - match:
        kuma.io/service: users-service
  conf:
    loadBalancer:
      roundRobin: {}
    split:
      - weight: 90
        destination:
          kuma.io/service: users-service
          version: v1
      - weight: 10
        destination:
          kuma.io/service: users-service
          version: v2

kubectl apply -f trafficroute.yaml

Результат:

90% трафика → users-service v1
10% трафика → users-service v2

#5.2. A/B тестирование по заголовку

# trafficroute-header.yaml
apiVersion: kuma.io/v1alpha1
kind: TrafficRoute
metadata:
  name: ab-test-route
spec:
  sources:
    - match:
        kuma.io/service: '*'
  destinations:
    - match:
        kuma.io/service: users-service
  conf:
    split:
      - weight: 100
        destination:
          kuma.io/service: users-service
          version: v2
        match:
          headers:
            x-ab-test: "enabled"
      - weight: 100
        destination:
          kuma.io/service: users-service
          version: v1

Использование:

# Запрос с заголовком попадает на v2
curl -H "x-ab-test: enabled" http://users-service:8080/api/users

# Обычный запрос попадает на v1
curl http://users-service:8080/api/users

#6. Policy Enforcement — политики доступа

Проблема: Нужно ограничить доступ между сервисами (например, только payments → orders).

Решение: MeshTrafficPermission политики.

#6.1. Разрешить только определённые сервисы

# restrict-access.yaml
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
  name: restrict-orders
spec:
  targetRef:
    kind: MeshService
    name: orders-service
  from:
    - targetRef:
        kind: MeshService
        name: payments-service
      default:
        action: Allow
    - targetRef:
        kind: Mesh
      default:
        action: Deny

kubectl apply -f restrict-access.yaml

Результат:

✅ payments-service → orders-service: разрешено
❌ любой другой сервис → orders-service: запрещено

#6.2. Иерархия политик

Mesh (глобально)
    ↓
Namespace
    ↓
Service
    ↓
Route (наиболее специфичный)

Более специфичная политика переопределяет общую.

#7. Observability в Kong Mesh

Проблема: Нужно видеть метрики и trace для сервисов в mesh.

Решение: Встроенные метрики Envoy и интеграция с Prometheus/Jaeger.

#7.1. Включение метрик

# meshmetrics.yaml
apiVersion: kuma.io/v1alpha1
kind: MeshMetrics
metadata:
  name: default
spec:
  targetRef:
    kind: Mesh
  prometheus:
    - path: /metrics
      port: 8080

kubectl apply -f meshmetrics.yaml

#7.2. Scraping метрик

# prometheus service monitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kong-mesh
spec:
  selector:
    matchLabels:
      app: kuma-sidecar
  endpoints:
    - port: metrics
      path: /metrics
      interval: 15s

#7.3. Distributed Tracing

# meshtrace.yaml
apiVersion: kuma.io/v1alpha1
kind: MeshTrace
metadata:
  name: default
spec:
  targetRef:
    kind: Mesh
  default:
    backend:
      zipkin:
        url: http://jaeger:9411/api/v2/spans
        sampling: 10.0

kubectl apply -f meshtrace.yaml

#8. Multi-Zone развёртывание

Проблема: Сервисы работают в разных кластерах/регионах, нужна единая mesh сеть.

Решение: Kong Mesh Multi-Zone архитектура.

┌─────────────────────────────────────────────────────────────┐
│                  Multi-Zone Architecture                     │
└─────────────────────────────────────────────────────────────┘

                    ┌──────────────────┐
                    │  Global CP       │
                    │  (единый)        │
                    └────────┬─────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
       ┌──────▼──────┐ ┌─────▼─────┐ ┌─────▼─────┐
       │  Zone CP    │ │ Zone CP   │ │ Zone CP   │
       │  (US-East)  │ │ (EU-West) │ │ (AP-South)│
       └──────┬──────┘ └─────┬─────┘ └─────┬─────┘
              │              │             │
       ┌──────┴──────┐ ┌─────┴─────┐ ┌────┴─────┐
       │  Services   │ │ Services  │ │ Services │
       └─────────────┘ └───────────┘ └──────────┘

#8.1. Настройка Global CP

# Global Control Plane должен быть доступен из всех зон
helm install kong-mesh-global kong/kong-mesh-global \
  --namespace kong-mesh \
  --set controlPlane.environment=universal \
  --set controlPlane.globalAddress=grpc://global-cp.example.com:5685

#8.2. Настройка Zone CP

# Каждая зона подключается к Global CP
helm install kong-mesh-zone kong/kong-mesh-zone \
  --namespace kong-mesh \
  --set controlPlane.zone=us-east \
  --set controlPlane.globalAddress=grpc://global-cp.example.com:5685

#9. Best Practices

#9.1. Безопасность

Включите mTLS по умолчанию для всех сервисов
Используйте MeshTrafficPermission для ограничения доступа
Регулярно ротируйте сертификаты (Kong Mesh делает это автоматически)
Изолируйте sensitive сервисы отдельными политиками

#9.2. Производительность

Настройте connection pooling в MeshTrafficRoute
Используйте локальный rate limiting для защиты от перегрузок
Мониторьте latency sidecar — не должен превышать 1-2ms

#9.3. Надёжность

Включите retry политики для transient ошибок
Настройте circuit breaker для защиты от каскадных сбоев
Используйте health checks для обнаружения неисправных сервисов

#9.4. Troubleshooting

# Проверка статуса sidecar
kubectl get pods -o custom-columns=NAME:.metadata.name,SIDECAR:.status.containerStatuses[*].ready

# Логи sidecar
kubectl logs users-service-xxxxx -c kuma-sidecar

# Проверка политик
kubectl get meshtrafficpermission
kubectl get meshroute

# Inspect сервис
kubectl inspect mesh service/users-service

┌─────────────────────────────────────────────────────────────┐ │ Service Mesh Architecture │ └─────────────────────────────────────────────────────────────┘ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Service │ │ Service │ │ Service │ │ A │ │ B │ │ C │ │ ┌────────┐ │ │ ┌────────┐ │ │ ┌────────┐ │ │ │ App │ │ │ │ App │ │ │ │ App │ │ │ └───┬────┘ │ │ └───┬────┘ │ │ └───┬────┘ │ │ ┌───┴────┐ │ │ ┌───┴────┐ │ │ ┌───┴────┐ │ │ │ Sidecar│ │ │ │ Sidecar│ │ │ │ Sidecar│ │ │ │ (Envoy)│ │ │ │ (Envoy)│ │ │ │ (Envoy)│ │ │ └────────┘ │ │ └────────┘ │ │ └────────┘ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └───────────────────┼───────────────────┘ │ ┌────────▼────────┐ │ Control Plane │ │ (Kong Mesh) │ └─────────────────┘

Характеристика

Kong Gateway

Kong Mesh

Тип трафика

North-South (клиент → сервис)

East-West (сервис → сервис)

Развёртывание

Центральный шлюз

Sidecar в каждом pod

Прокси

nginx

Envoy

Безопасность

TLS termination

mTLS между сервисами

Маршрутизация

По path/host к сервисам

Traffic splitting между версиями

Use case

Внешний API, аутентификация

Внутренняя коммуникация, шифрование

┌──────────────────────────────────────────────────────────────┐ │ Полный стек │ └──────────────────────────────────────────────────────────────┘ Интернет │ ▼ ┌──────────────┐ │ Kong Gateway │ ← North-South (API Gateway) └──────┬───────┘ │ ▼ ┌─────────────────────────────────────────┐ │ Kubernetes Cluster │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────┐ │ │ │ Service │◄──►│ Service │◄──►│Svc │ │ │ │ +Sidecar│ │ +Sidecar│ │+SC │ │ │ └─────────┘ └─────────┘ └─────┘ │ │ ▲ │ │ └──────────────────────────────────┘ │ │ Kong Mesh │ │ (East-West) │ └─────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐ │ mTLS Handshake │ └─────────────────────────────────────────────────────────────┘ Service A (sidecar) Service B (sidecar) │ │ │ 1. ClientHello + cert A │ ├────────────────────────────────►│ │ │ │ 2. ServerHello + cert B │ │ + CertificateRequest │ ◄─────────────────────────────────┤ │ │ │ 3. Client cert A │ ├────────────────────────────────►│ │ │ │ 4. Verify cert A │ │ Verify cert B │ │ │ │ 5. Зашифрованное соединение │ ◄────────────────────────────────►│

┌─────────────────────────────────────────────────────────────┐ │ Multi-Zone Architecture │ └─────────────────────────────────────────────────────────────┘ ┌──────────────────┐ │ Global CP │ │ (единый) │ └────────┬─────────┘ │ ┌──────────────┼──────────────┐ │ │ │ ┌──────▼──────┐ ┌─────▼─────┐ ┌─────▼─────┐ │ Zone CP │ │ Zone CP │ │ Zone CP │ │ (US-East) │ │ (EU-West) │ │ (AP-South)│ └──────┬──────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ ┌──────┴──────┐ ┌─────┴─────┐ ┌────┴─────┐ │ Services │ │ Services │ │ Services │ └─────────────┘ └───────────┘ └──────────┘