Istio

2729 мая пройдёт онлайн-интенсив Kubernetes Мега. Чему учить будем?



Мы не сделаем из вас продвинутого специалиста за три дня, а само участие в интенсиве не поднимет вашу зарплату. Но вы получите практические навыки управления инфраструктурой, с которыми можно уверенно работать с Kubernetes в продакшене.

Павел Селиванов, Senior DevOps Engineer в Mail.ru Cloud Solutions, Сергей Бондарев, архитектор в Southbridge и Марсель Ибраев, CTO в Слёрм будут разбирать тонкости установки, конфигурации production-ready кластера (the-not-so-easy-way) и отвечать на ваши вопросы.

Отказоустойчивость

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

А для того чтобы защитить кластер от падения метеорита на дата-центр, покажем инструмент, позволяющий организовать резервное копирование в кластере Kubernetes.

Тема 1: Процесс создания отказоустойчивого кластера изнутри

• Работа с Kubeadm,
• Тестирование и траблшутинг кластера.

Тема 9: Резервное копирование и восстановление после сбоев

• Методы резервного копирования,
• Бэкап и восстановление кластера с применением Heptio Velero (бывш. Ark) и etcd.

Говоря про кластер, мы думаем о некой распределённой отказоустойчивой системе, в которой задублировано практически всё: диски, процессоры, память, сетевые линки, системы хранения данных.

Подобный уровень резервирования позволяет снизить риски простоя при аппаратных сбоях.

Безопасность

Все компоненты кластера между друг другом аутентифицируются с помощью сертификатов. Мы расскажем, что делать, если сертификаты просрочились и как предотвратить такие ситуации.

Но для живых пользователей этот вариант подходит не очень хорошо, так как сложен в применении, обязательно расскажем про лучшие варианты: Authentication proxy и OIDC.

Ещё есть безопасный вариант с паролями или токенами, но это уже в теме хранения секретов, для пользователей он не очень удобен в реализации, особенно в случае с несколькими мастер-нодами.

Тема 2: Авторизация в кластере при помощи внешнего провайдера

• LDAP (Nginx + Python),
• OIDC (Dex + Gangway).

Тема 4: Безопасные и высокодоступные приложения в кластере

• PodSecurityPolicy,
• PodDisruptionBudget,
• PriorityClass,
• LimitRange/ResourceQuota.

Тема 7: Хранение секретов

• Управления секретами в Kubernetes,
• Vault.

Тема 10: Ежегодная ротация сертификатов в кластере

• Сертификаты компонентов кластера,
• Продление сертификатов control-plane с помощью kubeadm.

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

Устройство Kubernetes

Осознанный выбор наиболее эффективных инструментов приходит с пониманием устройства Kubernetes, его компонентов, устройства сети и процесса её создания.

Тема 3: Network policy

• Введение в CNI,
• Network Security Policy.

Тема 5: Kubernetes. Заглядываем под капот

• Строение контроллера,
• Операторы и CRD.

Более глубокое понимание, как работает Kubernetes, сеть в кластере позволит решать задачи продвинутого уровня, такие как, например, написание собственного контроллера, оптимальная организация сети в кластере Kubernetes.

Базы данных в Kubernetes

Можно ли запустить базу данных в Kubernetes можно, но есть нюансы. Надо задуматься: стоит ли запускать Stateful приложения, какие есть от этого выгоды и с какими проблемами вам предстоит столкнуться. Посмотрим на реальном примере, как можно запустить базу данных в Kubernetes.

Тема 6: Stateful приложения в кластере

• Нюансы запуска базы данных в Kubernetes,
• Запуск кластера базы данных на примере RabbitMQ и CockroachDB.

Единственный положительный момент это простота и скорость запуска stateful приложения, поэтому production базы, которые работают под нагрузкой, надо запускать на отдельных, выделенных серверах.

Но не всё так плохо. Для разработки и тестирования вполне можно запускать базы данных в kubernetes.

Масштабирование

Один из самых частых запросов в Kubernetes автоматически скейлить количество инстансов приложений в зависимости от нагрузки и других показателей.

Спикеры расскажут об инструменте Kubernetes, который позволит вам динамически управлять количеством реплик приложения.

Тема 8: Horizontal Pod Autoscaler

• Скейлинг на основе встроенных метрик,
• Кастомные метрики.

Деплой приложения

Существует шесть самых популярных стратегий деплоя, некоторые реализованы в Kubernetes нативно, для других нужно использовать специальные инструменты и пляску с бубном.

Тема 11: Деплой приложения

• Инструменты темплэйтирования и деплоя,
• Стратегии деплоя.

Знание и использование разнообразных стратегий деплоя позволит более гибко подходить к развёртыванию вашего приложения. Использовать преимущества одних стратегий и не обойти недостатки других, там, где это необходимо. Можно выбирать.

Service mesh

Обзорное представление технологии service mesh и её конкретной реализации Istio необходимо, чтобы понять, какие проблемы может решать service mesh, какими инструментами и когда её можно использовать.

Тема 12: Service mesh

• Установка Istio,
• Обзор основных абстракций.

Сертификация

Итоговая практическая работа

Сертификация от учебного центра Слёрм подтверждает, что вы действительно владеете материалом. Чтобы получить сертификат, нужно сдать внутренний экзамен: мы дадим задание и предоставим стенд для выполнения.

Выполнив задание, вы отправляете настроенный кластер на ревью. Мы оцениваем качество настройки, выставляем баллы по теме. Если вы набрали достаточно баллов, мы выдаём вам номерной именной сертификат.

Формат

Практические задания и сертификация будут выполняться из личного кабинета, трансляция со спикерами пройдёт в zoom, а для общения дополнительно будет telegram-чат.

До интенсива осталось 2 недели, регистрируйтесь по ссылке: slurm.club/megamay21
Вопросы по интенсиву в комменты.

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




Мое знакомство с service mesh было во многом случайным, когда в 2017 году мне на глаза попался анонс о сотрудничестве Google и IBM по созданию нового open source проекта. Не сказать, что партнерства крупнейших технологических компаний редки, но именно этот случай вызвал у меня большой интерес. Во-первых, примеров взаимодействия именно компаний Google и IBM все же не так много: пожалуй, наиболее известными фактами будут работа вокруг открытой аппаратной архитектуры OpenPOWER, а также наличие сервисов IBM в Google Cloud. Во-вторых, несмотря на наличие примеров, когда и Google, и IBM развивают один и тот же open source проект (Kubernetes или TensorFlow), случаев, чтобы обе эти компании стали именно основателями проекта, очень мало, и они достаточно уникальны. И, в-третьих, наличие среди основателей проекта IBM и Google компании Lyft конкурента Uber как сервиса вызова такси, вызывало вопросы и неподдельный интерес. Тот анонс в 2017 году рассказывал о выпуске технологии Istio, предназначенной для управления взаимодействием различных сервисов. Поначалу не совсем очевидно, в чем заключается проблема и зачем создавать такой проект, так как подходов по управлению взаимодействием между сервисами было известно довольно много. Чтобы понять проблематику, стоит взглянуть на ситуацию шире и посмотреть на изменения в ИТ-архитектуре на тот момент времени.

Что такое service mesh

Причины появления и столь стремительно нарастающей популярности service mesh неразрывно связаны с изменениями в ИТ архитектуре. Представить появление service mesh без микросервисной архитектуры достаточно сложно давайте посмотрим почему. Можно долго спорить, что такое микросервисная архитектура, так как единого и устоявшегося определения нет (и вообще эта тема заслуживает отдельной статьи), но для упрощения остановимся на следующих ключевых характеристиках: это небольшие автономные части бизнес-логики, реализованные как сервисы, каждый из которых имеет свой цикл сборки и поддержки. В таком случае логично задуматься о том, как эти небольшие сервисы будут взаимодействовать друг с другом и как контролировать этот процесс. Здесь и появляется service mesh. В реальной жизни эту технологию можно сравнить с дорожным навигатором. На дорогах могут случаться различные ситуации: аварии, заторы, выход из строя светофоров, а система позволяет вам добраться из пункта А в пункт Б наиболее оптимальным способом, зная обо всех произошедших событиях.

