Архитектура кластера Kubernetes и рабочие нагрузки для AKS, включенные Azure Arc

  • Статья

Область применения: AKS в Azure Stack HCI 22H2, AKS в Windows Server

Служба Azure Kubernetes (AKS) в Azure Stack HCI и Windows Server — это платформа контейнеров Kubernetes корпоративного уровня на платформе Azure Stack HCI. Она включает в себя поддерживаемые корпорацией Майкрософт основные компоненты Kubernetes, специально созданный узел контейнеров Windows и узел контейнеров Linux, поддерживаемый корпорацией Майкрософт, с целью простого развертывания и управления жизненным циклом.

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

Архитектура кластера Kubernetes

Kubernetes — это основной компонент AKS, включенный Azure Arc. AKS использует набор предопределенных конфигураций для эффективного развертывания кластеров Kubernetes с учетом масштабируемости.

Операция развертывания создает несколько виртуальных машин Linux или Windows и объединяет их для создания кластеров Kubernetes.

Примечание

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

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

Кластер Служба Azure Kubernetes содержит следующие компоненты:

  • Кластер управления (также известный как узел AKS) предоставляет основной механизм оркестрации и интерфейс для развертывания одного или нескольких кластеров рабочей нагрузки и управления ими.
  • Кластеры рабочей нагрузки (также называемые целевыми кластерами) — это кластеры, где развертываются контейнерные приложения.

Иллюстрация, показывающая техническую архитектуру Служба Azure Kubernetes в Azure Stack HCI и Windows Server.

Управление AKS с поддержкой Arc

Вы можете управлять AKS с помощью следующих параметров управления:

  • Windows Admin Center предлагает интуитивно понятный пользовательский интерфейс для оператора Kubernetes для управления жизненным циклом кластеров.
  • Модуль PowerShell упрощает скачивание, настройку и развертывание AKS. Модуль PowerShell также поддерживает развертывание и настройку других кластеров рабочей нагрузки, а также перенастройку существующих кластеров.

Кластер управления

При создании кластера Kubernetes кластер управления создается и настраивается автоматически. Этот кластер управления отвечает за подготовку кластеров рабочей нагрузки, в которых выполняются рабочие нагрузки, и управление ими. Кластер управления включает следующие основные компоненты Kubernetes:

  • Сервер API: сервер API предоставляет базовые API Kubernetes. Этот компонент обеспечивает взаимодействие со средствами управления, такими как Windows Admin Center, модули PowerShell или kubectl.
  • Подсистема балансировки нагрузки. Подсистема балансировки нагрузки — это отдельная выделенная виртуальная машина Linux с правилом балансировки нагрузки для сервера API кластера управления.

Кластер рабочей нагрузки

Кластер рабочей нагрузки — это высокодоступное развертывание Kubernetes с использованием виртуальных машин Linux для запуска компонентов уровня управления Kubernetes и рабочих узлов Linux. Виртуальные машины windows Server Core используются для установки рабочих узлов Windows. Может существовать один или несколько кластеров рабочей нагрузки, управляемых одним кластером управления.

Компоненты кластера рабочей нагрузки

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

Уровень управления

  • Сервер API: сервер API позволяет взаимодействовать с API Kubernetes. Этот компонент обеспечивает взаимодействие со средствами управления, такими как Windows Admin Center, модули PowerShell или kubectl.
  • Etcd. Etcd — это распределенное хранилище ключей и значений, в котором хранятся данные, необходимые для управления жизненным циклом кластера. Он сохраняет состояние уровня управления.

Подсистема балансировки нагрузки

Подсистема балансировки нагрузки — это виртуальная машина под управлением Linux и HAProxy + KeepAlive для предоставления служб балансировки нагрузки для кластеров рабочей нагрузки, развернутых кластером управления. Для каждого кластера рабочей нагрузки AKS добавляет по крайней мере одну виртуальную машину подсистемы балансировки нагрузки. Любая служба Kubernetes типа LoadBalancer , созданная в кластере рабочей нагрузки, в конечном итоге создает правило балансировки нагрузки на виртуальной машине.

Рабочие узлы

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

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

Модули pod

Для запуска экземпляров приложения Kubernetes использует модули pod. Каждый pod соответствует одному экземпляру приложения. Как правило, модули pod имеют сопоставление 1:1 с контейнером, хотя существуют сложные сценарии, в которых pod может содержать несколько контейнеров. Эти объекты pod с несколькими контейнерами планируются вместе на одном узле, что дает возможность контейнерам совместно использовать связанные ресурсы. Дополнительные сведения см. в обзоре модулей pod Kubernetes и документации по жизненному циклу pod Kubernetes.

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

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

StatefulSet и DaemonSet

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

  • StatefulSets. StatefulSet похож на развертывание в том, что создается один или несколько идентичных модулей pod и управляются ими. Реплики в StatefulSet следуют корректному, последовательному подходу к развертыванию, масштабированию, обновлению и завершению. При использовании StatefulSet (по мере переноса реплик) соглашение об именовании, сетевые имена и хранилище сохраняются. Реплики в StatefulSet планируются и выполняются на любом доступном узле в кластере Kubernetes. Если необходимо убедиться, что хотя бы один модуль pod в наборе выполняется на узле, можно использовать DaemonSet. Дополнительные сведения см. в документации по StatefulSet в Kubernetes.
  • DaemonSets: для конкретных потребностей в сборе журналов или мониторинге может потребоваться запустить данный модуль pod на всех или выбранных узлах. DaemonSet снова используется для развертывания одного или нескольких идентичных модулей pod, но контроллер DaemonSet гарантирует, что каждый указанный узел запускает экземпляр pod. Дополнительные сведения см. в документации по DaemonSet в Kubernetes.

Пространства имен

Ресурсы Kubernetes, такие как модули pod и развертывания, логически группируются в пространство имен. Эти группировки предоставляют способ логического разделения кластеров рабочей нагрузки и ограничения доступа к созданию, просмотру ресурсов и управлению ими. Например, вы можете создать отдельные пространства имен для разных бизнес-подразделений. Пользователи смогут взаимодействовать только с ресурсами из назначенных им пространств имен. Дополнительные сведения см. в документации по пространствам имен в Kubernetes.

При создании кластера Служба Azure Kubernetes в AKS, включенном Arc, доступны следующие пространства имен:

  • default: пространство имен, в котором модули pod и развертывания создаются по умолчанию, если они не указаны. В небольших средах вполне допустимо развертывать все приложения в пространстве имен по умолчанию, не создавая дополнительные логические разделы. Если при любом взаимодействии с API Kubernetes, например через kubectl get pods, не указано конкретное пространство имен, всегда используется пространство имен по умолчанию.
  • kube-system: пространство имен, в котором существуют основные ресурсы, например сетевые функции, такие как DNS и прокси-сервер, или панель мониторинга Kubernetes. Обычно вам не нужно развертывать приложения в этом пространстве имен.
  • kube-public: пространство имен обычно не используется, но может использоваться для того, чтобы ресурсы были видимы во всем кластере и могли просматриваться любым пользователем.

Секреты

Секреты Kubernetes позволяют хранить конфиденциальную информацию, например пароли, маркеры OAuth и ключи SSH, и управлять ими. По умолчанию Kubernetes хранит секреты в виде незашифрованных строк в кодировке Base64, и любой пользователь с доступом к API может получить их в виде обычного текста. Дополнительные сведения см. в разделе Секреты Kubernetes.

Постоянные тома

Постоянный том — это ресурс хранилища в кластере Kubernetes, подготовленный администратором или динамически подготовленный с помощью классов хранения. Чтобы использовать постоянные тома, модули pod запрашивают доступ с помощью PersistentVolumeClaim. Дополнительные сведения см. в разделе Постоянные тома.

Смешанные развертывания ОС

Если данный кластер рабочей нагрузки состоит из рабочих узлов Linux и Windows, его необходимо запланировать на ОС, которая может поддерживать подготовку рабочей нагрузки. Kubernetes предлагает два механизма для обеспечения того, чтобы рабочие нагрузки помещались на узлы с целевой операционной системой:

  • Селектор узлов — это простое поле в спецификации pod, которое ограничивает планирование модулей pod только на работоспособных узлах, соответствующих операционной системе.
  • Ограничения и разрешения работают вместе, чтобы гарантировать, что модули pod не будут планироваться на узлах непреднамеренно. Узел может быть "запятнан" таким образом, что он не принимает модули pod, которые явно не допускают его запятнание с помощью "допуска" в спецификации pod.

Дополнительные сведения см. в разделе селекторы узлов , а также ограничения и допуски.

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

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