Шаблон кластера Kubernetes с высоким уровнем доступности

В этой статье описывается, как разработать и управлять высокодоступной инфраструктурой На основе Kubernetes с помощью подсистемы Azure Kubernetes Service (AKS) в Azure Stack Hub. Этот сценарий распространен для организаций с критически важными рабочими нагрузками в строго ограниченных и регулируемых средах. Организации в таких областях, как финансы, оборона и правительство.

Контекст и проблема

Многие организации разрабатывают облачные решения, использующие современные службы и технологии, такие как Kubernetes. Хотя Azure предоставляет центры обработки данных в большинстве регионов мира, иногда существуют пограничные варианты использования и сценарии, в которых критически важные для бизнеса приложения должны работать в определенном расположении. К ним относятся следующие рекомендации:

• Чувствительность к местоположению
• Задержка между приложением и локальными системами
• Сохранение пропускной способности
• Связь
• Нормативные или законодательные требования

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

Решение

В этом шаблоне предполагается, что необходимо иметь дело с строгим набором ограничений. Приложение должно выполняться локально, и все персональные данные не должны находиться в общедоступных облачных службах. Мониторинг и другие данные, отличные от PII, могут быть отправлены в Azure и обрабатываться там. К внешним службам, таким как общедоступный реестр контейнеров или другим аналогичным, можно получить доступ, но они могут быть фильтрованы через брандмауэр или прокси-сервер.

Пример приложения, показанный здесь, предназначен для использования собственных решений Kubernetes по возможности. Эта конструкция позволяет избежать блокировки поставщика вместо использования собственных служб платформы. Например, приложение использует локальную серверную часть базы данных MongoDB вместо службы PaaS или внешней службы базы данных. Дополнительные сведения см. в статье "Введение в Kubernetes" в схеме обучения Azure.

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

1. Кластер Kubernetes на базе AKS Engine в Azure Stack Hub.
2. cert-manager, который предоставляет набор средств для управления сертификатами в Kubernetes, используемый для автоматического запроса сертификатов из Let's Encrypt.
3. Пространство имен Kubernetes, содержащее компоненты приложения для внешнего интерфейса (ratings-web), API (ratings-api) и базы данных (ratings-mongodb).
4. Контроллер входящего трафика, который направляет трафик HTTP/HTTPS в конечные точки в кластере Kubernetes.

Пример приложения используется для иллюстрации архитектуры приложения. Все компоненты являются примерами. Архитектура содержит только одно развертывание приложения. Чтобы обеспечить высокий уровень доступности ,мы запускаем развертывание по крайней мере дважды на двух разных экземплярах Azure Stack Hub. Они могут выполняться в одном расположении или в двух (или более) разных сайтах:

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

Компоненты

Общая архитектура состоит из следующих компонентов:

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

Подсистема обслуживания Azure Kubernetes (ядро AKS) — это механизм, который стоит за предложением управляемой службы Kubernetes, службой Azure Kubernetes (AKS), доступной в Azure сегодня. Для Azure Stack Hub обработчик AKS позволяет развертывать, масштабировать и обновлять полностью управляемые кластеры Kubernetes с помощью возможностей IaaS Azure Stack Hub. Дополнительные сведения см. в статье "Обзор подсистемы AKS ".

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

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

Azure Load Balancer используется для конечной точки API Kubernetes и контроллера входящего трафика Nginx. Подсистема балансировки нагрузки направляет внешний трафик (например, Интернет) на узлы и виртуальные машины, предлагающие определенную службу.

Реестр контейнеров Azure (ACR) используется для хранения частных образов Docker и диаграмм Helm, развернутых в кластере. Модуль AKS может пройти проверку подлинности в реестре контейнеров с помощью идентификатора Microsoft Entra. Kubernetes не требует ACR. Вы можете использовать другие реестры контейнеров, например Docker Hub.

Azure Repos — это набор средств управления версиями, которые можно использовать для управления кодом. Вы также можете использовать GitHub или другие репозитории на основе git. Дополнительные сведения см. в обзоре Azure Repos .

Azure Pipelines является частью Azure DevOps Services и выполняет автоматизированные сборки, тесты и развертывания. Вы также можете использовать сторонние решения для CI/CD, такие как Jenkins. Перейдите к обзору Azure Pipeline, чтобы узнать больше.

Azure Monitor собирает и сохраняет метрики и журналы, включая метрики платформы для служб Azure в решении и телеметрии приложений. Используйте эти данные для мониторинга приложения, настройки оповещений и панелей мониторинга и выполнения анализа первопричин сбоев. Azure Monitor интегрируется с Kubernetes для сбора метрик с контроллеров, узлов и контейнеров, а также журналов контейнеров и журналов главных узлов. Дополнительные сведения см. в обзоре Azure Monitor .

Диспетчер трафика Azure — это подсистема балансировки нагрузки на основе DNS, которая позволяет оптимально распределять трафик между службами в разных регионах Azure или развертываниях Azure Stack Hub. Диспетчер трафика также обеспечивает высокую доступность и скорость реагирования. Конечные точки приложения должны быть доступны извне. Существуют и другие локальные решения.

Контроллер входящего трафика Kubernetes предоставляет маршруты HTTP(S) к службам в кластере Kubernetes. Nginx или любой подходящий контроллер входящего трафика можно использовать для этой цели.

Helm — это диспетчер пакетов для развертывания Kubernetes, предоставляющий способ упаковки различных объектов Kubernetes, таких как Deployments, Services, Secret, в одну "диаграмму". Вы можете публиковать, развертывать, управлять версиями и обновлять объект диаграммы. Реестр контейнеров Azure можно использовать в качестве репозитория для хранения упакованных диаграмм Helm.

Рекомендации по проектированию

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

• Приложение использует собственные решения Kubernetes, чтобы избежать блокировки поставщика.
• Приложение использует архитектуру микрослужб.
• Azure Stack Hub не требует входящего трафика, но разрешает исходящие подключения к Интернету.

Эти рекомендации также применяются к реальным рабочим нагрузкам и сценариям.

Рекомендации по масштабируемости

Масштабируемость важна для обеспечения согласованного, надежного и эффективного доступа к приложению.

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

Уровень архитектуры	Влияет	Как?
Заявление	Заявление	Горизонтальное масштабирование на основе количества Pods, реплик и инстанций контейнеров
Кластер	Кластер Kubernetes	Количество узлов (от 1 до 50), размер виртуальной машины-SKU и пулы узлов (ядро AKS в Azure Stack Hub в настоящее время поддерживает только один пул узлов); с помощью команды масштабирования ядра AKS (вручную)
Инфраструктура	Azure Stack Hub	Количество узлов, емкости и единиц масштабирования в развертывании Azure Stack Hub

* Использование автоматического горизонтального масштабирования подов в Kubernetes (HPA); автоматическое масштабирование на основе метрик или вертикальное масштабирование посредством изменения размера экземпляров контейнеров (CPU/память).

Azure Stack Hub (уровень инфраструктуры)

Инфраструктура Azure Stack Hub является основой этой реализации, так как Azure Stack Hub работает на физическом оборудовании в центре обработки данных. При выборе оборудования Концентратора необходимо выбрать параметры ЦП, плотности памяти, конфигурации хранилища и количества серверов. Дополнительные сведения о масштабируемости Azure Stack Hub см. в следующих ресурсах:

• Общие сведения о планировании емкости для Azure Stack Hub
• Добавление дополнительных узлов единиц масштабирования в Azure Stack Hub

Кластер Kubernetes (уровень кластера)

Сам кластер Kubernetes состоит из компонентов IaaS Azure (Stack), включая вычислительные, хранилища и сетевые ресурсы. Решения Kubernetes включают главные и рабочие узлы, которые развертываются как виртуальные машины в Azure (и Azure Stack Hub).

• Узлы уровня управления (master) предоставляют основные службы Kubernetes и оркестрацию рабочих нагрузок приложений.
• Рабочие узлы (рабочие узлы) выполняют рабочие нагрузки приложения.

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

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

• Масштабируемость — масштабируемость кластера достигается путем масштабирования и увеличения количества главных и рабочих узлов, а также путем добавления дополнительных пулов узлов (недоступных в Azure Stack Hub сегодня). Масштабирование кластера можно выполнить на основе данных о производительности, собранных с помощью Аналитики контейнеров (Azure Monitor и Log Analytics).

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

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

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

• Рабочие нагрузки приложений . Ознакомьтесь с концепциями кластеров и рабочих нагрузок в основных понятиях Kubernetes для документа службы Azure Kubernetes. Эта статья поможет вам определить правильный размер виртуальной машины в зависимости от потребностей вычислений и памяти приложения.

Приложение (уровень приложения)

На прикладном уровне мы используем Horizontal Pod Autoscaler (HPA) в Kubernetes. HPA может увеличить или уменьшить количество реплик (экземпляров Pod или контейнеров) в рамках развертывания, опираясь на различные метрики (такие как использование центрального процессора (ЦП)).

Другим вариантом является масштабирование экземпляров контейнеров по вертикали. Это можно сделать, изменив объем запрошенного ЦП и памяти для определенного развертывания. Дополнительные сведения см. в статье "Управление ресурсами для контейнеров" в kubernetes.io.

Рекомендации по работе с сетями и подключением

Сеть и подключение также влияют на три уровня, упомянутые ранее для Kubernetes в Azure Stack Hub. В следующей таблице показаны слои и службы, которые они содержат:

Уровень	Влияет	Что?
Заявление	Заявление	Как приложение доступно? Будет ли это выставляться в Интернете?
Кластер	Кластер Kubernetes	API Kubernetes, виртуальная машина движка AKS, загрузка образов контейнеров (исходящий трафик), отправка данных мониторинга и телеметрии (исходящий трафик)
Инфраструктура	Azure Stack Hub	Доступность конечных точек управления Azure Stack Hub, таких как портал и конечные точки Azure Resource Manager.

Приложение

Для уровня приложений наиболее важно учитывать, предоставляется ли приложение и доступно из Интернета. С точки зрения Kubernetes, доступ к Интернету подразумевает открытие развертывания или pod с помощью службы Kubernetes или контроллера Ingress.

Опубликование приложения с помощью общедоступного IP-адреса через балансировщик нагрузки или контроллер входящего трафика не означает, что это приложение теперь доступно через Интернет. Azure Stack Hub может иметь общедоступный IP-адрес, который отображается только в локальной интрасети. Не все общедоступные IP-адреса действительно доступны в Интернете.

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

• Извлечение образов контейнеров, хранящихся в DockerHub или Реестре контейнеров Azure
• Получение диаграмм Helm
• Выдача данных Application Insights (или других данных мониторинга)

Для некоторых корпоративных сред может потребоваться использование прозрачных или непрозрачныхпрокси-серверов . Эти серверы требуют определенной конфигурации для различных компонентов нашего кластера. Документация по обработчику AKS содержит различные сведения о том, как разместить сетевые прокси-серверы. Дополнительные сведения см. в разделе "Ядро AKS" и прокси-серверы

Наконец, трафик между кластерами должен передаваться между экземплярами Azure Stack Hub. Пример развертывания состоит из отдельных кластеров Kubernetes, работающих в отдельных экземплярах Azure Stack Hub. Трафик между ними, например трафик репликации между двумя базами данных, является внешним трафиком. Внешний трафик должен направляться через VPN типа "сеть — сеть" или общедоступные IP-адреса Azure Stack Hub для подключения Kubernetes к двум экземплярам Azure Stack Hub:

Гроздь

Кластер Kubernetes не обязательно должен быть доступен через Интернет. Соответствующая часть – это API Kubernetes, используемый для управления кластером, например с помощью kubectl. Конечная точка API Kubernetes должна быть доступна всем, кто управляет кластером или развертывает приложения и службы на его основе. Этот раздел подробно рассматривается в разделе "Рекомендации по развертыванию (CI/CD) с точки зрения DevOps.

На уровне кластера также рассматриваются некоторые аспекты исходящего трафика:

• Обновления узлов (для Ubuntu)
• Данные мониторинга (отправленные в Azure LogAnalytics)
• Другие агенты, требующие исходящего трафика (относящиеся к среде развертывания)

Перед развертыванием кластера Kubernetes с помощью модуля AKS запланируйте окончательный проект сети. Вместо создания выделенной виртуальной сети может оказаться более эффективным развертывание кластера в существующей сети. Например, можно использовать существующее VPN-подключение типа "сеть — сеть", уже настроенное в среде Azure Stack Hub.

Инфраструктура

Инфраструктура ссылается на доступ к конечным точкам управления Azure Stack Hub. Конечные точки включают порталы клиента и администрирования, а также администратор Azure Resource Manager и конечные точки клиента. Эти конечные точки необходимы для работы Azure Stack Hub и ее основных служб.

Рекомендации по данным и хранилищу

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

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

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

В нашей архитектуре эти слои были рассмотрены:

Конфигурация

Конфигурация включает конфигурацию Azure Stack Hub, ядра AKS и самого кластера Kubernetes. Конфигурация должна быть автоматизирована как можно больше и храниться как инфраструктура как код в системе управления версиями на основе Git, например Azure DevOps или GitHub. Эти параметры не могут быть легко синхронизированы в нескольких развертываниях. Поэтому рекомендуется хранить и применять конфигурацию извне и использовать конвейер DevOps.

Приложение

Приложение должно храниться в репозитории на основе Git. При каждом развертывании, изменении приложения или аварийном восстановлении его можно легко развернуть с помощью Azure Pipelines.

Данные

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

Достижение этого дизайна зависит от выбора технологий. Ниже приведены некоторые примеры решения для реализации базы данных в высокодоступном режиме в Azure Stack Hub:

• Развертывание группы доступности SQL Server 2016 в Azure и Azure Stack Hub
• Развертывание высокодоступного решения MongoDB в Azure и Azure Stack Hub

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

• Задержка и сетевое соединение между центрами Azure Stack.
• Доступность удостоверений для служб и разрешений. Каждый экземпляр Azure Stack Hub интегрируется с внешним каталогом. Во время развертывания вы решили использовать идентификатор Microsoft Entra ID или федерацию идентификаторов Microsoft Entra ID. Таким образом, есть возможность использовать единое удостоверение для взаимодействия с несколькими независимыми экземплярами Azure Stack Hub.

Непрерывность бизнес-процессов и аварийное восстановление

Непрерывность бизнес-процессов и аварийное восстановление (BCDR) — это важный раздел в Azure Stack Hub и Azure. Основное различие заключается в том, что в Azure Stack Hub оператор должен управлять всем процессом BCDR. В Azure части BCDR автоматически управляются корпорацией Майкрософт.

BCDR влияет на те же области, которые упоминаются в предыдущем разделе "Данные и хранилище":

• Инфраструктура и конфигурация
• Доступность приложений
• Данные приложения

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

Инфраструктура и конфигурация

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

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

• Восстановление данных в Azure Stack Hub с помощью службы архивации инфраструктуры
• Включение резервного копирования для Azure Stack Hub на портале администрирования
• Восстановление после катастрофической потери данных
• Рекомендации по службе резервного копирования инфраструктуры

Azure Stack Hub — это платформа и структура, на которой будут развернуты приложения Kubernetes. Владелец приложения для приложения Kubernetes будет пользователем Azure Stack Hub с доступом, предоставленным для развертывания инфраструктуры приложений, необходимой для решения. Инфраструктура приложений в этом случае означает кластер Kubernetes, развернутый с помощью ядра AKS и окружающих служб. Эти компоненты развертываются в Azure Stack Hub в рамках ограниченного предложения Azure Stack Hub. Убедитесь, что предложение, принятое владельцем приложения Kubernetes, имеет достаточную емкость (выраженную в квотах Azure Stack Hub) для развертывания всего решения. Как рекомендуется в предыдущем разделе, развертывание приложения должно быть автоматизировано с помощью конвейеров инфраструктуры как кода и развертывания, таких как Azure DevOps Azure Pipelines.

Дополнительные сведения о предложениях и квотах Azure Stack Hub см. в обзоре служб Azure Stack Hub, планов, предложений и подписок.

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

Доступность приложения

Приложение не должно полагаться на резервные копии развернутого экземпляра. В качестве стандартной практики, разверните приложение полностью заново, следуя принципам "Инфраструктура как код". Например, повторное развертывание с помощью Azure DevOps Azure Pipelines. Процедура BCDR должна включать повторное развертывание приложения в том же или другом кластере Kubernetes.

Данные приложения

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

Рекомендуется использовать следующие способы обеспечения целостности:

• Собственное решение резервного копирования для конкретной базы данных.
• Решение для резервного копирования, которое официально поддерживает резервное копирование и восстановление типа базы данных, используемого приложением.

Это важно

Не сохраняйте данные резервного копирования в том же экземпляре Azure Stack Hub, где находятся данные приложения. Полный сбой экземпляра Azure Stack Hub также компрометирует резервные копии.

Вопросы доступности

Kubernetes в Azure Stack Hub, развернутый с помощью AKS Engine, не является управляемой службой. Это автоматическое развертывание и настройка кластера Kubernetes с помощью Инфраструктуры Azure как службы (IaaS). Таким образом, он обеспечивает ту же доступность, что и базовая инфраструктура.

Инфраструктура Azure Stack Hub уже устойчива к сбоям и предоставляет такие возможности, как группы доступности для распространения компонентов между несколькими доменами сбоя и обновления. Но базовая технология (отказоустойчивая кластеризация) по-прежнему вызывает некоторое время простоя для виртуальных машин на затронутом физическом сервере, если произошел сбой оборудования.

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

Клиенты, у которых есть один кластер Kubernetes, обычно подключаются к IP-адресу службы или DNS-имени данного приложения. В развертывании с несколькими кластерами клиенты должны подключаться к DNS-имени диспетчера трафика, которое указывает на службы или входящий трафик в каждом кластере Kubernetes.

Замечание

Этот шаблон также рекомендуется использовать для кластеров AKS (управляемых) в Azure.

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

Вопросы идентификации и безопасности

Идентификация и безопасность являются важными разделами. Особенно если решение охватывает независимые экземпляры Azure Stack Hub. Kubernetes и Azure (включая Azure Stack Hub) имеют различные механизмы управления доступом на основе ролей (RBAC):

• Azure RBAC управляет доступом к ресурсам в Azure (и Azure Stack Hub), включая возможность создания новых ресурсов Azure. Разрешения могут назначаться пользователям, группам или субъектам-службам. (Учетная запись службы является удостоверением безопасности, используемым приложениями.)
• Kubernetes RBAC контролирует разрешения для API Kubernetes. Например, создание модулей pod и перечисление модулей pod — это действия, которые могут быть авторизованы (или запрещены) пользователю через RBAC. Чтобы назначить пользователям разрешения Kubernetes, создайте роли и привязки ролей.

Идентификация Azure Stack Hub и RBAC

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

• Идентификатор Microsoft Entra — можно использовать только в подключенной среде.
• Федерация Microsoft Entra ID с традиционным лесом Active Directory может использоваться как в подключенной среде, так и в отключенной.

Поставщик удостоверений управляет пользователями и группами, включая проверку подлинности и авторизацию для доступа к ресурсам. Доступ можно предоставить ресурсам Azure Stack Hub, таким как подписки, группы ресурсов и отдельные ресурсы, такие как виртуальные машины или подсистемы балансировки нагрузки. Чтобы обеспечить согласованную модель доступа, следует использовать одни и те же группы (прямые или вложенные) для всех Azure Stack Hub. Ниже приведен пример конфигурации:

Пример содержит выделенную группу для определенной цели. Например, чтобы предоставить разрешения участника для группы ресурсов, содержащей инфраструктуру кластера Kubernetes в определенном экземпляре Azure Stack Hub (здесь "Участник кластера Сиэтл K8s"). Затем эти группы вложены в общую группу, содержащую подгруппы для каждого Azure Stack Hub.

Теперь у примера пользователя будут разрешения "Участник" для обеих групп ресурсов, содержащих весь набор ресурсов инфраструктуры Kubernetes. Пользователь имеет доступ к ресурсам в обоих экземплярах Azure Stack Hub, поскольку экземпляры используют одного и того же идентификационного провайдера.

Это важно

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

Идентификация Kubernetes и RBAC

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

API Kubernetes (например, доступ к которым осуществляется с помощью kubectl) также защищен учетными записями служб, включая учетную запись службы "администратор кластера" по умолчанию. Учетные данные для этой учетной записи службы изначально хранятся в .kube/config файле на главных узлах Kubernetes.

Управление секретами и учетные данные приложения

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

• Azure Key Vault
• Секреты Kubernetes
• 3-сторонние решения, такие как HashiCorp Vault (работает в Kubernetes)

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

Исправление и обновление

Процесс исправления и обновления (PNU) в службе Azure Kubernetes частично автоматизирован. Обновления версий Kubernetes активируются вручную, а обновления системы безопасности применяются автоматически. Эти обновления могут включать исправления безопасности ОС или обновления ядра. AKS не перезагружает эти узлы Linux автоматически, чтобы завершить процесс обновления.

Процесс PNU для кластера Kubernetes, развернутого с помощью AKS Engine на Azure Stack Hub, является неуправляемым и требует ручного управления со стороны оператора кластера.

Ядро AKS помогает выполнять две наиболее важные задачи:

• Обновление до новой версии образа Kubernetes и базового образа ОС
• Обновление только базового образа ОС

Новые базовые образы ОС содержат последние исправления безопасности ОС и обновления ядра.

Механизм автоматического обновления автоматически устанавливает обновления системы безопасности, выпущенные до того, как новая версия базового образа ОС доступна в Azure Stack Hub Marketplace. Автоматическое обновление включается по умолчанию и устанавливает обновления безопасности автоматически, но не перезагружает узлы кластера Kubernetes. Перезагрузка узлов может быть автоматизирована с помощью с открытым исходным кодом Kubernetes REboot Демон(kured). Kured отслеживает узлы Linux, которым требуется перезагрузка, затем автоматически обрабатывает перепланировку работающих pod'ов и процесс перезагрузки узлов.

Вопросы, которые следует учитывать при развертывании (CI/CD)

Azure и Azure Stack Hub предоставляют те же интерфейсы REST API Azure Resource Manager. Эти API рассматриваются так же, как и любое другое облако Azure (Azure, Azure China 21Vianet, Azure для государственных организаций). Существуют различия в версиях API между облаками, и Azure Stack Hub предоставляет только подмножество служб. URI конечной точки управления также отличается для каждого облака и каждого экземпляра Azure Stack Hub.

Помимо незначительных различий, REST API Azure Resource Manager обеспечивают согласованный способ взаимодействия как с Azure, так и с Azure Stack Hub. Этот же набор инструментов можно использовать здесь, как и в любом другом облаке Azure. Вы можете использовать Azure DevOps, такие как Jenkins или PowerShell, для развертывания и оркестрации служб в Azure Stack Hub.

Рекомендации

Одним из основных различий в развертывании Azure Stack Hub является вопрос о специальных возможностях Интернета. Специальные возможности Интернета определяют, следует ли выбрать размещенный корпорацией Майкрософт или локальный агент сборки для заданий CI/CD.

Локальный агент может выполняться поверх Azure Stack Hub (как виртуальная машина IaaS) или в сетевой подсети, которая может получить доступ к Azure Stack Hub. Перейдите к агентам Azure Pipelines , чтобы узнать больше о различиях.

На следующем рисунке вы можете решить, требуется ли локальный агент сборки или агент сборки, размещенный корпорацией Майкрософт:

• Доступны ли конечные точки управления Azure Stack Hub через Интернет?
  • Да: Мы можем использовать Azure Pipelines с агентами, размещаемыми Microsoft, для подключения к Azure Stack Hub.
  • Нет. Нам нужны автономные агенты, которые могут подключаться к конечным точкам управления Azure Stack Hub.
• Доступен ли наш кластер Kubernetes через Интернет?
  • Да. Мы можем использовать Azure Pipelines с агентами, размещенными корпорацией Майкрософт, для взаимодействия непосредственно с конечной точкой API Kubernetes.
  • Нет. Нам нужны автономные агенты, которые могут подключаться к конечной точке API кластера Kubernetes.

В сценариях, когда конечные точки управления Azure Stack Hub и API Kubernetes доступны через Интернет, развертывание может использовать размещенный корпорацией Майкрософт агент. Это развертывание приводит к архитектуре приложения следующим образом:

Если конечные точки Azure Resource Manager, API Kubernetes или оба не доступны напрямую через Интернет, мы можем использовать локальный агент сборки для выполнения шагов конвейера. Эта конструкция требует меньшего количества подключений и может быть развернута только с помощью локального сетевого подключения к конечным точкам Azure Resource Manager и API Kubernetes:

Замечание

Что касается сценариев без подключения? В сценариях, когда Azure Stack Hub или Kubernetes или оба из них не имеют конечных точек управления, подключенных к Интернету, для развертываний по-прежнему можно использовать Azure DevOps. Вы можете использовать локальный пул агентов (который является агентом DevOps, работающим локально или в Azure Stack Hub) или полностью размещенным локальным сервером Azure DevOps. Для локального агента требуется только исходящее подключение HTTPS (TCP/443).

Шаблон может использовать кластер Kubernetes (развернутый и оркестрированный движком AKS) в каждом экземпляре Azure Stack Hub. Он включает в себя приложение, состоящее из внешнего интерфейса, среднего уровня, внутренних служб (например, MongoDB) и контроллера входящего трафика на основе nginx. Вместо использования базы данных, размещенной в кластере K8s, можно использовать внешние хранилища данных. Параметры базы данных включают MySQL, SQL Server или любую базу данных, размещенную за пределами Azure Stack Hub или в IaaS. Такие конфигурации не входят в область действия.

Решения партнеров

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

Решения для хранения и данных

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

SCALITY

Scality обеспечивает хранилище веб-масштабирования, которое обеспечивает цифровые предприятия с 2009 года. Scality RING, наше программное хранилище, превращает сырьевые серверы x86 в неограниченный пул носителей для любого типа данных —файла и объекта — в масштабе петабайтов.

CLOUDIAN

Cloudian упрощает корпоративное хранилище с неограниченным масштабируемым хранилищем, которое объединяет массовые наборы данных в единую легко управляемую среду.

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

Дополнительные сведения о концепциях, представленных в этой статье:

• Масштабирование между облаками и геораспределяемые шаблоны приложений в Azure Stack Hub.
• Архитектура микрослужб в службе Azure Kubernetes (AKS).

Когда вы будете готовы протестировать пример решения, перейдите к руководству по развертыванию кластера Kubernetes с высоким уровнем доступности. Руководство по развертыванию содержит пошаговые инструкции по развертыванию и тестированию компонентов.