Ключевыми задачами, которые берет на себя service mesh, являются:

• управление трафиком
• балансировка нагрузки
• обеспечение безопасности при взаимодействии сервисов
• сбор метрик и мониторинг

Другим аналогом service mesh из реальной жизни может быть служба почтовой доставки: она решает, что делать с посылкой, если вас нет дома или вы переехали, следит за безопасностью транспортировки, обеспечивает приватность передачи посылки и отслеживает статусы.

Эволюция развития service mesh

В настоящее время service mesh стал отдельным слоем и во многом стандартом де-факто современной ИТ-архитектуры на уровне инфраструктуры. Можно ли строить современные решения без service mesh и реализовывать этот функционал как-то по-другому? Конечно, да, только вопрос в удобстве, гибкости, времени реализации и дальнейшей поддержке решения. Безусловно, задачи, связанные с управлением трафика или балансировкой, можно решить самому на уровне кода для каждого из сервисов. Но так как микросервисная архитектура подразумевает существование десятков, сотен или даже тысяч различных сервисов, то реализовывать один и тот же функционал при разработке каждого из них совсем не удобно. Зачем разрабатывать один и тот же функционал десятки или сотни раз, если можно вынести его отдельно?
Первые реализации service mesh были сделаны на прикладном уровне. Самый известный пример фреймворк (или набор библиотек) Netflix OSS, доступный для использования с 2012 года. В него вошли компоненты, реализующие функционал, присущий service mesh: с помощью Eureka производится обнаружение сервисов (service discovery), с помощью Hystrix ряд паттернов обнаружений ошибок (circuit breaker), Zuul решает задачи динамической маршрутизации (dynamic routing).

На необходимость изменения этого подхода оказали сильное влияние следующие факторы:

• поддержка нескольких языков программирования и отсутствие зависимости от них
• удобство разделения прикладных и инфраструктурных задач для DevOps: возможность вносить изменения в прикладной код без влияния на инфраструктуру
• развитие контейнерных технологий

Как ни крути, Netflix OSS куда больше был интегрирован в прикладную логику сервиса, требовал использование стека технологий Netflix, имел зависимость библиотек от языка разработки и не был заточен для использования в контейнерах.
Istio как пример следующей волны эволюции технологии использует sidecar (Envoy от Lyft), то есть прокси, который располагается рядом с каждым сервисом и берет на себя функционал по управлению политиками безопасности, трафиком, сбор телеметрии и пр. Это позволяет быть нейтральным к выбору языка программирования, иметь хорошую интеграцию с Kubernetes как стандарта де-факто по оркестрации контейнерных сред и не иметь никаких зависимостей от прикладной логики сервисов. По факту именно на этом шаге эволюции технологии service mesh произошло ее окончательное выделение в отдельный инфраструктурный слой как самостоятельный уровень современной ИТ-архитектуры.

Адаптация технологии в корпоративном мире

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

Вопрос 1: Достигла ли технология Istio достаточной зрелости для внедрения в корпорациях?

Так как мы говорим о крупных организациях, то для них вопрос зрелости той или иной технологии является одним из самых первых. Что подразумевается под зрелостью? Параметрами зрелости могут быть функциональность, стабильность работы, количество промышленных внедрений, максимальная нагрузка, а также соответствие ряду нефункциональных требований, например, по отказоустойчивости или масштабированию. Важно понимать, что для каждой компании количественные значения каждого из параметров будут своими в зависимости от ее масштабов и сценариев использования.
Что можно сказать про Istio? С точки зрения стабильности работы в мире open source немаловажным является выпуск версии 1.0, которая сообществом контрибьюторов Istio была представлена еще летом 2018 года. Примерами по использованию технологии являются уже десятки компаний, наиболее известными среди которых являются Ebay, Yahoo и банк ING. Интересными примером является история использования Istio при эксплуатации истребителя F16. Отдельно стоит выделить факт, что ведущие облачные провайдеры IBM и Google предоставляют сервисы на базе Istio для своих клиентов. Более того, Istio используется даже как часть новых open source фреймворков. Пример: Kabanero, направленный на более быструю разработку приложений поверх контейнерной инфраструктуры.

С точки зрения нефункциональных требований в корпорациях уделяется большое внимание требованиям по отказоустойчивости, и здесь Istio предоставляет большое число опций по развертыванию, как внутри одного, так и нескольких кластеров Kubernetes. Ниже в статье мы рассмотрим вопрос об опциях развертывания подробнее. Думаю, излишне говорить, что все эти аргументы однозначно позволяют судить о том, что Istio как технология достигла достаточного уровня зрелости для внедрения в корпоративном сегменте для решения бизнес-критичных задач.

Вопрос 2: Service mesh для новых сред с контейнерами, а что делать с традиционным ландшафтом на виртуальных машинах?

Service mesh принадлежит типу технологий, относящихся к cloud native, которые создавались в эру развития контейнеров. Но, вспоминая реальность ИТ ландшафта корпораций, можно заметить, что промышленных систем, работающих поверх контейнеров не так много, и корпорации стоят лишь в начале пути по их массовому использованию. Многие бизнес-критичные задачи по-прежнему работают на виртуальных машинах и здесь возникает вопрос: неужели для них нельзя использовать Istio?
Краткий ответ конечно, можно. Istio позволяет создавать разные конфигурации с использованием как контейнерной инфраструктуры, так и виртуальных машин или даже bare metal. Для связи виртуальных машин и service mesh необходимо выполнить ряд действий, например обеспечить видимость IP-адресов кластера с Istio и пр. Более подробное описание и примеры можно найти здесь.

Вопрос 3: Какую модель развертывания выбрать?

Этот вопрос, между прочим, весьма непростой и затрагивающий много областей, включая как технические вещи (нефункциональные требования по отказоустойчивости, безопасности и производительности), так и организационные (структуру команд). Какие опции развертывания возможны?

• один или несколько кластеров (мультикластер)
• один или несколько сетевых сегментов
• одна или несколько контрольных точек управления (control panel)
• одна или несколько сеток (mesh)

На текущий момент времени можно сказать, что опция мультикластерного развертывания является наиболее востребованной в корпорациях среди прочих не случайно этому аспекту уделяется большая часть работы сообщества вокруг проекта Istio. Каковы причины выбора именно этой опции? Это наличие большого количества команд разработки отдельных продуктов и систем, это необходимость развертывания в нескольких ЦОД, это разделение на зоны разработки, тестирования и промышленной эксплуатации. Из-за всех этих требований опция развертывания одного кластера даже с несколькими сервисными сетками внутри него не позволяет обеспечить необходимый уровень изоляции ресурсов.
Безусловно, внутри мультикластерного развертывания могут быть также варианты размещения контрольных панелей: не обязательно размещать одну контрольную панель на один кластер, несколько кластеров могут использовать одну контрольную панель.
На практике на определение опции развертывания уходит не одна неделя проектирования, так как архитекторам необходимо прийти к компромиссу между хорошим уровнем изоляции ресурсов и накладными расходами на взаимодействие между кластерами.

Вопрос 4: А какую нагрузку выдержит?

Так как речь идет о корпорациях, то, как правило, они обслуживают большое число клиентов и, соответственно, имеют на своих системах большие нагрузки. Поэтому вопрос абсолютно не праздный и на практике не редки случаи, когда та или иная новая технология не давала нужную производительность и не могла обеспечить предоставление сервисов компании по запросу клиентов.
Конечно, самый грамотный ответ на этот вопрос: зависит от множества факторов. То, как развернута система, какие требования по отказоустойчивости или изоляции, какая версия технологии используется все эти факторы оказывают прямое воздействие на производительность. Но вряд ли этот ответ способен дать хоть какие-то оценки, поэтому посмотрим на уже имеющийся опыт других компаний. К сожалению, в открытых источниках сложно найти детальную информацию от компаний по их опыту использования Istio, но на различных встречах, митапах или конференциях уже в начале 2019 года одной из компаний в области информационной безопасности были представлены цифры в десятки тысяч транзакций в секунду (TPS) системы, использующей Istio. Многие корпорации провели пилотные проекты и получили результаты в несколько сотен транзакций в секунду. Много это или мало? Для примера, только несколько крупных банков России имеют нагрузки в несколько тысяч TPS на своих ИТ системах, поэтому оценка даже в несколько сотен TPS с лихвой покроет подавляющее большинство задач любой корпорации.

