Sidecar proxy что это
Kubernetes — изучаем паттерн Sidecar
Объяснение паттерна Sidecar на примере
Под, содержащий один контейнер, относится к одно-контейнерным подам и это самый распространенный вариант их использования в Kubernetes. Под, который содержит несколько связанных контейнеров, относится к мульти-контейнерным подам. Есть несколько паттернов для мульти-контейнерных подов и один из них — это паттерн sidecar. В этом посте мы на примере проекта детально рассмотрим этот паттерн.
Что такое контейнер Sidecar
Другие паттерны
Пример
Тестируем с объектом Deployment
Как настроить ресурсные ограничения Resource Limits
Когда мы должны использовать этот паттерн
Заключение
Что такое Sidecar-контейнер
Sidecar-контейнер — это контейнер, который должен быть запущен рядом с основным контейнером внутри пода. Этот паттерн нужен для расширения и улучшения функциональности основного приложения без внесения в него изменений. Сейчас мы знаем, что технология контейнеризации позволяет собирать все зависимости, чтобы мы могли запустить приложение где угодно. Контейнер делает только одну вещь и делает её хорошо.
Представьте, что у вас есть под с одним контейнером, который очень хорошо работает, и вы бы хотели добавить какой-то функционал к этому контейнеру, не внося в него изменений. Как тогда можно добавить или расширить для него какие-то функции? Паттерн Sidecar может помочь именно в такой ситуации.
На диаграмме выше видно, как вы можете создать любое количество Sidecar контейнеров и ваш основной контейнер будет успешно с ними взаимодействовать. Все контейнеры работают параллельно и полный функционал будет доступен только если каждый из контейнеров успешно запущен. В большинстве случаев sidecar-контейнеры просты и легковесны и потребляют намного меньше ресурсов чем основной контейнер.
Другие паттерны
Вот некоторые другие паттерны, которые можно использовать для повседневной работы в Kubernetes:
Пример проекта
Здесь пример проекта, который вы можете скопировать и запустить на своих мощностях. Предварительно вам нужно установить Minikube.
Давайте запустим простой проект, чтобы понять как работает этот паттерн. Здесь под, в котором есть основной и sidecar контейнеры. Основной контейнер это Nginx, слушающий на порту 80, который отдает страницу index.html из volume, примонтированного в location workdir. И sidecar-контейнер с образом busybox, который пишет лог с timestamp в тот же самый файл. Так как sidecar-контейнер и основной контейнер запущены параллельно, Nginx будет показывать новую информацию каждый раз, когда вы делаете обращение через браузер.
Вы можете установить curl и сделать запрос на localhost, чтобы проверить ответ сервера.
Тестирование Sidecar Container
Тестирование с объектом Deployment
Давайте создадим сущность deployment с тем же определением подов и 5 репликами. Я создал service с типом порта NodePort, чтобы мы могли получить доступ к deployment через браузер. Поды создаются динамически и поддержкой заданного состояния всегда занимается deployment controller, поэтому у вас не может быть одного статического IP для доступа к поду, вместо этого вам нужно создать сущность service, которая будет открывать определенный порт во внешний мир. Внутри кластера service перенаправляет запросы извне на 80 порт контейнеров с соответствующими селекторами (тут много изменений оригинального текста). Вы увидите как это работает через некоторое время.
Deployment
Теперь давайте посмотрим на приведенный ниже deployment, в котором мы определили один основной контейнер и два sidecar-контейнера. Все контейнеры работают параллельно. Два sidecar-контейнера пишут лог в директорию /var/log. Основной контейнер с Nginx будет отдавать эти файлы, когда мы будем подключаться к порту 80. Вы увидите это в действии через некоторое время.
И выполним следующие команды, чтобы протестировать deployment.
deployment в действии
На диаграмме выше вы можете видеть 5 подов, запущенных на разных IP-адресах и service, связывающие порты 32123 и 80. Вы можете получить доступ к этому deployment из браузера через IP ворке-ноды Kubernetes 192.168.64.2 и через порт сервиса 32123:
Вы также можете протестировать под следующими командами:
Паттерн Sidecar в действии
Как настроить ограничения ресурсов
Настроить ограничения ресурсов очень важно, если речь идет о sidecar-контейнерах. Главное, что нам нужно понять, это то, что все контейнеры работают параллельно, поэтому при настройке ограничений ресурсов для пода вы должны это учитывать.
Суммировать все ограничения ресурсов для основных контейнеров, а также для дополнительных контейнеров (поскольку все контейнеры работают параллельно).
Когда нам нужно использовать этот паттерн
Вот несколько сценариев, в которых вы можете использовать этот паттерн:
Всегда, когда вы хотите дополнить функционал уже существующего единичного контейнера без внесения в него изменений
Вы можете использовать этот контейнер для синхронизации кода основного контейнера с кодом на git-сервере используя pull.(You can use this pattern to synchronize the main container code with the git server pull.)
Вы можете использовать этот контейнер, чтобы отправлять логи основного контейнера на внешний сервер.
Вы можете использовать этот контейнер для задач, связанных с установлением сети (network-related tasks.).
Под, который содержит один контейнер, относится к одно-контейнерному поду и это самый распространенный шаблон его использования.
Под, содержащий несколько взаимосвязанных контейнеров, относится к мульти-контейнерному поду.
Sidecar-контейнер запускается параллельно с основным контейнером. Поэтому вам нужно учитывать ограничения ресурсов для sidecar-контейнера прежде, чем вы задаете запросы/ограничения ресурсов для пода.
Контейнер с приложением и Sidecar-контейнер запускаются параллельно, что значит, что они будут работать в одно и то же время. Поэтому вам нужно суммировать все запросы/ограничения ресурсов для контейнеров, прежде чем задавать запросы/ограничения ресурсов для подов.
Вам нужно настроить health checks для sidecar-контейнеров так же, как и для основных контейнеров, что бы быть уверенными, что они в порядке.
Все поды, порожденные deployment не имеют статического IP-адреса, поэтому вам нужно создать сущность service, чтобы дать к ним доступ из внешнего мира.
Сущность service перенаправляет трафик внутри кластера с внешних портов на порты контейнера в соответствии с выбранными селекторами.
Заключение
Знать проверенные временем паттерны в kubernetes полезно. Убедитесь, что все ваши sidecar-контейнеры достаточно просты и малы, потому что вам нужно будет просуммировать все запросы и ограничения ресурсов прежде чем задавать их для пода в целом. Также нужно быть уверенным, что Sidecar-контейнеры “здоровы”, настроив health checks. Помните об этих моментах, когда добавляете функционал в основной контейнер или используйте отдельный контейнер.
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 на продвинутом уровне.
Ликбез по запуску Istio
Istio Service Mesh
Мы в Namely уже год как юзаем Istio. Он тогда только-только вышел. У нас здорово упала производительность в кластере Kubernetes, мы хотели распределенную трассировку и взяли Istio, чтобы запустить Jaeger и разобраться. Service mesh так здорово вписалась в нашу инфраструктуру, что мы решили вложиться в этот инструмент.
Пришлось помучиться, но мы изучили его вдоль и поперек. Это первый пост из серии, где я расскажу, как Istio интегрируется с Kubernetes и что мы узнали о его работе. Иногда будем забредать в технические дебри, но не сильно далеко. Дальше будут еще посты.
Что такое Istio?
Istio — это инструмент конфигурации service mesh. Он читает состояние кластера Kubernetes и делает обновление до прокси L7 (HTTP и gRPC), которые реализуются как sidecar-ы в подах Kubernetes. Эти sidecar-ы — контейнеры Envoy, которые читают конфигурацию из Istio Pilot API (и сервиса gRPC) и маршрутизируют по ней трафик. С мощным прокси L7 под капотом мы можем использовать метрики, трассировки, логику повтора, размыкатель цепи, балансировку нагрузки и канареечные деплои.
Начнем с начала: Kubernetes
В Kubernetes мы создаем под c помощью деплоя или StatefulSet. Или это может быть просто «ванильный» под без контроллера высокого уровня. Затем Kubernetes изо всех сил поддерживает желаемое состояние — создает поды в кластере на ноде, следит, чтобы они запускались и перезапускались. Когда под создается, Kubernetes проходит по жизненному циклу API, убеждается, что каждый шаг будет успешным, и только потом наконец создает под на кластере.
Этапы жизненного цикла API:
Спасибо Banzai Cloud за крутую картинку.
Один из этапов — модифицирующие вебхуки допуска. Это отдельная часть жизненного цикла в Kubernetes, где ресурсы кастомизируются до коммита в хранилище etcd — источнике истины для конфигурации Kubernetes. И здесь Istio творит свою магию.
Модифицирующие вебхуки допуска
Когда под создается (через kubectl или Deployment ), он проходит через этот жизненный цикл, и модифицирующие вебхуки доступа меняют его, прежде чем выпустить в большой мир.
Во время установки Istio добавляется istio-sidecar-injector как ресурс конфигурации модифицирующих вебхуков:
Sidecar-поды
Sidecar-ы — это трюки нашего фокусника Istio. Istio так ловко все проворачивает, что со стороны это прямо магия, если не знать деталей. А знать их полезно, если вдруг надо отладить сетевые запросы.
Init- и прокси-контейнеры
В Kubernetes есть временные одноразовые init-контейнеры, которые можно запускать до основных. Они объединяют ресурсы, переносят базы данных или, как в случае с Istio, настраивают правила сети.
@jimmysongio нарисовал отличную схему связи между правилами iptables и прокси Envoy:
Envoy получает весь входящий и весь исходящий трафик, поэтому весь трафик вообще перемещается внутри Envoy, как на схеме. Прокси Istio — это еще один контейнер, который добавляется во все поды, изменяемые sidecar-инжектором Istio. В этом контейнере запускается процесс Envoy, который получает весь трафик пода (за некоторым исключением, вроде трафика из вашего кластера Kubernetes).
Процесс Envoy обнаруживает все маршруты через Envoy v2 API, который реализует Istio.
Envoy и Pilot
У самого Envoy нет никакой логики, чтобы обнаруживать поды и сервисы в кластере. Это плоскость данных и ей нужна плоскость контроля, чтобы руководить. Параметр конфигурации Envoy запрашивает хост или порт сервиса, чтобы получить эту конфигурацию через gRPC API. Istio, через свой сервис Pilot, выполняет требования для gRPC API. Envoy подключается к этому API на основе sidecar-конфигурации, внедренной через модифицирующий вебхук. В API есть все правила трафика, которые нужны Envoy для обнаружения и маршрутизации для кластера. Это и есть service mesh.
Обмен данными «под Pilot»
Pilot подключается к кластеру Kubernetes, читает состояние кластера и ждет обновлений. Он следит за подами, сервисами и конечными точками в кластере Kubernetes, чтобы потом дать нужную конфигурацию всем sidecar-ам Envoy, подключенным к Pilot. Это мост между Kubernetes и Envoy.
Из Pilot в Kubernetes
Когда в Kubernetes создаются или обновляются поды, сервисы или конечные точки, Pilot узнает об этом и отправляет нужную конфигурацию всем подключенным экземплярам Envoy.
Какая конфигурация отправляется?
Какую конфигурацию получает Envoy от Istio Pilot?
По умолчанию Kubernetes решает ваши сетевые вопросы с помощью sevice (сервис), который управляет endpoint (конечные точки). Список конечных точек можно открыть командой:
Это список всех IP и портов в кластере и их адресатов (обычно это поды, созданные из деплоя). Istio важно это знать, чтобы настраивать и отправлять данные о маршрутах в Envoy.
Сервисы, прослушиватели и маршруты
Когда вы создаете сервис в кластере Kubernetes, вы включаете ярлыки, по которым будут выбраны все подходящие поды. Когда вы отправляете трафик на IP сервиса, Kubernetes выбирает под для этого трафика. Например, команда
Istio и Envoy слегка меняют эту логику. Istio настраивает Envoy на основе сервисов и конечных точек в кластере Kubernetes и использует умные функции маршрутизации и балансировки нагрузки Envoy, чтобы обойти сервис Kubernetes. Вместо проксирования по одному IP Envoy подключается прямо к IP пода. Для этого Istio сопоставляет конфигурацию Kubernetes с конфигурацией Envoy.
Термины Kubernetes, Istio и Envoy немного отличаются, и не сразу понятно, что с чем едят.
Сервисы
Все те же сервисы есть в этом пространстве имен:
Как Istio узнает, какой протокол использует сервис? Настраивает протоколы для манифестов сервисов по полю name в записи порта.
Если использовать kubectl и админскую страницу переадресации портов в Envoy, видно, что конечные точки account-grpc-public реализуются Pilot как кластер в Envoy с протоколом HTTP2. Это подтверждает наши предположения:
Порт 15000 — это админская страница Envoy, доступная в каждом sidecar.
Прослушиватели
Прослушиватели узнают конечные точки Kubernetes, чтобы пропускать трафик в поды. У сервиса проверки адреса здесь одна конечная точка:
Поэтому у пода проверки адреса один прослушиватель на порте 50051:
Маршруты
В Namely мы используем Istio Ingress-Gateway для всего внутреннего GRPC-трафика:
Если переадресовать порт пода Istio-IngressGateway и посмотреть конфигурацию Envoy, мы увидим, что делает VirtualService:
Что мы гуглили, копаясь в Istio
Возникает ошибка 503 или 404
Причины разные, но обычно такие:
Что означает NR/UH/UF в логах прокси Istio?
По поводу высокой доступности с Istio
Почему Cronjob не завершается?
Когда основная рабочая нагрузка выполнена, sidecar-контейнер продолжает работать. Чтобы обойти проблему, отключите sidecar в cronjobs, добавив аннотацию sidecar.istio.io/inject: “false” в PodSpec.
Как установить Istio?
Спасибо Bobby Tables и Michael Hamrah за помощь в написании поста.
Istio: обзор и запуск service mesh в Kubernetes
Istio- одна из реализацией концепии Service Mesh, позволяющая реализовать Service Discovery, Load Balancing, контроль над трафиком, canary rollouts и blue-green deployments, мониторить трафик между приложениями.
Мы будем использовать Istio в AWS Elastic Kubernetes Service для мониторинга трафика, в роли API gateway, разграничения трафика и, возможно, для реализации различных deployment strategies.
В этом посте рассмотрим что такое Service mesh вообще, общую архитектуру и компоненты Istio, его установку и настройку тестового приложения.
Перед тем, как рассматривать Istio – давайте разберёмся, что такое Service Mesh.
Service Mesh
По сути, это менеджер прокси-сервисов, таких как NGINX, HAProxy или Envoy, система, работающая на Layer 7 модели OSI и позволяющая динамически управлять трафиком и настраивать коммуникацию между приложениями.
Service mesh занимается обнаружением новых сервисов/приложений, балансировкой нагрузки, аутентификацией и шифрованием трафика.
Для контроля трафика в service mesh для каждого приложения, или в случае с Kubernetes – для каждого пода, запускается прокси-сервис называемый sidecar, и эти sidecar-сервисы проксируют и управляют трафиком.
Вместе эти sidecar-контейнеры представляют собой Data Plane.
Для их конфигурирования и управления существует другая группа процессов или сервисов, называемых Control Plane. Они занимаются обнаружением новых приложений, обеспечивают управление ключами шифрования, сбором метрик и т.д.
Схематично сервис меш можно отобразить так:
Среди Service mesh решений можно выделить:
Архитектура Istio
Итак, Istio как service mesh состоит из двух основных частей – Data plane и Control plane:
В целом схема Istio выглядит так:
Control Plane
Istio включает в себя четыре основных компонента:
Data Plane
Состоит из sidecar-контейнеров, которые в Kubernetes запускаются внутри подов через kube-inject, см. Installing the Sidecar.
Контейнеры являются инстансами Envoy-прокси, которые позволяют:
Модель сети Istio
Перед тем, как приступать к запуску и настройке приложения и Istio – кратко рассмотрим ресурсы, которые участвуют в управлении трафиком.
При установке Istio создаёт ресурс Ingress Gateway (и Egress Gateway, если было определено при установке) – новый объект в Kubernetes, который описывается в Kubernetes CRD при установке Istio.
В AWS при настройках по-умолчанию Ingress Gateway создаёт AWS Classic LoadBalancer, т.к. Ingress Gateway является Kubernetes-объектом Ingress с типом LoadBalancer.
“За” Ingress Gateway создаётся ресурс Gateway, который также описывается в Kubernetes CRD во время установки Istio и описывает хосты и порты, на которые будет отправляться трафик через этот Gateway.
Далее следует ещё один ресурс – VirtualService, который описывает маршрутизацию трафика, прошёдшего через Gateway, и отправляет его на Kubernetes Services следуя заданным Destination rules.
Ingress Gateway состоит из двух компонентов – Kubernetes Pod с инстансом Envoy, который управляет входящим трафиком, и Kubernetes Ingress, который принимает подключения.
В свою очередь Gateway и VirtualService управляют конфигурацией Envoy, который является Ingress Gateway controller.
Т.е. в целом схема прохождения пакета выглядит так:
Запуск Istio в Kubernetes
Istio поддерживает различные Deployment models. В нашем случае используется один EKS-кластер, а поды в нём работают в общей VPC сети.
Установить Istio можно разными способами – с помощью istioctl из манифест-файлов, из Helm-чарта, либо с помощью Ansible.
Также, стоит обратить внимание на Mutual TLS (mTLS) – см. Permissive mode. Если кратко, то по-умолчанию Istio устанавливается в Permissive mode, что позволяет уже существующим приложениям продолжать коммуникацию используя plaintext-трафик. При этом новые подключения через Envoy-контейнеры, sidecars, уже будут выполняться с TLS-шированием.
Пока выполним установку руками, а на Дев и Прод кластера Кубера скорее всего будем инсталить через Helm.
Генерируем kubeconfig для нового тестового кластера (для AWS EKS, если используется Minikube – он при старте сгенерирует конфиг сам):
Устанавливаем Istio с профилем default:
Проверяем версию ещё раз:
Далее задеплоим тестовое приложение, и настроим роутинг через Istio Ingress Gateway.
Тестовое приложение
Не будем использовать Bookinfo приложение из Istio Gettings Started, а напишем свой велосипед создадим свой Namespace, Deployment с одним подом с NGINX, и к нему Service – эмулируем миграцию уже имеющихся у нас приложений под управление Istio.
Кроме того, сейчас специально не будем настраваить добавление sidecar-контейнеров в приложение – вернёмся к этому вопросу чуть позже.
Манифест сейчас выглядит так:
Повышаем безопасность микросервисов с Istio
Всем привет! Меня зовут Илья, я работаю DevOps-инженером в команде разработки. Мы активно используем микросервисный подход, и, из-за специфики нашей работы, для нас важна безопасность межсервисного взаимодействия. В этой статье я хочу описать принцип работы Istio и на примере показать, как использовать некоторые ее возможности по обеспечению безопасности. Надеюсь, это окажется полезным для решения ваших задач. Приятного чтения!
Для чего вообще нужна сервисная сеть
Service mesh, в данном случае Istio – это обвязка для всего того, что требуется для управления и конфигурирования межсервисного взаимодействия: маршрутизация, аутентификация, авторизация, трассировка, контроль доступа и многое другое. И хотя существует масса открытых библиотек, чтобы реализовать эти функции непосредственно в коде сервиса, с Istio можно получить все то же самое, ничего не добавляя в сам сервис.
Компоненты
Istio логически разбита на плоскость данных (data plane) и плоскость управления (control plane).
Плоскость данных это совокупность прокси-серверов (Envoy), добавленных к pod’у в виде сайдкаров. Эти прокси-серверы обеспечивают и контролируют всю сетевую связь между микросервисами и конфигурируются из плоскости управления.
Плоскость управления (istiod) обеспечивает service discovery, настройку и управление сертификатами. Она конвертирует Istio объекты в понятные для Envoy конфигурации и распространяет их в плоскости данных.
Компоненты Istio service mesh
Добавить envoy в pod приложения можно как вручную, так и настроив автоматическое добавление с помощью Mutating Admission webhook, который Istio добавляет при своей установке. Для этого нужно проставить на необходимый неймспейс метку istio-injection=enabled.
2-3 мс, каждый envoy занимает порядка 40 Мб памяти, и потребление CPU возрастает в среднем на 5%-7% на pod.
Давайте на практике посмотрим, как сайдкар захватывает входящий и исходящий трафик из контейнера. Для этого взглянем на сетевое пространство какого-нибудь pod’а с добавленным Istio сайдкаром подробнее.
Для практических примеров я буду использовать свеже установленный Kubernetes кластер с Istio.
Локально развернуть Kubernetes несложно с помощью minikube:
Istio с demo профилем можно установить по документу с официального сайта:
Для примеров межсервисного взаимодействия я буду использовать два микросервиса: productpage и details. Они оба идут в стандартной поставке Istio для демонстрации ее возможностей.
Посмотрим список контейнеров приложения productpage:
Кроме самого productpage, в pod’е работают sidecar istio-proxy (тот самый envoy) и init контейнер istio-init.
Посмотреть на настроенные в пространстве имена pod’а iptables-правила можно с помощью утилиты nsenter. Для этого нам надо узнать pid процесса контейнера:
Теперь мы можем посмотреть правила iptables, установленные в этом контейнере.
Видно, что практически весь входящий и исходящий трафик теперь перехватывается и перенаправляется на порты, на которых его уже поджидает envoy.
Включаем взаимное шифрование трафика
Объекты Policy и MeshPolicy были удалены из istio 1.6. Вместо них предлагается использовать объект PeerAuthentication
Istio позволяет зашифровать весь трафик между контейнерами, причем сами приложения даже не будут знать, что общаются через tls. Делается это самим Istio из коробки буквально одним манифестом, так как в сайдкары-прокси уже смонтированы клиентские сертификаты.
Все тело и заголовки прекрасно читаемы в plain text.
Включим tls. Для этого создадим объект типа PeerAuthentication в неймспейсе с нашими pod’ами.
Запустим запрос из product page к details опять и посмотрим, что удастся получить:
Авторизация
Объекты ClusterRbacConfig, ServiceRole, and ServiceRoleBinding были удалены вместе с внедрением новой авторизационной политики. Вместо них предлагается использовать объект AuthorizationPolicy.
С помощью политик авторизации Istio может настраивать доступ одного приложения к другому. Причем, в отличие от чистых Kubernetes network policies, это работает на L7 уровне. Например, для http-трафика можно тонко управлять методами и путями запроса.
Как мы уже видели в предыдущем примере, по умолчанию доступ открыт для всех pod’ов всего кластера.
Теперь запретим все активности в неймспейсе default с помощью такого yaml-файла:
И попробуем достучаться до сервиса details:
Отлично, теперь наш запрос не проходит.
А теперь настроим доступ так, чтобы проходил только GET запрос и только по пути /details, а все остальные запросы отклонялись. Для этого есть несколько вариантов:
Для использования политик авторизации на основе сервис аккаунтов необходимо включить взаимную аутентификацию TLS.
Настраиваем новую политику доступа:
И пробуем достучаться вновь:
Все работает. Попробуем другие методы и пути:
Заключение
В заключение отмечу, что рассмотренные возможности это лишь малая толика того, что умеет Istio. Из коробки мы получили и настроили межсервисное шифрование трафика и авторизацию, правда, ценой добавления дополнительных компонентов и, следовательно, дополнительным расходом ресурсов.