Развертывание кластера Kubernetes с высоким уровнем доступности в Azure Stack Hub

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

С помощью этого руководства по развертыванию решения вы узнаете, как выполнять следующие задачи:

• Скачивание и подготовка обработчика AKS
• Подключение к вспомогательной виртуальной машине обработчика AKS
• Развертывание кластера Kubernetes
• Подключение к кластеру Kubernetes
• Подключение Azure Pipelines к кластеру Kubernetes
• Настройка мониторинга
• Развертывание приложения
• Автомасштабирование приложения
• Настройка диспетчера трафика
• Обновление Kubernetes в Службе контейнеров Azure (AKS)
• Масштабирование Kubernetes

Совет

Microsoft Azure Stack Hub — это расширение Azure. Azure Stack Hub обеспечивает гибкость и высокую скорость внедрения инноваций облачных вычислений в локальной среде. Это решение позволяет использовать единственное гибридное облако, с помощью которого можно создавать и развертывать гибридные приложения в любой точке мира.

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

Предварительные требования

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

• Ознакомьтесь со статьей Шаблон кластера Kubernetes с высоким уровнем доступности.
• Просмотрите содержимое вспомогательного репозитория GitHub, в котором можно найти дополнительные ресурсы, упоминаемые в этой статье.
• Подключите для вашей учетной записи доступ к пользовательскому порталу Azure Stack Hub с по меньшей мере разрешениями участника.

Скачивание и подготовка обработчика AKS

Обработчик AKS — это двоичный файл, который можно использовать на любом узле Windows или Linux для достижения конечных точек Azure Resource Manager в Azure Stack Hub. В этом руководстве описано, как развертывать новую виртуальную машину Linux (или Windows) в Azure Stack Hub. Она будет использоваться позже, когда обработчик AKS развернет кластеры Kubernetes.

Примечание

Для развертывания кластера Kubernetes в Azure Stack Hub с помощью обработчика AKS можно также использовать существующую виртуальную машину на Windows или Linux.

Пошаговые инструкции и требования для обработчика AKS описаны здесь:

• Установка обработчика AKS на Linux в Azure Stack Hub (или же используя Windows)

Обработчик AKS — это вспомогательное средство для развертывания и эксплуатации (неуправляемых) кластеров Kubernetes (в Azure и Azure Stack Hub).

О сведениях и отличиях обработчика AKS в Azure Stack Hub можно почитать здесь:

• Что собой представляет обработчик AKS в Azure Stack Hub?
• Использование обработчика AKS в Azure Stack Hub (на GitHub)

Пример среды будет использовать Terraform для автоматизации развертывания виртуальной машины обработчика AKS. Сведения и код можно найти во вспомогательном репозитории GitHub.

После выполнения этого шага в Azure Stack Hub появится новая группа ресурсов, содержащая вспомогательную виртуальную машину обработчика AKS, а также связанные ресурсы:

Примечание

Если обработчик AKS необходимо развернуть в отключенной от Интернета автономной среде, ознакомьтесь со сведениями в разделе об экземплярах Azure Stack Hub, отключенных от Интернета .

На следующем шаге мы будем использовать только что развернутую виртуальную машину обработчика AKS для развертывания кластера Kubernetes.

Подключение к вспомогательной виртуальной машине обработчика AKS

Сначала необходимо подключиться к ранее созданной вспомогательной виртуальной машине обработчика AKS.

У виртуальной машины должен быть общедоступный IP-адрес и доступ через SSH (порт 22/TCP).

Совет

Для подключения к виртуальной машине Linux с помощью SSH можно использовать любое средство на ваш выбор, включая MobaXterm, puTTY или PowerShell на Windows 10.

ssh <username>@<ipaddress>

Подключившись, выполните команду aks-engine. Ознакомьтесь с поддерживаемыми версиями обработчика AKS, чтобы узнать больше об обработчике AKS и версиях Kubernetes.

Развертывание кластера Kubernetes

Сама вспомогательная виртуальная машина обработчика AKS еще не создала кластер Kubernetes в Azure Stack Hub. Создание кластера является первым действием, которое необходимо выполнить на вспомогательной виртуальной машине обработчика AKS.

Пошаговые инструкции описаны здесь:

• Развертывание кластера Kubernetes с обработчиком AKS в Azure Stack Hub

В результате выполнения команды aks-engine deploy и подготовительных действий, описанных на предыдущих шагах, вы получите полнофункциональный кластер Kubernetes, развернутый в пространстве клиента первого экземпляра Azure Stack Hub. Сам кластер состоит из таких компонентов Azure IaaS, как виртуальные машины, подсистемы балансировки нагрузки, виртуальные сети, диски и т. д.

1. Azure Load Balancer (конечная точка API K8s) 2) рабочие узлы (пул агентов) 3) главные узлы

Теперь кластер настроен и работает. На следующем шаге мы попробуем к нему подключиться.

Подключение к кластеру Kubernetes

Теперь к ранее созданному кластеру Kubernetes можно подключиться либо через протокол SSH (с помощью ключа SSH, указанного в составе развертывания), либо используя kubectl (рекомендуется). Программа командой строки Kubernetes kubectl для Windows, Linux и macOS доступна здесь. Он уже предварительно установлен и настроен на главных узлах кластера:

ssh azureuser@<k8s-master-lb-ip>

Главный узел не рекомендуется использовать как инсталляционный сервер для административных задач. Конфигурация kubectl хранится в .kube/config на главных узлах, а также на виртуальной машине обработчика AKS. Вы можете скопировать конфигурацию на компьютер администратора с подключением к кластеру Kubernetes, а затем выполнить на нем команду kubectl. Позже для настройки подключения службы в Azure Pipelines можно также использовать файл .kube/config.

Важно!

Защитите эти файлы, поскольку они содержат учетные данные для вашего кластера Kubernetes. У злоумышленника с доступом к файлу появится достаточно сведений, чтобы получить права администратора. Все действия, которые выполняются с помощью начального файла .kube/config, выполняются под учетной записью администратора кластера.

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

kubectl get nodes

NAME                       STATUS   ROLE     VERSION
k8s-linuxpool-35064155-0   Ready    agent    v1.14.8
k8s-linuxpool-35064155-1   Ready    agent    v1.14.8
k8s-linuxpool-35064155-2   Ready    agent    v1.14.8
k8s-master-35064155-0      Ready    master   v1.14.8

kubectl cluster-info

Kubernetes master is running at https://aks.***
CoreDNS is running at https://aks.***/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://aks.***/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
Metrics-server is running at https://aks.***/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy

Важно!

Kubernetes имеет собственную модель контроль доступа на основе ролей (RBAC), которая позволяет создавать детализированные определения ролей и привязки ролей. Этот способ управления доступом к кластеру является более предпочтительным, чем передача разрешений администратора кластера.

Подключение Azure Pipelines к кластерам Kubernetes

Чтобы подключить Azure Pipelines к только что развернутый кластер Kubernetes, нам нужен его файл kubeconfig (.kube/config), как описано на предыдущем шаге.

• Подключитесь к одному из главных узлов кластера Kubernetes.
• Скопируйте содержимое файла .kube/config.
• Перейдите в раздел Параметры > проекта Azure DevOps > Подключения к службе, чтобы создать подключение к службе Kubernetes (используйте KubeConfig в качестве метода проверки подлинности).

Важно!

Для Azure Pipelines (или его агентов сборки) требуется доступ к API Kubernetes. При наличии подключения к Интернету из Azure Pipelines к кластеру Kubernetes Azure Stack Hub необходимо развернуть локальный агент сборки Azure Pipelines.

Процесс развертывания локальных агентов для Azure Pipelines можно выполнить или в Azure Stack Hub, или на компьютере с сетевым подключением ко всем необходимым конечным точкам управления. См. подробные сведения здесь:

• Агенты Azure Pipelines для Windows или Linux

В разделе шаблонов Рекомендации по развертыванию (CI/CD) содержится поток решений, который поможет вам понять, когда нужно использовать локальные агенты и когда агенты, размещенные Майкрософт:

Скачайте файл Visio со всеми схемами из этой статьи.

В этом примере решения топология включает в себя локальный агент сборки на каждом экземпляре Azure Stack Hub. Агент может получить доступ и к конечным точкам управления Azure Stack Hub, так и к конечным точкам API кластера Kubernetes.

Скачайте файл Visio со всеми схемами из этой статьи.

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

Настройка мониторинга

Для мониторинга контейнеров в решении можно использовать Azure Monitor для контейнеров. Это позволит указать для Azure Monitor кластер Kubernetes, развернутый обработчиком AKS в Azure Stack Hub.

Есть два способа включить Azure Monitor для кластера. Для обоих способов понадобится настроить в Azure рабочую область Log Analytics.

• Метод 1 использует диаграмму Helm
• Метод 2, относящийся к спецификации кластера обработчика AKS

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

Для следующего шага на вашем компьютере должна быть рабочая область Azure Log Analytics (ее идентификатор и ключ), Helm (версия 3) и kubectl.

Helm — это диспетчер пакетов Kubernetes, представленный в виде двоичного файла, который выполняется на macOS, Windows и Linux. Его можно скачать на helm.sh. Helm использует файл конфигурации Kubernetes, используемый kubectl для команды :

helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
helm repo update

helm install incubator/azuremonitor-containers \
--set omsagent.secret.wsid=<your_workspace_id> \
--set omsagent.secret.key=<your_workspace_key> \
--set omsagent.env.clusterName=<my_prod_cluster> \
--generate-name

Выполнив эту команду, можно установить агент Azure Monitor в кластере Kubernetes:

kubectl get pods -n kube-system

NAME                                       READY   STATUS
omsagent-8qdm6                             1/1     Running
omsagent-r6ppm                             1/1     Running
omsagent-rs-76c45758f5-lmc4l               1/1     Running

Агент Operations Management Suite (OMS) в кластере Kubernetes будет передавать данные мониторинга в рабочую область Azure Log Analytics (используя исходящий протокол HTTPS). Теперь вы можете использовать Azure Monitor, чтобы получить более подробные аналитические сведения о кластерах Kubernetes в Azure Stack Hub. Приведенная схема отлично отображает возможности аналитики, которую можно автоматически развернуть в кластерах вашего приложения.

Важно!

Если azure Monitor не отображает данные Azure Stack Hub, убедитесь, что вы внимательно выполнили инструкции по добавлению AzureMonitor-Containers решения в рабочую область Azure Log Analytics .

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

Перед установкой нашего примера приложения следует выполнить еще один шаг по настройке контроллера объекта ingress на основе nginx в нашем кластере Kubernetes. Контроллер объекта ingress используется в качестве подсистемы балансировки нагрузки уровня 7 для маршрутизации трафика в кластере на основе узла, пути или протокола. Входящий трафик Nginx доступный в виде диаграммы Helm. Подробные инструкции см. в разделе о диаграммах Helm в репозитории GitHub.

Пример приложения также упаковывается как диаграмма Helm, аналогично агенту наблюдения Azure с предыдущего шага. Таким образом, развертывать приложение на нашем кластере Kubernetes довольно просто. Файлы диаграммы Helm можно найти во вспомогательном репозитории GitHub

Пример приложения — это трехуровневое приложение, развернутое в кластере Kubernetes на каждом из двух экземпляров Azure Stack Hub. Приложение использует базу данных MongoDB. Дополнительные сведения о том, как получить данные, реплицируемые в нескольких экземплярах, см. в разделе Рекомендации по данным и хранилищу.

Развернув диаграмму Helm для приложения, вы увидите, что все три уровня приложения представленные в качестве развертываний и наборов с отслеживанием состояния (для базы данных) с одним объектом pod:

kubectl get pod,deployment,statefulset

NAME                                         READY   STATUS
pod/ratings-api-569d7f7b54-mrv5d             1/1     Running
pod/ratings-mongodb-0                        1/1     Running
pod/ratings-web-85667bfb86-l6vxz             1/1     Running

NAME                                         READY
deployment.extensions/ratings-api            1/1
deployment.extensions/ratings-web            1/1

NAME                                         READY
statefulset.apps/ratings-mongodb             1/1

На стороне службы можно найти контроллер объекта ingress на основе nginx, а также его общедоступный IP-адрес:

kubectl get service

NAME                                         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)
kubernetes                                   ClusterIP      10.0.0.1       <none>        443/TCP
nginx-ingress-1588931383-controller          LoadBalancer   10.0.114.180   *public-ip*   443:30667/TCP
nginx-ingress-1588931383-default-backend     ClusterIP      10.0.76.54     <none>        80/TCP
ratings-api                                  ClusterIP      10.0.46.69     <none>        80/TCP
ratings-web                                  ClusterIP      10.0.161.124   <none>        80/TCP

"Внешний IP-адрес" — это наша "конечная точка приложения". С его помощью пользователи будут подключаться, чтобы открыть приложение. Кроме того, мы будем использовать этот IP в качестве конечной точки на шаге Настройки диспетчера трафика.

Автомасштабирование приложения

При необходимости вы можете настроить средство горизонтального автомасштабирования объекта pod, с помощью которого можно увеличивать или уменьшать масштаб на основе определенных метрик, например загрузки ЦП. Следующая команда создаст средство горизонтального автомасштабирования объекта pod, которое обслуживает от 1 до 10 реплик Pod, управляемых с помощью веб-развертывания оценок. HPA увеличит и уменьшит количество реплик (с помощью развертывания), чтобы поддерживать среднюю загрузку ЦП во всех модулях Pod на 80 %:

kubectl autoscale deployment ratings-web --cpu-percent=80 --min=1 --max=10

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

kubectl get hpa

NAME          REFERENCE                      TARGET    MINPODS   MAXPODS   REPLICAS   AGE
ratings-web   Deployment/ratings-web/scale   0% / 80%  1         10        1          18s

Настройка диспетчера трафика

Для распределения трафика между двумя (или больше) развертываниями приложения используется диспетчер трафика Azure. Диспетчер трафика Azure — это подсистема балансировки нагрузки в Azure, основанная на DNS.

Примечание

Диспетчер трафика использует DNS для направления клиентских запросов к наиболее подходящей конечной точке службы в зависимости от метода маршрутизации трафика и работоспособности конечных точек.

Вместо Диспетчера трафика Azure можно также использовать другие глобальные решения для балансировки нагрузки, размещенные локально. В примере сценария мы будем использовать Диспетчер трафика Azure, чтобы распределять трафик между двумя экземплярами нашего приложения. Они могут выполняться на экземплярах Azure Stack Hub в одинаковых или различных расположениях:

Скачайте файл Visio со всеми схемами из этой статьи.

Мы настроим Диспетчер трафика в Azure так, чтобы он указывал на два разных экземпляра нашего приложения:

Как видите, две конечные точки указывают на два экземпляра развернутого приложения, упоминаемого в предыдущем разделе.

На этом этапе:

• Создана инфраструктура Kubernetes, включая контроллер входящего трафика.
• Развернуты кластеры между двумя экземплярами Azure Stack Hub.
• Настроен мониторинг.
• Диспетчер трафика Azure будет распределять нагрузку трафика между двумя экземплярами Azure Stack Hub.
• Помимо этой инфраструктуры был автоматически развернут пример трехуровневого приложения с использованием диаграмм Helm.

Решение теперь настроено и доступно для пользователей!

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

Обновление Kubernetes в Службе контейнеров Azure (AKS)

При обновлении кластера Kubernetes обратите внимание на следующие темы:

• Обновление кластера Kubernetes — это сложная операция Дня 2, которую можно выполнить с помощью обработчика AKS. Дополнительные сведения см. в разделе Обновление кластера Kubernetes в Azure Stack Hub.
• Обработчик AKS позволяет обновлять кластеры до более новых версий Kubernetes и базовых образов ОС. Дополнительные сведения см. в разделе Шаги для обновления к более новой версии Kubernetes.
• Вы также можете обновить только базовые узлы до более новых версий базового образа ОС. Дополнительные сведения см. в разделе Шаги для обновления образа ОС.

Более новые базовые образы ОС содержат обновления безопасности и ядра. Ответственность за отслеживание доступности более новых версий Kubernetes и образов ОС лежит на операторе кластера. Оператор должен планировать и выполнять эти обновления с помощью обработчика AKS. Базовые образы ОС необходимо скачать с Azure Stack Hub Marketplace, используя оператор Azure Stack Hub.

Масштабирование Kubernetes

Масштабирование является еще одной операцией Дня 2, которой можно управлять с помощью обработчика AKS.

Команда scale использует тот же файл конфигурации кластера (apimodel.json) в выходном каталоге, как входные данные для нового развертывания Azure Resource Manager. Обработчик AKS выполняет операцию масштабирования для указанного пула агентов. После завершения операции масштабирования обработчик AKS обновляет определение кластера в том же файле apimodel.json. Определение кластера отражает новое число узлов, чтобы соответствовать обновленной текущей конфигурации кластера.

• Масштабирование кластера Kubernetes в Azure Stack Hub

Дальнейшие действия

• Узнайте больше о рекомендациях по проектированию гибридных приложений.
• Изучите и предложите улучшения для кода в этом примере на сайте GitHub.