[Перевод] Istio Service Mesh: как упростить управление микросервисами16.02.2023 13:16

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

• Как маршрутизируются запросы между службами?

• Как обеспечить безопасность связи?

• Как обнаружить сбои и время простоя?

• Как обновить и протестировать новые версии сервиса?

• Приложения не запускаются в среде green field.

• Проблемы возникают в сети между службами.

• Layer N/w сложно поддается управлению.

Для решения всех этих проблем применяется Service Mesh.

Проблемы, решаемые с помощью Service Mesh:

Service Mesh — это выделенный инфраструктурный уровень, который вы можете добавить в свои приложения. Он позволяет вам прозрачно добавлять такие возможности, как наблюдаемость, управление трафиком и безопасность, не добавляя их в свой собственный код. Термин «service mesh» описывается как тип программного обеспечения, которое вы используете для реализации этого шаблона, так и безопасность или сетевой домен, который создается при использовании этого программного обеспечения.

Ранее бизнес-логика и сеть были объединены в одно целое. Таким образом, разработчикам пришлось писать код для mTLS или circut breaker и многих других функциональных возможностей, что отнимало так много времени, что они не могли сосредоточиться на бизнес-логике. Но использование Service Mesh прокси sidecar отделяет бизнес-логику от сети и позволяет разработчикам собственно сосредоточиться на бизнес-логике, а Istio управляет прокси-сервером envoy.

На рынке существует множество Service mesh, но мы привыкли к Istio, поскольку он пользуется популярностью. Он логически разделен на control plane и data plane.

Data plane — это связь между службами. Без Service mesh сеть не понимает передаваемый трафик и не может принимать никаких решений, основанных на том, какой это тип трафика или от кого он поступает.

Service mesh использует прокси-сервер для перехвата всего вашего сетевого трафика, предоставляя широкий набор функций, зависящих от приложения, в зависимости от заданной вами конфигурации.

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

Control plane принимает желаемую конфигурацию и свое представление о службах и динамически конфигурирует прокси-серверы, обновляя их по мере изменения правил или среды.

Приложение для книжного магазина, использующее Istio

Описание:

Приложение отображает информацию о записи книги в книжном интернет-магазине. На странице товара отображается описание книги, сведения о книге (ISBN, количество страниц и так далее) и несколько рецензий на книги.

Приложение Bookinfo разбито на четыре отдельных микросервиса:

1.productpage. Микросервис страницы продукта вызывает микросервисы сведений и обзоров для заполнения страницы.

2. details. Микросервис details содержит информацию о книге.

3. reviews. Микросервис reviews содержит обзоры книг. Он также вызывает микросервис ratings.

4. ratings. Микросервис ratings содержит информацию о ранжировании книг, которая сопровождает рецензию на книгу.

Существует 3 версии микросервиса отзывов:

a.Version v1 ==> не вызывает сервис рейтингов.

b.Version v2 ==> вызывает сервис рейтингов и отображает каждый рейтинг в виде от 1 до 5 черных звезд.

c.Version v3 ⇒ вызывает сервис рейтингов и отображает каждый рейтинг в виде от 1 до 5 красных звезд.

Architecture of the BookStore Application:

Пример приложения без Istio

Чтобы запустить приложение с помощью istio, нам просто нужно настроить и запустить службы в среде с поддержкой Istio, при этом сайдкар-прокси Envoy будут встроены в каждый микросервис.

Установка Istio по умолчанию использует automatic sidecar injection. Установите метку на пространство имен default, в котором будет размещаться приложение, вида istio-injection=enabled:

kubectl label namespace default istio-injection=enabled

Все микросервисы будут дополнены Envoy sidecar, который перехватывает входящие и исходящие вызовы для сервисов, предоставляя hooks, необходимые для внешнего управления, через control plane Istio, роутинг, сбор телеметрии и применения политики для приложения в целом.

Развертывание служб приложений (установка на GKE)

1. Перейдите на страницу Istio, чтобы загрузить установочный файл для вашей ОС и перейдите в каталог пакетов Istio. Добавьте клиент istioctl в свой path (Linux или macOS):

a. Включите Google Kubernetes Engine API.

b. Создайте кластер GKE: gcloud container clusters create istio-gke-capability — region us-central1 — node-locations us-central1-a — num-nodes 2 — machine-type=n1-standard-2 

Получите учетные данные для вашего нового кластера : gcloud container clusters get-credentials istio-gke-capability — region=us-central1 — project=sincere-bongo-349311

d. curl -L https://istio.io/downloadIstio | sh —

e. cd istio-1.14.1

f. export PATH=$PWD/bin:$PATH

istioctl install --set profile=default -y

2. Проверьте, что поды прокси-сервера envoy запущены в пространстве имен istio-system. (по умолчанию установлены компоненты istiod и istio-ingressgateway)

kubectl get ns

kubectl get pods -n istio-system

3. Добавьте метку на пространства имен, чтобы проинструктировать Istio автоматически добавлять прокси-серверы Envoy sidecar при последующем развертывании вашего приложения:

kubectl label namespace default istio-injection=enabled

4. Разверните приложение BookStore (содержит страницу продукта, подробную информацию, микросервис обзора и оценки)

Этот микросервис уже присутствует по этому пути

kubectl apply -f bookinfo.yaml

Вы можете проверить, что в каждом поде запущено по 2 контейнера. Один из них — прокси-сервер envoy sidecar, а другой — микросервис. Вы можете проверить это, используя команду describe

kubectl describe pod [pod-name]

kubectl получает услуги

5. Убедитесь, что до этого момента все работало правильно. Запустите эту команду, чтобы проверить, запущено ли приложение внутри кластера и обслуживает ли HTML-страницы, проверив заголовок страницы в ответе:

Возвращает заголовок HTML-страницы продукта

kubectl exec »$(kubectl get pod -l app=ratings -o jsonpath=»{.items[0].metadata.name}»)» -c ratings — curl -sS productpage:9080/productpage | grep -o »»

6. Нам нужно изменить тип сервиса istio-ingressgateway с «LoadBalancer» на «ClusterIP»

Проверим, что тип сервиса изменился с LoadBalancer на ClusterIP

Схема архитектуры приложения Book Info, доступного с помощью TCP Load balancer

Чтобы управлять внешним трафиком, вам нужен load balancer, который является внешним по отношению к mesh

По умолчанию Google Cloud развертывает общедоступный load balancer TCP/UDP. Load balancer прослушивает порт 80 и перенаправляет трафик на IstioIngressGateway. 

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

Хотя, как мы видим, используется load balancer TCP/UPD по умолчанию с Istio ServiceMesh, у него нет дополнительных функций, которыми обладает Global Http Load Balancer.

Преимущества внешнего HTTP load balancer

• Это глобальный load balancer, который реализован как управляемый сервис на Google Front Ends. Он работает на Layer 7.

• TCP Load Balancer является региональным и работает на Layer L4, в то время как HTTP load balancer является глобальным и работает на уровне L7 (Application Layer).

• Защита от DDoS-атак и фильтрация трафика на стыке с помощью Google Cloud Armor.

• Функциональность шлюза API с IAP.

• Он поддерживает расширенные возможности управления трафиком, такие как:

• зеркальное отображение трафика, разделение трафика на основе веса, преобразования заголовков на основе запроса/ответа;

• Может получать доступ к бэкендам в нескольких регионах;

Автоматическое создание и ротация общедоступных сертификатов с помощью сертификатов, управляемых Google.

Предоставление доступа к приложениям servicemesh через Ingress (глобальный load balancer HTTPS L7)

a. Добавьте аннотации в Istio-Ingress Gateway svc

Этот сервис имеет следующие аннотации, которые задают параметры для балансировщика нагрузки Ingress при его развертывании:

cloud.google.com/backend-config ссылается на имя пользовательского ресурса, называемого Backend Config. Ingress Controller использует Backend Config для установки параметров на ресурсе backend сервиса Google Cloud. Вы используете этот ресурс на следующем шаге для определения пользовательских параметров проверки работоспособности Google Cloud.

