Введение в service mesh: основные функции и преимущества

25 февраля, 2019 11:45 дп 5 751 views | Комментариев нет

| | Комментировать запись

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

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

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

  • Обнаружением сервисов
  • Маршрутизацией и настройкой трафика
  • Шифрованием и аутентификацией/авторизацией
  • Метриками и мониторингом

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

Зачем нужен service mesh?

Service mesh предназначен для решения некоторых проблем, присущих распределенным архитектурам приложений.

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

Чтобы решить эту проблему, такие организации, как Google, Netflix и Twitter, разработали внутренние библиотеки «толстых клиентов» для стандартизации операций в среде выполнения между сервисами. Эти библиотеки обеспечивали балансировку нагрузки, маршрутизацию и телеметрию – это предшественники service mesh. Однако они также наложили ограничения на языки, которые могли использовать разработчики, и требовали внесения изменений во все сервисы при собственном обновлении.

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

  • Повышенная гибкость в разработке и развертывании (поскольку группы могут независимо работать и развертывать различные функции приложений).
  • Улучшенные функции CI/CD, поскольку отдельные микросервисы можно протестировать и перераспределить независимо.
  • Дополнительные параметры для языков и инструментов. Разработчики могут использовать лучшие инструменты для выполнения поставленных задач, а не ограничиваться определенным языком или набором инструментов.
  • Легкость в масштабировании.
  • Улучшения в среде выполнения и пользовательском опыте, стабильность.

Конечно, микросервисы также создали проблемы:

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

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

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

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

Изначально существовало несколько инструментов для обнаружения сервисов в микросервисной инфраструктуре. Хранилища типа ключ-значение, такие как etcd, были объединены с другими инструментами, такими как Registrator, чтобы предложить средства для обнаружения сервисов. Такие инструменты, как Consul, объединили хранилище ключ-значение с интерфейсом DNS, который позволяет пользователям работать напрямую со своим DNS-сервером или нодой.

Используя подобный подход, Kubernetes предлагает обнаружение сервисов на основе DNS по умолчанию. С его помощью вы можете искать сервисы и сервисные порты, а также выполнять обратное преобразование IP, используя общие соглашения по именованию DNS. В общем случае запись A для сервиса Kubernetes соответствует такому шаблону:

service.namespace.svc.cluster.local

Давайте посмотрим, как это работает в контексте приложения 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 предлагает нативные подходы к каждой процедуре.

  • Аутентификация: запросы API в Kubernetes привязаны к учетным записям пользователей или сервисов, которые необходимо аутентифицировать. Существует несколько различных способов управления учетными данными: статические токены, токены начальной загрузки, клиентские сертификаты X509 и внешние инструменты, такие как OpenID Connect.
  • Авторизация: Kubernetes имеет различные модули авторизации, которые позволяют определять доступ на основе ролей, атрибутов и других специализированных функций. Поскольку все запросы к серверу API по умолчанию отклоняются, каждая часть запроса API должна определяться политикой авторизации.
  • Шифрование может относиться к соединениям между конечными пользователями и сервисами, секретным данным, конечным точкам в плоскости управления Kubernetes и связь между компонентами рабочего кластера и главными компонентами. Kubernetes имеет различные решения:

Конфигурирование отдельных политик и протоколов безопасности в Kubernetes требует административных затрат. Service mesh типа Istio может объединить некоторые из этих задач.

Istio предназначен для автоматизации работ по обеспечению безопасности сервисов. Его плоскость управления включает в себя несколько компонентов, обеспечивающих безопасность:

  • Citadel: управляет ключами и сертификатами.
  • Pilot: контролирует политику аутентификации и именования и передает эту информацию прокси-агентам Envoy.
  • Mixer: управляет авторизацией и аудитом.

Например, при создании сервиса 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 и другие).

В service mesh, таком как Istio, структура конвейера полной метрики является частью дизайна. Сопроводители Envoy, работающие на уровне подов, передают метрики в Mixer, который управляет политиками и телеметрией. Кроме того, сервисы Prometheus и Grafana включены по умолчанию (хотя, если вы устанавливаете Istio с Helm , вам нужно будет указать granafa.enabled=true во время установки). Вы также можете настроить другие сервисы и развертывания для логирования и просмотра параметров.

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

Реплицируя структуру конвейера метрик Kubernetes и упрощая доступ к некоторым из его компонентов, service mesh упрощает процесс сбора и визуализации данных при работе с кластером.

Заключение

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

Читайте также:

Tags: , ,

Добавить комментарий