Развёртывать микросервисы на сервере — то ещё удовольствие, даже с Kubernetes. К тому же Kubernetes не занимается коммуникациями между сервисами. Для этой задачи мы привлекаем Istio — реализацию service mesh.

В Kubernetes мы развёртываем сервисы в подах, но как поды внутри Kubernetes общаются друг с другом и в чём тут загвоздка? Разберемся в этой статье. 

Взаимодействие между подами

Kubernetes использует интерфейс CNI для взаимодействия между сетью и подами в кластере. На рабочей ноде за общение подов отвечает kube-proxy — сетевой прокси, который работает на каждой ноде в кластере и управляет сетевыми правилами. Сетевые правила регулируют взаимодействие в кластере и за его пределами.

Когда мы создаём под, или сервис, kube-proxy обновляет правила iptables, чтобы поды могли общаться:

Иллюстрация из «Kubernetes в действии» (Kubernetes In Action)
Иллюстрация из «Kubernetes в действии» (Kubernetes In Action)

Когда мы создаём сервис Service B, сервер API Kubernetes уведомляет kube-proxy на рабочей ноде, чтобы он добавил в iptables правила для Service B. Когда какой-то под будет вызывать Service B, запрос сначала будет направлен в iptables. iptables заменит целевой IP в Packet X на IP пода Pod B и перешлёт запрос в Pod B.
Но у kube-proxy есть ограничения:

  • Запросы подам отправляются случайным образом. 

  • Трафик нельзя поделить на части по процентам.

  • Канареечные и сине-зелёные развёртывания не поддерживаются.

  • Сложно мониторить и отлаживать.

Безопасность, повторы запросов, наблюдаемость и т. д. при общении микросервисов приходится прописывать в коде.

Это не критично, но все эти процессы воруют ресурсы у главного приложения. И писать лишний код неохота. Так мы пришли к service mesh.

Service mesh

Service mesh — это отдельный инфраструктурный уровень, который мы добавляем к приложениям для взаимодействия между сервисами или микросервисами. На этом уровне можно прозрачно добавить наблюдаемость, управление трафиком и безопасность, чтобы не включать их в код.

У service mesh есть control plane управления и data plane. Первая управляет прокси для маршрутизации трафика, а вторая отвечает за коммуникации между сервисами. Data plane обычно реализуется как sidecar, который развёртывается вместе с кодом приложения.В Kubernetes data plane — это sidecar-контейнер рядом с главным контейнером в поде. Когда service mesh запускается на платформе кубернетес, data plane service mesh представлен sidecar-контейнером, который выполняется рядом с основным контейнером в поде. Эти sidecar-контейнеры обеспечивают взаимодействие между сервисами в разных подах. Таким образом теперь взаимодействие между подами происходит не через kube-proxy, а через sidecar: под обращается к sidecar-контейнеру и уже через него общается с другими подами.

 Безопасность, автоматические повторы запросов, мониторинг и другие возможности обрабатывает sidecar-контейнер, а приложение содержит только бизнес-логику.Две самых популярных реализации service mesh — Istio и Consul. Мы познакомимся только с Istio.

Istio

Istio — это service mesh с открытым кодом, который прозрачно накладывается на существующие распределённые приложения. Istio предлагает единообразный и эффективный подход к безопасности, взаимодействию и мониторингу.
Control plane в Istio реализована в контейнере Istiod, а data plane развёртывается в поде как sidecar с помощью контейнера с Envoy.

Схема Istio
Схема Istio

Istiod отвечает за обнаружение сервисов, конфигурацию и управление сертификатами. Он преобразует высокоуровневые правила маршрутизации трафика в конфигурации для Envoy, а затем распространяет их по sidecar-контейнерам в рантайме.
Прокси Envoy развёртываются как sidecar’ы в подах и дают несколько возможностей:

  • динамическое обнаружение сервисов;

  • балансировки нагрузки;

  • терминация TLS;

  • прокси HTTP/2 и gRPC;

  • размыкатели цепи;

  • проверки работоспособности;

  • постепенное развёртывание с процентным разделением трафика;

  • внесение ошибок;

  • всевозможные метрики.

Если мы установим Istio в Kubernetes и создадим под, контейнер Envoy будет внедрен в него автоматически — его не придётся объявлять в манифесте пода. Сейчас Istio — это проект Cloud Native Computing Foundation (CNCF).Теперь вы знаете, зачем микросервисам нужна service mesh и причём тут Istio.

Еще больше о service mesh

9-11 декабря пройдет 3-й поток интенсива «Service mesh» от Александра Лукьянченко, руководителя юнита PaaS в Авито, и Георга Гаала, Senior Infrastructure Engineer в Workato.

Мы на практике изучим принцип работы технологии, решим реальные бизнес-кейсы и научимся искать причины проблем. Чтобы разобраться в технологиях, потребуется всего три дня — столько продлится наш интенсив по service mesh.

Как будет проходить интенсив?

Вы не просто посмотрите на то, какие фичи есть у service mesh, а попробуете с ними поработать в специально разработанном приложении онлайн-кинотеатра, состоящего из нескольких микросервисов.

Мы будем внедрять service mesh с нуля, а также смотреть, как это корректно делать именно в таких условиях, когда у нас уже что-то есть. Большинство компаний будут внедрять не с нуля, и нам это важно отработать. Также все кейсы мы берем из реальной практики и будем последовательно закрывать возникающие проблемы с помощью service mesh.

После интенсива вы:

  • Будете точно понимать, как правильно подходить к внедрению разных частей service mesh, и как сделать так, чтобы не ронять всю систему.

  • Разберетесь как в эксплуатации быть уверенным в том, что все работает в штатном режиме, а в случае проблем быстро это исправлять.

 «Интенсив будет хорошим вариантом как сэкономить кучу времени на набивании шишек», — Станислав Емец, слушатель предыдущего интенсива, ведущий инженер по эксплуатации в Ростелеком ИТ.

«Набрался знаний, часть из которых начал активно применять на своих проектах почти сразу. Отдельно хочу отметить подачу материала: это было не монотонное вливание материала лектором, а достаточно живая подача, постоянно закрепляемая практикой. Такой формат максимально закрепился в голове и руках», — Василий Егоров, Devops-инженер ООО МЛМ-Софт, автор канала RealManual.

Количество мест ограничено. Самое время узнать подробности и оставить заявку.

Комментарии (1)


  1. stan1901
    25.11.2022 11:14

    А есть хоть какая-нибудь оценка того, сколько реально позволило сэкономить применение Istio? Желательно не на "сферическом примере в вакууме", а на реальном. Мы вот заморочились, внедрили Istio по требованиям организации, словили кучу проблем с ним. И никто не видит никакой пользы. Терминирование TLS особо не нужно (безопасность требует шифровать всё); балансировки по кругу хватает; размыкатели цепи в теории штука неплохая, но нередко уже встроена в библиотеки, да и без зашкаливающей нагрузки особо не нужна; метрики - и так всё обвешено Прометеями настолько, что глаз смотреть не хватает.