cloud.google.com/neg:»{«ingress»: true}» включает серверные части Ingress (в данном случае прокси-серверы mesh ingress) для load balancer внутри контейнера. Для более эффективной и стабильной балансировки нагрузки эти backend части используют группы конечных точек сети (NEGS) вместо групп экземпляров.

cloud.google.com/app-protocols:»{«https»: «HTTP2»}» направляет GFE для подключения к входному шлюзу service mesh, используя HTTP2 с TLS, как описано в Ingress для внешних HTTP. Load balancer, и внешние HTTP (ы) load balancer анализируют дополнительный уровень шифрования.

b. Примените настройки backend сервиса

Backend Config — это Custom Resource Definition (CRD), которое определяет параметры бэкэнда для балансировки нагрузки Ingress. Необходимы особенные настройки проверок работоспосбоности (хелсчеков), так как ингресс прокси сервис меша использует порт 443, отличный от стандартного порта для проверок 15021. GKE Ingress использует следующие параметры проверки работоспособности в BackendConfig для настройки проверок работоспособности Google Cloud load balancer.

healthCheck.port определяет порт, который используется с IP-адреса каждого пода для проверки работоспособности балансировщиком Google Cloud.

healthCheck.requestPathопределяет HTTP-путь, по которому выполняется проверка работоспособности указанного порта.

typeопределяет протокол проверки работоспособности (в данном случае HTTP).

Аннотации сервисов не применяются к Google Cloud load balancer до тех пор, пока не будет развернут ресурс Ingress. Применение Ingress связывает все эти ресурсы воедино.

c. Установка TLS managed сертификата

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

Проверьте ресурс ManagedCertificate, чтобы проверить ход выпуска сертификата:

kubectl describe managedcertificate gke-ingress-cert -n istio-system

d. Разверните ресурс Ingress

Этот манифест определяет ресурс типа Ingress, который связывает все предыдущие ресурсы вместе. В манифесте указаны следующие поля:

kubernetes.io/ingress.allow-http: «false» отключает HTTP-трафик на порту 80 балансировщика нагрузки Google Cloud. Это эффективно предотвращает подключение любых клиентов с незашифрованным трафиком, поскольку порт 443 прослушивает только HTTPS, а порт 80 отключен.

kubernetes.io/ingress.global-static-ip-name: «istio-lb» связывает ранее созданный IP-адрес с балансировщиком нагрузки. Эта ссылка позволяет создавать IP-адрес отдельно от Load Balancer, чтобы его можно было повторно использовать отдельно от жизненного цикла Load Balancer.

networking.gke.io/managed-certificates: «gke-ingress-cert» связывает этот балансировщик нагрузки с ранее созданным ресурсом SSL-сертификата, управляемым Google.

Мы подключили эластичный ip-адрес к HTTP Load Balancer.

e. Настройте ingress gateway

Gateway описывает балансировщик нагрузки, работающий на границе service mesh, принимающий входящие или исходящие HTTP/TCP соединения. Спецификация описывает набор портов, которые должны быть открыты, тип используемого протокола, конфигурацию SNI для балансировщика нагрузки и т.д.

Следующая конфигурация Gateway настраивает прокси-сервер для выполнения функций балансировщика нагрузки, предоставляя доступ к порту 80 (http) для входа. Gateway будет применен к прокси, работающему на поде с лейблом (меткой) istio: ingress gateway. В то время как Istio настроит прокси для прослушивания этих портов, пользователь несет ответственность за обеспечение того, чтобы внешний трафик к этим портам был разрешен в mesh.

f. Настройте Virtual Service для отправки маршрутов трафика микросервисам

Затем VirtualService может быть привязан к gateway для управления пересылкой трафика, поступающего на определенный хост или порт gateway. Он определяет набор правил маршрутизации трафика, которые применяются при обращении к хосту. Каждое правило маршрутизации определяет критерии соответствия для трафика определенного протокола. Если трафик подходит, то он отправляется в конкретный сервис-назначение (или его какое-то подмножество или конкретную версию), определенный в реестре сервисов.

