eShopOnContainers — часть 3 (внедрение Istio)

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

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

Kube-proxy является неотъемлемой частью настройки сети Kubernetes и работает на сетевом уровне для управления связью между модулями, работающими на разных узлах в кластере. Он работает в одном из трех режимов: пользовательское пространство, iptables и IPVS (IP Virtual Server).

В режим пользовательского пространства, kube-proxy взаимодействует напрямую с сетевым стеком хоста для управления трафиком. В режим iptableskube-proxy управляет правилами iptables для перенаправления трафика на соответствующие модули. Режим IPVS использует виртуальный IP-сервер Linux для обработки переадресации трафика.

Основная роль kube-proxy — обрабатывать входящие сетевые запросы и перенаправлять их в соответствующий внутренний модуль. Он реализует службы, определенные в кластере, выполняя такие задачи, как переадресация потоков TCP и UDP, балансировка нагрузки и отслеживание сетевых подключений.

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

Таким образом, kube-proxy отвечает за обеспечение сетевого подключения между модулями в кластере Kubernetes и за балансировку нагрузки для служб, работающих в кластере.

Компонент kube-proxy в этом процессе также должен перехватывать трафик, за исключением того, что kube-proxy перехватывает трафик к узлу Kubernetes и от него, а sidecar-прокси перехватывает трафик к поду и от него.

Istio может отслеживать регистрацию службы в Kubernetes, а также может взаимодействовать с другими системами обнаружения служб через адаптеры платформы в плоскости управления; а затем сгенерировать конфигурации плоскости данных (используя CRD, которые хранятся в etcd) с прозрачными прокси для плоскости данных. Прозрачный прокси плоскости данных развертывается как дополнительный контейнер в модуле каждой службы приложений, и все эти прокси должны запрашивать плоскость управления для синхронизации конфигурации прокси. Он использует Envoy Proxy в качестве сайдкара.

• Istio Control Plane устанавливается в кластере Kubernetes. Сюда входят компоненты Istio Pilot, Mixer и Citadel, отвечающие за управление трафиком, политиками и безопасностью.

• Когда в кластере создается новый модуль, контроллер допуска Kubernetes перехватывает запрос на создание модуля и проверяет, есть ли у него аннотация, указывающая, что его необходимо внедрить с помощью дополнительного прокси-сервера Istio. Эта аннотация — sidecar.istio.io/inject: true.

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

• Измененное определение YAML затем используется для создания модуля с дополнительным прокси-контейнером вместе с основным контейнером для приложения.

• После создания модуля прокси-сервер Istio перехватывает весь входящий и исходящий трафик для контейнера приложения. Он использует сервисную сетку для управления и защиты связи между микросервисами в приложении.

Переключить текущий контекст

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

kubectl config use-context docker-desktop

Установить Истио

1. Загрузите выпуск Istio. Вы можете загрузить последний выпуск Istio с официального веб-сайта Istio. (istio-1.15.1-win.zip). Извлеките его в каталог в вашей системе.

2. Добавьте путь к переменной окружения.

3. Установите Custom Resource Definitions (CRD) Istio и установите компоненты плоскости управления Istio:

istioctl install --set profile=demo

4. Проверка установки: Вы можете проверить установку, проверив состояние компонентов Istio с помощью следующей команды:

kubectl get pods -n istio-system

5. (Необязательно) Установите надстройку istio
   Мы можем найти файлы yaml в папке загрузки istio, istio-1.15.1-win\istio-1.15.1\samples\addons, чтобы применить все дополнения к istio.

kubectl apply -f prometheus.yaml
kubectl apply -f kiali.yaml
kubectl apply -f jaeger.yaml
kubectl apply -f grafana.yaml

6. Все аддоны устанавливаются в пространство имен istio-system и могут быть просмотрены:

kubectl get svc -n istio-system

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

Sidecars обычно используются для добавления дополнительного уровня функциональности в существующие контейнерные среды. Ячеистая архитектура Istio опирается на связь между сайдкарами Envoy, которые составляют плоскость данных ячеистой сети, и компонентами плоскости управления. Чтобы сетка работала, нам нужно убедиться, что каждый под в сетке также будет запускать sidecar Envoy.

Есть два пути достижения этой цели:
• ручной впрыск коляски
• автоматический впрыск коляски.

Мы включим автоматическое внедрение sidecar, пометив пространство имен, в котором мы будем создавать объекты нашего приложения, меткой istio-injection=enabled. Это гарантирует, что контроллер MutatingAdmissionWebhook сможет перехватывать запросы к kube-apiserver и выполнять определенное действие — в данном случае гарантирует, что все наши модули приложений будут запускаться с sidecar.

kubectl label namespace default istio-injection=enabled

Мы можем убедиться, что команда работает должным образом, выполнив следующее:

kubectl get namespace -L istio-injection

Развернуть eShopOnContainer

Теперь, когда система Istio установлена ​​и запущена, пришло время развернуть eShopContainer в кластере Kubernetes. Убедитесь, что Helm установлен, так как приведенный ниже сценарий powershell использует Helm (см. часть 2):

.\deploy-all.ps1 -imageTag linux-latest -useLocalk8s $true -imagePullPolicy Always

Затем проверьте состояние всех модулей.

kubectl get pods

В моем случае я получал CrashLoopBackOff статус для webMVC, catalog-api и т. д. Статус «CrashLoopBackOff» в Kubernetes означает, что контейнер в модуле продолжает сбой и перезапуск, а количество перезапусков превышает политику перезапуска, определенную в модуле. Этот статус указывает на проблему с контейнером, например проблему с приложением внутри контейнера, отсутствие зависимостей или сбой при запуске. При проверке журнала я обнаружил, что приложение, пытающееся подключиться к RabbitMQ, Redis и SQL Data через sidecar (envoy proxy), не работает. Итак, я решил пропустить коляску для этих стручков.

Чтобы пропустить внедрение sidecar Istio для модулей, созданных развертыванием в пространстве имен, помеченном «istio-injection=enabled», вы можете добавить аннотацию «sidecar.istio.io/inject» в спецификацию шаблона развертывания со значением «false». » (показано ниже). Эта аннотация будет применена ко всем модулям, созданным в ходе развертывания, что предотвратит внедрение в эти модули дополнения Istio.

Ниже вы можете видеть, что выделенные модули работают с коляской.

Определение входящего IP и маршрутизация трафика на webmvc

kubectl get svc -n istio-system

Вы можете видеть, что ВНЕШНИЙ IP-адрес istio-ingress-gateway является локальным хостом и доступен через порт 80. А для маршрутизации трафика на webmvc вам необходимо создать шлюз и ресурс VirtualService в Istio. Создайте файл с именем istio-шлюз.yaml в каталоге вашего проекта и вставьте следующее:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: mvcweb-gateway
spec:
  selector:
    istio: ingressgateway 
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: webmvc-virtual-service
spec:
  hosts:
  - "*"
  gateways:
  - mvcweb-gateway
  http:
  - route:
    - destination:
        host: webmvc

В этом примере ресурс шлюза с именем «mvcweb-gateway» открывает порт 80 на входном шлюзе Istio. Ресурс VirtualService с именем «webmvc-virtual-service» запрашивает маршрут «webmvc».

Разверните это в кластере с помощью следующей команды:

kubectl apply -f istio-gateway.yaml

Все готово, теперь вы вызываете приложение webmvc для доступа к порту 80 локального хоста.

В качестве альтернативы вы также можете получить доступ к webmvc напрямую, используя переадресацию портов, и проверить, работает ли приложение —

kubectl port-forward svc/webmvc 7777:80

Включение доступа к телеметрии через Ingress

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