Service mesh редко ломается из-за одной настройки. Production-сбои обычно возникают на стыке control plane, sidecar-прокси, политик, сертификатов и сетевой инфраструктуры. Основные симптомы: рост 503/504, неожиданные 403, TLS handshake errors, увеличение latency, OOMKilled у прокси, потеря метрик и невозможность быстро отключить mesh.
Каждую ошибку проверяют в staging на реальном трафикоподобном сценарии, с измеримыми критериями остановки rollout. Материал охватывает несовместимость версий компонентов, некорректные политики маршрутизации и авторизации, проблемы с сертификатами и ротацией ключей, перегрузку sidecar-прокси, а также ошибки в сетевых правилах и настройках observability. Для каждой проблемы рассматриваются признаки, возможные последствия и способы проверки до rollout. Статья завершается пошаговым чек-листом безопасного внедрения, включая тестирование в staging, контроль нагрузки, план отката и проверку готовности команды к восстановлению после инцидента.
Какие ошибки при внедрении service mesh в production приводят к сбоям
Service mesh добавляет новый слой управления трафиком, безопасности и наблюдаемости. Ошибки в его конфигурации могут привести к полной недоступности сервисов, утечке данных или непредсказуемому поведению. Наиболее опасные классы ошибок:
- Несовместимые версии control plane, sidecar и Kubernetes.
- Некорректные правила маршрутизации и авторизации.
- Проблемы с сертификатами и ротацией ключей.
- Перегрузка sidecar-прокси и рост latency.
- Сетевые правила, блокирующие служебный или прикладной трафик.
- Формальная observability, которая не помогает расследованию.
Проверка должна охватывать совместимость, трафик, безопасность, ресурсы, сеть и наблюдаемость. Только комплексный подход снижает риск production-сбоя.
Что проверить до внедрения service mesh в Kubernetes production
Перед установкой mesh необходимо убедиться, что среда готова. Базовый preflight-контроль включает инвентаризацию трафика, фиксацию baseline и проверку staging.
Инвентаризация трафика, зависимостей и исключений
Составьте таблицу сервис-сервис, внешних API, DNS-имен, портов, протоколов, long-lived connections, gRPC, WebSocket, webhook и административного трафика. Отдельно отметьте workload, которым нельзя без подготовки добавлять sidecar: stateful-сервисы, системные компоненты, jobs, DaemonSet и приложения с нестандартным сетевым поведением.
Baseline до rollout: доступность, latency и ресурсы
Зафиксируйте p50/p95/p99 latency, RPS, долю ошибок, время установления соединения, CPU и память приложений, количество соединений и сетевой throughput. Эти показатели станут точкой сравнения для оценки влияния service mesh. Определите допустимые отклонения и критерии остановки rollout при их превышении.
Проверка staging и сценария аварийного отключения
Проверьте типовые пользовательские и фоновые сценарии в staging, включая отказ upstream, недоступность control plane, истечение сертификата и перезапуск pod. Подготовьте способ удаления или обхода sidecar, процедуру возврата конфигурации, ответственных и ожидаемое время восстановления.
Ошибка 1. Несовместимые версии control plane, sidecar и Kubernetes
Установка может завершиться успешно, но трафик начнет ломаться после инъекции sidecar или обновления control plane. Причина: несовместимость версий mesh, прокси, CRD, Kubernetes API или admission-компонентов.
Какие компоненты должны быть согласованы
Перечислите control plane, data plane, admission webhook, CRD, Kubernetes API, CNI или init-контейнер, ingress и egress gateway, observability-агенты и внешние CA. Совместимость нужно проверять не только для установки, но и для постепенного обновления.
Проверки перед установкой и обновлением
Проверьте версии через штатные CLI и манифесты, состояние control plane, готовность webhook, наличие CRD и отсутствие deprecated API. Прогоните dry-run и валидацию конфигурации, установите тестовую версию в staging, проверьте инъекцию sidecar и выполните restart нескольких тестовых workload.
Как безопасно обновлять mesh по этапам
Обновляйте control plane canary-способом, контролируйте версии прокси, переносите namespace ограниченно и проверяйте трафик после каждой группы. Критерии остановки: ошибки xDS, рост 5xx, ухудшение p99, падение readiness и увеличение рестартов.
Ошибка 2. Некорректные правила маршрутизации и авторизации
Ошибки в traffic policy приводят к недоступности сервисов, неверному направлению запросов или блокировке легитимного трафика.
Почему VirtualService и DestinationRule начинают конфликтовать
Разберите несоответствие host, label subset, порта и протокола, конфликт нескольких правил, ошибочный weight и отсутствие конечных endpoints. Для Istio используйте VirtualService, DestinationRule и Gateway, но отделяйте общие принципы от реализации конкретного продукта.
Ошибки в AuthorizationPolicy и mTLS
Переходите от permissive к strict mTLS поэтапно, проверяйте identity, namespace и service account, а также влияние внешних клиентов, health checks и системных компонентов. Проверяйте policy с разрешенными и запрещенными запросами и сопоставляйте результат с кодом ответа и логами прокси.
Проверка правил на реальных сценариях
Составьте матрицу тестов: разрешенный сервис-сервис, запрещенный вызов, ingress из внешней сети, egress к API, запрос без identity, health check, retry после отказа upstream и длинное соединение. Для каждого сценария зафиксируйте ожидаемый код, маршрут, identity и метрики.
Ошибка 3. Проблемы с сертификатами и ротацией ключей
Сертификатная проблема может проявиться не во время установки, а спустя часы или дни после внедрения. Признаки: certificate expired, unknown authority, failed TLS handshake, несовпадение SAN, ошибки SDS или невозможность получить secret.
Цепочка доверия, SAN и источник времени
Проверьте issuer, цепочку CA, SAN, trust domain, hostname и clock skew на nodes. Корректный сертификат должен быть не только действующим по сроку, но и соответствовать identity и имени, которое использует клиент.
Ротация сертификатов без массового отказа
Проверьте TTL, окно обновления, работу SDS или другого механизма доставки секретов, права service account и поведение proxy при недоступном CA. Проведите тестовую ротацию в staging, затем проверьте, что новые сертификаты применились к существующим pod и что старые соединения корректно завершаются.
Что проверять при ошибках TLS handshake
Сопоставьте время возникновения ошибки, логи proxy и control plane, статус сертификата, состояние CA, identity клиента и сервера, а также наличие сетевой доступности до SDS или CA. Не ограничивайтесь просмотром секрета: проверьте сертификат, реально загруженный прокси.
Ошибка 4. Перегрузка sidecar-прокси и рост latency
Service mesh меняет профиль потребления ресурсов. Sidecar добавляет CPU, память, файловые дескрипторы, connection pools, TLS handshakes, retries и обработку телеметрии. Приложение может выглядеть здоровым, но proxy получает OOMKilled или начинает добавлять задержку.
Ресурсные requests и limits для proxy
Проверьте requests и limits для CPU и памяти, QoS-класс pod, node capacity, autoscaling и влияние resource limits на latency. Сравните потребление приложения до и после инъекции, определите запас на пиковой нагрузке и проверьте поведение при нехватке ресурсов.
Retries, timeouts и connection pools
Чрезмерные retries, длинные timeouts и большие connection pools увеличивают нагрузку на upstream и proxy. Настройте ограниченные retries, согласованные deadlines, circuit breaking и outlier detection только после измерения поведения приложения.
Нагрузочный тест перед production-rollout
Сравните сценарии без mesh и с mesh при штатной, пиковой и деградационной нагрузке. Измерьте p95/p99 latency, error rate, CPU и память proxy, RPS, connection count, queue time, рестарты и время восстановления после отказа зависимости.
Ошибка 5. Сетевые правила блокируют служебный или прикладной трафик
Sidecar не отменяет базовые сетевые ограничения Kubernetes и инфраструктуры. Конфликты между service mesh, CNI, NetworkPolicy, firewall и cloud security groups могут привести к потере связи между control plane и приложениями.
Конфликт NetworkPolicy и перехвата трафика
Проверьте ingress и egress правила для pod, служебные порты proxy, DNS и control plane. Сопоставьте фактический маршрут пакета с ожидаемым, проверьте исключения для health checks и убедитесь, что policy учитывает identity и namespace.
Egress к внешним сервисам и интернету
Опишите варианты выхода через egress gateway или прямое соединение, требования к DNS и TLS passthrough, allowlist внешних адресов и динамические IP. Проверьте внешние API, базы данных, платежные шлюзы, object storage и webhook-получателей.
Ingress, Gateway и health checks
Проверьте TLS termination, порты Gateway, readiness и liveness probes, маршруты от ingress controller до workload, а также source IP и заголовки, используемые приложением. Убедитесь, что probes не блокируются AuthorizationPolicy или mTLS.
Ошибка 6. Observability включена формально и не помогает расследованию
Наличие Prometheus или Grafana само по себе не означает готовность к диагностике. Нужен минимальный набор сигналов: RED-метрики для сервисов, proxy metrics, access logs, control plane logs, distributed tracing, состояние сертификатов, xDS sync и показатели ресурсов.
Метрики, которые нужно видеть до и после rollout
Проверьте request rate, error rate, duration, статусы 4xx/5xx, upstream reset, retries, active connections, CPU и memory proxy, xDS sync, certificate expiry и состояние endpoints. Свяжите дашборды с конкретными SLO и критериями остановки rollout.
Логи proxy и трассировка запросов
Настройте корреляционный идентификатор, access logs с upstream/downstream-контекстом и sampling для tracing. Проверьте, что trace проходит через ingress, несколько сервисов и egress, а sensitive headers и персональные данные не попадают в логи.
Алерты и runbook для дежурной команды
Подготовьте алерты на 5xx, p99 latency, TLS errors, proxy OOM, отсутствие endpoints, рассинхронизацию xDS и истечение сертификатов. Для каждого алерта укажите владельца, первичные команды проверки, условие эскалации и действие по откату.
Пошаговый чек-лист безопасного внедрения service mesh
Компактный чек-лист с отметками pass/fail и ответственным за каждый пункт. Последовательность включает аудит зависимостей, фиксацию baseline, проверку версий, установку в staging, тестирование маршрутизации и mTLS, нагрузочный тест, проверку observability, canary rollout, критерии остановки, план отката и постинцидентную проверку. Не объявляйте rollout успешным только по факту запуска pod.
Этап 1. Подготовка и инвентаризация
Зафиксируйте версии Kubernetes и mesh, список workload, зависимости, критичные маршруты, текущие SLO, владельцев сервисов, ограничения безопасности и резервные копии конфигураций. Назначьте ответственных за rollout, наблюдение и откат.
Этап 2. Staging и проверка функциональности
Выполните инъекцию sidecar на ограниченный набор сервисов, проверьте east-west и north-south traffic, DNS, probes, retries, timeout, ingress, egress, mTLS, AuthorizationPolicy и интеграции с внешними системами. Сравните результаты с baseline.
Этап 3. Контроль нагрузки и устойчивости
Проведите нагрузочные и отказоустойчивые тесты: пик RPS, недоступный upstream, задержка зависимости, рестарт proxy, потеря control plane, ротация сертификата и нехватка ресурсов. Зафиксируйте p95/p99, error rate, CPU, память, соединения и время восстановления.
Этап 4. Canary rollout и критерии остановки
Начните с одного namespace, сервиса или небольшой доли pod. Увеличивайте охват только после контрольного окна. Опишите численные пороги для 5xx, latency, resource saturation, TLS errors, рестартов и потери telemetry, при которых rollout немедленно приостанавливается.
Этап 5. Откат и восстановление после инцидента
Проверьте удаление или отключение инъекции, возврат предыдущих политик, переключение маршрута, восстановление сертификатов и очистку зависших ресурсов. Проведите tabletop или практическую тренировку, убедитесь в доступности runbook, контактов и прав у дежурной команды. После отката проверьте метрики приложения, proxy, control plane и внешних зависимостей.
Дополнительные материалы по теме: 10 частых ошибок Kubernetes в production, Типичные ошибки в проектировании маршрутизации процессов, Интеллектуальная маршрутизация в Service Mesh: Istio и Linkerd, Проектируем отказоустойчивую архитектуру ИС.