Вопрос 5: Когда будут нужные нам фичи?

Во время внедрения Istio технические специалисты организаций часто обращаются в IBM как к компании-основателю проекта с вопросами о сроках реализации конкретных новых фич технологии.

На этом вопросе можно хорошо показать разницу между проприетарным программным обеспечением от какого-либо вендора и миром open source. Многие корпорации с точки зрения своих ожиданий одинаково относятся и к тем, и другим технологиям, хотя в ряде моментов различия достаточно большие и ждать такой же ответственности от участников open source проекта, как от компании-производителя коммерческого ПО, странно. Безусловно, за большинством успешных open source проектов стоит одна или несколько компаний, которая, как правило, и является основателем. Но в отличие от коммерческого ПО, компания-основатель не может просто так взять и добавить фичу в проект без обратной связи от других контрибьюторов. Здесь есть и свои плюсы, и минусы. Бывали случаи, когда один из контрибьюторов брался за реализацию конкретной фичи, в которой были заинтересованы многие участники проекта, но срывал сроки из-за занятости и болезни, отодвигая релиз на несколько месяцев вперед. Поэтому в случае open source проекта гарантировать выход конкретной фичи в конкретный срок намного тяжелее, чем в случае с коммерческим ПО. С другой стороны, нет такой прямой зависимости от решения одной компании, так как реализацию может взять на себя другой участник проекта.

Поэтому четкого ответа на этот вопрос не существует, но есть ряд рекомендаций, которые позволят держать руку на пульсе происходящего в open source проекте. На примере Istio cписок рабочих групп проекта известен, их встречи и протоколы обсуждений открыты, доступна возможность задавать вопросы и описывать проблемы во всех этих, а также многих других вещах представители корпораций могут участвовать. В текущий момент времени корпорации крайне осторожно принимают участие в жизни сообщества, и очень хочется надеяться, что в ближайшее время этот тренд изменится.

Вместо заключения

Что можно сказать в итоге? Несмотря на то, что Istio достаточно молодая технология, ее текущий уровень зрелости и существующий функционал полностью отвечают требованиям корпораций. Видно, что среди крупных российских компаний интерес к Istio за последний год существенно вырос и все больше и больше ИТ команд начинают свои первые проекты, а ряд из них уже использует технологию в промышленной среде.
Для тех, кто хочет видеть Istio не только в своих ИТ системах, но и на полке или столе, мой коллега создал модель парусника как копию логотипа Istio для распечатки на 3D-принтере, которую можно скачать здесь.

Использование Istio+Kiali для запуска и визуализации Canary деплоя

---

Статьи этого цикла

1. Canary Deployment в Kubernetes #1: Gitlab CI
2. Canary Deployment в Kubernetes #2: Argo Rollouts
3. (эта статья)
4. Canary Deployment используя Jenkins-X Istio Flagger

Canary Deployment

Надеемся, что вы читали первую часть, где мы кратко объясняли что такое Canary deployments и показывали как его реализовать при помощи стандартных ресурсов Kubernetes.

Istio

И мы предполагаем, что читая эту статью, вы уже знаете что такое Istio. Если нет, то вы можете почитать о нем здесь.

Приложение для тестов

Каждый под содержит два контейнера: наше приложение и istio-proxy.

Мы будем использовать простое тестовое приложение с подами frontend-nginx и backend на python. Под с nginx будет просто перенаправлять каждый запрос на под с backend и работать как прокси. Детали можно посмотреть подробнее в следующих yamls:

• frontend.yaml
• backend.yaml
• istio.yaml

Запуск тестового приложения самостоятельно

Если вы хотите последовать моему примеру и использовать данное тестовое приложение самостоятельно, см. readme проекта.

Начальный Deployment

При запуске первого Deployment видим, что поды нашего приложения имеют всего по 2 контейнера, то есть Istio sidecar пока только внедряется:

---

И также видим Istio Gateway Loadbalancer в namespace istio-system:

Создание трафика

Мы будем использовать следующий IP, что бы сгенерировать трафик, который будет принят frontend подами и перенаправлен на backend поды:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

Мы так же добавим frontend.istio-test в наш hosts файл.

Просмотр Mesh через Kiali

Мы установили тестовое приложение и Istio вместе с Tracing, Grafana, Prometheus и Kiali (подробнее см. readme проекта). Следовательно, мы можем использовать Kiali через:

istioctl dashboard kiali # admin:admin

Kiali визуализирует текущий трафик через Mesh

Как мы видим, 100% трафика попадает на frontend service, затем на под фронтенда с label v1, так как мы используем простой nginx-прокси, который перенаправляет запросы на backend service, который в свою очередь перенаправляет их на backend поды с label v1.

Kiali работает отлично вместе с Istio и предоставляет коробочное решение для визуализации Mesh. Просто прекрасно.

Canary Deployment

Наш бекенд уже имеет два k8s deployments, один для v1 и один для v2. Теперь нам нужно просто сказать Istio перенаправлять определенный процент запросов на v2.

Шаг 1: 10%

И все что нам нужно сделать это отрегулировать вес VirtualService в istio.yaml:

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: backend  namespace: defaultspec:  gateways: []  hosts:  - "backend.default.svc.cluster.local"  http:  - match:    - {}    route:    - destination:        host: backend.default.svc.cluster.local        subset: v1        port:          number: 80      weight: 90    - destination:        host: backend.default.svc.cluster.local        subset: v2        port:          number: 80      weight: 10

---

Мы видим, что 10% запросов перенаправлено на v2.

Шаг 2: 50%

И теперь достаточно просто увеличить его до 50%:

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: backend  namespace: defaultspec:...    - destination:        host: backend.default.svc.cluster.local        subset: v1        port:          number: 80      weight: 50    - destination:        host: backend.default.svc.cluster.local        subset: v2        port:          number: 80      weight: 50

---

Шаг 3: 100%

Теперь Canary deployment может считаться завершенным и весь трафик перенаправляется на v2:

---

Тестирование Canary вручную

Допустим, сейчас мы отправляем на бэкэнд v2 10% от всех запросов. Что, если мы хотим вручную протестировать v2, чтобы убедиться, что все работает как мы ожидаем?

Мы можем добавить специальное соответствующее правило, основанное на HTTP заголовках:

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: backend  namespace: defaultspec:  gateways: []  hosts:  - "backend.default.svc.cluster.local"  http:  - match:    - headers:        canary:          exact: "canary-tester"    route:    - destination:        host: backend.default.svc.cluster.local        subset: v2        port:          number: 80      weight: 100  - match:    - {}    route:    - destination:        host: backend.default.svc.cluster.local        subset: v1        port:          number: 80      weight: 90    - destination:        host: backend.default.svc.cluster.local        subset: v2        port:          number: 80      weight: 10

Теперь используя curl мы можем принудительно запросить v2 отправив заголовок:

---

Запросы без заголовка все еще будут управляться соотношением 1/10:

---

Canary для двух зависимых версий

Теперь мы рассмотрим вариант, где у нас есть версия v2 и для frontend и для backend. Для обоих мы указали, что 10% трафика должно идти к v2:

---

Мы видим, что frontend v1 и v2 оба пересылают трафик в соотношении 1/10 на backend v1 и v2.

А что если бы мы нам было нужно пересылать трафик с frontend-v2 только на backend-v2, потому что он не совместим с v1? Для этого мы установим 1/10 соотношение для frontend, который контролирует какой трафик попадает на backend-v2 используя согласование по sourceLabels :

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: backend  namespace: defaultspec:  gateways: []  hosts:  - "backend.default.svc.cluster.local"  http:...  - match:    - sourceLabels:        app: frontend        version: v2    route:    - destination:        host: backend.default.svc.cluster.local        subset: v2        port:          number: 80      weight: 100

В результате получаем то, что нужно:

---

Отличия от ручного Canary подхода

В первой части мы выполняли Canary deployment вручную, также используя два k8s deployments. Там мы управляли соотношением запросов, изменяя количество реплик. Такой подход работает, но имеет серьезные недостатки.

Istio дает возможность определять соотношение запросов вне зависимости от количества реплик. Это значит, к примеру, что мы можем использовать HPAs (Horizontal Pod Autoscalers горизонтальное масштабирование подов) и его не нужно настраивать в соответствии с текущем состоянием Canary деплоя.

Итог

Istio работает отлично и используя его вместе с Kiali получаем очень мощную комбинацию. Следующий в моем списке интересов это комбинация Spinnaker с Istio для автоматизации и Canary-аналитики.

Легко и непринужденно настраиваем Istio для уменьшения нагрузки и влияния как на control, так и data plane, используя ресурс Sidecar.

По умолчанию все прокси вашей mesh получают настройки, требуемые для достижения любых других прокси. Важно заметить, что Config это не тоолько данные, которые вы пишете в ваши DestinationRule и VirtualService, но и описание состояния всех Endpoints ваших сервисов, поэтому, каждый раз, когда вы запускаете Deployment, или Pod переходит в состояние unready, ваш сервис масштабируется или происходит что-то еще, изменяющее состояние настройки отсылаются всем прокси.

Это отличный сценарий, если сервисы в вашей mesh можно пересчитать по пальцам, в таком случае он помогает новым пользователям достичь своей цели с минимальными притирками, но если ваша mesh растет, вы начинаете замечать следующее:

• Control plane (pilot или istiod) начинает жрать процессорное время, и, внезапно, сеть;
• Использование оперативной памяти на всех прокси растет вместе с ростом mesh, поскольку они все хранят все настройки всех сервисов;
• Pilot дольше загружает настройки на все требуемые сервисы, так что изменения требуют больше времени на распространение.

Что это значит в реальном мире?

Маловероятно, что все ваши сервисы должны общаться со всеми другими сервисами. Например, на картинке ниже изображен граф, показывающий связи сервисов в Auto Trader. Более 400 сервисов, однако среднее число N+1 соединений между сервисами равно 5. Это значит, что для подавляющего большинства случаев настройки прокси включают просто ненужные 395 наборов настроек.

Чтобы узнать еще немного цифр по графу с примера выше, сделав запрос GET :15000/config_dump на istio-proxy без настройки sidecar, мы получим результат размером в 5Мб. Умножая это число на число подов (1000) получаем порядка 5Гб полных настроек, загружаемых всеми сервисами. Это куча работы для control plane, особенно для кластера с постоянной высокой текучкой, где enpoints часто меняются.

Все эти настройки влияют по istio-proxy, кардинально увеличивая потребности в оперативной памяти. К примеру, обычный прокси, с 2 или 3 сервисами, использует примерно 25Мб оперативной памяти, поэтому 400 сервисов потребуют 250Мб. Умножая на вышесказанные 1000 прокси получаем, что вам надо будет использовать от 240Гб оперативной памяти.

Настройка Sidecar

Для решения этой проблемы Istio предоставляет ресурс Sidecar.Он определяем, какие настройки прокси должны получать от control plane. Проще говоря, он делает так: Эй, в mesh есть 400 сервисов, но мне нужны только вот эти два.

Так что если, допустим, сервис service-a общается с двумя другими service-b и service-c, но ему не нужно соединение с остальными 397 сервисами в mesh, мы создаем ресурс Sidecar, выглядящий примерно так:

apiVersion: networking.istio.io/v1beta1kind: Sidecarmetadata:  name: default  namespace: service-aspec:  egress:  - hosts:    - "./*"              # current namespace    - "istio-system/*"   # istio-system services    - "service-b/*"      # dependency 1    - "service-c/*"      # dependency 2

Это пример подразумевает, что каждый сервис развернут в своем отдельном пространстве имен.

Примечание 1: Мы здесь не используем селектор нагрузки, так что этот sidecar будет применяться на всех прокси в пространстве имен service-a

Примечание 2: Если вы примените эти настройки к существующему сервису, вам надо будет перезапустить вашу рабочую нагрузку, чтобы увидеть улучшения по оперативной памяти, поскольку если istio-proxy её запросил он не будет её отдавать обратно операционной системе до перезапуска.

Наблюдение за Pilot

Есть несколько важных параметров для мониторинга, чтобы получить данные о том, как долго Pilot выгружает настройки:

• pilot_xds_push_time_bucket общее время в секундах, потраченное Pilot на выгрузку lds, rds, cds и eds.
• pilot_proxy_convergence_time_bucket задержка в секундах между изменением настроек и их получением в прокси
• pilot_proxy_queue_time_bucket время в секундах, которое прокси тратит на ожидание в очереди выгрузки настроек.

На изображении ниже наш кластер на 400 сервисов, мы никогда не выходим за пределы 1 секунды:

Определение неверных настроек

Мы выкатываем настройки Istio с использованием outboundTrafficPolicy.mode: REGISTRY_ONLY. Это по-умолчанию запрещает все, поэтому нашим пользователям надо принудительно указывать в их настройках сервисы: если они не добавят сервисы в свой Sidecar они не будут работать. Сейчас это выражается двумя способами:

• Код ответа, возвращаемый от локального прокси, если он пытается связаться с неопределенным в Sidecar сервисом, будет 502.
• Выставляется параметр response_code в 502, а destination_service_name в соответствующее значение в BlackHoleCluster. Мы используем эту информацию, чтобы показывать предупреждение разработчикам. Они должны знать, что где-то ошиблись в настройках:

Результат

Потребление ресурсов на нашем производственном кластере (примерно 1500 подов, 1000 с istio-proxy) с правильно настроенным Sidecars такое:

• control plane: 1Гб оперативной памяти, всплески по процессору редко превышают потребление одного ядра;
• data plane: 35Гб оперативной памяти, загрузка по процессору от 7 до 25 потребляемых ядер, зависит от операций в секунду по сети.

Корректная настройка Sidecar критически важна для того, чтобы запустить Istio легко и непринужденно. Сами понимаете, что проще это все делать в самом начале, чем возвращаться и добавлять позднее.

От редакции: Для тех, кто хочет освоить в теории и на практике тонкости установки и конфигурации отказоустойчивого кластера, спикеры Слёрма создали видеокурс Kubernetes Мега. Курс поможет начать работать с Kubernetes на продвинутом уровне.

Что такое service mesh и какие задачи по управлению инфраструктурой решает? Как service mesh внедряли в Авито и почему отказались от популярного Istio? Зачем стали писать аналог и к чему в итоге пришли? Об этом в интервью Слёрму рассказал Александр Лукьянченко тимлид в команде архитектуры Авито и разработчик интенсива по service mesh.

В Авито Александр Лукьянченко строит внутреннюю платформу для всех разработчиков на базе оркестратора Kubernetes. В Слёрме готовит интенсив по service mesh, который стартует в марте.

Начнём с основ: что такое service mesh?

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

Это подход, когда мы неважно, какая у нас технология, на каком стеке написана система добавляем в каждый узел sidecar-контейнер и через него получаем возможность внедрять в сетевое взаимодействие любую логику. В результате можем внедрять разного рода вещи, которые я упомянул, а также инструменты observability для понимания, как все эти кусочки системы взаимодействуют.

Как узнать, что компании пора внедрять service mesh решения?

Самое главное это понять, какие проблемы есть в системе, и закрывает ли их service mesh.

1. Управление трафиком: канареечные деплои, деплои по методу blue-green, различные схемы балансировки (round-robin, хеш-балансировки и т. д.) между микросервисами. Это про эффективность и условное тестирование в продакшене, чтобы меньше аффектить пользователей в случае проблем.
2. Безопасность. Когда мы хотим не только снаружи, но и внутри иметь безопасное общение между всеми узлами в системе. Много кто идет в технологию, исходя именно из этого пункта. Если есть много компонентов в системе и надо сделать так, чтобы каждый из них взаимодействовал с другим по защищенному соединению, протоколу это задача сложная не только в плане имплементации, но и в плане поддержки. Надо заниматься ручной ротацией сертификатов или писать инструменты, которые это будут делать. А service mesh закрывает эти проблемы.
3. Observability. В развитой микросервисной архитектуре не всегда можно быстро найти причину деградации или какого-нибудь падения. Service mesh даёт возможность простого внедрения унифицированного распределенного трейсинга, мониторинга. Это в том числе и логирование, но логирование именно сетевого взаимодействия. Например, envoy proxy позволяет удобно и в подробном виде получать логи всех взаимодействий.
4. Объединение в единую сеть больших кусков системы. Например, нескольких Kubernetes-кластеров. Это тоже важный момент. Здесь есть два поинта. Первый мы с помощью такого подхода обновляем Kubernetes-кластера на новые версии, делая это не inplace для постепенного перехода. И второй когда у нас есть, например, несколько публичных облачных провайдеров либо своих дата-центров, мы можем с помощью этого подхода объединять их в единую сеть.
5. Отказоустойчивость системы. В распределенной системе в разных частях могут возникать периодические сетевые ошибки. С помощью паттернов circuit breaker, outlier detection, retry политик можно эти проблемы обойти. Но реализовывать в каждом узле их затратно. С service mesh это также можно решить.

Это основные моменты. На мой взгляд, их наличие хороший сигнал о том, что надо посмотреть на service mesh.

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

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

Как к внедрению service mesh пришли в Авито?

Были две глобальные задачи: решить проблемы с пониманием того, что происходит в системе и более гибко управлять трафиком. Сначала мы хотели улучшить observability, получить унифицированный мониторинг и трейсинг. Это была первая цель, которой мы добивались, внедряя service mesh.

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

Эти две глобальные задачи возникли с разницей примерно в год. Когда только начали подступаться к решению, помимо истории с observability был ещё один технический аспект, почему мы вообще пошли в эту технологию, начали её ресёрчить и внедрять, почему стали смотреть на Istio.

Дело в том, что к тому моменту мы уже использовали в продакшене Сontour.io от Heptio (сейчас VMware). Contour это ingress-контроллер на базе envoy proxy. Это более мощное решение, нежели стандартный ingress-контроллер на базе Nginx. Он позволяет делать много разных штук, которые умеет envoy, в том числе внедрять более мощные стратегии управления трафиком, нативные канареечные релизы. Кроме того, Contour обладал лучшим перфомансом, чем механика, которую использовал Nginx (reload конфигураций со сторонним контроллером и множеством логики на lua).

Но что самое интересное, по сути Contour использовал тот же стек технологий и тот же подход, что и решения service mesh. У него был свой control plane, очень похожий на то, что есть в Istio (в то время это был pilot компонент). Он использовал то же самое прокси-решение envoy proxy. Мы понимали подход и знали, что envoy proxy уже production ready, и его можно использовать в нашей системе. Поэтому мы начали входить в Istio.

В докладе о service mesh ты говорил, что его внедрение было обусловлено ещё и задачами тестирования.

Да, это как раз трек про управление трафиком. В непродакшн средах нам действительно нужна была фича перенаправление динамического трафика на новую версию микросервиса.

Это один из подходов, который позволял нам дешево тестировать: мы просто выкладываем новую версию сервиса и с помощью service mesh перенаправляли на неё трафик только для конкретно этих тестовых запросов с помощью специальных заголовков.

Возвращаясь к переходу от Contour к Istio: чем эти решения различаются?

Contour это ingress-контроллер, то есть решение, которое позволяет принимать внешний трафик внутрь Kubernetes-кластеров. По сути, только эту задачу он и решает.

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

Надо сказать, что почти все service mesh решения предоставляют возможность (на том же самом control plane, на тех же технологиях) использовать свой ingress-контроллер. Например, в Istio есть Gateway. Но есть и отдельные проекты, которые делают чисто ingress-контроллеры, Contour это один из них.

Рассматривали ли вы другие решения, кроме Istio?

В то время (а это был, по-моему, 2017 год) существовало два проекта, которые мы рассматривали Istio и Conduit (сейчас переименован в Linkerd 2). Почему мы выбрали Istio?

Первый поинт был в используемых технологиях, потому что envoy proxy в то время был уже продакшн-реди продукт, который использовался большими компаниями. Например, в Lyft, где и разработали envoy proxy, его уже использовали по паттерну service mesh. Мы понимали, что это решение, скорее всего, будет хорошо подготовлено к нагрузкам и будет успешно использоваться и в Авито с точки зрения перфоманса. А в Conduit было свое решение, написанное на Rust. У нас экспертизы по этому языку было немного, и казалось, что это не очень правильный подход, что там ещё свой прокси.

Второй момент это, конечно, маркетинг Istio и внедрение его в индустрию Google и IBM. Они очень качественно представили проект в индустрии: выпустили много презентаций и видео о возможностях Istio. Где-то за год им удалось сделать так, что если кто-то узнавал о service mesh или говорил, то рядом обязательно всплывало слово Istio. Istio стало как бы дефолтной реализацией.

И мы понимали, что скорее всего на горизонте нескольких лет именно Istio будет основной реализацией, которую будет использовать большинство компаний. Остальные имплементации может быть и останутся, но будут менее популярными и менее поддерживаемыми, чем Istio.

Каким образом вы начали внедрение? В своем интервью ты говорил, что перед этим тестировали Istio около года.

Начав его внедрять, мы уже примерно понимали, как всё устроено и как организовать процесс.

Начинали с песочницы?

Естественно, раскатывали постепенно. Сначала на staging-кластерах тестировали механику работы, разбирались в логике. Затем начали постепенно, посервисно внедрять. Спустя несколько месяцев дошли до продакшена.

К тому времени в основном Kubernetes-кластере у нас была уже достаточно большая система: тысячи инстансов, тысячи подов микросервисов. Поэтому новая система сразу же проверялась на перфоманс насколько она готова к такому объему.

При внедрении Istio в продакшн и всплыли явные проблемы, в том числе та, из-за которой мы спустя время решили отказаться от Istio. Самой большой проблемой оказался как раз перформанс работы Istio. Об этом я много рассказывал на конференциях.

Причина этой проблемы скрывалась в архитектуре, и устранить её нельзя было без сильного внедрения в исходный код Istio. Каждый инстанс содержал в себе знание о всей системе, и так как у нас уже была большая система с тысячами инстансов, каждый из узлов потреблял большое количество оперативной памяти. Вместе с тем, чтобы получать эти знания, Istio сильно утилизировал и сеть, и CPU.

Мы посмотрели, как это всё ведет себя в проде, умножили на количество наших инстансов и в принципе даже были готовы потянуть такой объем (хотя он был огромным, терабайты оперативной памяти просто так). Но понимали, что в будущем мы будем расти, и этот объём тоже будет расти, причём квадратично. То есть решение просто не масштабируется.

Помимо этого при внедрении возникали какие-то проблемы, встречались баги мы их сами фиксили. К тому времени у нас уже был свой форк Istio вещи, которые мы быстро не могли протащить в апстрим, исправляли сами. Но исправить проблему с перфомансом в то время было крайне сложно, потому что нужно было переписать процентов 30 кодовой базы Istio.

Получалось, что мы вроде как используем Istio, но при этом должны его сильно менять, и в итоге получить свой уникальный service mesh, просто на базе Istio.

Тогда мы начали понимать, что в Istio таком виде у нас в проде не может лететь в долгую. Совместно с еще одним моментом, на который закрывали глаза: Istio был не очень стабилен по API и от релиза к релизу делал ломающие изменения. Для больших компаний это проблема, потому что когда есть много мест, где используется технология, менять по каждому из вхождений имена это большая работа. Но мы были готовы с ней мириться, если бы не проблема с перфомансом.

Как могло получиться, что Istio разрабатывали такие большие компании, но с большими нагрузками она справляется плохо?

Istio и многие другие service mesh решения развивались эволюционно. Взять даже envoy proxy. В первой версии протокола использовался не gRPC, который позволяет делать сервер-пуши для обновления конфигураций в каждом узле. Там использовался обычный http, который давал оверхед на взаимодействие control plane с прокси-контейнерами. Соответственно, на это потреблялось большое количество CPU и сети, чтобы делать long polling, затем, спустя время перешли на gRPC.

В случае с Istio ровно та же история. Сначала сделали базовое решение, которое в целом решало нужные проблемы, но еще без больших внедрений. На мой взгляд, архитектурные решения вроде раздачи всего discovery в каждый узел были приняты исходя из того, что они просто работали. Да, они работали до определенного уровня и на этапе зарождения технологий это было не так важно. Внедрение на каких-то не очень больших проектах работало хорошо и позволяло быстро достичь результата.

Забегая вперед скажу, что в конце 2018 года в Istio решили внедрять механизм чёткого декларирования зависимостей. Этот подход мы использовали в своём control plane, разработанном уже после отказа от Istio. В Istio он появился примерно в 2019 году и как раз позволял чётко задекларировать, какому узлу какие данные нужны и решить таким образом проблемы с потреблением памяти, сети и вообще, в целом, оптимизировать всю эту систему. Но это было спустя несколько лет.

Отказавшись от Istio, вы стали разрабатывать своё решение. На какие характеристики делали упор в первую очередь?

У нас был достаточно длинный путь. После первого внедрения Istio мы преследовали те же задачи, повышение observability в первую очередь.

Чтобы просто иметь возможность получать с каждого узла нужные метрики, а с каждого микросервиса трейсинг-спаны, мы разработали альтернативный прокси. Заменили envoy proxy на собственную реализацию, которая потом стала называться Netramesh. Это технология тоже service mesh, она позволяла нам без control plane, без настраивающей части прокси-контейнера получать со всей системы нужную нам информацию о том, как взаимодействуют части системы. С этим решением мы жили достаточно долго, и до сих пор оно в продакшене.

Со временем возникла новая задача объединить несколько Kubernetes-кластеров в единый контур. Однажды получилось так, что у нас появилось несколько равноценных Kubernetes-кластеров, которые использовались в одном окружении. Нужно было управлять ими с помощью единой сети, и мы снова пришли к service mesh.

Только в этом случае нужно было в каждом узле знать всю систему, все Kubernetes-кластеры. Нам нужен был тот самый control plane выделенный компонент, который бы всем рассказывал, куда нужно ходить, какие у нас есть зоны, какие зоны отказа и так далее. Так мы пришли к созданию дополнительного решения, по своей архитектуре очень похожего на Istio.

Мы взяли envoy proxy, написали control plane под его протокол xDS и назвали это решение Navigator (здесь можно посмотреть базовое описание и исходный код).

Таким образом сейчас мы имеем в продакшене сразу два прокси-контейнера: Netramesh, который занимается задачами observability, и envoy proxy, который настраивается с помощью Navigator и управляет трафиком.

В результате мы получили возможность связать Kubernetes-кластера в единую систему и объединить в единую сеть. Сейчас мы используем большое количество envoy proxy и service mesh подход как раз с помощью Navigator. В том числе различные схемы балансировки трафика между сервисами, канареечные деплои, mTLS, стики-сессии (по кукам, по хедерам), настраиваем зоны приоритетов подачи трафика, везде используем outlier detection, connect retries.

Путь такой. Соответственно, каждое из этих решений закрывало определенную проблему. Сначала проблему observability закрыла Netra, сейчас Navigator управляет взаимодействием между инстансами микросервисов.

Когда возникла необходимость объединить кластеры, вы не рассматривали Istio снова?

Да, перед внедрением Navigator мы ещё раз пробовали внедрить Istio, проводили перфоманс-тесты, уже зная проблемы, но он всё еще был не готов.

Это было примерно полтора года назад, а спустя ещё полгода эта проблема в Istio была решена с помощью специальной sidecar-сущности, которая позволяет отрезать discovery.

Я общался в комьюнити Istio и знал, что решение будет, и что оно будет именно такое, но ждать мы не могли были проблемы и потребности, которые нужно было закрыть. Тогда мы подумали, что сможем за достаточно короткий срок разработать свой control plane, который будет решать конкретный набор задач (не всё, что есть в Istio, а лишь определенный пул).

Примерно так и вышло. Мы разработали первую версию Navigator буквально за месяц. Причем большую часть времени заняло написание инфраструктуры мощного мультикластерного e2e тестирования. Без них было нельзя, потому что это корневой инфраструктурный компонент.
В итоге мы получили стабильное решение, которое смогли ввести в продакшн значительно раньше, чем если бы продолжили дожидаться Istio и решений с его стороны.

А если предположить, что тогда Istio был бы готов. Вы бы стали его внедрять?

Мы бы запустили следующий перфоманс-тест, и если вы всё было хорошо, то смотрели бы на стабильность в плане логики работы. Если бы там не было больших проблем (скорее всего их бы не было, потому что мы их еще несколько лет назад полноценно ревьюили и репортили), то да, скорее всего мы бы пошли в сторону Istio.

Кроме оверхеда у Istio было ещё одно не очень приятное для нас качество большие возможности. С одной стороны, это круто, ты можешь делать очень много с помощью инструмента. С другой стороны, порог входа и удобство использования оставляло желать лучшего. Это огромное количество разной документации разного уровня качества. Входить и разбираться в проект, в котором есть большое количество возможностей, крайне сложно и вводить в такой инструмент нескольких инженеров достаточно затратно.

Сейчас разработчики Istio сворачивают управление его возможностями в небольшой set кастомных ресурсов, возможностей конфигурации. Делают, чтобы по дефолту все работало максимально в том виде, в каком нужно пользователям в продакшене.

Возможно, какие-то такие вещи могли бы нас еще остановить, но в целом это всё решаемое. Скорее всего, мы бы взяли Istio как основное решение.

Сейчас Istio всё ещё на позиции лидера, или есть какие-то более-менее равноценные аналоги?

Я бы сказал, что есть три продукта, которые точно стоит рассматривать.
Не стоит фокусироваться чисто на Istio. Стоит посмотреть, попробовать, как минимум изучить, какие есть возможности и архитектура работы трех решений. Первое Istio, второе Linkerd2, несмотря на то, что он без envoy proxy, посмотреть на его механику работы, попробовать в каких-то частях своей системы, я думаю, стоит. Так как у этого проекта как раз долгое время был упор на перфоманс, на более эффективную работу, и возможно, что в конкретном кейсе он подойдёт лучше, где нужно будет более эффективно сделать взаимодействие. Хотя на горизонте нескольких лет все-таки есть уверенность, что победят service mesh на базе envoy.

Третье решение, которое точно стоит посмотреть, это Consul Connect от HashiCorp. Это решение, по сути, альтернатива. Оно в текущих версиях ушло от своего прокси-контейнера тоже в сторону envoy proxy. И сейчас Consul Connect умеет настраивать envoy и умеет решать задачи мультиклауда если у нас несколько дата-центров, либо несколько публичных облаков, он позволяет объединять это в единую сеть. Если в стеке технологий в компании уже есть Consul или другие продукты от HashiCorp, то, возможно, это вообще очень хороший кандидат в том плане, что он позволяет объединять в единую сеть в том числе ворклоады и части системы, которые находятся, например, вне Kubernetes-кластеров, вне стандартных решений, на которые обычно ложатся service mesh.

Ну и с точки зрения стабильности HashiCorp имеет реальных клиентов, и они в них внедряют и отлаживают эту систему, поэтому она продакшн-реди, и ее можно рассматривать как хорошее решение для внедрения к себе.

Если смотреть на эти три проекта в целом, то всё ещё кажется, что выиграет Istio, но вполне возможно, что будет просто несколько альтернативных решений как сейчас. Consul Connect, на мой взгляд, сейчас достаточно популярен. Менее популярен, чем Istio, но есть определенный набор компаний, который его использует в продакшене и успешно.

Интересно, что ты не упомянул связку, которую вы используете.

Да, могу рассказать про нашу связку. Мы заопенсорсили наш продукт: и Netra, и Navigator можно найти на GitHub, их можно использовать. В принципе, это один из вариантов, который можно внедрить, и он действительно с точки зрения перфоманса и тех фич, которые реализованы, очень стабилен, проверен уже временем, там несколько лет активного использования в продакшене.

