Упражнение. Реализация устойчивости инфраструктуры с помощью Kubernetes
В предыдущем уроке вы реализовали устойчивость, добавив код обработки сбоев с помощью собственного расширения устойчивости .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 см. следующие ресурсы: