Развёртывать микросервисы на сервере — то ещё удовольствие, даже с 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 есть 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 — это 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 от Александра Лукьянченко, руководителя юнита PaaS в Авито, и Георга Гаала, Senior Infrastructure Engineer в Workato. Мы на практике изучим принцип работы технологии, решим реальные бизнес-кейсы и научимся искать причины проблем. Чтобы разобраться в технологиях, потребуется всего три дня — столько продлится наш интенсив по service mesh. Вы не просто посмотрите на то, какие фичи есть у service mesh, а попробуете с ними поработать в специально разработанном приложении онлайн-кинотеатра, состоящего из нескольких микросервисов. Мы будем внедрять service mesh с нуля, а также смотреть, как это корректно делать именно в таких условиях, когда у нас уже что-то есть. Большинство компаний будут внедрять не с нуля, и нам это важно отработать. Также все кейсы мы берем из реальной практики и будем последовательно закрывать возникающие проблемы с помощью service mesh. Будете точно понимать, как правильно подходить к внедрению разных частей service mesh, и как сделать так, чтобы не ронять всю систему. Разберетесь как в эксплуатации быть уверенным в том, что все работает в штатном режиме, а в случае проблем быстро это исправлять.  «Интенсив будет хорошим вариантом как сэкономить кучу времени на набивании шишек», — Станислав Емец, слушатель предыдущего интенсива, ведущий инженер по эксплуатации в Ростелеком ИТ. «Набрался знаний, часть из которых начал активно применять на своих проектах почти сразу. Отдельно хочу отметить подачу материала: это было не монотонное вливание материала лектором, а достаточно живая подача, постоянно закрепляемая практикой. Такой формат максимально закрепился в голове и руках», — Василий Егоров, Devops-инженер ООО МЛМ-Софт, автор канала RealManual. Количество мест ограничено. Самое время узнать подробности и оставить заявку.