Но есть один момент. Наши решения решали проблемы именно Авито в первую очередь. Поэтому здесь можно посмотреть, насколько наши решения закрывают все потребности.

Сейчас мы не предоставляем наше решение как продукт с возможностями платной или бесплатной поддержки. Мы, конечно, отвечаем на вопросы тем, кто использует, например, Netra (она давно используется в нескольких компаниях и помимо Авито), но надо понимать, что это не бизнес в данный момент. Это просто open source решение.

Ты был основным разработчиком этого решения?

Одним из основных. Конкретно Netra занимался в основном я и в будущем было еще несколько человек, это уже точечные contribution по добавлению дополнительной функциональности. Всего в сумме поучаствовало где-то 5-6 человек. Navigator это уже более мощное решение, в его разработке изначально участвовало уже три инженера и в будущем подключались еще на различные проекты и фичи, которые были нужны, еще несколько человек. Это те, кто активно развивали продукт.

Текущие решения, которые используются в Авито, закрывают все задачи, которые были поставлены до этого?

Те проблемы, которые мы хотели решить этими инструментами, мы их решили, но, как и любой инструмент, любой продукт не может быть заморожен, у него все равно с течением времени появляются какие-то новые фича реквесты, новые хотелки, которые нужны. И мы продолжаем его активно дорабатывать. Внедряем какие-то новые фичи, например, из последних вещей, mTLS тот же самый и внедрение его по всей системе сейчас в активной фазе развития. То есть, такого рода вещи, которые мы изначально не ставили в цель решение с помощью этих инструментов, но сейчас такие задачи появились, и мы их закрываем этими решениями. Navigator растет, развивается. Изначальные задачи были решены, но есть и новые.

Предположим, компания решила внедрять service mesh. Какие компетенции необходимы команде?

Вообще технология service mesh лежит посередине между разработчиками и теми, кто занимается эксплуатацией. Какие необходимы знания? Надо точно понимать, как происходит взаимодействие тех узлов в системе, в которые мы хотим это внедрять. Какие протоколы используются, какая сетевая подсистема, Kubernetes, как сейчас происходит взаимодействие инстансов в нашей системе. Вообще представлять, как работает на текущий момент наша система.

Ключевым я бы назвал понимание именно сетевого стека работы всех систем, протоколов, TCP, прикладных протоколов, которыми общаются микросервисы в системе. И в целом понимание того, как архитектурно работают такие распределенные системы.

Чего-то особенного тут, в принципе, нет. Это система, которая использует достаточно стандартные подходы, стандартные технологии для своего внедрения, поэтому каких-то базовых знаний, в принципе, достаточно. Но важно понимать именно сетевую составляющую, как происходит взаимодействие узлов.

Ты сказал, что service mesh это нечто посередине между разработчиками и теми, кто занимается эксплуатацией. А какая роль разработки здесь? И вообще, внедрение service mesh влияет на работу разработчиков?

Это зависит от того, каким образом оно внедряется и потом поставляется. Я имел в виду, что, с одной стороны, инфраструктурный компонент, который достаточно низкоуровнево внедрятся во взаимодействие между узлами, на самом деле решает те задачи, которые обычно решают разработчики в своем коде, прямо в своих микросервисах. И это инструмент, который позволяет как бы перевести на уровень ниже это. Поэтому здесь и возникает такой момент, что, с одной стороны, внедряют это обычно ребята из платформы, те, кто занимается инфраструктурой, но, с другой стороны, в результате получаются фичи, которые нужны в первую очередь разработчикам микросервисов. Например, circuit breaker паттерн.

Это вещи, которые нужны разработчикам и поэтому разработчики обычно здесь вовлечены с той стороны, что они, во-первых, должны понимать, какого рода дополнительные фичи вносятся во взаимодействие. И во-вторых, в зависимости от того подхода, который выбирает компания, они могут либо их настраивать (то есть понимать, какие есть возможности и применять манифесты для настройки этого взаимодействия), либо с помощью каких-то более высокоуровневых абстракций, инструментов, также опосредованно использовать эту технологию. Например, говорить: я хочу, чтобы ко мне была другого вида балансировка трафика. И оно там под капотом в итоге улетает в service mesh и применятся. Поэтому это что-то посередине. Конечно, с точки зрения внедрения, это больше со стороны инфраструктуры, но интересует и разработчиков.

О чем ты будешь рассказывать на мартовском интенсиве по service mesh?

Когда мы приходим компанией к тому, что эта технология нам полезна, и мы хотим ее потрогать, посмотреть и внедрить в будущем в своей компании, здесь есть два поинта.

Первый состоит в том, что эта технология достаточно сложна в первоначальном входе, есть много различных компонентов, возможностей, настроек, и нужно разобраться вообще, как это все архитектурно устроено, за что каждый компонент отвечает. Понять, как работают все эти механизмы, чтобы подступиться к внедрению технологии или наоборот понять, что такой подход нам вообще неинтересен и неприменим в конкретном случае. Поэтому первый момент, который будет раскрываться, это именно сама механика работы. Что это за технология, как она позволяет закрывать эти проблемы, которые мы обсуждали.

Второй момент очень важен для компаний, особенно крупных, у которых есть фокус на то, что все системы должны работать стабильно, без даунтаймов и действительно нет возможностей для экспериментов на продакшене. На самом деле, большинство компаний такие. Крайне важно понимать, какими шагами можно прийти к тому, чтобы эту систему полноценно внедрить и внедрить без каких-то неожиданностей в продакшене. И здесь есть путь, который мы прошли, есть большое количество граблей, на которые мы наступили и сами словили в момент и внедрения, и эксплуатации этого решения.

Поэтому есть важные моменты, которые в каждой части курса мы будем рассматривать, как правильно подходить к внедрению разных частей service mesh. Расскажем в целом, как этот процесс вести таким образом, чтобы не ронять всю систему и понимать в будущем, в момент эксплуатации, что у нас вообще происходит.

Service mesh это технология, которая на самом низком уровне радикально меняет инфраструктуру. И если вдруг в момент эксплуатации что-то идёт не так, это обычно приводит к катастрофе полные даунтаймы системы, серьезные последствия. Поэтому очень важно понимать, как все устроено и как в эксплуатации быть уверенным в том, что все работает в штатном режиме и в случае проблем быстро это исправлять.

Основной упор всё-таки будет сделан на Istio?

С помощью Istio мы будем рассматривать именно подходы и брать его как основную реализацию. То есть, смотреть, как это все использовать, все основные фичи и так далее. Но envoy proxy это сейчас основное решение, вокруг которого базируется большинство service mesh, и мы не будем прямо сильно фокусироваться на каком-то интерфейсе Istio и, грубо говоря, изучать, какие ключи нужно ввести, чтобы получить определенную настройку.

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

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

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

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

Кому не стоит идти на этот курс?

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

А если говорить про уровень специалистов? Интенсив рассчитан на техлидов или специалистов, которые потенциально могли бы это внедрять?

С одной стороны, можно сказать, что это будет полезно тем, кто еще сомневается, не принял решение, и это могут быть техлиды и вообще человек, который активно не работал с Kubernetes он получит одного рода инсайты из этого курса. Но я проектировал интенсив направленный на то, чтобы человек после него имел полное представление о технической части, как возникающие проблемы решаются и в итоге качественно и с полным пониманием технологии мог её внедрять. Поэтому целевая аудитория практикующие инженеры эксплуатации, платформенные и инфраструктурные разработчики. Их и ожидаю увидеть!

Интервью подготовила Виктория Федосеенко Vika_Fedoseenko

Фото Brian McGowan, Unsplash.com

Мы использовали Istio в продакшене почти два года, но больше не хотим. Я расскажу, чем мы недовольны и как выбрали другую service mesh.

Начнем с начала.

Зачем вообще нужна service mesh?

• Она мониторит трафик между микросервисами, включая схему взаимодействия и коды статусов HTTP между ними.
• Она позволяет добавлять mTLS, то есть шифрованный HTTP-трафик между сервисами.

