Упражнение. Реализация устойчивости инфраструктуры с помощью Kubernetes

11 мин

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

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

Повторно разверните приложение без какой-либо устойчивости в Kubernetes.
Разверните компоновщик в кластере Kubernetes.
Настроить приложение так, чтобы использовать Linkerd для обеспечения устойчивости.
Изучить поведение приложения с Linkerd.

Повторное развертывание приложения

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

На нижней панели перейдите на вкладку ТЕРМИНАЛА и выполните следующие команды Git, чтобы отменить изменения:
```
cd Store
git checkout Program.cs
git checkout Store.csproj
cd ..
dotnet publish /p:PublishProfile=DefaultContainer
```

Установка Kubernetes

В пространстве кода установите Kubernetes и k3d. k3d — это средство, которое запускает кластер Kubernetes с одним узлом в виртуальной машине на локальном компьютере. Это полезно для тестирования развертываний Kubernetes локально и работает хорошо в пространстве кода.

Выполните следующие команды, чтобы установить Kubernetes и MiniKube:

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/kubernetes-apt-keyring.gpg

echo 'deb [signed-by=/etc/apt/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubectl

curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash
k3d cluster create devcluster --config k3d.yml

Развертывание служб eShop в Docker Hub

Локальные образы создаваемых служб должны размещаться в реестре контейнеров для развертывания в Kubernetes. В этом уроке в качестве реестра контейнеров используется Docker Hub.

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

sudo docker login

sudo docker tag products [your username]/productservice
sudo docker tag store [your username]/storeimage

sudo docker push [your username]/productservice
sudo docker push [your username]/storeimage

Преобразование файла docker-compose в манифесты Kubernetes

На данный момент вы определяете, как приложение работает в Docker. Kubernetes использует другой формат для определения запуска приложения. С помощью средства с именем Kompose можно преобразовать файл docker-compose в манифесты Kubernetes.

Эти файлы необходимо изменить, чтобы использовать изображения, отправленные в Docker Hub.
В пространстве кода откройте файл backend-deploy.yml.
Измените эту строку:
```
  containers:
    - image: [YOUR DOCKER USER NAME]/productservice:latest
```
Замените заполнитель [ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER] фактическим именем пользователя Docker.
Повторите эти действия для файла frontend-deploy.yml .
Измените эту строку:
```
  containers:
  - name: storefrontend
    image: [YOUR DOCKER USER NAME]/storeimage:latest  
```
Замените заполнитель [ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER] фактическим именем пользователя Docker.

Разверните приложение eShop в Kubernetes:

kubectl apply -f backend-deploy.yml,frontend-deploy.yml

Вы должны увидеть выходные данные, аналогичные следующим сообщениям:

deployment.apps/productsbackend created
service/productsbackend created
deployment.apps/storefrontend created
service/storefrontend created

Убедитесь, что выполняются все службы:

kubectl get pods

Вы должны увидеть выходные данные, аналогичные следующим сообщениям:

NAME                        READY   STATUS    RESTARTS   AGE
backend-66f5657758-5gnkw    1/1     Running   0          20s
frontend-5c9d8dbf5f-tp456   1/1     Running   0          20s

Перейдите на вкладку "ПОРТЫ", чтобы просмотреть электронный магазин, работающий в Kubernetes, выберите значок глобуса рядом с портом переднего плана (32000).

Установка компоновщика

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

curl -sL run.linkerd.io/install | sh
export PATH=$PATH:/home/vscode/.linkerd2/bin
linkerd check --pre

Отображаются выходные данные, аналогичные следующим:

kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version

pre-kubernetes-setup
--------------------
√ control plane namespace does not already exist
√ can create non-namespaced resources
√ can create ServiceAccounts
√ can create Services
√ can create Deployments
√ can create CronJobs
√ can create ConfigMaps
√ can create Secrets
√ can read Secrets
√ can read extension-apiserver-authentication configmap
√ no clock skew detected

pre-kubernetes-capability
-------------------------
√ has NET_ADMIN capability
√ has NET_RAW capability

linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date

Status check results are √

Развертывание Компоновщика в Kubernetes

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

linkerd install --crds | kubectl apply -f -

Затем выполните следующую команду:

linkerd install --set proxyInit.runAsRoot=true | kubectl apply -f -

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

linkerd install создает манифест Kubernetes с необходимыми ресурсами в плоскости управления.
Созданный манифест отправляется kubectl applyв канал, который устанавливает эти ресурсы плоскости управления в кластере Kubernetes.

Первая строка выходных данных показывает, что плоскость управления установлена в отдельном пространстве имен linkerd. Остальные выходные данные представляют создаваемые объекты.

namespace/linkerd created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-identity created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-identity created
serviceaccount/linkerd-identity created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-controller created

Проверка развертывания Linkerd

Выполните следующую команду:

linkerd check

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

kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version

linkerd-existence
-----------------
√ 'linkerd-config' config map exists
√ heartbeat ServiceAccount exist
√ control plane replica sets are ready
√ no unschedulable pods
√ controller pod is running
√ can initialize the client
√ can query the control plane API

linkerd-config
--------------
√ control plane Namespace exists
√ control plane ClusterRoles exist
√ control plane ClusterRoleBindings exist
√ control plane ServiceAccounts exist
√ control plane CustomResourceDefinitions exist
√ control plane MutatingWebhookConfigurations exist
√ control plane ValidatingWebhookConfigurations exist
√ control plane PodSecurityPolicies exist

linkerd-identity
----------------
√ certificate config is valid
√ trust anchors are using supported crypto algorithm
√ trust anchors are within their validity period
√ trust anchors are valid for at least 60 days
√ issuer cert is using supported crypto algorithm
√ issuer cert is within its validity period
√ issuer cert is valid for at least 60 days
√ issuer cert is issued by the trust anchor

linkerd-api
-----------
√ control plane pods are ready
√ control plane self-check
√ [kubernetes] control plane can talk to Kubernetes
√ [prometheus] control plane can talk to Prometheus
√ tap api service is running

linkerd-version
---------------
√ can determine the latest version
√ CLI is up to date

control-plane-version
---------------------
√ control plane is up to date
√ control plane and CLI versions match

linkerd-addons
--------------
√ 'linkerd-config-addons' config map exists

linkerd-grafana
---------------
√ grafana add-on service account exists
√ grafana add-on config map exists
√ grafana pod is running

Status check results are √

Совет

Чтобы просмотреть список установленных компонентов Компоновщика, выполните следующую команду: kubectl -n linkerd get deploy

Настройка приложения для использования Linkerd

Компоновщик развертывается, но он не настроен. Поведение приложения не изменилось.

Linkerd не знает о внутренних компонентах служб и не может определить, можно ли повторить запрос, завершившийся ошибкой. Например, повторение завершившегося ошибкой запроса HTTP POST за отдельную плату — не самая удачная идея. Профиль службы необходим по этой причине. Профиль службы — это пользовательский ресурс Kubernetes, определяющий маршруты для службы. Он также включает функции отдельных маршрутов, такие как повторные попытки и время ожидания. Linkerd повторяет только маршруты, настроенные в манифесте профиля службы.

Для краткости реализуйте Компоновщик только в агрегаторе и купон службах. Чтобы реализовать Linkerd для этих двух служб, вам потребуется:

Измените развертывания eShop, чтобы Linkerd создал свой прокси-контейнер в модулях pod.
Чтобы настроить повторные попытки в маршруте службы купон, добавьте объект профиля службы в кластер.

Изменение развертываний eShop

Службы должны быть настроены для использования контейнеров прокси-сервера Компоновщика.

Добавьте заметку в linkerd.io/inject: enabled файл backend-deploy.yml в метаданные шаблона.
```
  template:
    metadata:
      annotations:
        linkerd.io/inject: enabled
      labels: 
```
Добавьте заметку linkerd.io/inject: enabled в файл frontend-deploy.yml в том же месте.
Обновите развертывания в кластере Kubernetes:
```
kubectl apply -f backend-deploy.yml,frontend-deploy.yml
```

Применение профиля службы Компоновщика для службы продуктов

Манифест профиля службы для службы продуктов:

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: backend
  namespace: default
spec:
  routes:
  - condition:
      method: GET
      pathRegex: /api/Product
    name: GET /v1/products
    isRetryable: true
  retryBudget:
    retryRatio: 0.2
    minRetriesPerSecond: 10
    ttl: 120s

Предыдущий манифест настроен так:

Любой идемпотентный маршрут HTTP GET, соответствующий шаблону /api/Product, можно повторить.
Повторные попытки могут добавлять не более 20 процентов к нагрузке запроса, а также еще 10 "бесплатных" повторных попыток в секунду.

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

kubectl apply -f - <<EOF
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: backend
  namespace: default
spec:
  routes:
  - condition:
      method: GET
      pathRegex: /api/Product
    name: GET /v1/products 
    isRetryable: true
  retryBudget:
    retryRatio: 0.2
    minRetriesPerSecond: 10
    ttl: 120s  
EOF

Отображаются следующие результаты:

serviceprofile.linkerd.io/backend created

Установка мониторинга в сетке служб

Компоновщик имеет расширения для предоставления дополнительных функций. Установите расширение viz и просмотрите состояние приложения на панели мониторинга Компоновщика.

В терминале выполните следующую команду, чтобы установить расширение:
```
linkerd viz install | kubectl apply -f -
```
Просмотрите панель мониторинга с помощью этой команды:
```
linkerd viz dashboard
```
Перейдите на вкладку "ПОРТЫ " и просмотрите новый порт, переадресованный с помощью процесса запуска панели мониторинга компоновщика viz. Нажмите кнопку "Открыть в браузере", чтобы открыть панель мониторинга.
На панели мониторинга Linkerd выберите пространства имен.
В разделе "Метрики HTTP" выберите значение по умолчанию.

Проверка устойчивости Linkerd

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

Проверьте состояние выполняемых модулей pod с помощью следующей команды:
```
kubectl get pods --all-namespaces
```
Остановите все модули pod службы продуктов:
```
kubectl scale deployment productsbackend --replicas=0
```
Перейдите в веб-приложение eShop и попробуйте просмотреть продукты. Существует задержка до сообщения об ошибке: "Существует проблема с загрузкой наших продуктов. Повторите попытку позже.
Перезапустите модули pod службы продуктов:
```
kubectl scale deployment productsbackend --replicas=1
```
Теперь приложение должно отображать продукты.

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

Дополнительная информация:

Для получения дополнительных сведений о конфигурации Linkerd см. следующие ресурсы: