Развёртывать микросервисы на сервере — то ещё удовольствие, даже с Kubernetes. К тому же Kubernetes не занимается коммуникациями между сервисами. Для этой задачи мы привлекаем Istio — реализацию service mesh.
В Kubernetes мы развёртываем сервисы в подах, но как поды внутри Kubernetes общаются друг с другом и в чём тут загвоздка? Разберемся в этой статье.
Взаимодействие между подами
Kubernetes использует интерфейс CNI для взаимодействия между сетью и подами в кластере. На рабочей ноде за общение подов отвечает kube-proxy — сетевой прокси, который работает на каждой ноде в кластере и управляет сетевыми правилами. Сетевые правила регулируют взаимодействие в кластере и за его пределами.
Когда мы создаём под, или сервис, kube-proxy обновляет правила iptables, чтобы поды могли общаться:
Когда мы создаём сервис 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.
Istiod отвечает за обнаружение сервисов, конфигурацию и управление сертификатами. Он преобразует высокоуровневые правила маршрутизации трафика в конфигурации для Envoy, а затем распространяет их по sidecar-контейнерам в рантайме.
Прокси Envoy развёртываются как sidecar’ы в подах и дают несколько возможностей:
динамическое обнаружение сервисов;
балансировки нагрузки;
терминация TLS;
прокси HTTP/2 и gRPC;
размыкатели цепи;
проверки работоспособности;
постепенное развёртывание с процентным разделением трафика;
внесение ошибок;
всевозможные метрики.
Если мы установим Istio в Kubernetes и создадим под, контейнер Envoy будет внедрен в него автоматически — его не придётся объявлять в манифесте пода. Сейчас Istio — это проект Cloud Native Computing Foundation (CNCF).Теперь вы знаете, зачем микросервисам нужна service mesh и причём тут Istio.
Еще больше о service mesh
Приходите на интенсив по service mesh от Александра Лукьянченко, руководителя юнита PaaS в Авито, и Георга Гаала, Senior Infrastructure Engineer в Workato.
Мы на практике изучим принцип работы технологии, решим реальные бизнес-кейсы и научимся искать причины проблем. Чтобы разобраться в технологиях, потребуется всего три дня — столько продлится наш интенсив по service mesh.
Как будет проходить интенсив?
Вы не просто посмотрите на то, какие фичи есть у service mesh, а попробуете с ними поработать в специально разработанном приложении онлайн-кинотеатра, состоящего из нескольких микросервисов.
Мы будем внедрять service mesh с нуля, а также смотреть, как это корректно делать именно в таких условиях, когда у нас уже что-то есть. Большинство компаний будут внедрять не с нуля, и нам это важно отработать. Также все кейсы мы берем из реальной практики и будем последовательно закрывать возникающие проблемы с помощью service mesh.
После интенсива вы:
Будете точно понимать, как правильно подходить к внедрению разных частей service mesh, и как сделать так, чтобы не ронять всю систему.
Разберетесь как в эксплуатации быть уверенным в том, что все работает в штатном режиме, а в случае проблем быстро это исправлять.
«Интенсив будет хорошим вариантом как сэкономить кучу времени на набивании шишек», — Станислав Емец, слушатель предыдущего интенсива, ведущий инженер по эксплуатации в Ростелеком ИТ.
«Набрался знаний, часть из которых начал активно применять на своих проектах почти сразу. Отдельно хочу отметить подачу материала: это было не монотонное вливание материала лектором, а достаточно живая подача, постоянно закрепляемая практикой. Такой формат максимально закрепился в голове и руках», — Василий Егоров, Devops-инженер ООО МЛМ-Софт, автор канала RealManual.
Количество мест ограничено. Самое время узнать подробности и оставить заявку.
