Русский
Русский
English
Статистика
Реклама

Service mesh

Kubernetes Мега от устройства Kubernetes до основ service mesh

11.05.2021 10:09:42 | Автор: admin
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
Вопросы по интенсиву в комменты.
Подробнее..

5 самых популярных вопросов при внедрении service mesh в корпорации на примере Istio

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

image


Мое знакомство с 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, чтобы помочь убедиться в ее готовности к внедрению.

image

Вопрос 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-принтере, которую можно скачать здесь.
Подробнее..

Онлайн-интенсив Service mesh 1921 марта

01.02.2021 18:10:50 | Автор: admin


Для тех, кто работает на проектах с развитой или развивающейся микросервисной архитектурой, мы в Слёрме готовим трехдневный интенсив по service mesh, он пройдет с 19 по 21 марта.


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


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


Для практики будем использовать проект без service mesh в Kubernetes-кластере. Задача постепенно внедрить service mesh, отслеживая изменения.


Преподаватели


Спикер интенсива: Александр Лукьянченко, тимлид в команде архитектуры Авито. Читать интервью со спикером
Лидер практики: Иван Круглов, Staff Software Engineer в Databricks.


Программа


1: Service mesh подход, решаемые задачи.
2: Готовые реализации. Запуск на своем Kubernetes-кластере. Внешний трафик через gateway.
3: Troubleshooting проблем работы service mesh.
4: Умный роутинг, правила доступа. Стратегии deploy: canary, blue/green с помощью SM.
5: Мультикластерность и прозрачная балансировка трафика. Поддержка нескольких ДЦ. Подход к обновлению Kubernetes.
6: Аутентификация и mTLS между сервисами в mesh.
7: Chaos engineering и реализация через service mesh.
8: Observability. Какие возможности дает service mesh.
9: Унифицированный трекинг взаимодействия через метрики prometheus/statsd.
10: Распределенный tracing через proxy контейнеры.


Стоимость обучения: 70 000 руб. при оплате до 1 марта.


Подробнее об интенсиве

Подробнее..

Перевод Сценарии использования service mesh

30.07.2020 10:07:11 | Автор: admin


Прим. перев.: автор это статьи (Luc Perkins) developer advocate в организации CNCF, являющейся домом для таких Open Source-проектов, как Linkerd, SMI (Service Mesh Interface) и Kuma (кстати, вы тоже задумывались, почему в этом списке нет Istio?..). В очередной раз пытаясь принести в DevOps-сообщество лучшее понимание в модный хайп под названием service mesh, он приводит 16 характерных возможностей, которые предоставляют подобные решения.

Сегодня service mesh одна из самых горячих тем в области программной инженерии (и по праву!). Я считаю эту технологию невероятно перспективной и мечтаю стать свидетелем ее широкого распространения (конечно, когда это имеет смысл). Тем не менее, она до сих пор окружена ореолом таинственности для большинства людей. При этом даже те, кто хорошо знаком с ней, нередко затрудняются сформулировать ее плюсы и что именно она собой представляет (включая и вашего покорного слугу). В статье я попытаюсь исправить ситуацию, перечислив различные сценарии использования сервисных сеток*.

* Прим. перев.: здесь и далее в статье будет использоваться именно такой перевод (сервисная сетка) для всё ещё нового термина service mesh.

Но сперва хочу сделать несколько замечаний:

  • Я никогда не работал с сервисными сетками и не использовал их вне проектов, затеянных ради собственного образования. С другой стороны, именно я написал кучу документации для внутренней service mesh компании Twitter в 2015 году (тогда она еще даже не называлась сервисной сеткой) и участвовал в разработке сайта и документации для Linkerd, так что это что-нибудь значит.
  • Мой список примерный и неполный. Вполне возможны неизвестные мне сценарии использования, и со временем наверняка возникнут новые варианты, по мере развития технологии и роста ее популярности.
  • В то же время далеко не каждая существующая реализация service mesh поддерживает все перечисленные случаи использования. Поэтому мои выражения вроде service mesh может следует читать как отдельные, а возможно, и все популярные реализации service mesh могут.
  • Порядок примеров не имеет какого-либо значения.

Краткий список:

  • обнаружение сервисов;
  • шифрование;
  • аутентификация и авторизация;
  • балансировка нагрузки;
  • circuit breaking;
  • автомасштабирование;
  • канареечные развертывания;
  • сине-зеленые развертывания;
  • проверка здоровья;
  • load shedding;
  • зеркалирование трафика;
  • изоляция;
  • ограничение частоты запросов, повторные попытки и тайм-ауты;
  • телеметрия;
  • аудит;
  • визуализация.

1. Обнаружение сервисов


TL;DR: Подключайтесь к другим сервисам в сети с помощью простых имен.

Сервисы должны иметь возможность автоматически находить друг друга с помощью адекватных имен например, service.api.production, pets/staging или cassandra. Облачные среды отличаются своей эластичностью, и за одним именем может скрываться множество экземпляров сервиса. Понятно, что в такой ситуации физически невозможно захардкодить все IP-адреса.

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

Каждая service mesh реализует механизм обнаружения сервисов по-своему. На данный момент самым распространенным способом является делегирования внешним процессам вроде DNS Kubernetes. В прошлом в Twitter для этих целей мы использовали систему имен Finagle. Кроме того, технология service mesh делает возможным появление пользовательских механизмов именования (хотя я еще не встречал ни одной реализации SM с таким функционалом).

2. Шифрование


TL;DR: Избавьтесь от незашифрованного трафика между сервисами и пускай этот процесс будет автоматизированным и масштабируемым.

Приятно осознавать, что злоумышленники не могут проникнуть в вашу внутреннюю сеть. Сетевые экраны прекрасно справляются с этим. Но что произойдет, если хакер все же проникнет внутрь? Он сможет делать с внутрисервисным трафиком все, что пожелает? Давайте надеяться, что этого все же не произойдет. Для того, чтобы предотвратить подобный сценарий, следует реализовать сеть с нулевым доверием (zero-trust), в которой весь трафик между сервисами зашифрован. Большинство современных сервисных сеток добиваются этого с помощью взаимного TLS (mutual TLS, mTLS). В некоторых случаях mTLS работает в целых облаках и кластерах (думаю, и межпланетные коммуникации когда-нибудь будут устроены аналогично).

Конечно, для mTLS service mesh необязательна. Каждый сервис может сам позаботиться о своем TLS, но это означает, что нужно будет найти способ генерировать сертификаты, распределять их по хостам сервиса, включать в приложение код, который будет загружать эти сертификаты из файлов. Да, еще не забудьте об обновлении этих сертификатов через определенные промежутки времени. Сервисные сетки автоматизируют mTLS с помощью систем вроде SPIFFE, которые, в свою очередь, автоматизируют процесс выпуска и ротации сертификатов.

3. Аутентификация и авторизация


TL;DR: Устанавливайте, кто является инициатором запроса, и определяйте, что им разрешено делать еще до того, как запрос достигнет сервиса.

Сервисы часто хотят знать, кто выполняет запрос (аутентификация), и, используя эту информацию, решают, что данному субъекту разрешено делать (авторизация). В данном случае за местоимением кто могут скрываться:

  1. Другие сервисы. Это называется аутентификацией peer'а. Например, сервис web хочет получить доступ к сервису db. Сервисные сетки обычно решают подобные проблемы с помощью mTLS: сертификаты в данном случае выступают в роли необходимого идентификатора.
  2. Некие пользователи-люди. Это называется аутентификацией запроса. Например, пользователь haxor69 хочет приобрести новую лампу. Сервисные сетки предоставляют различные механизмы, например, JSON Web Tokens.

    Многим из нас доводилось делать это в коде приложения. Приходит запрос, мы просматриваем таблицу users, находим пользователя и сравниваем пароль, затем проверяем столбец permissions и т.д. В случае service mesh это происходит еще до того, как запрос достигнет сервиса.

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

4. Балансировка нагрузки


TL;DR: Распределяйте нагрузку по экземплярам сервиса по определенному шаблону.

Сервис в составе сервисной секти очень часто состоит из множества идентичных экземпляров. Например, сегодня сервис cache состоит из 5 копий, а завтра их число может возрасти до 11. Запросы, направляющиеся в cache, должны распределяться в соответствии с определенной целью. Например, минимизировать задержку или максимизировать вероятность попасть на работоспособный экземпляр. Чаще всего используется алгоритм кругового обслуживания (Round-robin), но существует и множество других например, метод взвешенных (weighted) запросов (можно выбрать предпочтительные цели), кольцевое (ring) хеширование (использование согласованного хеширования для upstream-хостов) или метод наименьшего числа запросов (предпочтение отдается экземпляру с наименьшим числом запросов).

Классические балансировщики имеют и другие функции, такие как кэширование HTTP и защита от DDoS, но они не очень актуальны для трафика типа east-west (т.е. для трафика, текущего в пределах датацентра прим. перев.)(типичная область применения service mesh). Конечно, не обязательно использовать service mesh для балансировки нагрузки, однако она позволяет задавать и контролировать политики балансировки для каждого сервиса из централизованного управляющего слоя, тем самым устраняя необходимость запускать и настраивать отдельные балансировщики в сетевом стеке.

5. Разрыв цепи (circuit breaking)


TL;DR: Останавливайте трафик к проблемному сервису и контролируйте ущерб при наихудших сценариях.

Если по какой-либо причине сервис не справляется с трафиком, service mesh предоставляет несколько вариантов решения этой проблемы (о других будет рассказано в соответствующих разделах). Circuit breaking это самый жесткий вариант отключения сервиса от трафика. Однако сам по себе он не имеет смысла необходим запасной план. Может предусматриваться противодавление (backpressure) на сервисы, выполняющие запросы (только не забудьте настроить свою service mesh для этого!), или, например, окрашивание статус-страницы в красный цвет и перенаправление пользователей на очередной вариант страницы с падающим китом (Twitter is down).

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

Вы вряд ли захотите злоупотреблять circuit breaking'ом, но приятно осознавать, что есть резервный план на крайний случай.

6. Автомасштабирование


TL;DR: Увеличивайте или уменьшайте число экземпляров сервиса в зависимости от заданных критериев.

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

Например, Kubernetes масштабирует сервисы в зависимости от использования pod'ами CPU и памяти (см. наш доклад Автомасштабирование и управление ресурсами в Kubernetes прим. перев.), но если вы решите проводить масштабирование на основе любого другого показателя (в нашем случае связанного с трафиком), понадобится специальная метрика. Руководство вроде такого показывает, как сделать это с помощью Envoy, Istio и Prometheus, но сам процесс довольно сложен. Мы бы хотелось, чтобы service mesh его упростила, позволив просто задавать условия вроде увеличь количество экземпляров сервиса auth, если число запросов, ожидающих выполнения, будет превышать пороговое значение в течение минуты.

7. Канареечные развертывания


TL;DR: Испытывайте новые функции или версии сервиса на подмножестве пользователей.

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

Service mesh'и реализуют это, позволяя указать критерии, определяющие, кто и какую версию приложения увидит, и соответствующим образом маршрутизируя трафик. При этом для самих сервисов ничего не меняется. Версия 1.0 сервиса считает, что все запросы поступают от пользователей, которые именно ее и должны увидеть, а версия 1.1 то же самое полагает в отношении своих пользователей. А вы, тем временем, можете менять процент трафика между старой и новой версией, перенаправляя растущее число пользователей на новую, если она работает стабильно и ваши подопытные дают добро.

8. Сине-зеленые развертывания


TL;DR: Выкатывайте новую крутую функцию, но будьте готовы немедленно вернуть все назад.

Смысл сине-зеленых развертываний в том, чтобы выкатить новый синий сервис, запустив его параллельно со старым, зеленым. Если все пойдет гладко и новый сервис хорошо себя зарекомендует, то старый можно будет постепенно отключить. (Увы, когда-нибудь и этот новый синий сервис повторит судьбу зеленого и исчезнет) Сине-зеленые развертывания отличаются от канареечных тем, что новая функция охватывает сразу всех пользователей (а не часть); смысл здесь в том, чтобы иметь наготове запасную гавань, если вдруг что-то пойдет не так.

Service mesh'и предлагают очень удобный способ тестирования синего сервиса и мгновенного переключения на рабочий зеленый в случае неполадок. Не говоря уже о том, что попутно они дают массу информации (см. пункт Телеметрия ниже) о работе синего, которая помогает понять, готов ли тот к полноценной эксплуатации.

Прим. перев.: Подробнее о разных стратегиях развертывания в Kubernetes (включая упомянутые canary, blue/green и другие) можно почитать в этой статье.

9. Проверка здоровья


TL;DR: Следите за тем, какие экземпляры сервисов работоспособны, и реагируйте на те из них, которые таковыми быть перестают.

Проверка здоровья (health check) помогает принять решение о том, готовы ли экземпляры сервиса принимать и обрабатывать трафик. Например, в случае HTTP-сервисов проверка здоровья может выглядеть как GET-запрос на endpoint /health. Ответ 200 OK будет означать, что экземпляр здоров, любой другой что он не готов принимать трафик. Service mesh'и позволяют указывать как способ, каким будет проверяться работоспособность, так и частоту, с которой эта проверка будет проводиться. Эту информацию можно затем использовать для других целей например, для балансировки нагрузки и circuit breaking'а.

Таким образом, проверка здоровья выступает не самостоятельным сценарием использования, а обычно используется для достижения других целей. Также, в зависимости от результатов health check'ов, могут потребоваться внешние (по отношению к другим целям сервисных сеток) действия: например, обновлять страницу состояния, создавать issue на GitHub или заполнять тикет JIRA. И service mesh предлагает удобный механизм для автоматизации всего этого.

10. Перебрасывание нагрузки (load shedding)


TL;DR: Перенаправляйте трафик в ответ на временный всплеск в использовании.

Если некий сервис оказывается перегружен трафиком, вы можете временно перенаправить часть этого трафика в другое место (то есть сбросить, перелить (shed) его туда). Например, в резервный сервис или дата-центр, или в постоянный Pulsar topic. В результате, сервис продолжит обрабатывать часть запросов вместо того, чтобы упасть и перестать обрабатывать вообще все. Сбрасывание нагрузки предпочтительнее, чем разрыв цепи, но все равно нежелательно злоупотреблять им. Оно позволяет предотвратить каскадные сбои, в результате которых падают downstream-сервисы.

11. Распараллеливание/зеркалирование трафика


TL;DR: Отправляйте один запрос сразу в несколько мест.

Иногда возникает необходимость отправить запрос (или некоторую выборку запросов) сразу в несколько сервисов. Характерный пример отправка части production-трафика в staging-сервис. Основной веб-сервер production'а отправляет запрос к нижестоящему сервису products.production и только к нему. А service mesh интеллектуально копирует этот запрос и отправляет его на products.staging, о чем веб-сервер даже не подозревает.

Еще один связанный сценарий использования сервисной сетки, который можно реализовать поверх распараллеливания трафика, это регрессионное тестирование. Оно предусматривает отправку одних и тех же запросов различным версиям сервиса и проверку того, ведут ли все версии себя одинаково. Мне пока не встречалась реализация service mesh с интегрированной системой регрессионного тестирования вроде Diffy, но сама идея кажется перспективной.

12. Изоляция


TL;DR: Разбивайте свою service mesh на мини-сети.

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

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

13. Ограничение частоты запросов, повторные попытки и тайм-ауты


TL;DR: Больше не надо включать в кодовую базу насущные задачи по управлению запросами.

Все эти вещи можно было бы рассматривать как отдельные случаи использования, но я решил объединить их из-за одной общей особенности: они перенимают на себя задачи по управлению жизненным циклом запросов, обычно отрабатываемые библиотеками приложений. Если вы разрабатываете веб-сервер на Ruby on Rails (не интегрированный с service mesh), который выполняет запросы к backend-сервисам через gRPC, приложение должно будет само решать, что делать, если N запросов завершатся неудачей. Также придется выяснять, какой объем трафика способны будут обработать эти сервисы и за'hardcode'ить эти параметры с помощью специальной библиотеки. Плюс ко всему, приложение должно будет решать, когда пора сдаться и позволить запросу протухнуть (по timeout). И для того, чтобы изменить любой из вышеперечисленных параметров, веб-сервер придется остановить, переконфигурировать и запустить заново.

Передача этих задач сервисной сетке означает не только то, что разработчикам сервисов не нужно будет думать о них, но и то, что их можно будет рассматривать более глобальным образом. Если используется сложная цепочка сервисов, скажем, A > B > C > D > E, необходимо учитывать весь жизненный цикл запроса. Если стоит задача продлить тайм-ауты в сервисе С, логично делать это все разом, а не по частям: обновив код сервиса и дожидаясь, пока pull request будет принят и CI-система развернет обновленный сервис.

14. Телеметрия


TL;DR: Собирайте всю нужную (и не совсем) информацию от сервисов.

Телеметрия это общий термин, включающий в себя метрики, распределенную трассировку и логи. Сервисные сетки предлагают механизмы для сбора и обработки всех трех типов данных. Здесь все становится немного расплывчатым, поскольку число возможных вариантов слишком велико. Для сбора метрик есть Prometheus и другие инструменты, для сбора логов можно использовать fluentd, Loki, Vector и др. (например, ClickHouse с нашим loghouse для K8s прим. перев.), для распределенной трассировки есть Jaeger и т.п. Каждая service mesh может поддерживать одни инструменты и не поддерживать другие. Любопытно будет посмотреть, сможет ли проект Open Telemetry обеспечить некоторую конвергенцию.

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

  • tail'ить логи от некоего сервиса в CLI;
  • отслеживать объем запросов с панели мониторинга service mesh;
  • собирать распределенные трассировки и перенаправлять их в систему вроде Jaeger.

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

15. Аудит


TL;DR: Тот, кто забывает уроки истории, обречен их повторять.

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

Понятно, что аудит очень тесно связан с телеметрией. Разница же состоит в том, что телеметрия обычно ассоциируется с такими вещами, как производительность и техническая стройность, в то время как аудит может иметь отношение к юридическим и другим вопросам, выходящим за рамки строго технической сферы (например, соответствие требованиям GDPR Общего регламента ЕС по защите данных).

16. Визуализация


TL;DR: Да здравствует React.js неистощимый источник причудливых интерфейсов.

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

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

Не были включены в список


Изначально я намеревался включить в список еще несколько сценариев использования, но потом решил не делать этого. Вот они вместе с причинами моего решения:

  • Мульти-датацентр. В моем представлении это не столько сценарий использования, сколько узкая и конкретная область применения сервисных сеток или некоторого набора функций вроде обнаружения сервисов.
  • Ingress и egress. Это связанная область, но я ограничил себя (возможно, искусственно) сценарием использования трафик east-west. Ingress и egress заслуживают отдельной статьи.

Заключение


На этом пока все! Опять же, этот список весьма условен и, скорее всего, неполон. Если вам кажется, что я что-то упустил, или в чем-то ошибся, обращайтесь ко мне в Twitter (@lucperkins). Пожалуйста, соблюдайте правила приличия.

P.S. от переводчика


В качестве основы для заглавной иллюстрации к статье взято изображение из статьи What is a Service Mesh (and when to use one)? (автор Gregory MacKinnon). На нем показано, как часть функциональности из приложений (зеленым цветом) перешла к service mesh, обеспечивающей взаимосвязи между ними (голубой цвет).

Читайте также в нашем блоге:

Подробнее..

Перевод Доступен NGINX Service Mesh

16.10.2020 12:13:24 | Автор: admin


Мы рады представить предварительную версию NGINX Service Mesh (NSM), связанную легковесную service mesh, использующую data plane на основе NGINX Plus для управления трафиком контейнеров в окружениях Kubernetes.


NSM можно бесплатно скачать здесь. Мы надеемся, что вы попробуете его использовать для dev и test окружений и ждем ваших отзывов на GitHub.


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


NSM решает эти проблемы, предоставляя вам в первую очередь:


  • Безопасность, которая сейчас важнее чем когда-либо. Утечка данных может стоить компании миллионы долларов ежегодно в виде потерь доходов и репутации. NSM обеспечивает шифрование всех соединений с помощью mTLS так что чувствительных данных, которые могут украсть взломщики по сети, просто нет. Контроль доступа позволяет вам задать политики, как сервисы будут общаться с другими сервисами.
  • Управление трафиком. При поставке новой версии приложения вы возможно захотите для начала ограничить ему входящий трафик на случай ошибки. С помощью интеллектуального управления трафиком контейнеров от NSM вы можете задать политику ограничения трафика новым сервисам, которая будет наращивать трафик с течением времени. Другие функции, например ограничение скорости и circuit breakers, дают вам полный доступ к управлению прохождения трафика всем вашим сервисам.
  • Визуализация. Управление тысячами сервисов может быть кошмаром отладки и визуализации. NSM помогает справиться с такой ситуацией с помощью встроенной панели управления Grafana, на которой отображаются все характеристики, доступные в NGINX Plus. А также внедренная Open Tracing позволяет детально следить за транзакциями.
  • Гибридные поставки, если ваша компания, как и большинство других, не использует инфраструктуру, полностью запущенную на Kubernetes. NSM гарантирует, что старые приложения не останутся без присмотра. С помощью внедренного NGINX Kubernetes Ingress Controller старые сервисы смогут связаться с mesh сервисами, и наоборот.

NSM также обеспечивает безопасность приложений в окружениях с нулевым доверием, прозрачно применяя шифрование и аутентификацию трафика контейнеров. Также он дает возможность наблюдения и анализа транзакций, помогая быстро и точно запускать развертывания и устранять проблемы. Кроме того, обеспечивается детальный контроль трафика, позволяя командам DevOps разворачивать и оптимизировать части приложений, одновременно давая возможность разработчикам создавать и легко соединять их распределенные приложения.


Как устроен NGINX Service Mesh?


NSM состоит из объединенного data plane для горизонтального (сервис-к-сервису) трафика и внедренного NGINX Plus Ingress Controller для вертикального, управляемые единым control plane.