Получается, всего две функции. Зато какие полезные.

Многие service mesh предлагают дополнительные фичи, например, разделение трафика, повторные попытки и т. д. Как по мне, не самые нужные функции. Во всяком случае для sidecar-proxy. Их часто используют не по назначению, чтобы закрыть проблемы, которые требуют другого решения.

Сложно ли использовать service mesh?

Да. Вы набьете немало шишек, пока не поймете, что:

Service mesh пока стабильно работает только для HTTP-трафика

Я работал с Istio и Linkerd, и обе вроде как должны поддерживать много разных протоколов, но на деле не все так радужно. Поддержка некоторых протоколов баз данных в Istio очень нестабильна в зависимости от версии. Linkerd не справляется с AMQP. И обе выдают странные ошибки для HTTPS. Видимо, написать прозрачный сетевой прокси не так-то просто. Пока я доверил бы service mesh только HTTP. С другой стороны, мне и не нужны другие протоколы для взаимодействия между сервисами Kubernetes.

Сетевые вызовы контейнера приложения не работают, если не запущен sidecar-прокси

Очень неприятная проблема, из-за которой я и считаю, что service mesh подходят не для всех сценариев. Если контейнер приложения запустится до sidecar-прокси, он не сможет выполнять запросы, для которых настроен sidecar-прокси.

Были какие-то разговоры о нативных sidecar в Kubernetes (чтобы помечать контейнер в поде как sidecar, который должен запускаться первым делом). Ожидалось, что они появятся в версии 1.20, но в итоге предпочтение отдали фичам, которые охватывают максимальное количество вариантов использования.

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

Init-контейнеры и cronjob не могут использовать service mesh

Почему? Контейнер прокси в service mesh никогда не завершает работу, а значит контейнеры init и cronjob никогда не выполняются до конца. В первом случае контейнер приложения так и не запустится, а во втором время ожидания cronjob истечет и задание завершится ошибкой.

Для этого, вроде, тоже есть обходные пути, но я ни одного годного не встречал.

Использую ли я service mesh?

У меня получалось успешно использовать их в кластерах в продакшене и стейджинге в двух случаях: sidecar-прокси отслеживают только HTTP-трафик и mTLS настроен как необязательный (при этом условии под за пределами mesh может общаться с подом в mesh).

Я не использую service mesh в кластерах для ревью запускать ревью приложений в service mesh слишком хлопотно.

Почему я удалил Istio?

Главная причина его было очень сложно использовать. На изучение Istio у меня ушло примерно столько же времени, сколько на изучение Kubernetes.

Мне понадобилось несколько недель на конфигурацию Helm-чарта для деплоймента Istio (обычно я укладываюсь в один день).

Для Istio нужно слишком много CRD (Custom Resource Definition). Я стараюсь избегать их, чтобы не попадать в зависимость от вендора. У меня ушло много времени и сил, чтобы разобраться с CRD для основных ресурсов, вроде Gateway, VirtualService и DestinationRule, а в документацию приходилось заглядывать гораздо чаще, чем хотелось бы.

Если честно, я побаивался Istio. Это же огромная единая точка отказа. Самое ужасное у нас случилось, когда один из разработчиков неправильно назвал секрет Kubernetes с секретом TLS для шлюза. Все шлюзы сломались и потянули за собой весь кластер. Был такой баг, из-за которого Istio, не найдя нужный секрет, просто не настраивалась и переставала работать совсем. Мы чуть с ума не сошли, пока искали ошибку, в логах на нее вообще ничего не указывало. Это не единственный случай, когда Istio полностью отказывает. Обычно это связано с передачей конфигурации в прокси Envoy. В документации это называется Break Glass Configuration (аварийная конфигурация).

Наконец самое важное в Istio отказались от Helm в пользу собственной утилиты командной строки istioctl а потом снова вернули Helm. Я не хочу деплоить сорок с лишним инструментов поддержки на кластерах кучей разных методов, поэтому я расстроился, когда они прекратили поддержку Helm, который используется у меня в каждом втором инструменте. Еще больше я огорчился, когда все вернули назад и мне пришлось снова все восстанавливать, чтобы проапгрейдиться до последней версии Istio.

Почему я вообще выбрал Istio?

Когда Kubernetes только появился, у него было три главных конкурента Mesos, Nomad и Swarm, но все очень быстро поняли, что Kubernetes победит.

Никогда не слышал, чтобы кто-то использовал Mesos (нелегко им пришлось без поддержки крупной корпорации), но знаю, что они сильно повлияли на оркестрацию контейнеров.
Swarm использовали чаще, но только потому, что он проще, чем Kubernetes. Лично я не верил в успех этого проекта за простотой на самом деле скрывался недостаток функционала. В Kubernetes все тоже несложно, если им не сильно пользоваться.

Nomad пока никуда не делся и, в принципе, неплохо работает с оркестрацией процессов прямо на серверах. Если вам нужна только оркестрация контейнеров, очень рекомендую Kubernetes.
В общем, когда появилась Istio, все было примерно так же. У неё был только один конкурент Linkerd (который лично у меня почему-то ассоциировался со Swarm), при этом Istio тоже была детищем Google. Вот её я и выбрал.

А потом service mesh начали появляться, как грибы после дождя, сначала AppMesh от AWS, потом Maesh от Traefik, потом Azure Open Service Mesh (название, видимо, намекает на то, что Istio упорно не входит в CNCF) и service mesh от Nginx. И это еще не все. Обычно для создания service mesh вендоры (например, Kuma и Consul Connect) используют прокси Envoy.

Явного победителя я тут не вижу.

Что я использую сейчас?

Сравнив несколько service mesh, я остановился на оригинале Linkerd. Остальные варианты либо пытаются привязать меня к вендору, либо делают не то, что я хочу (например, Maesh добавляет прокси к ноде, а не к поду).

Что мне нравится в Linkerd:

• Она поддерживает деплои с Helm (правда, я использую модифицированную версию Helm и немного кастомного кода, чтобы избежать конфигурации вручную извне).
• С ней просто работать. Нужно только одно CRD, а Helm-чарт было легко освоить.
• У неё приятный дашборд. Istio использует Grafana/Promethus и Kiali. Linkerd тоже использует Grafana/Prometheus, а еще специальный кастомный дашборд, который легко использовать.
• Они написали собственный прокси на Rust (в версии 2). Сначала я засомневался, ведь Envoy так популярен, а потом понял, что так Linkerd стала только динамичнее. Envoy разросся до огромных размеров и пытается поддерживать очень много вендоров, а Linkerd вольны делать со своим прокси что захотят, и это серьезно ускоряет разработку. И все написано на Rust! Круто же?
• Они входят в CNCF. В отличие от Istio.
• Linkerd выбрали правильный подход. Istio сначала хватили лишнего с разными деплойментами, которыми нам приходилось управлять, а теперь перешли на единый деплоймент. Linkerd с этого начали. Другие деплойменты у них тоже есть, но не основные. Они добавляют новые фичи, но заботиться нужно только о главном деплойменте.

Что мне не нравится в Linkerd?

Всего одна мелочь, и та скорее про маркетинг они заявляют, что service mesh можно установить и настроить всего за пять минут. Но, как вы понимаете, service mesh вряд ли можно назвать почти готовым решением. У Linkerd те же проблемы, что и у остальных, например, отсутствие нативных sidecar или ненадежная обработка других протоколов, кроме HTTP.

Заключение

Может быть, однажды мы перестанем заморачиваться выбором service mesh как сейчас мало кто знает, какую оверлейную сеть он использует с Kubernetes. Каждая service mesh внедряет SMI (Service Mesh Interface), так что когда-нибудь, будем надеяться, service mesh станет просто нативным ресурсом в Kubernetes. Принятие открытых стандартов первый шаг в этом направлении.

Мне не нравится, что Istio нет в CNCF, и объяснения Криса Дибоны (Chris DiBona) в Kubernetes Podcast меня не переубедили.

Linkerd входит в CNCF, и если они не будут ничего усложнять, я планирую пока остаться с ними.

Жду с нетерпением, когда в Kubernetes появится нативное решение для sidecar.