Введение в сервисные сетки

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

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

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

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

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

Эти архитектуры выросли из трехуровневой модели приложений, которая делит приложения на веб-уровень, уровень приложений и уровень базы данных. В масштабе, эта модель оказалась сложной для организаций, испытывающих быстрый рост. Базы кода монолитных приложений могут вырасти до громоздких“big balls of mud”, что создает проблемы для разработки и развертывания.

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

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

В то же время, микросервисы также создали проблемы:

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

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

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

Используя подобный подход, Kubernetes предлагает обнаружение службы на основе DNS по умолчанию. С его помощью вы можете искать сервисы и сервисные порты, а также выполнять обратный поиск IP, используя общие соглашения по именованию DNS. В общем, запись A для сервиса Kubernetes соответствует этому шаблону:service.namespace.svc.cluster.local. Давайте посмотрим, как это работает в контексте приложения Bookinfo. Если, например, вам нужна информация о службеdetails из приложения Bookinfo, вы можете посмотреть соответствующую запись на панели управления Kubernetes:

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

Сетка сервисов, такая как Istio, также предлагает возможности обнаружения сервисов. Для обнаружения сервисов Istio полагается на связь между Kubernetes API, собственной плоскостью управления Istio, управляемой компонентом управления трафикомPilot, и ее плоскостью данных, управляемой дополнительными прокси-серверамиEnvoy. Pilot интерпретирует данные с сервера API Kubernetes для регистрации изменений в расположениях Pod. Затем он переводит эти данные в каноническое представление Istio и перенаправляет их на прокси коляски.

Это означает, что обнаружение служб в Istio не зависит от платформы, что мы можем увидеть, используяGrafana add-on Istio, чтобы снова взглянуть на службуdetails на панели управления службами Istio:

Наше приложение работает в кластере Kubernetes, поэтому мы снова можем видеть соответствующую информацию DNS о службеdetails вместе с другими данными о производительности.

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

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

Kubernetes предлагает различные инструменты, объекты и сервисы, которые позволяют разработчикам контролировать внешний трафик в кластер:kubectl proxy,NodePort,Load Balancers иIngress Controllers and Resources. Иkubectl proxy, иNodePort позволяют вам быстро предоставлять свои сервисы внешнему трафику:kubectl proxy создает прокси-сервер, который разрешает доступ к статическому контенту по пути HTTP, аNodePort предоставляет случайно назначенный порт на каждом узле. Хотя это обеспечивает быстрый доступ, к недостаткам относится необходимость запускаkubectl в качестве аутентифицированного пользователя в случаеkubectl proxy и отсутствие гибкости в портах и ​​IP-адресах узлов в случаеNodePort. с. И хотя балансировщик нагрузки оптимизируется для обеспечения гибкости путем подключения к определенной службе, для каждой службы требуется собственный балансировщик нагрузки, который может быть дорогостоящим.

Ingress Resource и Ingress Controller вместе обеспечивают большую степень гибкости и настраиваемости по сравнению с этими другими параметрами. Использование Ingress Controller с Ingress Resource позволяет направлять внешний трафик в Services и настраивать внутреннюю маршрутизацию и балансировку нагрузки. Чтобы использовать Ingress Resource, вам необходимо настроить ваши сервисы, Ingress Controller иLoadBalancer, а также сам Ingress Resource, который будет указывать желаемые маршруты к вашим сервисам. В настоящее время Kubernetes поддерживает собственныйNginx Controller, но есть и другие варианты, которые вы также можете выбрать, управляемыеNginx,Kong и другими.

Istio повторяет шаблон Kubernetes Controller / Resource сIstio Gateways иVirtualServices. Как и Ingress Controller, шлюз определяет порядок обработки входящего трафика, указывая открытые порты и протоколы для использования. Он работает в сочетании с VirtualService, который определяет маршруты к Сервисам в сетке. Оба этих ресурса передают информацию Пилоту, который затем передает эту информацию доверенным лицам Посланника. Хотя они похожи на контроллеры и ресурсы Ingress, шлюзы и VirtualServices предлагают другой уровень контроля над трафиком: вместо объединенияOpen Systems Interconnection (OSI) layers and protocols, шлюзы и VirtualServices позволяют вам различать уровни OSI в ваших настройках. Например, с помощью VirtualServices группы, работающие со спецификациями уровня приложений, могут отделить интересы от групп операций по безопасности, работающих с разными спецификациями уровня. Виртуальные сервисы позволяют разделить работу над отдельными функциями приложения или внутри разных доверенных доменов и могут использоваться для таких вещей, как канареечное тестирование, постепенное развертывание, A / B-тестирование и т. Д.

Чтобы визуализировать взаимосвязь между Сервисами, вы можете использовать IstioServicegraph add-on, который производит динамическое представление взаимосвязи между Сервисами с использованием данных трафика в реальном времени. Приложение Bookinfo может выглядеть так без применения какой-либо настраиваемой маршрутизации:

Точно так же вы можете использовать инструмент визуализации, напримерWeave Scope, чтобы увидеть взаимосвязь между вашими Сервисами в данный момент времени. Приложение Bookinfo без расширенной маршрутизации может выглядеть так:

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

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

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

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

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

Например, когда вы создаете Сервис, Citadel получает эту информацию отkube-apiserver и создает сертификаты и ключиSPIFFE для этого Сервиса. Затем он передает эту информацию в коляски Pods и Envoy для облегчения связи между Сервисами.

Вы также можете реализовать некоторые функции безопасности с помощьюenabling mutual TLS во время установки Istio. К ним относятся надежные сервисные идентификаторы для межкластерной и межкластерной связи, защищенная связь между сервисами и между пользователями и система управления ключами, которая может автоматизировать создание, распространение и ротацию ключей и сертификатов.

Итерируя, как Kubernetes обрабатывает аутентификацию, авторизацию и шифрование, сервисные сетки, такие как Istio, могут консолидировать и расширять некоторые из рекомендуемых лучших практик для работы безопасного кластера Kubernetes.

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

Kubernetes включает в себя некоторые инструменты внутреннего мониторинга по умолчанию. Эти ресурсы принадлежат егоresource metrics pipeline, что гарантирует правильную работу кластера. КомпонентcAdvisor собирает статистику использования сети, памяти и ЦП от отдельных контейнеров и узлов и передает эту информацию в kubelet; kubelet, в свою очередь, предоставляет эту информацию через REST API. Metrics Server получает эту информацию от API и затем передает ееkube-aggregator для форматирования.

Вы можете расширить эти внутренние инструменты и возможности мониторинга с помощью полного решения для показателей. Использование такой службы, какPrometheus, в качестве агрегатора метрик, позволяет создавать непосредственно поверх конвейера метрик ресурсов Kubernetes. Прометей напрямую интегрируется с cAdvisor через своих собственных агентов, расположенных на узлах. Его основной сервис агрегации собирает и хранит данные с узлов и предоставляет их через информационные панели и API. Дополнительные параметры хранения и визуализации также доступны, если вы решите интегрировать свою основную службу агрегации с внутренними средствами хранения, ведения журнала и визуализации, такими какInfluxDB,Grafana,ElasticSearch,Logstash. ,Kibana и другие.

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

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

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

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

Для получения дополнительной информации по некоторым темам Kubernetes, рассмотренным здесь, см. Следующие ресурсы:

Кроме того, центры документацииKubernetes иIstio - отличное место для поиска подробной информации по обсуждаемым здесь темам.