Control plane специально разработана и оптимизирована для NGINX Plus data plane, определяет правила управления трафиком, распределенные по NGINX Plus sidecars.


В NSM sidecars proxy устанавливаются для каждого сервиса в mesh. Они взаимодействуют с следующими решениями с открытым исходным кодом:


  • Grafana, визуализация параметров Prometheus, встроенная панель NSM помогает вам при работе;
  • Kubernetes Ingress Controllers, для управления входящим и исходящим трафиком в mesh;
  • SPIRE, CA для управления, распределения и обновления сертификатов в mesh;
  • NATS, масштабируемая система отправки сообщений, например обновления маршрутов, с control plane к sidecars;
  • Open Tracing, распределенная отладка (поддерживаются Zipkin и Jaeger);
  • Prometheus, сбор и хранение характеристик от NGINX Plus sidecars, например число запросов, соединений и SSL handshakes.

Функции и компоненты


NGINX Plus в качестве data plane охватывает sidecar proxy (горизонтальный трафик) и Ingress controller (вертикальный), перехватывая и управляя трафиком контейнеров между сервисами.


Функции включают:


  • Взаимную аутентификацию TLS (mTLS);
  • Балансировку нагрузки;
  • Отказоустойчивость;
  • Ограничение скорости;
  • Circuit breaking;
  • Сине-зеленые и канареечные развертывания;
  • Контроль доступа.

Запуск NGINX Service Mesh


Для запуска NSM нужно:


  • доступ к окружению Kubernetes. NGINX Service Mesh поддерживается на многих платформах Kubernetes, включая Amazon Elastic Container Service for Kubernetes (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), VMware vSphere и обычные кластера Kubernetes, развернутые на "железных" серверах;
  • Инструмент kubectl, установленный на машине, откуда будет устанавливаться NSM;
  • Доступ к пакетам выпусков NGINX Service Mesh. В пакете есть образы NSM, нужные для выгрузки в закрытую registry для контейнеров, доступную в кластере Kubernetes. Пакет также содержит nginx-meshctl, нужную для разворачивания NSM.

Для того, чтобы развернуть NSM с настройками по умолчанию, запустите следующую команду. Во время развертывания выводятся сообщения об успешной установке компонентов и, наконец, сообщение о том, что NSM работает в отдельном пространстве имен:


$ DOCKER_REGISTRY=your-Docker-registry ; MESH_VER=0.6.0 ; \ ./nginx-meshctl deploy  \  --nginx-mesh-api-image "${DOCKER_REGISTRY}/nginx-mesh-api:${MESH_VER}" \  --nginx-mesh-sidecar-image "${DOCKER_REGISTRY}/nginx-mesh-sidecar:${MESH_VER}" \  --nginx-mesh-init-image "${DOCKER_REGISTRY}/nginx-mesh-init:${MESH_VER}" \  --nginx-mesh-metrics-image "${DOCKER_REGISTRY}/nginx-mesh-metrics:${MESH_VER}"Created namespace "nginx-mesh".Created SpiffeID CRD.Waiting for Spire pods to be running...done.Deployed Spire.Deployed NATS server.Created traffic policy CRDs.Deployed Mesh API.Deployed Metrics API Server.Deployed Prometheus Server nginx-mesh/prometheus-server.Deployed Grafana nginx-mesh/grafana.Deployed tracing server nginx-mesh/zipkin.All resources created. Testing the connection to the Service Mesh API Server...Connected to the NGINX Service Mesh API successfully.NGINX Service Mesh is running.

Для получения дополнительных параметров, включая расширенные настройки, запустите эту команду:


$ nginx-meshctl deploy h

Проверить, что control plane работает корректно в пространстве имен nginx-mesh, можно так:


$ kubectl get pods n nginx-meshNAME                                 READY   STATUS    RESTARTS   AGEgrafana-6cc6958cd9-dccj6             1/1     Running   0          2d19hmesh-api-6b95576c46-8npkb            1/1     Running   0          2d19hnats-server-6d5c57f894-225qn         1/1     Running   0          2d19hprometheus-server-65c95b788b-zkt95   1/1     Running   0          2d19hsmi-metrics-5986dfb8d5-q6gfj         1/1     Running   0          2d19hspire-agent-5cf87                    1/1     Running   0          2d19hspire-agent-rr2tt                    1/1     Running   0          2d19hspire-agent-vwjbv                    1/1     Running   0          2d19hspire-server-0                       2/2     Running   0          2d19hzipkin-6f7cbf5467-ns6wc              1/1     Running   0          2d19h

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


Например если мы развернем приложение sleep в пространстве имен default, а затем проверим Pod увидим два запущенных контейнера, приложение sleep и связанный с ним sidecar:


$ kubectl apply f sleep.yaml$ kubectl get pods n defaultNAME                     READY   STATUS    RESTARTS   AGEsleep-674f75ff4d-gxjf2   2/2     Running   0          5h23m

Также мы можем следить за приложением sleep в панели NGINX Plus, запуская эту команду для получения доступа к sidecar с вашей локальной машины:


$ kubectl port-forward sleep-674f75ff4d-gxjf2 8080:8886

Затем просто заходим сюда в браузере. Вы также можете соединиться с Prometheus чтобы следить за приложением sleep.


Вы можете использовать отдельные ресурсы Kubernetes для настройки политик трафика, например контроля доступа, ограничения скорости и circuit breaking, для этого смотрите документацию


Заключение


NGINX Service Mesh бесплатно доступна для загрузки на портале F5. Попробуйте ее в работе на ваших dev и test окружениях и напишите нам о результатах.


Чтобы попробовать NGINX Plus Ingress Controller, активируйте бесплатный испытательный период на 30 дней, или свяжитесь с нами для обсуждения ваших вариантов использования.


Перевод в авторстве Павла Демковича, инженера компании Southbridge. Системное администрирование за 15 000 в месяц. И как отдельное подразделение обучающий центр Слёрм, практика и ничего, кроме практики.

Подробнее..

Опыт внедрения service mesh в Авито

29.01.2021 08:04:08 | Автор: admin


Что такое 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

Подробнее..

Перевод Service Mesh Wars, прощаемся с Istio

24.05.2021 12:21:25 | Автор: admin

image
Фото 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.

Подробнее..

Новый HAProxy Data Plane API два примера программной конфигурации

02.07.2020 10:04:35 | Автор: admin

Новый HAProxy Data Plane API: два примера программной конфигурации


Используйте HAProxy Data Plane API для динамического управления конфигурацией балансировщика нагрузки с помощью HTTP-команд.


Проектирование для высокой доступности почти всегда означает наличие высокого уровня прокси / балансировщика нагрузки. Прокси-сервер предоставляет основные услуги, такие как:


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

Задача состоит в том, чтобы поддерживать ваши конфигурации в актуальном состоянии, что особенно сложно, поскольку сервисы перемещаются в контейнеры, и эти контейнеры становятся эфемерными. Доступный начиная с HAProxy 2.0 вы можете использовать новый HAProxy Data Plane API (Перевод: http://personeltest.ru/aways/habr.com/ru/post/508132/), который является современным REST API.


HAProxy Data Plane API дополняет гибкий язык конфигурации HAProxy, который предоставляет строительные блоки для определения простых и сложных правил маршрутизации. Это также идеальное дополнение к существующему Runtime API, которое позволяет запускать, останавливать и пропускать трафик с серверов, изменять вес сервера и управлять проверками работоспособности.


Новый Data Plane API дает вам возможность динамически добавлять и настраивать внешние интерфейсы, внутренние интерфейсы и логику маршрутизации трафика. Вы также можете использовать его для обновления конечных точек ведения журнала и создания фильтров SPOE. По сути, почти весь балансировщик нагрузки может быть настроен с помощью HTTP-команд. В этой статье вы узнаете, как лучше его использовать.


Управление конфигурацией


Обычно при настройке HAProxy вам нужно вручную отредактировать файл конфигурации /etc/haproxy/haproxy.cfg. Этот файл используется для управления всеми функциями балансировщика нагрузки. Он в основном разделен на frontend разделы, определяющие общедоступные IP-адреса, к которым подключаются клиенты, и backend разделы, содержащие вышестоящие сервера, на которые направляется трафик. Но вы можете сделать гораздо больше, в том числе установить глобальные параметры, влияющие на работающий процесс, установить значения по умолчанию, добавить анализ поведения трафика с помощью таблиц флеш-памяти, прочитать файлы карт, определить правила фильтрации с помощью ACL и многое другое.


Хотя редактировать файл вручную довольно просто, это не всегда целесообразно, особенно при работе с десятками или даже сотнями сервисов и прокси. Это позволяет всему трафику проходить от прокси к прокси, по существу абстрагируя сеть и ее непостоянство от смежных сервисов приложений. Прокси на этом уровне могут добавить к вашим услугам логику повторных попыток, авторизацию и шифрование TLS. Тем не менее, количество прокси будет быстро расти, так как для каждой услуги есть свой прокси.


В этом случае крайне важно иметь возможность вызвать HTTP API для динамического обновления определений прокси. В сервисной сетке программное обеспечение Data Plane контролирует прокси и динамически вызывает API конфигурации. HAProxy Data Plane API позволяет интегрировать HAProxy с этими платформами. Более того, API использует API времени выполнения для внесения изменений, которые по возможности не требуют перезагрузки.


Data Plane API использует Go пакеты config-parser и client-native для парсинга конфигурации HAProxy и вызова команд Runtime API соответственно. Вы можете использовать их в своих собственных проектах для интеграции с HAProxy.


Динамическое конфигурирование HAProxy


С помощью Data Plane API вы можете многое сделать. В этом разделе вы узнаете, как создать backend с серверами и frontend, который направляет трафик на него. Но сначала следуйте официальной документации по установке и настройке API.


После того как он будет установлен и запущен, вызовите GET в конечной точке /v1/services/haproxy/configuration/backends, чтобы увидеть уже определенные разделы backend, например:


$ curl --get --user admin:mypassword \    http://localhost:5555/v1/services/haproxy/configuration/backends

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


Вызовите endpoint /v1/services/haproxy/transactions для создания новой транзакции. Для этого потребуется параметр версии в URL, но командам внутри транзакции он не нужен. Всякий раз, когда вызывается команда POST, PUT или DELETE, должна быть включена версия, которая затем записывается в файл конфигурации HAProxy. Это гарантирует, что если несколько клиентов будут использовать API, они избежать конфликтов. Если версия, которую вы передаете, не соответствует версии, указанной в файле конфигурации, вы получите сообщение об ошибке. При использовании транзакции эта версия указывается заранее при ее создании.


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       http://localhost:5555/v1/services/haproxy/transactions?version=1

Вы найдете идентификатор транзакции в возвращенном документе JSON:


{"_version":5,"id":"9663c384-5052-4776-a968-abcef032aeef","status":"in_progress"}

Затем используйте endpoint /v1/services/haproxy/configuration/backends, чтобы создать новый бэкэнд, отправив идентификатор транзакции в качестве параметра URL:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "test_backend", "mode":"http", "balance": {"algorithm":"roundrobin"}, "httpchk": {"method": "HEAD", "uri": "/", "version": "HTTP/1.1"}}' \            http://localhost:5555/v1/services/haproxy/configuration/backends?transaction_id=9663c384-5052-4776-a968-abcef032aeef

Затем вызовите endpoint /v1/services/haproxy/configuration/servers для добавления серверов в backend:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "server1", "address": "127.0.0.1", "port": 8080, "check": "enabled", "maxconn": 30, "weight": 100}' \       "http://localhost:5555/v1/services/haproxy/configuration/servers?backend=test_backend&transaction_id=9663c384-5052-4776-a968-abcef032aeef"

Затем добавьте frontend с помощью endpoint /v1/services/haproxy/configuration/frontends :


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "test_frontend", "mode": "http", "default_backend": "test_backend", "maxconn": 2000}' \       http://localhost:5555/v1/services/haproxy/configuration/frontends?transaction_id=9663c384-5052-4776-a968-abcef032aeef

У этого frontend еще нет никаких bind операторов. Добавьте одно, используя endpoint /v1/services/haproxy/configuration/binds, как на примере:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "http", "address": "*", "port": 80}' \       "http://localhost:5555/v1/services/haproxy/configuration/binds?frontend=test_frontend&transaction_id=9663c384-5052-4776-a968-abcef032aeef"

Затем, чтобы зафиксировать транзакцию и применить все изменения, вызовите endpoint /v1/services/haproxy/transactions/[transaction ID] с помощью PUT, например:


$ curl -X PUT --user admin:mypassword \       -H "Content-Type: application/json" \       http://localhost:5555/v1/services/haproxy/transactions/9663c384-5052-4776-a968-abcef032aeef

Вот как выглядит конфигурация сейчас:


frontend test_frontend    mode http    maxconn 2000    bind *:80 name http    default_backend test_backendbackend test_backend    mode http    balance roundrobin    option httpchk HEAD / HTTP/1.1    server server1 127.0.0.1:8080 check maxconn 30 weight 100

Этот балансировщик нагрузки готов принимать трафик и перенаправлять его на вышестоящий сервер.


Поскольку в спецификации Data Plane API используется OpenAPI, его можно использовать для генерации клиентского кода на многих поддерживаемых языках программирования.


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


Другой пример


Вы увидели простоту и мощь HAProxy Data Plane API. С помощью нескольких HTTP-команд вы можете динамически изменять конфигурацию. Давайте рассмотрим другой пример. Мы создадим ACL, который будет проверять имеет ли заголовок Host значение example.com. Если это так, то строка use_backend будет направлена на другой сервер с именем example_servers. Мы также добавим правило http-request deny, которое будет отклонять любые запросы для пути URL /admin.php, если исходный IP-адрес клиента не находится в сети 192.168.50.20/24.


Сначала используйте endpoint /v1/services/haproxy/transactions для создания новой транзакции и получения ее идентификатора:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \        http://localhost:5555/v1/services/haproxy/transactions?version=2{"_version":2,"id":"7d0d6737-655e-4489-92eb-6d29cdd69827","status":"in_progress"}

Затем используйте endpoint /v1/services/haproxy/configuration/backends вместе с идентификатором транзакции, чтобы создать новый backend с именем example_servers:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "example_servers", "mode":"http", "balance": {"algorithm":"roundrobin"}}' \       http://localhost:5555/v1/services/haproxy/configuration/backends?transaction_id=7d0d6737-655e-4489-92eb-6d29cdd69827

Используйте endpoint /v1/services/haproxy/configuration/servers для добавления server в backend:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"name": "server1", "address": "127.0.0.1", "port": 8081, "check": "enabled", "maxconn": 30, "weight": 100}' \       "http://localhost:5555/v1/services/haproxy/configuration/servers?backend=example_servers&transaction_id=7d0d6737-655e-4489-92eb-6d29cdd69827"

