Начало работы с реестром кластеров

Повышение устойчивости облачно-родных сетевых функций с помощью реестра кластеров Azure Operator Service Manager (AOSM)

История документов

  • Создано и опубликовано: 26 июля 2024 г.
  • Обновлено для HA: 16 октября 2024 г.
  • Обновлено для GC: 5 ноября 2024 г.

Зависимости компонентов

Для этой функции требуется следующая минимальная среда:

  • Минимальная версия API ARM AOSM: 2023-09-01
  • Первая версия, нет высокой доступности (HA) для расширения сетевой функции (NF) Kubernetes: 1.0.2711-7
  • Первая версия с расширением HA для kubernetes NF: 2.0.2810-144
  • Первая версия с расширением GC для NF kubernetes: 2.0.2860-160

Общие сведения о реестре кластеров

Реестр кластеров Azure Operator Service Manager (AOSM) позволяет хранить локальную копию образов контейнеров в кластере Nexus K8s. Если контейнерная сетевая функция (CNF) установлена с включенным реестром кластера, образы контейнеров извлекаются из удаленного хранилища артефактов AOSM и сохраняются в этом локальном реестре кластеров. Реестр кластеров, используя мутирующий веб-перехватчик, автоматически перехватывает запросы образов и заменяет локальный путь реестра, чтобы избежать изменений упаковки издателя. При помощи реестра кластера доступ CNF к образам контейнеров сохраняется даже при потере подключения к удаленному хранилищу артефактов.

Ключевые варианты использования и преимущества

Облачные собственные сетевые функции (CNF) нуждаются в доступе к образам контейнеров, а не только во время первоначального развертывания с помощью хранилища артефактов AOSM, но и для поддержания работы сетевой функции. Ниже приведены некоторые из следующих сценариев:

  • Перезапуск Pod: остановка и повторный запуск Pod может привести к тому, что узел в кластере загружает образы контейнеров из реестра.
  • Операции планировщика Kubernetes: во время назначения модулей на узлы в соответствии с правилами профиля планировщика, если новый узел не содержит локально кэшированные образы контейнеров, узел загружает образы контейнеров из реестра.

Преимущества использования реестра кластеров AOSM:

  • Предоставляет необходимые локальные образы, чтобы предотвратить нарушение работы CNF, когда подключение к хранилищу артефактов AOSM потеряно.
  • Уменьшает количество извлечения изображений в хранилище артефактов AOSM, так как каждый узел кластера теперь извлекает образы только из локального реестра.
  • Преодолевает проблемы с неправильно сформированными URL-адресами реестра, используя мутирующий веб-перехватчик для замены правильного пути URL-адреса локального реестра.

Синтаксис команды реестра кластера

Реестр кластеров AOSM активируется с помощью расширения Arc K8s для «Оператора сетевых функций» (NFO). В следующем интерфейсе командной строки показано, как реестр кластеров включен в кластере Nexus K8s.

az k8s-extension create --cluster-name
                        --cluster-type {connectedClusters}
                        --extension-type {Microsoft.Azure.HybridNetwork}
                        --name
                        --resource-group
                        --scope {cluster}
                        --release-namespace {azurehybridnetwork}
                        --release-train {preview, stable}
                        --config Microsoft.CustomLocation.ServiceAccount=azurehybridnetwork-networkfunction-operator
                        [--auto-upgrade {false, true}]
                        [--config global.networkfunctionextension.enableClusterRegistry={false, true}]
                        [--config global.networkfunctionextension.enableLocalRegistry={false, true}]
                        [--config global.networkfunctionextension.enableEarlyLoading={false,true}]
                        [--config global.networkfunctionextension.clusterRegistry.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.storageClassName=]
                        [--config global.networkfunctionextension.clusterRegistry.storageSize=]
                        [--config global.networkfunctionextension.webhook.pod.mutation.matchConditionExpression=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold=]
                        [--version]

Если функция реестра кластера включена в расширение Arc K8s оператора сетевых функций, все образы контейнеров, развернутые из хранилища артефактов AOSM, доступны локально в кластере Nexus K8s. Пользователь может выбрать постоянный размер хранилища для реестра кластера.

Примечание.

Если пользователь не предоставляет никаких входных данных, используется постоянный том по умолчанию размером 100 ГБ.

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

Функция реестра кластеров развертывает поддерживающие поды на целевом edge-кластере для поддержки расширения NFO.

Согласователь компонентов

  • Этот основной модуль pod заботится о согласовании настраиваемых объектов ресурсов компонента ,созданных K8sBridge с помощью поставщика ресурсов (RP), гибридного ретранслятора и агента Arc, работающего Microsoft.Kubernetes в кластере.

Изменение веб-перехватчика pod

  • Эти поды реализуют мутирующие допускающие вебхуки Kubernetes, обслуживая экземпляр мутирующего API. Мутаный API выполняет две действия:
    • Он изменяет путь реестра образов к IP-адресу локального реестра, заменив хранилище артефактов AOSM в реестре контейнеров Azure (ACR).
    • Он создает артефакт CR в пограничном кластере.

Примиритель артефактов

  • Этот pod примирит артефакты CROs, созданные мутировавшим веб-перехватчиком.

Реестр

  • Этот модуль pod сохраняет и извлекает образы контейнеров для CNF.

Рекомендации по обеспечению высокого уровня доступности и устойчивости

Расширение AOSM NF опирается на мутирующий веб-перехватчик и использует граничный реестр для поддержки ключевых функций.

  • Внедрение helm charts без необходимости настройки указания пути к образу.
  • Локальный реестр кластеров для ускорения операций с подами и поддержки работы в отключенном режиме. Эти основные компоненты должны быть высокодоступными и устойчивыми.

Сведения о ВД (Высокой доступности) режиме работы

С включенной поддержкой высокой доступности реестр кластеров и pod'ы webhook поддерживают replicaset с минимум тремя и максимум пятью репликами. Конфигурация ключа набора реплик выглядит следующим образом:

  • Используется стратегия постепенного развертывания обновления.
  • PodDisruptionBudgets (PDB) используются для доступности во время добровольных сбоев.
  • Механизм анти-аффинности Pod используется для равномерного распределения pod по узлам.
  • Проверка готовности используется, чтобы убедиться, что поды готовы к обслуживанию трафика.
  • Модули рабочей нагрузки pod AOSM назначаются только пулу системных узлов.
  • Модули Pod масштабируются горизонтально при нагрузке на ЦП и память.

Копии

  • Кластер с несколькими копиями или репликами приложения обеспечивает первый уровень избыточности. Реестр кластера и веб-перехватчик задаются как «kind:deployment» с минимум тремя репликами и максимум пятью репликами.

СтратегияРазвертывания

  • Стратегия rollingUpdate используется для достижения обновлений без простоя и поддержки постепенного развертывания приложений. Конфигурация maxUnavailable по умолчанию позволяет выводить из эксплуатации только один pod одновременно, пока не будет создано достаточно pod для удовлетворения политики избыточности.

Бюджет сбоя pod

  • Бюджет сбоя политики (PDB) защищает модули pod от добровольных нарушений и развертывается вместе с объектами Deployment, ReplicaSet или StatefulSet. Для модулей pod оператора AOSM используется PDB с параметром minAvailable 2.

Анти-аффинность pod

  • Анти-аффинность Pod регулирует распределение подов приложений по нескольким узлам в вашем кластере. С включенной функцией HA, AOSM реализует следующие правила анти-аффинности:
    • Используется предпочтительный тип правилаDuringSchedulingIgnoredDuringExecution(Soft). При мягком планировании, когда доступны топологии, удовлетворяющие критериям предпочтения, Kubernetes осуществляет расписание пода. Если такие топологии недоступны, pod всё равно может быть запланирован на других узлах, которые не соответствуют предпочтениям.
    • Ключ топологии используется на основе значения kubernetes.io/hostname.
    • Используется вес, равный 100.

Привязанность узлов

Размещение узлов Nexus равномерно распределено по зонам по замыслу конструкции, что приводит к резервированию зон. AOSM далее равномерно распределяет pods по узлам, используя следующие правила:

  • Предпочитать узлы без роли "плоскости управления" (вес: 10)
  • Предпочитать узлы с режимом системы (вес: 20)

Хранилище

  • Так как в пограничном реестре AOSM есть несколько реплик, которые распределяются по узлам, постоянный том должен поддерживать режим доступа ReadWriteManyX (RWX). ПВХ 'nexus-shared; том доступен в кластерах Nexus и поддерживает режим доступа RWX.

Мониторинг с помощью проб готовности

  • AOSM использует пробы готовности http, чтобы узнать, когда контейнер готов к приему трафика. Модуль считается готовым, когда все контейнеры готовы. Когда модуль Pod не готов, он удаляется из подсистем балансировки нагрузки службы.

Пул системных узлов

  • Все поды оператора AOSM назначаются в пул системных узлов. Этот пул предотвращает влияние неправильно настроенных или вредоносных модулей pod на системные модули pod.

Горизонтальное масштабирование

  • В Kubernetes функция HorizontalPodAutoscaler (HPA) автоматически обновляет ресурс рабочей нагрузки с целью автоматического масштабирования рабочей нагрузки в соответствии с требованиями. Для подов оператора AOSM настроены следующие параметры политики HPA.
    • Минимум три экземпляра.
    • Максимальное количество реплик — пять.
    • Целевой средний уровень использования для центрального процессора и памяти с 80 %.

Ограничения ресурсов

  • Ограничения ресурсов используются для предотвращения перегрузки ресурсов на узлах, где выполняются pod'ы AOSM. AOSM использует два параметра ресурса для ограничения потребления ЦП и памяти.
    • Запрос ресурса — минимальный объем, который должен быть зарезервирован для модуля pod. Это значение должно быть задано как использование ресурсов при обычной загрузке приложения.
    • Ограничение ресурсов — максимальная величина, которую должен использовать pod, если использование достигает этого предела, он завершится. Все контейнеры операторов AOSM настраиваются с соответствующим запросом, ограничением для ЦП и памяти.

Известные ограничения HA

  • Кластеры Nexus AKS (NAKS) с одним активным узлом в пуле агентов системы не подходят для высокой доступности. Топология в рабочей среде Nexus должна использовать как минимум три активных узла в пуле системных агентов.
  • Класс хранилища nexus-shared — это служба хранилища сетевой файловой системы (NFS). Эта служба хранилища NFS доступна для сети облачных служб (CSN). Любой кластер Nexus Kubernetes, подключенный к CSN, может подготавливать постоянный объём из этого общего пула хранилища. В настоящее время пул хранения ограничен максимальным размером 1 ТиБ в версии Network Cloud (NC) 3.10, тогда как NC 3.12 предлагает опцию на 16 ТиБ.
  • Pod Anti affinity касается только первоначального размещения модулей pod; последующее масштабирование и восстановление соответствует стандартной логике планирования K8s.

Автоматическая очистка реестра кластеров

При включении расширение AOSM NFO запускает фоновое задание сборки мусора (GC) для регулярного очистки реестра кластеров NAKS. Сборка мусора — это процесс удаления артефактов из файловой системы, которые больше не упоминаются ни одним манифестом. С помощью сборки мусора пользователь может лучше управлять дисковыми пространствами, используемыми реестром кластера. Сборка мусора также является соображением безопасности, когда желательно убедиться, что определенные слои больше не существуют в файловой системе. Задание GC выполняется по расписанию, проверяет, достигает ли использование реестра кластера указанное пороговое значение, а если да, инициирует процесс сборки мусора.

Очистите неиспользуемые манифесты образов

AOSM поддерживает ссылки между ресурсом владельца pod'а и потребляющими артефактами в реестре кластеров. После запуска процесса очистки реестра кластера определяются артефакты, которые не связаны с модулями, и выполняется мягкое удаление для их удаления из реестра кластера. Этот тип мягкого удаления не сразу освобождает память в реестре кластеров. Удаление файлов образов зависит от текущих параметров сборки мусора в реестре.

Примечание.

Ссылка между владельцем пода и его артефактами контейнеров гарантирует, что AOSM не удаляет артефакты по ошибке. Например, если модуль pod набора реплик исчезает, AOSM не разыменовывает артефакты. AOSM отменяет ссылки на артефакты только при удалении репликасета. Тот же принцип применяется к pods, управляемым заданиями Kubernetes и демонсетами.

Распределение сборки мусора

AOSM зависит от возможностей сборки мусора, предоставляемых Garbage collection | Public Distribution. AOSM реализует стандартный двухфазный процесс "разметки и очистки" для удаления артефактов и свободного места в хранилище реестра. Во-первых, соответствующие изображения помечены, а затем очищаются во время сверки только в том случае, если выполнены определённые условия.

Примечание.

Процесс GC требует, чтобы реестр кластера был в режиме только для чтения. В противном случае существует риск, что артефакты могут быть ошибочно удалены, что приводит к повреждению артефактов. При запуске GC реестр блокируется в режиме только для чтения до 1 минуты. В течение этого времени AOSM откладывает новые операции до тех пор, пока блокировка реестра не будет освобождена.

Параметры автоматической очистки реестра кластерии

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

Вопросы и ответы

Можно ли использовать реестр кластеров AOSM с ранее развернутыми приложениями CNF?

Если приложение CNF уже развернуто без реестра кластера, образы контейнеров недоступны автоматически. Реестр кластеров необходимо включить перед развертыванием сетевой функции с помощью AOSM.

Можно ли изменить размер хранилища после развертывания?

Размер хранилища нельзя изменить после первоначального развертывания. Рекомендуется установить размер тома в 3–4 раза больше начального.

Можно ли перечислить файлы, хранящиеся в репозитории кластера?

Следующая команда может использоваться для перечисления файлов в формате, доступном для чтения.

 kubectl get artifacts -A -o jsonpath='{range .items[*]}{.spec.sourceArtifact}'

Эта команда должна создать следующие выходные данные:

 ppleltestpublisheras2f88b55037.azurecr.io/nginx:1.0.0
  • Last updated on