Розгортання Istio на Amazon EKS для вдосконаленого керування Service Mesh.

У цій статті ми реалізуємо всі теоретичні концепції, описані в моїй попередній статті, ‘Розбір концепцій Service Mesh.’ Якщо ви ще не читали її, рекомендую це зробити, особливо якщо ви новачок у цій області. Почнемо!

Огляд архітектури Istio

Архітектура service mesh допомагає спростити проблеми, з якими розробники та оператори часто стикаються у розподілених або мікросервісних системах. Istio побудована навколо двох основних компонентів: Data plane та Control plane.

Data plane:

Data plane (плани даних) відповідає за комунікацію між сервісами, покращуючи спосіб, у який мережа обробляє та розуміє трафік, перехоплюючи його. Istio використовує розширену версію Envoy Proxy, яка перехоплює весь мережевий трафік і надає різні можливості, залежно від налаштованих правил. Ці проксі-сервери Envoy розгортаються поруч із кожним сервісом у вашому кластері Amazon EKS, що забезпечує ефективне управління трафіком.

Control plane:

Control plane (управлінська плита) приймає налаштування, які ви визначаєте, і програмує проксі Envoy, базуючись на розумінні сервісів. Вона постійно оновлює проксі, щоб обробляти зміни в правилах або адаптуватися до змін середовища, забезпечуючи безперебійну та безпечну комунікацію між сервісами у вашій мікросервісній архітектурі.

https://istio.io/latest/about/service-mesh/

Istio на Amazon EKS

Ми використаємо цю статтю від AWS як посилання для нашого пояснення. Якщо ви хочете отримати більше деталей, не соромтеся звертатися до неї.

• Почнемо з розгортання додатків на Amazon EKS, закладаючи основу для надійної та масштабованої інфраструктури.
• Далі інтегруємо ці додатки в mesh-сервіс Istio, дозволяючи потужні можливості для управління трафіком, безпеки та спостереження.
• Також розглянемо, як керувати вхідним трафіком на межі вашого service mesh, використовуючи Istio Ingress Gateway та AWS Network Load Balancer, забезпечуючи безпечний та контрольований доступ до ваших сервісів.
• Покажемо, як точно контролювати вхідний HTTP трафік і перенаправляти його до правильного сервісу в Istio.
• Нарешті, ми використаємо інструменти візуалізації, такі як Kiali, Prometheus, і Grafana.

Архітектура демонстрації

Додаток, який ми будемо розгортати на EKS, ви можете знайти в цьому GitHub репозиторії.

Додаток складається з трьох мікросервісів: Frontend, Product Catalog і Catalog Detail.

Розглянемо діаграму нижче:

https://aws.amazon.com/blogs/opensource/getting-started-with-istio-on-amazon-eks/

1. EKS: Інфраструктура хоститься в AWS за допомогою кластера EKS, а Managed Node Group розгортається в межах EKS.
2. NLB: Зовнішній трафік потрапляє в систему через Network Load Balancer (NLB), який обробляє початковий трафік до компонента Istio Ingress Gateway.
3. Istio Ingress Gateway: діє як точка входу до service mesh та маршрутизує вхідний трафік до відповідних сервісів.
4. Istio Service Mesh: Це складається з Envoy проксі, які розгортаються поруч з кожним мікросервісом (Frontend, Product Catalog, Catalog Detail v1, і Catalog Detail v2). Проксі обробляють комунікацію між сервісами, управління трафіком, безпеку та спостереження.
   5.
   Мікросервіси: Frontend: Сервіс, що взаємодіє з користувачем і працює з сервісами Product Catalog та Catalog Detail. Product Catalog: Сервіс, що відповідає за управління інформацією про продукти. Catalog Detail v1 та v2: Дві версії сервісу Catalog Detail, ймовірно для версіонування або canary deployments (канаркових випусків).
5. Mesh Traffic (зелені стрілки): Трафік між сервісами проходить через проксі Envoy.
6. Control Plane до Envoy Traffic (сині пунктирні стрілки): Управлінська плита налаштовує та керує проксі Envoy.
7. Інструменти спостереження: Архітектура інтегрує інструменти для моніторингу та візуалізації - Kiali: Надає графічне представлення service mesh та потоку трафіку. Prometheus: Збирає метрики з проксі Envoy та компонентів Istio. Grafana: Візуалізує зібрані метрики на налаштовуваних інформаційних панелях.

Налаштування EKS та Istio

EKS Blueprints для Istio для налаштування кластера Amazon EKS разом із налаштуванням Istio та додатковими компонентами спостереження. Використання Terraform-базованих EKS Blueprints для Istio спрощує процес налаштування та управління Istio у вашому середовищі Kubernetes. Цей шаблон надає структурований і ефективний спосіб розгортання Istio на Amazon EKS, уникаючи багатьох ручних налаштувань і можливих складнощів.

Шаблон виконає наступні завдання:

1. Розгорне кластер Amazon EKS з однією керованою групою вузлів у VPC.
2. Додасть правила nodesecuritygroup для необхідного доступу до портів, необхідних для комунікації Istio.
3. Встановить Istio за допомогою Helm-ресурсів, керованих через Terraform.
4. Встановить Istio Ingress Gateway за допомогою Helm-ресурсів у Terraform (цей крок розгортає сервіс типу LoadBalancer, який створює AWS Network Load Balancer).

git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git  
cd terraform-aws-eks-blueprints/patterns/istio

Почніть з перегляду розділу передумов та встановлення необхідних інструментів для цього налаштування. Потім виконайте наступну команду для оновлення локальної інформації про доступні чарти з репозиторіїв чартів

helm repo update

Виконайте наступну послідовність команд для налаштування інфраструктури для кластера EKS з Istio.

terraform init   
terraform apply -auto-approve  
kubectl rollout restart deployment istio-ingress -n istio-ingress

Для більш детальної інформації ви також можете звернутися до розділу Deploy в документації EKS Blueprint.

Використовуйте наступний фрагмент коду для додавання компонентів спостереження Istio до кластера EKS з вже розгорнутим Istio.

for ADDON in kiali jaeger prometheus grafana  
do  
 ADDON_URL="https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/$ADDON.yaml"  
 kubectl apply --server-side -f $ADDON_URL  
done

Розгортання мікросервісів

git clone https://github.com/aws-samples/istio-on-eks.git  
cd istio-on-eks/modules/01-getting-started

Для більш детальної інформації ви також можете звернутися до репозиторію github.

Створіть Namespace:

kubectl create namespace workshop

Позначте Namespace:

kubectl label namespace workshop istio-injection=enabled

Мітка istio-injection=enabled інструктує Istio автоматично вставляти проксі Envoy sidecar у контейнери, створені в цьому Namespace.

Розгортання Helm Chart

Тепер розгорніть наданий Helm chart mesh-basic. Цей чарт включає манифести для розгортання наступних компонентів:

1. Усі три мікросервіси: frontend, prodcatalog та catalogdetail.
2. Istio Gateway та VirtualService для управління та маршрутизації трафіку.

helm install mesh-basic .

-n workshop  
kubectl get pods -n workshop

Ви можете отримати URL інтерфейсу користувача програми, виконавши наступні команди:

ISTIO_INGRESS_URL=$(kubectl get svc istio-ingress -n istio-ingress -o jsonpath='{.status.loadBalancer.ingress[*].hostname}')  
echo "http://$ISTIO_INGRESS_URL"

Перейшовши за цим URL у браузері, ви потрапите до програми Product Catalog:

https://aws.amazon.com/blogs/opensource/getting-started-with-istio-on-amazon-eks/

Компоненти Istio

https://aws.amazon.com/blogs/opensource/getting-started-with-istio-on-amazon-eks/

Ця діаграма ілюструє потік трафіку в межах програми Product Catalog, використовуючи архітектуру service mesh Istio. Ось деталі:

1. Запит користувача: Користувач взаємодіє з системою, надсилаючи запит до програми. Запит маршрутується через Ingress Gateway, який є точкою входу для зовнішнього трафіку в service mesh.

2. Ingress Gateway: Istio Ingress Gateway обробляє зовнішні HTTP запити. Він маршрутує трафік на основі правил, визначених у конфігурації Virtual Service.

Виконайте наступну команду, щоб отримати список всіх ресурсів Istio, які були створені:

kubectl get Gateway,VirtualService -n workshop

Виведення:

Давайте подивимося на визначення productapp-gateway більш детально, виконавши цю команду kubectl:

kubectl get gateway productapp-gateway -n workshop -o yaml

apiVersion: networking.istio.io/v1beta1  
kind: Gateway  
metadata:  
 annotations:  
 meta.helm.sh/release-name: mesh-basic  
 meta.helm.sh/release-namespace: workshop  
 creationTimestamp: "2023-08-28T22:13:32Z"  
 generation: 1  
 labels:  
 app.kubernetes.io/managed-by: Helm  
 name: productapp-gateway  
 namespace: workshop  
 resourceVersion: "2436"  
 uid: 8a2e97eb-6879-4005-9864-2990db03b009  
spec:  
 selector:  
 istio: ingressgateway  
 servers:  
 - hosts:  
 - '*'  
 port:  
 name: http  
 number: 80  
 protocol: HTTP

На основі наданого YAML визначення Gateway, ми можемо зробити такі висновки щодо productapp-gateway:

Застосовано до проксі Envoy:

• Gateway застосовується до проксі Envoy у подах, мічених як istio: ingressgateway. Ця мітка гарантує, що екземпляр Istio Ingress Gateway оброблятиме трафік, визначений цим ресурсом Gateway.

Приймає трафік для всіх хостів:

• Поле hosts встановлено на '*', що означає, що він приймає трафік для всіх імен хостів без обмежень.

Приймає трафік на порту 80 для протоколу HTTP:

• Налаштування port вказує на number: 80 і protocol: HTTP, що означає, що Gateway приймає HTTP трафік на порту 80.

1. Virtual Service: Virtual Service визначає правила маршрутизації для трафіку в межах service mesh. У цьому випадку трафік з host: productapp направляється до сервісу frontend.

kubectl get VirtualService productapp -n workshop -o yaml

kind: VirtualService  
metadata:  
 annotations:  
 meta.helm.sh/release-name: mesh-basic  
 meta.helm.sh/release-namespace: workshop  
 creationTimestamp: "2023-08-28T22:13:32Z"  
 generation: 1  
 labels:  
 app.kubernetes.io/managed-by: Helm  
 name: productapp  
 namespace: workshop  
 resourceVersion: "2440"  
 uid: 3ebc2a6f-0ef8-40b9-9fc3-dba326039577  
spec:  
 gateways:  
 - productapp-gateway  
 hosts:  
 - '*'  
 http:  
 - match:  
 - uri:  
 prefix: /  
 route:  
 - destination:  
 host: frontend  
 port:  
 number: 9000

На основі цього YAML визначення VirtualService, ми можемо зробити такі висновки щодо productapp VirtualService:

1.
Асоціація з Gateway:

• Він безпосередньо пов'язаний з productapp-gateway Gateway, що означає, що він обробляє вхідний трафік, маршрутизований через цей Gateway.

1. Підходить для будь-якого імені хоста (*):

• Поле hosts: '*' вказує на те, що воно підходить для HTTP трафіку з будь-якого імені хоста.

1. Маршрутизує трафік на основі контекстного шляху:

• Коли URI запиту збігається з кореневим шляхом (/) або не має конкретного контекстного шляху, трафік маршрутується до сервісу frontend на порт 9000.

Ця конфігурація забезпечує, що всі HTTP запити через productapp-gateway Gateway будуть спрямовані до сервісу frontend, незалежно від імені хоста чи конкретного URI шляху.

1. Комунікація мікросервісів

Frontend Service:

• Трафік маршрутується до мікросервісу frontend.
• Envoy proxy (проксі Envoy), розгорнутий разом із сервісом, керує комунікацією та застосовує політики Istio.

Product Catalog Service:

• Сервіс frontend взаємодіє з сервісом productcatalog для отримання даних про продукти.
• Envoy proxy обробляє трафік між цими сервісами, забезпечуючи безпечну та ефективну комунікацію.

Catalog Detail Service:

• Сервіс productcatalog взаємодіє з сервісом catalogdetail.
• Існують дві версії сервісу catalogdetail (v1 і v2). Трафік може бути розподілений між цими версіями, що дозволяє реалізувати такі функції, як canary deployments або A/B тестування.

Візуалізація

Kiali — потужна консоль для управління та візуалізації Istio service mesh. У цьому налаштуванні ми використовуватимемо Kiali для перевірки та моніторингу нашого розгортання Istio.

Щоб отримати доступ до консолі Kiali, ви можете переадресувати порт сервісу Kiali на вашу локальну машину за допомогою наступної команди:

kubectl port-forward svc/kiali 20001:20001 -n istio-system

Використовуйте браузер, щоб перейти за адресою http://localhost:20001

https://aws.amazon.com/blogs/opensource/getting-started-with-istio-on-amazon-eks/

https://aws.amazon.com/blogs/opensource/getting-started-with-istio-on-amazon-eks/

Grafana

Grafana — потужний інструмент для запитів, візуалізації, налаштування сповіщень і аналізу метрик, незалежно від того, де вони зберігаються. У контексті Istio, Grafana зазвичай використовується для моніторингу продуктивності та здоров'я service mesh.

Щоб отримати доступ до консолі Grafana, ви можете переадресувати порт її сервісу на вашу локальну машину за допомогою наступної команди:

kubectl port-forward svc/grafana 3000:3000 -n istio-system

Використовуйте браузер, щоб перейти за адресою http://localhost:3000/dashboards

https://aws.amazon.com/blogs/opensource/getting-started-with-istio-on-amazon-eks/

Перекладено з: Deploying Istio on Amazon EKS for Enhanced Service Mesh Management