какую роль выполняет proxy у каждой поды приложения
Введение в service mesh: основные функции и преимущества
Service mesh (буквально «сетка для сервисов») – это слой инфраструктуры, который позволяет вам управлять связью между микросервисами вашего приложения. Service mesh появились по мере распространения микросервисов в разработке, чтобы упростить и повысить эффективность работы за счет объединения общих задач управления и администрирования в распределенной установке.
Использование микросервисного подхода к архитектуре приложений подразумевает разбиение приложения на набор слабо связанных сервисов. Такой подход дает определенные преимущества: разработчики могут быстро выполнять итерации дизайна и масштабировать проект, используя более широкий спектр инструментов и языков. С другой стороны, микросервисы ставят новые задачи, связанные со сложностью обработки операций, согласованностью данных и безопасностью.
Service mesh предназначены для решения некоторых из этих проблем через тонкий контроль над взаимодействием сервисов друг с другом. В частности, они предлагают разработчикам управление:
Конечно, эти задачи можно выполнить при помощи встроенных функций систем оркестровки типа Kubernetes. Однако этот подход включает в себя больший объем принятия предварительных решений и администрирования по сравнению с тем, что предлагают решения service mesh, такие как Istio и Linkerd. В этом смысле service mesh могут упростить процесс работы с общими компонентами в микросервисной архитектуре. В некоторых случаях они могут даже расширить функциональность этих компонентов.
Зачем нужен service mesh?
Service mesh предназначен для решения некоторых проблем, присущих распределенным архитектурам приложений.
Эти архитектуры выросли из трехуровневой модели приложений, которая включает уровень клиента, логики и данных. В результате такая модель оказалась сложной для быстро растущих организаций. Кодовые базы монолитных приложений могут стать громоздкими, что создает проблемы в разработке и развертывании.
Чтобы решить эту проблему, такие организации, как Google, Netflix и Twitter, разработали внутренние библиотеки «толстых клиентов» для стандартизации операций в среде выполнения между сервисами. Эти библиотеки обеспечивали балансировку нагрузки, маршрутизацию и телеметрию – это предшественники service mesh. Однако они также наложили ограничения на языки, которые могли использовать разработчики, и требовали внесения изменений во все сервисы при собственном обновлении.
Микросервисный дизайн позволяет избежать некоторых из этих проблем. Вместо большой централизованной кодовой базы приложения у вас есть набор дискретно управляемых сервисов, которые представляют функцию вашего приложения. Преимущества микросервисного подхода:
Конечно, микросервисы также создали проблемы:
Service mesh предназначен для решения этих проблем, предлагая скоординированный и детальный контроль над взаимодействием сервисов. В следующих разделах мы расскажем, как service mesh облегчает обмен данными посредством обнаружения сервисов, маршрутизации и внутренней балансировки нагрузки, конфигурации трафика, шифрования, аутентификации и авторизации, а также метрик и мониторинга. Для примера мы будем использовать приложение Istio Bookinfo – четыре микросервиса, которые вместе отображают информацию о конкретных книгах.
Обнаружение сервисов
В распределенной среде необходимо знать, как подключаться к сервисам и доступны ли они. Расположение экземпляров сервиса в сети назначается динамически, и информация о них постоянно меняется по мере создания и уничтожения контейнеров в результате автоматического масштабирования, обновлений и сбоев.
Изначально существовало несколько инструментов для обнаружения сервисов в микросервисной инфраструктуре. Хранилища типа ключ-значение, такие как etcd, были объединены с другими инструментами, такими как Registrator, чтобы предложить средства для обнаружения сервисов. Такие инструменты, как Consul, объединили хранилище ключ-значение с интерфейсом DNS, который позволяет пользователям работать напрямую со своим DNS-сервером или нодой.
Используя подобный подход, Kubernetes предлагает обнаружение сервисов на основе DNS по умолчанию. С его помощью вы можете искать сервисы и сервисные порты, а также выполнять обратное преобразование IP, используя общие соглашения по именованию DNS. В общем случае запись A для сервиса Kubernetes соответствует такому шаблону:
Давайте посмотрим, как это работает в контексте приложения Bookinfo. Если, например, вам нужна информация о сервисе details приложения Bookinfo, вы можете посмотреть соответствующую запись в панели инструментов Kubernetes: Discovery and load balancing → Services → details.
Это даст вам соответствующую информацию о сервисе: его имя, пространство имен и ClusterIP, которое вы можете использовать для соединения с сервисом, даже если отдельные контейнеры будут уничтожены и созданы заново.
Service mesh типа Istio также предлагает возможности обнаружения сервисов. Для этого Istio использует связь между API Kubernetes, собственной плоскостью управления Istio (через компонент управления трафиком Pilot) и плоскостью данных, управляемой прокси-серверами Envoy. Pilot интерпретирует данные с сервера Kubernetes API для регистрации изменений в расположениях подов. Затем он переводит эти данные в каноническое представление Istio и перенаправляет их на сопровождающие прокси-серверы.
Это означает, что обнаружение сервисов в Istio не зависит от платформы, что мы можем увидеть, используя аддон Grafana для Istio.
Наше приложение работает в кластере Kubernetes, поэтому мы снова можем увидеть соответствующую информацию DNS о сервисе details, а также другие данные о производительности.
В распределенной архитектуре важно иметь актуальную, точную и удобную информацию о сервисах. И Kubernetes, и service mesh, такие как Istio, предлагают способы получения этой информации по соглашениям DNS.
Маршрутизация и настройка трафика
Управление трафиком в распределенной среде означает управление тем, как трафик попадает в ваш кластер и как он направляется на ваши сервисы. Чем больше контроля и специфики у вас есть при настройке внешнего и внутреннего трафика, тем тоньше вы сможете настроить эти процессы. Например, когда вы работаете с канареечными развертываниями, переносите приложения на новые версии или проводите стрессовое тестирование определенных сервисов с помощью внесения неисправностей, ключевым моментом для успешного проведения таких операций является возможность определить, какой объем трафика получают ваши сервисы и откуда он поступает.
Kubernetes предлагает различные инструменты, объекты и сервисы, которые позволяют разработчикам контролировать внешний трафик в кластере: прокси-сервер kubectl, NodePort, балансировщик нагрузки и контроллеры и ресурсы Ingress. kubectl proxy и NodePort позволяют вам быстро направлять внешний трафик на сервисы: kubectl proxy создает прокси-сервер, который обеспечивает доступ к статическому контенту по пути HTTP, а NodePort предоставляет случайно назначенный порт на каждой ноде. Это обеспечивает быстрый доступ, но есть и недостатки: необходимость запускать kubectl в качестве аутентифицированного пользователя (у kubectl proxy) и отсутствие гибкости в портах и IP-адресах нод (в случае NodePort). И хотя балансировщик нагрузки оптимизирует гибкость путем подключения к определенному сервису, для каждого сервиса требуется собственный балансировщик нагрузки, а это недешево.
Ingress Resource и Ingress Controller вместе обеспечивают большую степень гибкости и настраиваемости по сравнению с предыдущими средствами. Использование Ingress Controller с Ingress Resource позволяет направлять внешний трафик на сервисы и настраивать внутреннюю маршрутизацию и балансировку нагрузки. Чтобы использовать Ingress Resource, вам необходимо настроить ваши сервисы, Ingress Controller и LoadBalancer, а также сам Ingress Resource, который будет указывать желаемые маршруты для ваших сервисов. В настоящее время Kubernetes поддерживает собственный контроллер Nginx, но есть и другие варианты под управлением Nginx, Kong и др.
Istio выполняет итерацию по шаблону контроллер/ресурс Kubernetes с помощью шлюзов Istio и VirtualServices. Как и Ingress контроллеры, шлюз определяет, как должен обрабатываться входящий трафик, указывая используемые порты и протоколы. Он работает в сочетании с VirtualService, который определяет маршруты к сервисам внутри mesh. Оба этих ресурса передают информацию в Pilot, который затем передает ее на прокси Envoy. Хотя шлюзы и VirtualServices похожи на контроллеры и ресурсы Ingress, они предлагают другой уровень контроля над трафиком: вместо того чтобы объединять уровни и протоколы OSI, шлюзы и VirtualServices позволяют различать уровни OSI в ваших настройках. Например, используя VirtualServices, группы, работающие со спецификациями прикладного уровня, могут отделить задачи от групп безопасности, работающих со спецификациями другого уровня. VirtualServices позволяет разделить работу над отдельными функциями приложения или внутри разных доверенных доменов и может использоваться для таких вещей, как канареечное тестирование, постепенное развертывание, A/B-тестирование и т.п.
Чтобы визуализировать взаимосвязь между сервисами, вы можете использовать аддон Servicegraph от Istio. Оно создает динамическое представление взаимосвязей между сервисами с использованием данных трафика в реальном времени.
Также вы можете использовать инструмент визуализации, такой как Weave Scope, чтобы увидеть связь между сервисами в определенный момент времени.
При настройке трафика приложений в распределенной среде существует ряд различных решений – от нативных вариантов для Kubernetes до service mesh типа Istio, – которые предлагают разные варианты определения способа поступления внешнего трафика в приложение и взаимодействия этих ресурсов.
Шифрование, аутентификация и авторизация
В распределенной структуре могут появиться уязвимости безопасности. Вместо связи через локальные внутренние вызовы, как это бывает в монолитной установке, сервисы в микросервисной архитектуре передают информацию, в том числе и конфиденциальную, по сети. В целом, это создает благоприятные условия для хакерских атак.
Защита кластеров Kubernetes включает в себя целый ряд процедур; мы сосредоточимся на аутентификации, авторизации и шифровании. Kubernetes предлагает нативные подходы к каждой процедуре.
Конфигурирование отдельных политик и протоколов безопасности в Kubernetes требует административных затрат. Service mesh типа Istio может объединить некоторые из этих задач.
Istio предназначен для автоматизации работ по обеспечению безопасности сервисов. Его плоскость управления включает в себя несколько компонентов, обеспечивающих безопасность:
Например, при создании сервиса Citadel получает эту информацию от kube-apiserver и создает для сервиса сертификаты и ключи SPIFFE. Затем он передает эту информацию в поды и сопровождающие контейнеры Envoy для облегчения связи между сервисами.
Вы также можете реализовать некоторые функции безопасности, включив взаимный TLS во время установки Istio. К ним относятся надежные сервисные идентификаторы для межкластерной связи, защищенного соединения между сервисами и пользователями и система управления ключами, которая может автоматизировать создание, распространение и ротацию ключей и сертификатов.
Итерируя методы Kubernetes для обработки аутентификации, авторизации и шифрования, service mesh типа Istio могут реализовать рекомендуемые условия работы защищенного кластера Kubernetes.
Метрики и мониторинг
Распределенные среды изменили требования к метрикам и мониторингу. Инструменты мониторинга должны быть адаптивными, учитывать частые изменения в сервисах и сетевых адресах и позволять учитывать объем и тип информации, передаваемой между сервисами.
Kubernetes включает в себя некоторые инструменты внутреннего мониторинга по умолчанию. Эти ресурсы принадлежат конвейеру метрик ресурсов, который обеспечивает работу кластера. Компонент cAdvisor собирает данные об использовании сети, памяти и ЦП из отдельных контейнеров и нод и передает эту информацию в kubelet; kubelet, в свою очередь, предоставляет эту информацию через REST API. Metrics Server получает эту информацию от API и затем передает ее в kube-aggregator для форматирования.
Вы можете расширить эти внутренние инструменты и возможности мониторинга с помощью полноценного средства для сбора метрик. Агрегатор метрик Prometheus можно установить прямо поверх конвейера метрик ресурсов Kubernetes. Prometheus напрямую интегрируется с cAdvisor через своих собственных агентов, расположенных на нодах. Его основной сервис агрегации собирает и хранит данные с нод и предоставляет данные через дашборды и API. Также доступны дополнительные опции хранения и визуализации (если вы решите интегрировать основной сервис агрегирования с такими внутренними инструментами хранения, логирования и визуализации, как InfluxDB, Grafana, ElasticSearch, Logstash, Kibana и другие).
С помощью этих метрик и инструментов визуализации вы можете получить централизованный доступ к текущей информации о сервисах и рабочих нагрузках.
Реплицируя структуру конвейера метрик Kubernetes и упрощая доступ к некоторым из его компонентов, service mesh упрощает процесс сбора и визуализации данных при работе с кластером.
Заключение
Микросервисные архитектуры предназначены для быстрой и надежной разработки и развертывания приложений. Тем не менее, рост межсервисных коммуникаций изменил рекомендации для определенных административных задач. В этой статье мы рассмотрели некоторые из этих задач, их обработку в нативном для Kubernetes контексте и управление ими с помощью service 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.