Тестирование Service Mesh

Что такое Service Mesh? #

Service mesh — это инфраструктурный слой, управляющий коммуникацией между микросервисами. Вместо того чтобы каждый сервис реализовывал собственную логику ретраев, circuit breaker-ы и шифрование, эти задачи решает proxy (sidecar), работающий рядом с каждым сервисом.

Наиболее распространённые реализации service mesh:

Как это работает #

┌──────────────────┐     ┌──────────────────┐
│  Сервис A         │     │  Сервис B         │
│  ┌──────────────┐│     │┌──────────────┐  │
│  │  Код прилож. ││     ││  Код прилож. │  │
│  └──────┬───────┘│     │└──────▲───────┘  │
│         │        │     │       │          │
│  ┌──────▼───────┐│     │┌──────┴───────┐  │
│  │  Sidecar     │├────▶││  Sidecar     │  │
│  │  Proxy       ││     ││  Proxy       │  │
│  └──────────────┘│     │└──────────────┘  │
└──────────────────┘     └──────────────────┘

Весь трафик между сервисами проходит через sidecar proxy. Control plane меша конфигурирует эти proxy правилами маршрутизации, политиками безопасности и настройками наблюдаемости.

Что тестировать в Service Mesh #

1. Маршрутизация трафика #

Service mesh позволяет сложную маршрутизацию: canary deployment-ы, A/B-тестирование, routing по заголовкам и разделение трафика.

Тест canary deployment:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: product-service
spec:
  hosts:
    - product-service
  http:
    - route:
        - destination:
            host: product-service
            subset: v1
          weight: 90
        - destination:
            host: product-service
            subset: v2
          weight: 10

Как проверить: Отправьте 1,000 запросов и убедитесь, что примерно 900 попали в v1, а 100 — в v2.

2. Балансировка нагрузки #

Проверьте, что mesh распределяет трафик между экземплярами сервиса по настроенному алгоритму (round-robin, least connections, random).

Подход:

1. Разверните 3 реплики сервиса.
2. Отправьте 100 запросов.
3. Проверьте access logs или метрики для подтверждения равномерного распределения.

3. Circuit Breaker-ы #

Circuit breaker-ы предотвращают каскадные сбои, останавливая запросы к нездоровому сервису.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: product-service
spec:
  host: product-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
        http2MaxRequests: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 60s
      maxEjectionPercent: 50

Подход к тестированию:

1. Сделайте один экземпляр сервиса возвращающим ошибки 500.
2. Отправьте трафик и убедитесь, что mesh исключает сбойный экземпляр после 5 последовательных ошибок 5xx.
3. Проверьте перенаправление трафика на здоровые экземпляры.
4. Восстановите сбойный экземпляр и проверьте его возвращение в пул.

4. Fault Injection #

Mesh может инжектировать сбои без изменения кода приложения — бесценно для тестирования устойчивости.

Инжекция задержки 5 секунд:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: product-service
spec:
  hosts:
    - product-service
  http:
    - fault:
        delay:
          percentage:
            value: 100
          fixedDelay: 5s
      route:
        - destination:
            host: product-service

Инжекция ошибок HTTP 503:

http:
  - fault:
      abort:
        percentage:
          value: 50
        httpStatus: 503
    route:
      - destination:
          host: product-service

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

Убедитесь, что mutual TLS применяется между сервисами.

Подход:

1. Проверьте конфигурацию mesh — mTLS в режиме STRICT (не PERMISSIVE).
2. Попробуйте вызвать сервис напрямую (в обход sidecar proxy) — должен быть отказ.
3. Используйте istioctl или дашборды mesh для подтверждения шифрования трафика.

6. Наблюдаемость #

Service mesh автоматически предоставляет метрики, распределённые трассировки и access logs.

Проверьте:

• Метрики Prometheus собираются для каждого вызова сервис-сервис.
• Распределённые трассировки (Jaeger/Zipkin) показывают полный путь запроса.
• Access logs содержат детали request/response.

Упражнение: Сценарии тестирования Service Mesh #

Настройте среду service mesh и протестируйте ключевые функции.

Подготовка #

Если у вас есть кластер Kubernetes с установленным Istio, используйте свои сервисы. Иначе используйте пример Bookinfo от Istio:

# Развернуть пример Bookinfo
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/platform/kube/bookinfo.yaml

# Создать gateway
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/networking/bookinfo-gateway.yaml

# Проверить развёртывание
kubectl get pods

Задание 1: Разделение трафика #

Настройте canary deployment для сервиса reviews:

1. Примените VirtualService, направляющий 80% трафика на reviews-v1 и 20% на reviews-v3.
2. Отправьте 50 запросов и запишите, какая версия обработала каждый.
3. Проверьте, что распределение примерно 80/20.

for i in $(seq 1 50); do
  curl -s http://$GATEWAY_URL/productpage | grep -o 'reviews-v[0-9]' >> results.txt
done
sort results.txt | uniq -c

Задание 2: Fault Injection #

Инжектируйте задержку 7 секунд в сервис ratings:

1. Примените VirtualService с fault injection.
2. Откройте productpage и наблюдайте поведение.
3. Загружается ли страница? Показывает ли ошибку? Сколько времени занимает?
4. Задокументируйте, как вышестоящие сервисы обрабатывают задержку.

Задание 3: Circuit Breaker #

Настройте circuit breaker для сервиса ratings:

1. Примените DestinationRule с outlier detection (3 последовательных ошибки 5xx, исключение на 30 секунд).
2. Сделайте сервис ratings возвращающим ошибки.
3. Отправьте трафик и наблюдайте, когда circuit breaker сработает.
4. Восстановите сервис и проверьте его возвращение в пул.

Задание 4: Аудит mTLS #

Проверьте шифрование между сервисами:

1. Проверьте политику PeerAuthentication — mTLS STRICT или PERMISSIVE?
2. Используйте Kiali или istioctl для проверки mTLS на всех соединениях.
3. Если PERMISSIVE, попробуйте отправить незашифрованный запрос между сервисами и задокументируйте результат.

Результаты #

1. Отчёт о тестировании с результатами каждого задания.
2. Скриншоты или вывод команд с распределением трафика, поведением при сбоях, активацией circuit breaker и статусом mTLS.
3. Список найденных проблем конфигурации и рекомендации.