Подготовка технических ресурсов контейнера Azure для приложения Kubernetes
Статья
В этой статье содержатся технические ресурсы и рекомендации, которые помогут вам создать предложение контейнера в Azure Marketplace для приложения Kubernetes.
Проектирование, сборка и тестирование используемых ресурсов занимают время и требуют технических знаний не только о платформе Azure, но и о технологиях, используемых для создания предложения.
Ваша команда разработчиков должна не только хорошо разбираться во всем, что касается вашего решения, но и обладать знаниями о технологиях Майкрософт. В частности, вашим специалистам потребуется следующее:
Приложение должно быть основано на диаграмме Helm.
Диаграмма Helm не должна содержать .tgz архивные файлы; все файлы должны быть распаковлены.
Если у вас несколько чартов, можно включать другие чарты helm как вложенные чарты, кроме основного чарта helm.
Все ссылки на изображения и сведения о дайджесте должны быть включены в диаграмму. Никакие другие диаграммы или изображения не могут быть скачаны во время выполнения.
У вас должен быть активный клиент публикации или доступ к клиенту публикации и учетной записи Центра партнеров.
Вы должны были создать реестр контейнеров Azure (ACR), который принадлежит активному арендатору публикации, указанному выше. Вы отправите в него пакет облачных собственных приложений (CNAB). Дополнительные сведения см. в статье "Создание Реестр контейнеров Azure".
Если средство упаковки запущено вручную, Docker необходимо установить на локальном компьютере. Дополнительные сведения см. в разделе, посвященном серверной части WSL 2, в документации Docker для Windows или Linux. Это поддерживается только на компьютерах Linux или Windows AMD64.
Ограничения
Контейнер Marketplace поддерживает только образы AMD64 на платформе Linux.
Предложение Container Marketplace поддерживает развертывание в Управляемых AKS и Kubernetes с поддержкой Arc. Одно предложение может быть направлено только на один тип кластера: либо управляемый AKS, либо Kubernetes с поддержкой Arc.
Предложения для кластеров Kubernetes с поддержкой Arc поддерживают только предварительно определенные модели выставления счетов. Дополнительные сведения о моделях выставления счетов см. в статье "Планирование предложения контейнера Azure".
Отдельные контейнеры не поддерживаются.
Связанные шаблоны Azure Resource Manager не поддерживаются.
Обзор процесса публикации
Первым шагом для публикации предложения контейнера на основе приложений Kubernetes в Azure Marketplace является упаковка приложения в виде пакета облачных собственных приложений (CNAB). CNAB, состоящий из артефактов вашего приложения, сначала публикуется в частный Реестр контейнеров Azure (ACR), а затем отправляется в публичный ACR Microsoft и используется в качестве единственного артефакта, на который вы ссылаетесь в Центре партнеров.
Оттуда выполняется сканирование уязвимостей, чтобы обеспечить безопасность изображений. Наконец, приложение Kubernetes регистрируется в качестве типа расширения для кластера Служба Azure Kubernetes (AKS).
После публикации предложения ваше приложение использует функцию расширения кластеров AKS для управления жизненным циклом приложения в кластере AKS.
Предоставьте доступ к вашему реестру контейнеров Azure
В процессе публикации корпорация Майкрософт полностью копирует ваш CNAB из вашего ACR в специальный ACR от Azure Marketplace, принадлежащий корпорации Майкрософт. Образы передаются в общедоступный реестр, доступный для всех. На этом шаге требуется предоставить корпорации Майкрософт доступ к реестру. ACR должен находиться в том же клиенте Microsoft Entra, который связан с учетной записью Центра партнеров.
Корпорация Майкрософт имеет первое приложение, ответственное за обработку этого процесса с помощью id32597670-3e15-4def-8851-614ff48c1efa. Чтобы начать, создайте учетную запись службы, основанную на приложении.
Если у вашей учетной записи нет разрешения на создание субъекта-службы, az ad sp create возвращает сообщение об ошибке, которое содержит текст "Недостаточно привилегий для завершения операции". Чтобы создать учетную запись службы, обратитесь к администратору Microsoft Entra.
Azure CLI
az login
Проверьте, существует ли субъект-служба для приложения:
Azure CLI
az ad sp show --id32597670-3e15-4def-8851-614ff48c1efa
Если предыдущая команда не возвращает результатов, создайте новую учетную запись службы.
Azure CLI
az ad sp create --id32597670-3e15-4def-8851-614ff48c1efa
Запишите идентификатор сервисного принципала для использования в следующих шагах.
Затем получите полный идентификатор реестра:
Azure CLI
az acr show --name<registry-name>--query"id"--output tsv
Выходные данные должны выглядеть следующим образом.
Затем создайте назначение ролей, чтобы предоставить служебной учётной записи возможность запрашивать данные из вашего реестра, используя значения, полученные ранее.
az role assignment create --assignee<sp-id>--scope<registry-id>--role acrpull
Наконец, зарегистрируйте Microsoft.PartnerCenterIngestion поставщика ресурсов в той же подписке, которая использовалась для создания Реестр контейнеров Azure:
Azure CLI
az provider register --namespace Microsoft.PartnerCenterIngestion --subscription<subscription-id>--wait
Отслеживайте регистрацию и убедитесь, что она завершена, прежде чем продолжить:
Azure CLI
az provider show -n Microsoft.PartnerCenterIngestion --subscription<subscription-id>
Примечание
Если у вашей учетной записи нет разрешения на создание служебного принципала, New-AzADServicePrincipal вернёт сообщение об ошибке с текстом "Недостаточно привилегий для завершения операции". Чтобы создать служебный принципал, обратитесь к администратору Microsoft Entra.
PowerShell
Connect-AzAccount
Проверьте, существует ли представитель службы для идентификатора приложения:
Наконец, зарегистрируйте Microsoft.PartnerCenterIngestion поставщика ресурсов в той же подписке, которая использовалась для создания Реестр контейнеров Azure:
Сбор артефактов в соответствии с требованиями к формату пакета
Каждый CNAB состоит из следующих артефактов:
Диаграмма Helm
CreateUiDefinition
Шаблон ARM
Файл манифеста
Обновление диаграммы Helm
Убедитесь, что диаграмма Helm соответствует следующим правилам:
Все имена изображений и ссылки параметризируются и представлены в values.yaml виде ссылок global.azure.images. Обновите файл шаблона диаграммы Helm deployment.yaml, чтобы ссылаться на эти изображения. Это гарантирует, что блок изображения можно обновить, чтобы ссылаться на образы ACR в Azure Marketplace.
Если у вас несколько чартов, можно включить другие чарты в качестве субчартов помимо основного helm-чарта. Все зависимые ссылки на изображения helm-чартов потребуют обновления и должны указывать на изображения, включенные в основной чарт values.yaml.
При ссылке на изображения можно использовать теги или дайджесты. Однако важно отметить, что образы заново перенаправляются внутри системы, чтобы указывать на принадлежащий Microsoft Реестр контейнеров Azure (ACR). При обновлении тега новая версия CNAB должна быть отправлена в Azure Marketplace. Это нужно для того, чтобы изменения были отражены в развертываниях клиентов.
Выполните следующие действия, чтобы добавить идентификатор в модели выставления счетов: Для каждого ядра, Для каждого модуля, Для каждого узла.
Добавьте метку azure-extensions-usage-release-identifier идентификатора выставления счетов в Pod-спецификацию в ваших yaml-файлах нагрузки.
Если рабочая нагрузка указана как спецификации Deployments, ReplicaSets, StatefulSets или DaemonSets, добавьте эту метку в .spec.template.metadata.labels.
Если рабочая нагрузка указана в спецификациях Pod, добавьте эту метку под .metadata.labels.
Для модели выставления счетов perCore укажите CPU Request, включив поле resources:requests в манифест ресурса контейнера. Этот шаг необходим только для модели выставления счетов perCore.
Снимок экрана запросов ресурсов ЦП в файле pods.yaml. Содержимое напоминает пример файла модели выставления счетов на ядро, приведенного в этой статье.
Во время развертывания функция расширений кластера заменяет значение идентификатора выставления счетов именем экземпляра расширения.
Примеры, настроенные для развертывания приложения для голосования Azure, см. в следующих статьях:
Чтобы убедиться, что диаграмма Helm действительна, проверьте, можно ли установить ее в локальном кластере. Можно также использовать helm install --generate-name --dry-run --debug для обнаружения определенных ошибок создания шаблонов.
Создание и проверка createUiDefinition
CreateUiDefinition — это JSON-файл, определяющий элементы пользовательского интерфейса для портал Azure при развертывании приложения. Дополнительные сведения см. в разделе:
или см. пример определения пользовательского интерфейса, который запрашивает входные данные для нового или существующего выбора кластера и передает параметры в приложение.
После создания файла createUiDefinition.json для приложения необходимо протестировать взаимодействие с пользователем. Чтобы упростить тестирование, скопируйте содержимое файла в среду песочницы. Песочница отображает ваш пользовательский интерфейс в текущем полноэкранном режиме портала. Песочница — это рекомендуемый способ предварительного просмотра пользовательского интерфейса.
Создание шаблона Azure Resource Manager (ARM)
Шаблон ARM определяет ресурсы Azure для развертывания. По умолчанию вы развернете ресурс расширения кластера для приложения Azure Marketplace. При необходимости можно развернуть кластер AKS.
В настоящее время мы разрешаем только следующие типы ресурсов:
Microsoft.ContainerService/managedClusters
Microsoft.KubernetesConfiguration/extensions
Например, см. этот пример шаблона ARM, предназначенный для получения результатов из примера определения пользовательского интерфейса, связанного ранее, и передачи параметров в приложение.
Поток параметров пользователя
Важно понять, как параметры пользователя проходят через объекты, которые вы создаете и упаковываете.
В примере приложения для голосования Azure параметры изначально определяются при создании пользовательского интерфейса с помощью файла createUiDefinition.json:
Параметры экспортируются с помощью outputs раздела:
Снимок экрана примера createUiDefinition, упомянутого в этой статье. Отображаются выходные строки для заголовка приложения, 'value1' и 'value2'.
Оттуда значения передаются в шаблон Azure Resource Manager и распространяются на диаграмму Helm во время развертывания:
Наконец, значения передаются в диаграмму Helm, values.yaml как показано ниже.
Примечание
В этом примере extensionResourceName также параметризован и передается ресурсу расширения кластера. Аналогичным образом можно параметризовать другие свойства расширения, например включить автоматическое обновление для дополнительных версий. Дополнительные сведения о свойствах расширения кластера см. в дополнительных параметрах.
Создание файла манифеста
Манифест пакета — это yaml-файл, описывающий пакет и его содержимое, и сообщает средству упаковки, где находить зависимые артефакты.
Поля, используемые в манифесте, приведены следующим образом:
Имя.
Тип данных
Описание
applicationName
Строка
Имя приложения
издатель
Строка
Имя издателя
описание
Строка
Краткое описание пакета
версия
Строка в #.#.# формате
Строка версии, описывающая версию пакета приложения, может или не совпадать с версией двоичных файлов внутри.
helmChart
Строка
Локальный каталог, в котором можно найти диаграмму Helm относительно этого manifest.yaml
clusterARMTemplate
Строка
Локальный путь, в котором можно найти шаблон ARM, описывающий кластер AKS, соответствующий требованиям в поле ограничений.
uiDefinition
Строка
Локальный путь, по которому можно найти JSON-файл, описывающий опыт создания в Azure Portal
сервер реестра
Строка
ACR, в который должен быть загружен окончательный пакет CNAB
extensionRegistrationParameters
Коллекция
Спецификация параметров регистрации расширения. Включите как минимум defaultScope и в качестве параметра.
область по умолчанию
Строка
Область по умолчанию для установки расширения. Допустимые значения: cluster или namespace. При заданной области cluster, для каждого кластера разрешён только один экземпляр расширения. Если выбрана область namespace, то в пределах пространства имен разрешен только один экземпляр. Так как кластер Kubernetes может иметь несколько пространств имен, может существовать несколько экземпляров расширения.
пространство имен
Строка
(Необязательно) Укажите пространство имен, в который устанавливается расширение. Это свойство является обязательным, если defaultScope задано значение cluster. Ограничения именования пространств имен см. в разделе "Пространства имен" и DNS.
поддерживаемые типы кластеров
Коллекция
(Необязательно) Укажите типы кластеров, поддерживаемые приложением. Допустимые типы — managedClusters, connectedClusters. "managedClusters" относится к кластерам службы Azure Kubernetes (AKS). "connectedClusters" относится к кластерам Kubernetes с поддержкой Azure Arc. Если supportedClusterTypes не предоставлен, все дистрибутивы managedClusters поддерживаются по умолчанию. Если предоставлена поддержкаClusterTypes, а указанный тип кластера верхнего уровня не указан, все дистрибутивы и версии Kubernetes для этого типа кластера рассматриваются как неподдерживаемые. Для каждого типа кластера укажите список одного или нескольких дистрибутивов со следующими свойствами: -распределение — поддержка_распространения — неподдерживаемые версии
распределение
Список
Массив дистрибутивов, соответствующих типу кластера. Укажите имя конкретных дистрибутивов. Задайте для значения [All"] значение , чтобы указать, что поддерживаются все дистрибутивы.
поддержка распространения
Логический
Логическое значение, представляющее, поддерживаются ли указанные дистрибутивы. Если значение false, предоставление неподдерживаемых версий приводит к ошибке.
неподдерживаемые версии
Список
Список версий для указанных дистрибутивов, неподдерживаемых. Поддерживаемые операторы: — "=" Указанная версия не поддерживается. Например, "=1.2.12" — ">" Все версии, превышающие указанную версию, не поддерживаются. Например, ">1.1.13" — "<" Все версии меньше указанной версии не поддерживаются. Например, "<1.3.14" - "..." Все версии в диапазоне не поддерживаются. Например, "1.1.2...1.1.15" (включает значение справа и исключает левое значение)
Для примера, сконфигурированного для приложения для голосования, см. следующий пример файла манифеста.
Структура приложения
Поместите файл createUiDefinition, шаблон ARM и файл манифеста рядом с диаграммой Helm приложения.
Для примера правильно структурированного каталога см. пример Azure Vote.
Для примера приложения для голосования, поддерживающего кластеры Kubernetes с поддержкой Azure Arc, см. пример только для ConnectedCluster .
После добавления всех необходимых артефактов запустите средство container-package-app упаковки для проверки артефактов, сборки пакета и отправки пакета в Реестр контейнеров Azure.
Так как CNAB — это новый формат, и к нему нужно привыкнуть, мы создали образ Docker для container-package-app со стартовой средой и инструментами, необходимыми для успешного запуска средства упаковки.
У вас есть два варианта использования средства упаковки. Его можно использовать вручную или интегрировать в конвейер развертывания.
Запуск средства упаковки вручную
Последнюю версию средства упаковки можно извлечь из mcr.microsoft.com/container-package-app:latest.
Следующая команда Docker извлекает последний образ средства упаковки, а также подключает каталог.
Предположим, что ~\<path-to-content> — это каталог, содержащий содержимое для упаковки, следующая команда Docker монтирует ~/<path-to-content> в /data контейнера. Обязательно замените ~/<path-to-content> на местоположение вашего собственного приложения.
Выполните следующие команды в оболочке container-package-app контейнера. Обязательно замените <registry-name> на имя вашего ACR.
Bash
export REGISTRY_NAME=<registry-name>
az login
az acr login -n $REGISTRY_NAMEcd /data/<path-to-content>
Для проверки подлинности ACR существует два варианта. Один из вариантов — использование az login, как показано ранее, а второй — с помощью docker, выполнив команду docker login 'yourACRname'.azurecr.io. Введите имя пользователя и пароль (имя пользователя должно быть именем ACR, а пароль — созданным ключом, предоставленным в портале Azure) и запустите.
Bash
docker login <yourACRname.azurecr.io>
Предположим, что D:\<path-to-content> — это каталог, содержащий содержимое для упаковки. Следующая команда Docker монтирует d:/<path-to-content> в /data внутри контейнера. Обязательно замените d:/<path-to-content> на путь к вашему собственному приложению.
Затем выполните cpa verify, чтобы просмотреть артефакты и проверить их поочередно, устраняя любые сбои. Запуститеcpa buildbundle, когда вы будете готовы упаковать и отправить CNAB в Реестр контейнеров Azure. Команда cpa buildbundle запускает процесс проверки, создает пакет и отправляет пакет в Реестр контейнеров Azure.
Bash
cpa verify
Bash
cpa buildbundle
Примечание
Используйте cpa buildbundle --force только в том случае, если вы хотите перезаписать существующий тег. Если вы уже присоединили этот CNAB к предложению Azure Marketplace, увеличьте вместо этого версию в файле манифеста.
Узнайте, как создавать, развертывать, масштабировать и управлять контейнерными облачными приложениями с помощью приложений контейнеров Azure, Реестр контейнеров Azure и Azure Pipelines. (AZ-2003)
Создавайте комплексные решения в Microsoft Azure для создания Функции Azure, реализации веб-приложений и управления ими, разработке решений, использующих службу хранилища Azure, и т. д.
