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

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

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

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

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

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

Решение

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

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

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

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

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

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

Components

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

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 и контроллера объекта ingress NGINX. Подсистема балансировки нагрузки направляет внешний трафик (например, Интернет) на узлы и виртуальные машины, предлагающие определенную службу.

Реестр контейнеров Azure (ACR) используется для хранения закрытых образов Docker и диаграмм Helm, которые развертываются в кластере. Обработчик АКS может выполнять аутентификацию в Реестре контейнеров с помощью удостоверения Azure AD. Для Kubernetes не требуется ACR. Можно использовать другие реестры контейнеров, такие как Центр Docker.

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. Диспетчер трафика также обеспечивает высокую доступность и скорость реагирования. Конечные точки приложения должны быть доступны за пределами системы. Также доступны и другие локальные решения.

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

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

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

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

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

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

Вопросы масштабируемости

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

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

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

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

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).

• Узлы уровня управления (главные) предоставляют основные службы 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". Эта статья поможет вам определить соответствующий размер виртуальной машины в зависимости от необходимого для приложения объема вычислительных ресурсов и памяти.

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

На уровне приложения используется средство горизонтального автомасштабирования pod (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-адреса через Load Balancer или контроллер объекта ingress не обязательно означает, что приложение теперь доступно через Интернет. 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:

Cluster

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

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

• обновления узла (для 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 Hub.
• Доступность удостоверений для служб и разрешений. Каждый экземпляр Azure Stack Hub интегрируется с внешним каталогом. Во время развертывания вы используете либо Azure Active Directory (Azure AD), либо службы федерации Active Directory (AD FS). Таким образом, существует возможность использовать единый идентификатор, который может взаимодействовать с несколькими независимыми экземплярами 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, включая выходные данные. Эти файлы содержат конфиденциальную информацию, используемую для доступа к кластеру Kubernetes, поэтому она должна быть защищена от пользователей, не являющихся администраторами.

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

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

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

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

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

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

Важно!

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

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

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

Инфраструктура 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. Например, создание и перечисление модулей — это действия, которые могут быть авторизованы (или запрещены) для пользователя с помощью RBAC. Чтобы назначить пользователям разрешения Kubernetes, создайте роли и привязки ролей.

Удостоверение Azure Stack Hub и RBAC

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

• Azure AD можно использовать только в подключенной среде.
• ADFS для традиционного леса Active Directory можно использовать как в подключенной, так и в отключенной среде.

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

Пример содержит выделенную группу (с использованием AAD или ADFS) для определенной цели. Например, чтобы предоставить разрешения участника для группы ресурсов, содержащей инфраструктуру кластера Kubernetes в определенном экземпляре Azure Stack Hub (здесь — участник кластера Seattle K8). Затем эти группы вкладываются в общую группу, которая содержит подгруппы для каждого экземпляра 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
• Сторонние решения, такие как хранилище HashiCorp (под управлением Kubernetes).

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

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

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

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

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

• Обновление до новой версии Kubernetes и базового образа операционной системы.
• Обновление только версии базового образа операционной системы.

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

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

Рекомендации по развертыванию (CI/CD)

Azure и Azure Stack Hub предоставляют те же REST API Azure Resource Manager. Эти API обрабатываются как любые другие облака Azure (Azure, Azure для Китая (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, является доступность через Интернет. Доступность через Интернет определяет, следует ли использовать для заданий непрерывной поставки и непрерывной интеграции агент сборки, размещенный в Майкрософт, или локальный агент сборки.

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

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

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

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

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

Примечание

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

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

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

Существуют решения партнеров Майкрософт, которые могут расширить возможности 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 с высоким уровнем доступности. В этом руководстве содержатся пошаговые инструкции по развертыванию и тестированию компонентов.