Используйте endpoint /v1/services/haproxy/configuration/acls, чтобы определить ACL с именем is_example, который проверяет, имеет ли заголовок узла значение example.com:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"id": 0, "acl_name": "is_example", "criterion": "req.hdr(Host)", "value": "example.com"}' \       "http://localhost:5555/v1/services/haproxy/configuration/acls?parent_type=frontend&parent_name=test_frontend&transaction_id=7d0d6737-655e-4489-92eb-6d29cdd69827"

Используйте /v1/services/haproxy/configuration/backend_switching_rules, чтобы добавить строку use_backend, которая оценивает ACL is_example:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"id": 0, "cond": "if", "cond_test": "is_example", "name": "example_servers"}' \       "http://localhost:5555/v1/services/haproxy/configuration/backend_switching_rules?frontend=test_frontend&transaction_id=7d0d6737-655e-4489-92eb-6d29cdd69827"

Используйте endpoint /v1/services/haproxy/configuration/http_request_rules, чтобы добавить правило http-request deny, которое проверяет, является ли путь /admin.php, а исходный IP-адрес клиента не находится в сети 192.168.50.20/24:


$ curl -X POST --user admin:mypassword \       -H "Content-Type: application/json" \       -d '{"id": 0, "cond": "if", "cond_test": "{ path /admin.php } !{ src 192.168.50.20/24 }", "type": "deny"}' \       "http://localhost:5555/v1/services/haproxy/configuration/http_request_rules?parent_type=frontend&parent_name=test_frontend&transaction_id=7d0d6737-655e-4489-92eb-6d29cdd69827"

Затем подтвердите транзакцию, чтобы изменения вступили в силу:


$ curl -X PUT --user admin:mypassword \       -H "Content-Type: application/json" \       http://localhost:5555/v1/services/haproxy/transactions/7d0d6737-655e-4489-92eb-6d29cdd69827

Ваша конфигурация HAProxy теперь выглядит вот так:


frontend test_frontend    mode http    maxconn 2000    bind *:80 name http    acl is_example req.hdr(Host) example.com    http-request deny deny_status 0 if { path /admin.php } !{ src 192.168.50.20/24 }    use_backend example_servers if is_example    default_backend test_backendbackend example_servers    mode http    balance roundrobin    server server1 127.0.0.1:8081 check maxconn 30 weight 100backend test_backend    mode http    balance roundrobin    option httpchk HEAD / HTTP/1.1    server server1 127.0.0.1:8080 check maxconn 30 weight 100

Заключение


В этой статье вы ознакомились с HAProxy Data Plane API, который позволяет полностью настроить HAProxy с использованием современного REST API. Более подробную информацию можно найти в официальной документации (Перевод: http://personeltest.ru/aways/habr.com/ru/post/508132/). У него имеются три мощных функции, которые включают гибкий язык конфигурации HAProxy и API времени выполнения. Data Plane API открывает двери для многостороннего использования, в частности, с использованием HAProxy в качестве уровня прокси в сетке сервиса.


Мы рады будущему использованию нового API для создания новых партнерских отношений и разнообразных функций. HAProxy продолжает обеспечивать высокую производительность и устойчивость в любой среде и в любом масштабе.


Если вам понравилась эта статья и вы хотите быть в курсе похожих тем, подпишитесь на этот блог. Вы также можете подписаться на нас в Твиттере и присоединиться к разговору на Slack. HAProxy Enterprise позволяет легко приступить к работе с Data Plane API, поскольку его можно установить в виде удобного системного пакета. Он также включает в себя надежную и передовую кодовую базу, корпоративный набор дополнений, экспертную поддержку и профессиональные услуги. Хотите узнать больше? Свяжитесь с нами сегодня и скачайте бесплатную пробную версию.


P.S. Телеграм чат HAproxy https://t.me/haproxy_ru

Подробнее..

Перевод Что такое Service Mesh?

16.06.2020 16:14:27 | Автор: admin
И снова здравствуйте!.. В преддверии старта курса Архитектор ПО мы подготовили еще один полезный перевод.



Service Mesh это конфигурируемый инфраструктурный уровень с низкой задержкой, который нужен для обработки большого объема сетевых межпроцессных коммуникаций между программными интерфейсами приложения (API). Service Mesh обеспечивает быструю, надёжную и безопасную коммуникацию между контейнеризированными и часто эфемерными сервисами инфраструктуры приложений. Service Mesh предоставляет такие возможности, как обнаружение сервисов, балансировку нагрузки, шифрование, прозрачность, трассируемость, аутентификацию и авторизацию, а также поддержку шаблона автоматического выключения (circuit breaker).
Service Mesh обычно реализуется путем предоставления каждому экземпляру сервиса экземпляра прокси, который называется Sidecar. Sidecar обрабатывают коммуникации между сервисами, производят мониторинг и устраняют проблемы безопасности, то есть все, что может быть абстрагировано от отдельных сервисов. Таким образом, разработчики могут писать, поддерживать и обслуживать код приложения в сервисах, а системные администраторы могут работать с Service Mesh и запускать приложение.

Istio от Google, IBM и Lyft, на данный момент является самый известной Service Mesh-архитектурой. А Kubernetes, который изначально разрабатывался в Google, сейчас является единственным фреймворком для оркестрации контейнеров, который поддерживается Istio. Вендоры пытаются создать коммерческие поддерживаемые версии Istio. Интересно, что нового они смогут привнести в проект с открытым исходным кодом.

Однако Istio это не единственный вариант, поскольку разрабатываются и другие реализации Service Mesh. Паттерн sidecar proxy является наиболее популярной реализацией, как можно судить по проектам Buoyant, HashiCorp, Solo.io и другим. Существуют и альтернативные архитектуры: технологический инструментарий Netflix это один из подходов, где функционал Service Mesh реализуется за счет библиотек Ribbon, Hysterix, Eureka, Archaius, а также таких платформ, как Azure Service Fabric.

Service Mesh также имеет свою собственную терминологию для компонентов-сервисов и функций:

  • Фреймворк оркестрации контейнеров. По мере того, как все больше и больше контейнеров добавляется в инфраструктуру приложения, появляется необходимость в отдельном инструменте для мониторинга и управления контейнерами фреймворке оркестрации контейнеров. Kubernetes плотно занял эту нишу, причем настолько, что даже его основные конкуренты Docker Swarm и Mesosphere DC/OS предлагают в качестве альтернативы интеграцию с Kubernetes.
  • Сервисы и экземпляры (поды Kubernetes). Экземпляр это единственная запущенная копия микросервиса. Иногда один экземпляр это один контейнер. В Kubernetes экземпляр состоит из небольшой группы независимых контейнеров, который называется подом. Клиенты редко обращаются напрямую к экземпляру или поду, чаще они обращаются к сервису, который представляет из себя набор идентичных масштабируемых и отказоустойчивых экземпляров или подов (реплик).
  • Sidecar Proxy. Sidecar Proxy работает с одним экземпляром или подом. Смысл Sidecar Proxy в том, чтобы направлять или проксировать трафик, приходящий от контейнера, с которым он работает, и обратный трафик. Sidecar взаимодействует с другими Sidecar Proxy и управляется фреймворком оркестрации. Многие реализации Service Mesh используют Sidecar Proxy для перехвата и управления всем входящим и исходящим трафиком экземпляра или пода.
  • Обнаружение сервисов. Когда экземпляру нужно взаимодействовать с другим сервисом, ему нужно найти (обнаружить) исправный и доступный экземпляр другого сервиса. Как правило экземпляр выполняет поиск по DNS. Фреймворк оркестрации контейнеров хранит список экземпляров, которые готовы к получению запросов, и предоставляет интерфейс для DNS-запросов.
  • Балансировка нагрузки. Большинство фреймворков оркестрации контейнеров обеспечивают балансировку нагрузки на 4 уровне (транспортном). Service Mesh реализует более сложную балансировку нагрузки на 7 уровне (прикладном), богатую алгоритмами и более эффективную в вопросе управления трафиком. Параметры балансировки нагрузки могут быть изменены с помощью API, что позволяет оркестрировать сине-зеленое или канареечное развертывание.
  • Шифрование. Service Mesh может зашифровывать и расшифровывать запросы и ответы, снимая это бремя с сервисов. Service Mesh также может повысить производительность за счет приоритезации или переиспользования существующих постоянных соединений, что снижает необходимость в дорогих вычислениях для создания новых соединений. Наиболее распространенной реализацией шифрования трафика является mutual TLS (mTLS), где инфраструктура открытых ключей (PKI) генерирует и распространяет сертификаты и ключи для использования их в Sidecar Proxy.
  • Аутентификация и авторизация. Service Mesh может авторизовывать и аутентифицировать запросы сделанные снаружи или изнутри приложения, отправляя экземплярам только валидированные запросы.
  • Поддержка шаблона автоматического выключения. Service Mesh поддерживает шаблон автоматического выключения, который изолирует нездоровые экземпляры, а затем постепенно возвращает их в пул здоровых экземпляров при необходимости.

Та часть приложения Service Mesh, которая управляет сетевым трафиком между экземплярами называется Data Plane. Создание и развертывание конфигурации, которая управляет поведением Data Plane, выполняется с помощью отдельной Control Plane. Control Plane обычно включает в себя или спроектирована таким образом, чтобы подключаться к API, CLI или GUI для управления приложением.


Control Plane в Service Mesh распределяет конфигурацию между Sidecar Proxy и Data Plane.

Часто архитектура Service Mesh применяется для решения сложных операционных задач с использованием контейнеров и микросервисов. Пионерами в области микросервисов являются такие компании как Lyft, Netflix и Twitter, которые предоставляют стабильно работающие сервисы миллионам пользователей по всему миру. (Здесь вы можете познакомиться с подробным описанием некоторых архитектурных задач, с которыми столкнулся Netflix). Для менее требовательных прикладных задач скорее всего будет достаточно более простых архитектур.

Архитектура Service Mesh вряд ли когда-нибудь станет ответом на все вопросы, связанные с работой приложений и их доставкой. Архитекторы и разработчики обладают огромным арсеналом инструментов, и только один из них молоток, который среди множества задач должен решать лишь одну забивать гвозди. Microservices Reference Architecture от NGINX, например, включает в себя несколько различных моделей, которые дают непрерывный спектр подходов к решению задач с помощью микросервисов.

Элементы, которые объединяются в архитектуре Service Mesh, такие как NGINX, контейнеры, Kubernetes и микросервисы в качестве архитектурного подхода, могут быть не менее продуктивно использованы и в реализациях без Service Mesh. Например, Istio был разработан как полноценная архитектура Service Mesh, но модульность говорит о том, что разработчики могут выбирать и применять только необходимые им компоненты технологий. Помня об этом, необходимо сформировать четкое понимание концепции Service Mesh, даже если вы не уверены в том, что сможете когда-нибудь полноценно ее реализовать в приложении.



Модульные монолиты и DDD


Подробнее..

Автоматизация тестирования в микросервисной архитектуре

07.07.2020 10:10:24 | Автор: admin

Привет, Хабр. Меня зовут Сергей Вертепов, я senior backend инженер. Это небольшая обзорная статья отом, как мы тестировали монолитное приложение Авито, и что изменилось спереходом намикросервисную архитектуру.



Тестирование в домикросервисную эпоху


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



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


Классическая пирамида тестирования длямонолитного приложения выглядит так:


  1. Много юнит-тестов.
  2. Чуть меньше интеграционных тестов.
  3. Ещё меньше сквозных тестов.
  4. Поверх всего непонятное количество мануальных тестов.


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


У нас был собственный тестовый framework наPHP сPHPUnit подкапотом. Система генерации тестовых данных унас тоже своя. Это ресурс-менеджер, который позволяет создать любой необходимый запрашиваемый ресурс длятестирования. Например, пользователя сденьгами, собъявлениями вопределённой категории наАвито, пользователя сопределённым статусом.


Система просмотра отчётов тоже самописная. Кроме неё мы написали собственный jsonwire-grid. Grid это система оркестрации селениумными нодами, она позволяет потребованию поднять селениумную ноду. Узнать подробности проGrid, как мы его разрабатывали и какие технологии использовали, можно издоклада моего коллеги Михаила Подцерковского cHeisenbug 2018года.


Также унас есть собственный selenium-maper. Мы написали собственную библиотечку, которая позволяет выполнять запросы поjsonwire-протоколу.


Наш CI-pipeline выглядел следующим образом: происходил какой-то CI Event, пусть для примера это будет пуш врепозиторий. ВCI собирался артефакт длязапуска тестов. Самописная система параллельного запуска тестов парсила артефакт и начинала запускать тесты накуче разных нод.



В качестве тестового приложения мы использовали РНР-имплементацию Selenide, полный порт сJava. Но впроцессе мы отнего отказались, потому что Selenide было тяжело поддерживать, сам он уже не развивался. Мы написали свой, более легковесный, PowerUI, вокруг которого построили и архитектуру тестовых приложений скастомными матчерами, селекторами и так далее. Этот продукт сильно упростил длянас тестирование и построение отчётов. Соответственно, дальше PowerUI черезjsonwire-grid входил вселениумную ноду и выполнял необходимые действия.


Само тестовое приложение унас дополнительно ходило вресурс-менеджер длягенерации тестовых данных, и потом уже отправляло данные внашу систему просмотра отчётов Test Report System.


В целом, втакой парадигме мы прекрасно жили. Вначале релизы большого монолитного PHP-приложения были раз вдень, потом их количество выросло дотрёх, а впоследствии и вовсе дошести. Унас было несколько тысяч Е2Е-тестов сбольшим покрытием, и они были довольно легковесными. Всреднем они выполнялись порядка минуты, заредким исключением. Тест, который проверял огромный кусок бизнес-логики мог занимать две-три минуты. Унас был минимум ручного регресса и минимум багов впродакшене.


Тестирование в микросервисной архитектуре


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


С монолитом пирамида тестирования унас не получилась. Вместо неё была мороженка тестирования. Счем это было связано? Е2Е-тесты благодаря разработанной инфраструктуре были довольно быстры и не причиняли особой боли. Поэтому мы делали основной упор наних. Мы даже могли пренебрегать юнит-тестами.



Сприходом микросервисной архитектуры такой подход перестал работать. Огромная часть бизнес-логики уехала вотдельные сервисы, их становилось всё больше. На 2020год унас порядка 2,5 тысяч разных репозиториев. Втаком случае, когда мы запускали Е2Е-тесты какой-то сервис мог, например, резко перестать отвечать. Если он отвалился, все тесты, которые ходили вэтот сервис и были блокирующими длямержа, тоже начинали падать. Соответственно, унас просто падал time tomarket, так как люди не могли мержиться из-западающих тестов. Мы были вынуждены сидеть и ждать, пока придёт оунер конкретного сервиса, разберётся, что происходит, перевыкатит его или разберется спроблемами.


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



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


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


Чтобы решить эту проблему, мы стали внедрять методологию Agile Testing. Суть этой методологии состоит втом, что мы предотвращаем баги, а не ищем их. Тестирование мы обсуждаем наProduct Backlog Refinements. Мы сразу определяем, как будем тестировать какую-то фичу: достаточно ли покрыть её юнит-тестом и если юнит-теста достаточно, какой это должен быть юнит-тест. Обсуждение происходит вместе стестировщиком, который определяет, нужно ли будет дополнительно провести ручное тестирование. Как правило, юнит-теста бывает достаточно. Плюс тестировщик может подсказать ещё какие-то кейсы, а также может предоставить чеклист, наоснове которого мы напишем нужные юнит- или функциональные тесты.


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


Но Agile Testing невозможен безShift-left тестов. Shift-left testing это методология, прикоторой мы тестируем каждый деплой и прикаждом пуше прогоняем все необходимые тесты. Выкатка без этого невозможна. Но тесты приэтом должны быть легковесными. Основная суть подхода находить дефекты наранних этапах, чтобы разработчик мог запустить необходимый тест влюбой момент, когда пишет код. Также он обеспечивает непрерывное тестирование вCI, и возможность автоматизации чего угодно.


Во время Shift-left тестов мы разбиваем большие, тяжёлые тесты накучу маленьких, чтобы они запускались и выполнялись быстрее. Мы декомпозировали наши огромные Е2Е-тесты накомпонентно-интерфейсные тесты, наюнит-, интеграционные тесты, функциональные тесты, то есть начали распределять Е2Е попирамиде. Раньше запуск тестов мог занять 2030минут и требовал танцев сбубном. Сейчас влюбом микросервисе тесты прогоняются за5-10минут, и разработчик сразу знает, сломал он что-либо или нет.


Также мы внедрили методологию контрактных тестов. Сокращение CDC-тесты значит Consumer-Driven Contract тесты. Когда мы пушим изменение кода врепозитории, специально написанный брокер собирает всю необходимую информацию потому, какие написанные CDC-тесты есть, и дальше понимает, ккакому сервису они имеют отношение.


Сами CDC-тесты пишутся настороне консьюмера сервиса. Привыкатке продюсера мы прогоняем все написанные тесты, то есть проверяем, что продюсер никак не нарушает контракт. Подробнее проэто рассказывал всвоём докладе Фрол Крючков, который как раз драйвил эту идею.


Помогли ли нам CDC-тесты? Нет, потому что появилась проблема стем, что сами консьюмеры не поддерживают свои тесты. Как результат тесты нестабильны, из-заэтого получалось, что наши продюсеры не могли вовремя выкатиться. Приходилось идти и фиксить тесты состороны консьюмеров. Плюс тесты все писали по-разному, наодну ручку мог быть десяток различных тестов, которые проверяют одно и то же. Это неудобно и долго. Поэтому отидеи CDC-тестов мы отказались.


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



Теперь сервис-потребитель и сервис-продюсер общаются между собой через Api Gateway. Настороне Api Gateway есть валидация контрактов наоснове бриф-файлов. Бриф-файл это очень простой структурный файлик, который описывает сервисное взаимодействие. Есть бриф-файл настороне продюсера, он описывает то, как мы должны общаться сэтим сервисом. Консьюмер копипастой берёт необходимую себе ручку, необходимую структуру, затаскивает всё это всвой сервис, и генерирует наоснове этого клиенты.


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


Ещё мы внедрили такую штуку, как service mesh. Service mesh это когда рядом скодом сервиса поднимается sidecar, который проксирует все необходимые запросы. Запрос идет не всам сервис, его сначала получает sidecar, который прокидывает необходимые заголовки, проверяет, роутит маршруты, и передаёт запрос сервису. Cервис передаёт запрос обратно вsidecar, и так дальше поцепочке.


Про service mesh подробно можно узнать издоклада Саши Лукьянченко сDevOpsConf 2019года. Внём Саша рассказывает прото, как разрабатывал решение и как мы кнему пришли.


На основе sidecar мы внедрили OpenTracing. Это технология, которая позволяет полностью отследить запросы отсамого фронта доконечного сервиса и посмотреть, какие были отвалы, сколько шёл запрос.



Это интерфейс Jaeger UI. На скриншоте трейсинг запросов современем выполнения и маршрутом


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



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


Всё это работает благодаря service mesh утилите Netramesh. Достаточно прописать заголовок X-Route, наш sidecar перехватывает запрос досервиса и перенаправляет куда надо. Вконкретном случаем мы его перенаправляли вникуда, будто бы сервис отвалился. Мы могли сказать ему, чтобы он вернул пятисотую ошибку, либо могли сделать таймаут. Netramesh всё это умеет, единственная проблема, что здесь необходимо черезDevTools-протокол добавлять ковсем запросам необходимый заголовок.


В сухом остатке


Сейчас для тестирования в микросервисной архитектуре мы используем:


  • Карму для E2E-тестов.
  • Методологию Agile Testing.
  • PaaS c Api Gateway.
  • Service mesh, благодаря которому работают OpenTracing и Graceful Degradation тестирование.
Подробнее..

Envoy как универсальный сетевой примитив

05.02.2021 00:16:03 | Автор: admin

В октябре прошлого года мои коллеги представили на EnvoyCon доклад "Построение гибкой подсистемы компрессии в Envoy". Вот он ниже



Судя по статистике сегодняшней статьи от SergeAx, тема компрессии сетевого трафика оказалась интересной многим. В связи с чем я немедленно возжелал вселенской славы и решил кратко пересказать содержание доклада. Тем более, что он не только о компрессии, но и том, как можно упростить сопровождение сетевой подсистемы как backend'а, так и мобильного frontend'а.


Я не стал полностью "новелизировать" видео доклада, а только ту часть, которую озвучил Хосе Ниньо. Она заинтересует больше людей.


Для начала о том, что такое Envoy.


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



Принцип работы прокси-сервера очень прост: клиент устанавливает сетевое соединение не напрямую с сервисом, а через прокси-сервер, который в случае необходимости, например, сжимает проходящий через него сетевой трафик. Или оконечивает TLS. Или, не разрывая соединения с клиентом, пытается повторно соединиться с временно недоступным сервисом. Или, если совсем всё плохо, соединиться с резервным сервисом. И так далее.
Главное в том, что подобная схема заметно снижает сложность кода и клиента, и сервиса. Особенно сервиса.



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



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



Мобильный клиент общается с граничным прокси (Edge), который решает, куда отправлять клиентские запросы дальше, попутно балансируя нагрузку на сервера. Сервисы получают запросы от Edge не напрямую, а через вспомогательные прокси (Sidecar). Далее, сервисы формируют ответы, опционально пообщавшись друг с другом, и отсылают их к Edge.


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



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



Так появился проект Envoy Mobile, который представляет собой байндинги на Java, Kotlin, Swift, Objective-C к Envoy. А тот уже линкуется к мобильному приложению как нативная библиотека.


Тогда задача уменьшения объёма трафика описанная в статье от FunCorp, могла бы быть решена примерно как на картинке ниже (если поменять местами компрессор и декомпрессор, и заменить response на request). То есть даже без необходимости установки обновлений на телефонах.



Можно пойти дальше, и ввести двустороннюю компрессию



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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru