istio sidecar что это

Istio — это просто: Sidecar

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

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

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

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

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

Настройка Sidecar

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

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

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

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

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

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

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

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

Результат

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

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

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

Источник

Как этот sidecar-контейнер оказался здесь [в Kubernetes]?

Прим. перев.: Этой статьёй, написанной Scott Rahner — инженером в Dow Jones, мы продолжаем цикл многочисленных материалов, доступно рассказывающих о том, как устроен Kubernetes, как работают, взаимосвязаны и используются его базовые компоненты. На сей раз это практическая заметка с примером кода для создания хука в Kubernetes, демонстрируемого автором «под предлогом» автоматического создания sidecar-контейнеров.

(Автор фото — Gordon A. Maxwell, найдено на просторах интернета.)

Когда я начал изучать sidecar-контейнеры и service mesh’и, мне потребовалось разобраться в том, как работает ключевой механизм — автоматическая вставка sidecar-контейнера. Ведь в случае использования систем вроде Istio или Consul, при деплое контейнера с приложением внезапно в его pod’е появляется и уже настроенный контейнер Envoy (схожая ситуация происходит и у Conduit, о котором мы писали в начале года — прим. перев.). Что? Как? Так начались мои исследования…

Для тех, кто не знает, sidecar-контейнер — контейнер, который деплоится рядом с контейнерами приложения, чтобы каким-либо образом «помогать» этому приложению. Примером такого использования может служить прокси для управления трафиком и завершения TLS-сессий, контейнер для стриминга логов и метрик, контейнер для сканирования проблем в безопасности… Идея в том, чтобы изолировать различные аспекты всего приложения от бизнес-логики с помощью применения отдельных контейнеров для каждой функции.

Перед тем, как продолжить, обозначу свои ожидания. Цель этой статьи — не объяснить хитросплетения и сценарии использования Docker, Kubernetes, service mesh’ей и т.п., а наглядно показать один мощный подход к расширению возможностей этих технологий. Статья — для тех, кто уже знаком с применением данных технологий или, по крайней мере, немало о них прочитал. Чтобы попробовать практическую часть в действии, потребуется машина с уже настроенными Docker и Kubernetes. Простейший способ для этого — https://docs.docker.com/docker-for-windows/kubernetes/ (инструкция для Windows, которая работает и в Docker for Mac). (Прим. перев.: В качестве альтернативы пользователям Linux и *nix-систем можем предложить Minikube.)

Общая картина

Для начала давайте немного разберёмся с Kubernetes:

Kube Arch, лицензированная под CC BY 4.0

Когда вы собираетесь задеплоить что-либо в Kubernetes, необходимо отправить объект в kube-apiserver. Чаще всего это делают передачей аргументов или YAML-файла в kubectl. В таком случае сервер API перед тем, как непосредственно помещать данные в etcd и планировать соответствующие задания, проходит через несколько этапов:

Эта последовательность важна, чтобы разобраться, как работает вставка sidecar-контейнеров. В частности, нужно обратить внимание на Admission Control, в рамках которого Kubernetes валидирует и, если необходимо, модифицирует объекты перед тем, как сохранять их (подробнее об этом этапе см. в главе «Контроль допуска» этой статьи — прим. перев.). Kubernetes также позволяет регистрировать webhooks, которые могут выполнять определяемую пользователем валидацию и изменения (mutations).

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

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

Название webhook говорит само за себя — это HTTP endpoint, реализующий API, определённый в Kubernetes. Вы создаёте API-сервер, который Kubernetes может вызывать перед тем, как разбираться с Deployment’ами. Здесь мне пришлось столкнуться со сложностями, поскольку доступны всего несколько примеров, некоторые из которых — просто unit-тесты Kubernetes, другие — спрятаны посреди огромной кодовой базы… и все написаны на Go. Но я выбрал более доступный вариант — Node.js:

Deployment

Хорошо, у нас есть код, который принимает запросы от API-сервера Kubernetes и отвечает на них, но как его задеплоить? И как заставить Kubernetes перенаправлять нам эти запросы? Развернуть такой endpoint можно везде, до чего может «достучаться» API-сервер Kubernetes. Простейшим способом является деплой кода в сам кластер Kubernetes, что мы и сделаем в данного примере. Я постарался сделать пример максимально простым, поэтому для всех действий использую лишь Docker и kubectl. Начнём с создания контейнера, в котором будет запускаться код:

Как видно, тут всё очень просто. Возьмите образ с node от сообщества и забросьте в него код. Теперь можно выполнить простую сборку:

Следующим шагом создадим Deployment в Kubernetes:

Заметили, как мы сослались на только что созданный образ? Так же просто тут мог быть и pod, и что-либо иное, к чему мы можем подключить сервис в Kubernetes. Теперь определим этот Service:

Так в Kubernetes появится endpoint с внутренним именем, который указывает на наш контейнер. Финальный шаг — сообщить Kubernetes’у, что мы хотим, чтобы API-сервер вызывал этот сервис, когда он готов производить изменения (mutations):

Название и путь здесь могут быть любыми, но я постарался сделать их настолько осмысленными, насколько возможно. Изменение пути будет означать необходимость модификации соответствующего кода в JavaScript. Важен и webhook failurePolicy — он определяет, должен ли объект сохраняться, если хук возвращает ошибку или не срабатывает. Мы в данном случае говорим Kubernetes’у не продолжать обработку. Наконец, правила ( rules ): они будут меняться в зависимости от того, на какие вызовы API вы ожидаете действий от Kubernetes. В данном случае, поскольку мы пытаемся эмулировать вставку sidecar-контейнера, нам требуется перехват запросов на создание pod’а.

Вот и всё! Так просто… но что насчёт безопасности? RBAC — это один из аспектов, который не затронут в статье. Я предполагаю, что вы запускаете пример в Minikube или же в Kubernetes, что идёт в поставке Docker for Windows/Mac. Однако расскажу ещё об одном необходимом элементе. API-сервер Kubernetes обращается только к endpoint’ам с HTTPS, поэтому для приложения потребуется наличие SSL-сертификатов. Также потребуется сообщить Kubernetes’у, кто является удостоверяющим центром корневого сертификата.

Только для демонстрационных целей(. ) я добавил в Dockerfile немного кода, чтобы создать root CA и воспользоваться им для подписи сертификата:

Теперь код поддерживает запуск HTTPS, а также сообщил Kubernetes’у, где найти нас и какому удостоверяющему центру доверять. Осталось лишь задеплоить всё это в кластер:

Резюмируем

Попробуем в деле!

Всё развёрнуто в кластере — время попробовать код в действии, что мы сделаем добавлением нового pod/Deployment. Если всё работает правильно, хук должен будет добавить дополнительный лейбл foo :

Источник

Istio — это просто: Sidecar

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

Настройка Sidecar

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

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

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

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

Результат

Источник

Service mesh для микросервисов. Часть II, основы работы с Istio

Перевод статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes».

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

Администрировать их порой — сплошная головная боль. В этой статье мы расскажем об Istio — инструменте для service mesh (эту архитектуру мы рассматривали ранее), который выводит управление крупными облачными развертываниями на новый уровень.

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

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

Знакомство с плоскостью данных и sidecar-прокси

Два основных архитектурных термина в Istio — плоскость данных (data plane) и плоскость управления (control plane). Плоскость данных работает с данными, которые перемещаются в приложении, передаются различным экземплярам сервисов и обрабатываются самими сервисами. Для ее реализации используется главным образом sidecar-прокси. На уровне управления определяется порядок инстанцирования сервисов, место хранения данных телеметрии и информации о сервисах. К основным элементам плоскости управления относятся Pilot и Mixer. Давайте разберемся, как это все работает.

Sidecar-прокси выполняется вместе с подом, который определяет ваш сервис в Kubernetes. Он добавляется к основным компонентам сервиса и работает с трафиком, который направляется в этот сервис. Вы можете добавить sidecar-прокси к существующему определению сервиса в поде: в сервис просто добавятся строки, определяющие sidecar-прокси, и он начнет работать.

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

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

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

Централизация: плоскость управления

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

Это проще всего увидеть, воспользовавшись командой get-svc в составе kubectl — вы получите список сервисов, связанных с конкретной библиотекой. Чтобы проверить, какие компоненты Istio выполняются, можно воспользоваться следующей командой:

Отобразится список основных элементов плоскости управления Istio, выполняемых в фоновом режиме. Возможно, некоторые из них вам уже знакомы, например Citadel — сервис, который управляет защитой трафика между сервисами.

Установка Istio