Следующая виртуальная служба перенаправляет все HTTP-запросы с путей, начинающихся с »/productpage» ,»/static» ,»/login» ,»/api/v1/products» ,»/logout» на сервис productpage.

Наконец, приложение BookInfo доступно.

Теперь вы можете увидеть 3 версии микросервиса рейтинга

Когда пользователи отправляют запросы на HTTP Load Balancer, к которому привязан статический IP. Управляемый сертификат GCP прикреплен к HTTP Load Balancer, который обеспечивает конфиденциальность и безопасность при пересылке трафика пользователями. В GKE объект Ingress определяет правила маршрутизации HTTP-трафика. Таким образом, когда вы создаете объект Ingress, контроллер входа GKE создает глобальный балансировщик нагрузки HTTP.

Балансировщик нагрузки HTTP (S) прослушивает порт 443 и пересылает запрос одному из рабочих узлов.

Объект Ingress имеет правила, определенные для маршрутизации http-трафика в службу istio-ingressgateway.

Служба istio-ingressgateway делает HTTP Load Balancer исправен путем настройки BackendConfig на порту 15021. Он перенаправляет запрос на развертывание Istio-IngressGateway.

Деплоймент Istio-IngressGateway настраивается при помощи объектов типа Gateway и VirtualService.

Gateway настраивает порты, протоколы и сертификаты. VirtualService настраивает информацию о маршруте для поиска правильной службы.

Деплоймент Istio-IngressGateway направляет запрос на прокси-сервер Envoy, который перенаправляет запрос в сервис productpage.

Установка функции дополнений Istio (Kiali, Jaeger, Prometheus…)

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

kubectl apply -f samples/addons

kubectl get pods -n istio-system

Prometheus и Grafana: с Istio для записи показателей, отслеживающих работоспособность Istio и приложений в service mesh, и Grafana для визуализации

Kiali: для понимания структуры и работоспособности service mesh через отслеживание потока трафика для определения топологии mesh и сообщений об ошибках

Jaeger: позволяет пользователям отслеживать транзакции в сложных распределенных системах и устранять неполадки в них.

Доступ к Kiali с помощью переадресации портов: kubectl port-forward svc/kiali 20001:20001 -n istio-system

Чтобы увидеть трассировку, вы должны отправить запрос в свой сервис :

for i in $(seq 1 1000); do curl -s -o /dev/null "https://test.istio.online/productpage"; done

Доступ к Jaeger: kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath=»{.items[0].metadata.name}») 16686:16686 &

Доступ к Grafana: kubectl port-forward svc/grafana 3000:3000 -n istio-system

Разделение трафика, при котором 100% запроса трафика будет отправляться на под review v1 (микросервис) и 0% трафика на другие поды v2 и v3.

Шаги:  

a. Перейдите на страницу сведений о микросервисе reviews

b. Нажмите на Actions + Traffic Shifting, добавьте 100% трафика в v1 и 0% в v2 и v3 и нажмите Create

c. Из консоли Kiali автоматически будут созданы соответствующие VirtualService и DestinationRule

VirtualService: определяет набор правил маршрутизации трафика для применения к сервису kubernetes или подмножеству сервисов на основе какого-либо перечня критериев.

DestinationRule: оно определяет политики, которые применяются к трафику, предназначенному конкретному сервису, после выполнения маршрутизации.

Пример разделения трафика, отправка 100% трафика на микросервис reviews v1

Теперь вы можете увидеть примененные VirtualService и DestinationRule!

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

Старт практического интенсива по service mesh 24 марта.

Создание смещения трафика, при котором 70% запросов трафика будет направляться на под сервиса Review v1 (микросервис) и 30% трафика на другие поды v2 и 0% трафика на поды v3.

Из панели мониторинга Kiali (версионный график) вы можете видеть, что 70% трафика поступает на микросервис Reviews v1 и 30% — на микросервис Reviews v2.

Теперь вы знаете, как маршрутизировать запросы между службами, обеспечить безопасность связи, обнаружить сбои и время простоя, а также обновить и протестировать новые версии сервиса, и как именно Service Mesh помогает решить эти проблемы.

Узнать о best practices в работе с service mesh

© Habrahabr.ru