Архитектура кластера Kubernetes и рабочие нагрузки для AKS, включенные Azure Arc
Область применения: AKS в Azure Stack HCI 22H2, AKS на Windows Server
Служба Azure Kubernetes (AKS) в Azure Local и Windows Server — это платформа контейнеров Kubernetes корпоративного уровня, на основе azure Local. Она включает в себя ядро Kubernetes, специально созданный узел контейнеров Windows и узел контейнера Linux, поддерживаемый Корпорацией Майкрософт, с целью простого развертывания и управления жизненным циклом.
В этой статье представлены основные компоненты инфраструктуры Kubernetes, такие как плоскость управления, узлы и пулы узлов. Кроме того, здесь дается представление о ресурсах рабочих нагрузок, таких как модули pod, развертывания и наборы, а также о возможности группировать ресурсы в пространства имен.
Архитектура кластера Kubernetes
Kubernetes — это основной компонент AKS, включенный Azure Arc. AKS использует набор предопределенных конфигураций для эффективного развертывания кластеров Kubernetes и с учетом масштабируемости.
Операция развертывания создает несколько виртуальных машин Linux или Windows и объединяет их для создания кластеров Kubernetes.
Примечание.
Чтобы повысить надежность системы, при использовании нескольких общих томов кластера (CSVS) в кластере данные виртуальной машины по умолчанию автоматически распределяются по всем доступным CSV в кластере. Это гарантирует, что приложения сохраняются в случае сбоя CSV. Это относится только к новым установкам (а не к обновлениям).
Развернутая система готова получать стандартные рабочие нагрузки Kubernetes, масштабировать эти рабочие нагрузки или даже масштабировать количество виртуальных машин и количество кластеров вверх и вниз по мере необходимости.
Кластер Служба Azure Kubernetes имеет следующие компоненты:
- Кластер управления (также известный как узел AKS) предоставляет основной механизм оркестрации и интерфейс для развертывания одного или нескольких кластеров рабочей нагрузки.
- Кластеры рабочих нагрузок (также известные как целевые кластеры ) находятся в развертывании контейнерных приложений.
Управление 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 доступны следующие пространства имен:
- по умолчанию: пространство имен, в котором модули pod и развертывания создаются по умолчанию, если они не указаны. В небольших средах вполне допустимо развертывать все приложения в пространстве имен по умолчанию, не создавая дополнительные логические разделы. Если при любом взаимодействии с API Kubernetes, например через
kubectl get pods, не указано конкретное пространство имен, всегда используется пространство имен по умолчанию. - kube-system: пространство имен, в котором существуют основные ресурсы, такие как сетевые функции, такие как DNS и прокси-сервер, или панель мониторинга Kubernetes. Обычно вам не нужно развертывать приложения в этом пространстве имен.
- kube-public: пространство имен обычно не используется, но может использоваться для ресурсов, видимых во всем кластере, и может просматриваться любым пользователем.
Секреты
Секреты Kubernetes позволяют хранить конфиденциальные данные и управлять ими, такими как пароли, маркеры OAuth и ключи Secure Shell (SSH). По умолчанию Kubernetes хранит секреты как незашифрованные строки в кодировке Base64, и их можно получить как обычный текст любым пользователем с доступом к API. Дополнительные сведения см. в разделе "Секреты Kubernetes".
перенос постоянных томов;
Постоянный том — это ресурс хранилища в кластере Kubernetes, подготовленный администратором или динамически подготовленный с помощью классов хранилища. Чтобы использовать постоянные тома, pod запрашивает доступ с помощью PersistentVolumeClaim. Дополнительные сведения см. в разделе "Постоянные тома".
Развертывания смешанной ОС
Если данный кластер рабочей нагрузки состоит из рабочих узлов Linux и Windows, его необходимо запланировать на ОС, которая может поддерживать подготовку рабочей нагрузки. Kubernetes предлагает два механизма для обеспечения того, чтобы рабочие нагрузки приземлились на узлах с целевой операционной системой:
- Селектор узлов — это простое поле в спецификации pod, которое ограничивает выполнение модулей pod только на здоровые узлы, соответствующие операционной системе.
- Ограничения и терпимые элементы работают вместе, чтобы гарантировать, что модули pod не запланированы на узлы непреднамеренно. Узел можно "запятнать" таким образом, что он не принимает модули pod, которые явно не допускают его тон через "терпимое" в спецификации pod.
Дополнительные сведения см. в разделе селекторов узлов и селекторов и толерации.
Следующие шаги
В этой статье вы узнали об архитектуре кластера AKS, включенной Azure Arc, и компонентах кластера рабочей нагрузки. Дополнительные сведения об этих понятиях см. в следующих статьях: