Артём Еремин, системный инженер Nova Container Platform в Orion soft.
Всем привет! Недавно я выступал на мероприятии СНОВА О КУБЕРЕ и рассказывал о Service Mesh. Тема достойна и поста на Хабре, потому что Service Mesh стал распространенной фишкой, но при этом не самой простой.
Мы в Orion soft решили внедрить ее в нашу платформу оркестрации Nova Container Platform, и по пути столкнулись с целым рядом «подводных камней»: от выбора самого решения до нюансов настройки MTLS и организации точек входа трафика в наш кластер. В этой статье я расскажу, как мы выбирали реализацию для Service Mesh, почему остановились на Istio, какие вопросы решали и что из этого получилось.
Что такое Service Mesh и зачем он нужен
Если вкратце, то ServiceMesh — это инфраструктурный уровень (или как его еще называют — слой), который упрощает сетевое взаимодействие между микросервисами.
Представьте, что у вас есть команда разработки, и в какой‑то момент вы понимаете, что хотите релизиться гораздо чаще и вносить минорные изменения в ваш кластер. Для этого вам нужно реализовать «канареечный деплоймент» либо blue/green deployment. И как раз здесь вам на помощь приходит Service Mesh. Он забирает на себя всю дополнительную сетевую логику вашего кластера, такую как, например, балансировка по весам между вашими сервисами, и оставляет на плечах вашей команды исключительно реализацию бизнес-логики вашего приложения.
Также Service Mesh позволяет повысить безопасность взаимодействия между вашими приложениями. Приведу пример из жизни. У вас есть старенькое HTTP-приложение без поддержки TLS, а его разработчик давно ушел из компании. Хотите шифровать трафик, но как? Вот тут и помогает ServiceMesh: внедряете его, и получаете MTLS «из коробки», не трогая само приложение.
Плюсы, которые дает Service Mesh:
гибкое управление трафиком (retry policy, тайм-ауты, сетевая логика);
улучшенная наблюдаемость кластера;
добавление MTLS и аутентификации между микросервисами.
Почему Istio
Ниже приведу несколько аргументов в пользу выбора Istio:
Полная поддержка L7-политик;
Istio не является CNI, в отличии от Cilium, это важно, потому что мы в Nova используем Calico и Cilium и некоторые большие инсталляции наших заказчиков выстроены на Calico;
Поддержка большим и активным сообществом по всему миру.
Istio — это не самый простой инструмент, но зато очень мощный.
Немного про минусы
А теперь давайте разберем минусы. Мы столкнулись с двумя главными проблемами:
Ресурсоемкость. Особенно в классическом Sidecar-режиме.
Сложность. Из-за обилия фич и сложности конфигурирования ввиду слабой документации решения легко «закопаться» и забыть, зачем все начиналось.
Ambient или Sidecar?
Istio сегодня работает в двух режимах:
Sidecar, который упоминал выше: в нем в каждый под с полезной нагрузкой подключается контейнер с инстантом envoy;
Ambient: траффик организован иначе, различные компоненты отвечают за L4/L7.
Ambient выглядит заманчиво: меньше ресурсов, проще масштабирование. Но он пока в альфа-стадии и по заявлениям сообщества не поддерживает полный функционал Istio, поэтому мы остановились на Sidecar.
Как устроен Istio у нас
Control Plane
Или другими словами — «мозг» Istio:
обнаруживает рабочие нагрузки;
управляет их сертификатами;
применяет конфигурации.
Мы также добавили компонент istio-csr в Nova Container Platform — это компонент, который взаимодействует с нашей системой хранения секретов StarVault и отвечает за логику выпуска сертификатов кластера.
Data Plane
Чтобы корректно маршрутизировать трафик между Istio-proxy и нашим конечным контейнером в рамках пода, необходимо настроить некоторые сетевые правила. Для их настройки нам нужен контейнер, и, чтобы он нормально работал и инициализировал соединения, ему необходимы дополнительные права, такие как NetRaw и NetAdmin. Как итог чем больше у нас нагрузок в кластере, тем больше у нас привилегированных init-контейнеров. Ситуация не очень хорошая, потому что она снижает безопасность кластера.
Вместо того, чтобы использовать большое количество этих init-контейнеров, мы разворачиваем на каждой ноде нашего кластера Istio-CNI-агент, который вставляется в конечную цепочку CNI и забирает на себя функциональность контейнера Istio-init.
Публикация приложений вовне
В Nova для публикации приложений вовне используется следующая схема: на Ingress нодах кластера разворачивается под Ingress Nginx Controller, который работает в пространстве HostNetwork и принимает сетевой трафик по понятным 80/443 портам, далее с помощью Ingress правил трафик маршрутизируется на целевой сервис.
В Istio такой вариант не сработает, для публикации приложения вовне используются специально сконфигурированные инстансы Envoy – Istio Gateway, который не может работать в пространстве HostNetwork.
Так перед нами с командой встал вопрос о выпуске трафика вовне: как организовать доступ к Istio-приложениям по понятным портам. Мы имеем большой опыт работы с BareMetal балансировщиками — MetalLB, kube‑vip, PureLB — они все работают примерно по одному принципу и предлагаются комьюнити и другими вендорами в качестве целевого решения данной проблемы, однако мы знаем о их существенных минусах.
Все эти инструменты работают стабильно и хорошо лишь на L2-уровне, и при падении одной из ведущих нод требуется время для переключения VIP на другой хост. В L3 для этого необходима интеграция по BPG с маршрутизатором клиента, что не всегда возможно и, к сожалению, на данный момент мы не можем предложить ничего другого для L3 (либо настраивать BPG, либо публиковать приложения через NodePort и ставить перед кластером балансировщик нагрузки).
Нам этот подход показался неприемлемым и мы ввели собственное решение, о котором подробно расскажем отдельно.
Управление и мониторинг
Для визуализации и анализа доступны следующие инструменты:
Kiali как основная консоль для Service Mesh;
Prometheus, который собирает метрики со всех компонентов;
Grafana, дает дашборды и визуализацию;
Jaeger дает трассировку.
Мы с командой используем отдельный инстанс Prometheus. Он собирает метрики с Envoy, которые внедрены в наши конечные нагрузки, с Istio CSR, с Istiod и со всех компонентов Mesh. Для того, чтобы визуализировать все эти метрики, мы поднимаем отдельные инстанс-графаны, завозим в него дефолтные дашборды и даем пользователю права на редактирование, чтобы он мог при необходимости поправить их. Затем мы предоставляем функциональность трассировки. Она у нас представлена в виде Jaeger второй версии и набора OTEL коллекторов, которые размазаны как daemonSet на наши ноды. Это решение позволяет нам избежать дополнительного инжекта Sidecar для Jaeger в нашей рабочей нагрузке.
Kiali собирает метрики из Prometheus, использует Grafana и ее графики для визуализации и использует Jaeger для трассировки. Звучит сложно, так как здесь огромное количество компонентов, которые необходимо сконфигурировать и за ними следить, но вся эта история работает довольно-таки просто.
Как все это нести в кластер и не сойти с ума
В Nova Container Platform естьоператор — Apps Operator, который:
принимает YAML-спеку для Service Mesh;
развертывает нужные ресурсы;
отслеживает статус установки.
Также мы поставляем базовые политики:
ограничение трафика внутри namespace;
MTLS.
Что дальше?
Мы активно работаем над:
мультикластером: объединяем несколько Nova-кластеров;
федерацией: возможность публикации отдельных кубовых сервисов, задеплоенных внутри платформы между кластерами Nova
тестированием Ambient Mesh, чтобы понять, насколько он силен в бою;
интеграцией графической консоли по управлению Service Mesh в Nova, чтобы не прыгать между интерфейсами.
Заключение
Внедрение Service Mesh требует глубокого понимания решения, инфраструктурной зрелости и продуманного подхода. Мы в Orion soft прошли большой путь и готовы делиться опытом, в том числе делаем это в нашем ТГ-коммьюнити СНОВА О КУБЕРЕ. Надеюсь, что наш кейс будет полезен кому-то, я готов ответить на ваши вопросы в комментариях.
Те, что уже через это прошел — напишите про свой опыт внедрения Service Mesh.