Давайте посмотрим, какие возможности Istio поддерживает по умолчанию. Мы установим плоскость управления Istio для администрирования базового API HTTP, который был описан в предыдущей статье. Этот сервис API был определен в Kubernetes и реализован как одиночный под Kubernetes с выполняемым в нем API.

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

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

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

Развертывание приложения helloworld

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

Внедрение sidecar-прокси Istio вручную

Istio задействует образец sidecar-прокси, чтобы разместить контейнер sidecar-прокси Istio в одном поде с контейнером приложения helloworld.

Проверьте, чтобы поды и сервис выполнялись:

Теперь проверьте трафик для приложения helloworld:

Следующие шаги

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

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

Источник

Service mesh для микросервисов. Часть III. Более глубокий взгляд на Istio

Перевод статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes».

Это третья статья из серии публикаций, посвященных Kubernetes и технологии service mesh (также известной как «сеть микросервисов» и «mesh-сеть микросервисов»). В предыдущей статье мы изучили основы работы с Istio и выяснили, как этот инструмент помогает настраивать и администрировать сложные облачные архитектуры. Так, с его помощью можно сконфигурировать mesh-сеть микросервисов и получить некоторые возможности централизации в распределенной микросервисной среде. Сегодня мы более подробно изучим функции Istio, чтобы по достоинству оценить преимущества технологии service mesh.

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

Поэтому сегодня мы подробно изучим четыре основных компонента Istio и их функции: управление трафиком (Envoy), плоскость управления (Pilot), компонент телеметрии (Mixer) и компонент безопасности (Citadel). Мы последовательно рассмотрим каждый из них и их роль в mesh-сети микросервисов.

Envoy

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

Sidecar-прокси работают как основные сетевые шлюзы для трафика конкретных сервисов, определенных вами: прокси принимает входящий трафик, направленный тому или иному сервису, и маршрутизирует его в соответствии с правилами и политиками, заданными в общей конфигурации.

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

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

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

Envoy позволяет создавать конфигурации, которые распределяют нагрузку между различными версиями. Например, можно начать с перенаправления всего 5 % трафика новым экземплярам. Как только данные модифицированной конфигурации будут переданы компоненту Pilot, изменится балансировка нагрузки в sidecar-прокси. Первоначально новый сервис будет получать небольшой объем трафика, а вы сможете собирать и обрабатывать экспериментальные данные. Затем можно будет постепенно увеличивать объем с 5 до 100 % и при необходимости уменьшать его, пока вы не будете уверены, что новая версия исправно работает.

Конфигурирование sidecar-прокси

Как выглядит такая конфигурация на практике? Для перенаправления трафика в различные целевые расположения необходимо задать параметр weight в конфигурации сервиса, например, так:

У нас есть один хост, hello1, с двумя версиями целевого расположения — v1 и v2. Сначала мы назначаем 75 % трафика для v1, а оставшиеся 25 % — для v2. После внедрения конфигурации можно проверить статус, выждав предварительно заданное время, и снова изменить параметры.

Таким образом, Envoy предоставляет отличные возможности для управления трафиком, направленным в конкретные целевые расположения. Если для вашего приложения характерны всплески трафика, которые перегружают оборудование, можно внедрить задержки с помощью параметра fault :

Pilot

Основной компонент, взаимодействующий с Envoy, — это Pilot, который осуществляет централизованное управление всеми экземплярами Envoy в mesh-сети. Pilot выступает в роли единого источника данных о состоянии среды. Это локальное хранилище всех правил для сервисов и их взаимодействий. Здесь же находятся сведения о выполняемых операциях. Pilot часто отождествляют с плоскостью управления Istio, так как он отвечает за администрирование и конфигурирование всех прокси Envoy (хотя технически другие компоненты, такие как Citadel, тоже относятся к плоскости управления).

Безусловно, Pilot играет важную роль в понимании принципов работы service mesh. Но на практике большинство операций, связанных с этим компонентом, выполняют прокси Envoy. Они периодически сверяются с Pilot, чтобы получать данные последних конфигураций, и регулярно обновляются. Любое изменение конфигурации mesh-сети подразумевает взаимодействие с плоскостью управления. Такое разделение задач — ключевой принцип Istio: прокси Envoy взаимодействуют с Pilot для создания сервисов, из которых строится приложение. Знание взаимосвязей между компонентами service mesh играет решающую роль в понимании сути этой технологии.

В первой статье мы говорили о преимуществах абстракции сети микросервисов, которая позволяет использовать высокоуровневые команды для определения взаимодействий между сервисами. Технология преобразовывает эти команды в точные конфигурации для сервисов, которые ей подконтрольны. Pilot — это компонент, отвечающий за эти ключевые функции. В качестве входных данных он получает правила обнаружения сервисов и генерирует определенные действия, которые выполняются прокси Envoy (или любыми другими sidecar-прокси, совместимыми с API Envoy).

Тест-драйв компонента Pilot

Лучший способ больше узнать об экземплярах Pilot в mesh-сети — ознакомиться с данными о статусе sidecar-прокси. Список сервисов и идентификатор Pilot, который их контролирует, можно получить, выполнив следующую команду:

Отобразится перечень сервисов и их идентификаторов с соответствующим идентификатором Pilot и текущим статусом синхронизации. Sidecar-прокси со статусом Synced или Synced (100 %) обновлены и получили последние конфигурации от компонента Pilot. Статус Not Sent означает, что конфигурация не менялась в последнее время, поэтому синхронизировать нечего. А статус Stale означает, что sidecar-прокси не реагирует на изменения.

На выходе вы получите следующее:

Обратите внимание, что вид выходных данных команд статуса прокси различается в разных версиях Istio (в частности, в версиях 1.0.5, 1.1.2 и в последней версии 1.1.7). Так, в более ранних версиях Istio выходные данные содержали полный объект JSON, но начиная с версии 1.1.7 они выглядят так, как показано выше. Вы можете столкнуться с другими форматами выходных данных.

Pilot покажет форматированные различия между изменениями конфигурации и текущим состоянием сервиса. Так вы сможете отследить, какие изменения еще не были внедрены в сервис и подтверждены.

Mixer

Как и Pilot, Mixer — это компонент Istio, который работает с трафиком и применяет настраиваемые правила. Основное отличие состоит в том, что Mixer работает на уровне всей mesh-сети и позволяет применять глобальные правила. Это значит, что его можно использовать для сбора телеметрии по всему приложению или настройки глобальных ограничений на использование тех или иных сервисов.

Теперь давайте разберемся, чем отличается работа Envoy и Mixer. Само название sidecar-прокси предполагает, что Envoy добавляется к каждому сервису, развернутому в приложении, и работает с трафиком, направленным в этот сервис. Mixer же функционирует на уровне всего приложения и применяет правила, заданные для среды в целом.

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

Еще одна полезная возможность этого компонента — интеграция со сторонними подключаемыми модулями. Основной источник централизованной информации о приложении должен быть совместим с инструментами для визуализации операций или просмотра журналов. Mixer позволяет добавлять эти возможности в Kubernetes и удобно отображать собираемую информацию, часто в режиме реального времени. Одна такая платформа для мониторинга событий (Prometheus) уже интегрирована.

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

Использование Mixer

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

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

Prometheus, встроенный инструмент для запроса журналов в Istio, — простейший способ просматривать трафик. Настройте переадресацию портов Prometheus:

Теперь Prometheus будет выполняться через порт 9090 локального компьютера — можно запрашивать журналы из этого расположения.

Citadel

Помимо масштабируемости, обеспечиваемой Envoy, и обширных сведений, предоставляемых Mixer, одним из преимуществ облачной mesh-архитектуры является безопасность. В Istio для этого используется Citadel — основной защитный компонент. Он помогает управлять ключами и сертификатами, которые являются неотъемлемой частью современных развертываний микросервисов.

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

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

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

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

Использование Citadel

Хотя функции безопасности этого компонента достаточно сложны, приступить к работе с Citadel совсем несложно. Как и в случае Mixer, основная часть работы выполняется автоматически. Чтобы запустить процесс, необходимо лишь активировать правильную конфигурацию.

Например, для включения глобальной взаимной аутентификации TLS нужно изменить политику аутентификации mesh-сети. Это можно сделать с помощью kubectl, применив следующую команду:

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

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

Заключение

Теперь вы гораздо лучше осведомлены о возможностях Istio и о том, как они связаны с преимуществами service mesh в целом. Четкое распределение задач — одна из сильных сторон этого инструмента. Все компоненты, такие как sidecar-прокси в Envoy или система управления ключами Citadel, являются изолированными и самостоятельными.

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

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

Источник