KubernetesManifest@1. Задача "Развертывание в Kubernetes версии 1"

  • Статья

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

Синтаксис

# Deploy to Kubernetes v1
# Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts.
- task: KubernetesManifest@1
  inputs:
    #action: 'deploy' # 'bake' | 'createSecret' | 'delete' | 'deploy' | 'patch' | 'promote' | 'scale' | 'reject'. Action. Default: deploy.
    #connectionType: 'kubernetesServiceConnection' # 'azureResourceManager' | 'kubernetesServiceConnection'. Required when action != bake. Service connection type. Default: kubernetesServiceConnection.
    #kubernetesServiceConnection: # string. Alias: kubernetesServiceEndpoint. Required when action != bake && connectionType = kubernetesServiceConnection. Kubernetes service connection. 
    #azureSubscriptionConnection: # string. Alias: azureSubscriptionEndpoint. Required when action != bake && connectionType = azureResourceManager. Azure subscription. 
    #azureResourceGroup: # string. Required when action != bake && connectionType = azureResourceManager. Resource group. 
    #kubernetesCluster: # string. Required when action != bake && connectionType = azureResourceManager. Kubernetes cluster. 
    #useClusterAdmin: false # boolean. Optional. Use when connectionType = azureResourceManager. Use cluster admin credentials. Default: false.
    #namespace: # string. Namespace. 
    #strategy: 'none' # 'canary' | 'none'. Optional. Use when action = deploy || action = promote || action = reject. Strategy. Default: none.
    #trafficSplitMethod: 'pod' # 'pod' | 'smi'. Optional. Use when strategy = canary. Traffic split method. Default: pod.
    #percentage: '0' # string. Required when strategy = Canary && action = deploy. Percentage. Default: 0.
    #baselineAndCanaryReplicas: '1' # string. Required when strategy = Canary && action = deploy && trafficSplitMethod = SMI. Baseline and canary replicas. Default: 1.
    #manifests: # string. Required when action = deploy || action = promote || action = reject. Manifests. 
    #containers: # string. Optional. Use when action = deploy || action = promote || action = bake. Containers. 
    #imagePullSecrets: # string. Optional. Use when action = deploy || action = promote. ImagePullSecrets. 
    #renderType: 'helm' # 'helm' | 'kompose' | 'kustomize'. Optional. Use when action = bake. Render Engine. Default: helm.
    #dockerComposeFile: # string. Required when action = bake && renderType = kompose. Path to docker compose file. 
    #helmChart: # string. Required when action = bake && renderType = helm. Helm Chart. 
    #releaseName: # string. Optional. Use when action = bake && renderType = helm. Helm Release Name. 
    #overrideFiles: # string. Optional. Use when action = bake && renderType = helm. Override Files. 
    #overrides: # string. Optional. Use when action = bake && renderType = helm. Overrides. 
    #kustomizationPath: # string. Optional. Use when action = bake && renderType = kustomize. Kustomization Path. 
    #resourceToPatch: 'file' # 'file' | 'name'. Required when action = patch. Resource to patch. Default: file.
    #resourceFileToPatch: # string. Required when action = patch && resourceToPatch = file. File path. 
    #kind: # 'deployment' | 'replicaset' | 'statefulset'. Required when action = scale || resourceToPatch = name. Kind. 
    #name: # string. Required when action = scale || resourceToPatch = name. Name. 
    #replicas: # string. Required when action = scale. Replica count. 
    #mergeStrategy: 'strategic' # 'json' | 'merge' | 'strategic'. Required when action = patch. Merge Strategy. Default: strategic.
    #arguments: # string. Optional. Use when action = delete. Arguments. 
    #patch: # string. Required when action = patch. Patch. 
    #secretType: 'dockerRegistry' # 'dockerRegistry' | 'generic'. Required when action = createSecret. Type of secret. Default: dockerRegistry.
    #secretName: # string. Optional. Use when action = createSecret. Secret name. 
    #secretArguments: # string. Optional. Use when action = createSecret && secretType = generic. Arguments. 
    #dockerRegistryEndpoint: # string. Optional. Use when action = createSecret && secretType = dockerRegistry. Docker registry service connection. 
    #rolloutStatusTimeout: '0' # string. Optional. Use when action = deploy || action = patch || action = scale || action = promote. Timeout for rollout status. Default: 0.

Входные данные

action - Действий
string. Допустимые значения: bake, createSecret (создать секрет), delete, deploy, patch, promote, scale, , . reject Значение по умолчанию: deploy.

Указывает действие, подлежащее выполнению.


connectionType - Тип подключения службы
string. Требуется, если action != bake. Допустимые значения: azureResourceManager (Azure Resource Manager), kubernetesServiceConnection (подключение к службе Kubernetes). Значение по умолчанию: kubernetesServiceConnection.

Выберите тип подключения службы Kubernetes.

  • kubernetesServiceConnection (Подключение к службе Kubernetes) — позволяет предоставить файл KubeConfig, указать учетную запись службы или импортировать экземпляр AKS с помощью параметра Подписка Azure . Для импорта экземпляра AKS с параметром "Подписка Azure " требуется доступ к кластеру Kubernetes во время настройки подключения службы.
  • azureResourceManager(Azure Resource Manager) — позволяет выбрать экземпляр AKS. Не получает доступ к кластеру Kubernetes во время настройки подключения службы.

Дополнительные сведения см. в разделе Примечания.


kubernetesServiceConnection - Подключение к службе Kubernetes
Входной псевдоним: kubernetesServiceEndpoint. string. Требуется, если action != bake && connectionType = kubernetesServiceConnection.

Указывает подключение к службе Kubernetes.


azureSubscriptionConnection - Подписка Azure
Входной псевдоним: azureSubscriptionEndpoint. string. Требуется, если action != bake && connectionType = azureResourceManager.

Выберите подписку Azure Resource Manager, которая содержит Реестр контейнеров Azure. Примечание. Чтобы настроить новое подключение к службе, выберите подписку Azure из списка и нажмите кнопку "Авторизовать". Если ваша подписка отсутствует в списке или вы хотите использовать существующий субъект-службу, можно настроить подключение к службе Azure с помощью кнопки "Добавить" или "Управление".


azureResourceGroup - Группа ресурсов
string. Требуется, если action != bake && connectionType = azureResourceManager.

Выберите группу ресурсов Azure.


kubernetesCluster - Кластер Kubernetes
string. Требуется, если action != bake && connectionType = azureResourceManager.

Выберите управляемый кластер Azure.


useClusterAdmin - Использование учетных данных администратора кластера
boolean. Необязательный элемент. Используйте при connectionType = azureResourceManager. Значение по умолчанию: false.

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


namespace - Пространства имен
string.

Задает пространство имен для команд с помощью флага –namespace . Если пространство имен не указано, команды будут выполняться в пространстве имен по умолчанию.


strategy - Стратегии
string. Необязательный элемент. Используйте при action = deploy || action = promote || action = reject. Допустимые значения: canary, none. Значение по умолчанию: none.

Указывает стратегию развертывания, используемую в действии deploy перед действием или reject действиемpromote. В настоящее canary время является единственной приемлемой стратегией развертывания.


trafficSplitMethod - Метод разделения трафика
string. Необязательный элемент. Используйте при strategy = canary. Допустимые значения: pod, smi. Значение по умолчанию: pod.

Для значения smiразделение трафика в процентах выполняется на уровне запроса с помощью сетки служб. Сетка служб должна быть настроена администратором кластера. Эта задача обрабатывает оркестрацию объектов SMI TrafficSplit .

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


percentage - Процент
string. Требуется, если strategy = Canary && action = deploy. Значение по умолчанию: 0.

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

Для указанных входных данных в процентах вычислите:

(процент × количество реплик) / 100

Если результат не является целым числом, при создании базовых и канареековых вариантов используется математическая часть результата.

Например, предположим, что развертывание hello-world находится во входном файле манифеста, а во входных данных задачи находятся следующие строки:

replicas: 4
strategy: canary
percentage: 25

В этом случае развертывания hello-world-baseline и hello-world-canary создаются с одним реплика каждого. Базовый вариант создается с тем же образом и тегом, что и стабильная версия, которая является вариантом с четырьмя реплика перед развертыванием. Вариант canary создается с изображением и тегом, соответствующими только что развернутых изменений.


baselineAndCanaryReplicas - Базовые и канарееарные реплики
string. Требуется, если strategy = Canary && action = deploy && trafficSplitMethod = SMI. Значение по умолчанию: 1.

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

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

strategy: canary
trafficSplitMethod: smi
percentage: 20
baselineAndCanaryReplicas: 1

В этом случае стабильный вариант получает 80 % трафика, в то время как базовые и канареековые варианты получают половину от указанных 20 %. Базовые и канаарные варианты не получают по три реплики. Вместо этого они получают указанное количество реплик, что означает, что каждая из них получает по одной реплика.


manifests - Манифесты
string. Требуется, если action = deploy || action = promote || action = reject.

Указывает путь к файлам манифеста, используемым для развертывания. Каждая строка представляет один путь. Шаблон сопоставления файлов является допустимым значением для каждой строки.


containers - Контейнеры
string. Необязательный элемент. Используйте при action = deploy || action = promote || action = bake.

Указывает полный URL-адрес ресурса изображения, используемого для подстановок в файлах манифеста. Примером является URL-адрес contosodemo.azurecr.io/helloworld:test .


imagePullSecrets - ImagePullSecrets
string. Необязательный элемент. Используйте при action = deploy || action = promote.

Указывает многострочный вход, где каждая строка содержит имя секрета реестра Docker, который уже был настроен в кластере. Каждое имя секрета добавляется в для imagePullSecrets рабочих нагрузок, которые находятся во входных файлах манифеста.


renderType - Обработчик отрисовки
string. Необязательный элемент. Используйте при action = bake. Допустимые значения: helm, kompose, kustomize. Значение по умолчанию: helm.

Указывает тип отрисовки, используемый для создания файлов манифеста.


dockerComposeFile - Путь к файлу Docker Compose
string. Требуется, если action = bake && renderType = kompose.

Указывает путь к файлу docker-compose.


helmChart - Диаграмма Helm
string. Требуется, если action = bake && renderType = helm.

Указывает путь к диаграмме Helm для создания.


releaseName - Название выпуска Helm
string. Необязательный элемент. Используйте при action = bake && renderType = helm.

Указывает используемое имя выпуска Helm.


overrideFiles - Переопределение файлов
string. Необязательный элемент. Используйте при action = bake && renderType = helm.

Указывает многострочного ввода, который принимает путь к файлам переопределения. Файлы используются при выпекании файлов манифеста из диаграмм Helm.


overrides - Переопределения
string. Необязательный элемент. Используйте при action = bake && renderType = helm.

Задает значения переопределения, которые необходимо задать.


kustomizationPath - Путь kustomization
string. Необязательный элемент. Используйте при action = bake && renderType = kustomize.

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


resourceToPatch - Ресурс для исправления
string. Требуется, если action = patch. Допустимые значения: file, name. Значение по умолчанию: file.

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

  • Файл манифеста определяет объекты для исправления.
  • Отдельный объект определяется по типу и имени в качестве целевого объекта исправления.

Допустимыми значениями являются файл и имя.


resourceFileToPatch - Путь к файлу
string. Требуется, если action = patch && resourceToPatch = file.

Указывает путь к файлу, используемому для исправления.


kind - Вид
string. Требуется, если action = scale || resourceToPatch = name. Допустимые значения: deployment, replicaset, statefulset.

Указывает тип объекта K8s, например deployment, replicaSet и многое другое.


name - Имя
string. Требуется, если action = scale || resourceToPatch = name.

Указывает имя объекта K8s.


replicas - Число реплик
string. Требуется, если action = scale.

Указывает количество реплик для масштабирования.


replicas - Число реплик
string. Требуется, если action = scale.

Указывает имя объекта K8s.


mergeStrategy - Стратегия слияния
string. Требуется, если action = patch. Допустимые значения: json, merge, strategic. Значение по умолчанию: strategic.

Указывает тип предоставляемого исправления.


arguments - Аргументы
string. Необязательный элемент. Используйте при action = delete.

Указывает аргументы для kubectl delete команды . Пример: arguments: deployment hello-world foo-bar


patch - Патч
string. Требуется, если action = patch.

Указывает содержимое исправления.


secretType - Тип секрета
string. Требуется, если action = createSecret. Допустимые значения: dockerRegistry, generic. Значение по умолчанию: dockerRegistry.

Создает или обновляет универсальный объект или docker imagepullsecret. Укажите dockerRegistry для создания или обновления imagepullsecret выбранного реестра. — imagePullSecret это способ передачи секрета, содержащего пароль реестра контейнеров, в Kubelet, чтобы он смог извлечь частный образ от имени pod.


secretName - Имя секрета
string. Необязательный элемент. Используйте при action = createSecret.

Указывает имя секрета. Это имя секрета можно использовать в файле конфигурации YAML Kubernetes.


secretArguments - Аргументы
string. Необязательный элемент. Используйте при action = createSecret && secretType = generic.

Задает ключи и литеральные значения для вставки в секрете. Например, --from-literal=key1=value1--from-literal=key2="top secret".


dockerRegistryEndpoint - Подключение к службе реестра Docker
string. Необязательный элемент. Используйте при action = createSecret && secretType = dockerRegistry.

Указывает учетные данные указанного подключения к службе, которые используются для создания секрета реестра Docker в кластере. Затем файлы манифеста в imagePullSecrets поле могут ссылаться на имя этого секрета.


rolloutStatusTimeout - Время ожидания для состояния развертывания
string. Необязательный элемент. Используйте при action = deploy || action = patch || action = scale || action = promote. Значение по умолчанию: 0.

Указывает продолжительность (в секундах) ожидания перед завершением watch on rollout состояния.


Параметры управления задачами

Помимо входных данных, все задачи имеют параметры управления. Дополнительные сведения см. в разделе Параметры управления и общие свойства задачи.

Выходные переменные

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

manifestsBundle
Расположение пакетов манифеста, созданных с помощью действия bake

Комментарии

Рекомендации по подключению к службе Kubernetes при доступе к AKS

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

  • KubeConfig
  • Учетная запись службы
  • Подписка Azure

Снимок экрана: выбор метода проверки подлинности подключения службы Kubernetes.

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

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

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

Использование подключения службы Resource Manager Azure для доступа к AKS

Для клиентов AKS тип подключения службы Resource Manager Azure предоставляет лучший способ подключения к частному кластеру или кластеру с отключенными локальными учетными записями. Этот метод не зависит от подключения к кластеру во время создания подключения к службе. Доступ к AKS откладывается в среду выполнения конвейера, которая имеет следующие преимущества:

  • Доступ к (частному) кластеру AKS можно осуществлять из локального агента или агента масштабируемого набора с прямой видимости кластера.
  • Маркер создается для каждой задачи, которая использует подключение службы Resource Manager Azure. Это гарантирует, что вы подключаетесь к Kubernetes с помощью кратковременного маркера, который является рекомендацией Kubernetes.
  • Доступ к AKS можно получить, даже если локальные учетные записи отключены.

Часто задаваемые вопросы о подключении к службе

Я получаю следующее сообщение об ошибке: Не удалось найти секрет, связанный с учетной записью службы. Что происходит?

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

Я использую AKS и не хочу ничего менять. Могу ли я продолжать использовать задачи с подключением к службе Kubernetes?

Мы обновляем этот метод для создания долгосрочных маркеров. Ожидается, что это будет доступно в середине мая. Однако имейте в виду, что этот подход не соответствует рекомендациям Kubernetes.

Я использую задачи Kubernetes и подключение службы Kubernetes, но не AKS. Следует ли мне беспокоиться?

Задачи будут продолжать работать, как и раньше.

Будет ли удален тип подключения службы Kubernetes?

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

Я клиент AKS, и все работает нормально, должен ли я действовать?

Нет необходимости ничего менять. Если вы используете подключение к службе Kubernetes и выбрали подписку Azure во время создания, следует учитывать рекомендации Kubernetes по использованию маркеров с длительным сроком действия.

Я создаю среду Kubernetes и не могу использовать подключения к службам

Если вы не можете получить доступ к AKS во время создания среды, можно использовать пустую среду и задать connectionType входные данные для подключения службы Resource Manager Azure.

У меня есть AKS, настроенный с помощью Azure Active Directory RBAC, и мой конвейер не работает. Будут ли эти обновления устранять это?

Доступ к Kubernetes при включении AAD RBAC не связан с созданием маркера. Чтобы предотвратить интерактивный запрос, мы будем поддерживать kubelogin в следующем обновлении.

Используйте задачу манифеста Kubernetes в конвейере сборки или выпуска для создания и развертывания манифестов в кластерах Kubernetes.

Эта задача поддерживает следующее:

  • Подстановка артефактов. Действие развертывания принимает в качестве входных данных список образов контейнеров, которые можно указать вместе с их тегами и дайджестами. Те же входные данные заменяются в нетемплатизованных файлах манифеста перед приложением в кластере. Эта подстановка гарантирует, что узлы кластера извлекут правильную версию образа.

  • Стабильность манифеста. Проверяется состояние развертывания развернутых объектов Kubernetes. Проверки стабильности включаются, чтобы определить, является ли задача успешной или неудачной.

  • Заметки трассировки. Заметки добавляются в развернутые объекты Kubernetes для наложения сведений о возможности трассировки. Поддерживаются следующие заметки:

    • azure-pipelines/org
    • azure-pipelines/project
    • azure-pipelines/pipeline
    • azure-pipelines/pipelineId
    • azure-pipelines/execution
    • azure-pipelines/executionuri
    • azure-pipelines/jobName

  • Обработка секретов. Действие createSecret позволяет создавать секреты реестра Docker с помощью подключений к службе реестра Docker. Он также позволяет создавать универсальные секреты с помощью переменных в виде обычного текста или секретных переменных. Перед развертыванием в кластере можно использовать secrets входные данные вместе с действием deploy , чтобы дополнить входные файлы манифеста соответствующим imagePullSecrets значением.

  • Создание манифеста. Действие bake задачи позволяет испечь шаблоны в файлах манифеста Kubernetes. Действие использует такие средства, как Helm, Compose и Kustomize. Благодаря выпечке эти файлы манифеста Kubernetes можно использовать для развертываний в кластере.

  • Стратегия развертывания. Выбор canary стратегии с действием deploy приводит к созданию имен рабочих нагрузок с -baseline суффиксами и -canary. Задача поддерживает два метода разделения трафика:

    • Интерфейс сетки служб. Абстракция интерфейса сетки служб (SMI) позволяет настраивать такие поставщики сетки служб, как Linkerd и Istio. Задача "Манифест Kubernetes" сопоставляет объекты SMI TrafficSplit со стабильными, базовыми и канарееарными службами в течение жизненного цикла стратегии развертывания.

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

    • Kubernetes без сетки служб. При отсутствии сетки служб вы можете не получить точное процентное разделение на уровне запроса. Однако можно выполнять канареарные развертывания, используя базовые и канарееарные варианты рядом со стабильным вариантом.

      Служба отправляет запросы в модули pod всех трех вариантов рабочей нагрузки по мере выполнения ограничений селектора и меток. Манифест Kubernetes учитывает эти запросы при создании базовых и canary вариантов. Такое поведение маршрутизации обеспечивает предполагаемый эффект маршрутизации только части общего числа запросов на канарее.

    Сравните базовые и канарееарные рабочие нагрузки с помощью задачи "Вмешательство вручную " в конвейерах выпуска или задачи "Задержка " в конвейерах YAML. Выполните сравнение перед использованием действия повышения или отклонения задачи.

Действие развертывания

Следующий код YAML является примером развертывания в пространстве имен Kubernetes с помощью файлов манифеста:

steps:
- task: KubernetesManifest@0
  displayName: Deploy
  inputs:
    kubernetesServiceConnection: someK8sSC1
    namespace: default
    manifests: |
      manifests/deployment.yml
      manifests/service.yml
    containers: |
      foo/demo:$(tagVariable1)
      bar/demo:$(tagVariable2)
    imagePullSecrets: |
      some-secret
      some-other-secret

В приведенном выше примере задача пытается найти совпадения для изображений foo/demo и bar/demo в полях изображений файлов манифеста. Для каждого найденного совпадения tagVariable1 значение или tagVariable2 добавляется в качестве тега к имени образа. Вы также можете указать дайджесты во входных данных контейнеров для подстановки артефактов.

Примечание

Хотя можно создавать deployдействия , promoteи reject с входными данными YAML, связанными со стратегией развертывания, поддержка задачи "Вмешательство вручную" в настоящее время недоступна для конвейеров сборки.

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

  1. Действие развертывания, указанное с помощью strategy: canary и percentage: $(someValue).
  2. Задача "Вмешательство вручную", чтобы можно было приостановить конвейер и сравнить базовый вариант с вариантом canary.
  3. Действие повышения, которое выполняется, если задача "Вмешательство вручную" возобновляется, и действие отклонить, которое выполняется при отклонении задачи "Вмешательство вручную".

Действие создания секрета

В следующем коде YAML показан пример создания секретов реестра Docker с помощью подключения к службе реестра Docker:

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: dockerRegistry
    secretName: foobar
    dockerRegistryEndpoint: demoACR
    kubernetesServiceConnection: someK8sSC
    namespace: default

В этом коде YAML показан пример создания универсальных секретов:

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: generic
    secretName: some-secret
    secretArguments: --from-literal=key1=value1
    kubernetesServiceConnection: someK8sSC
    namespace: default

Действие "Выпекать"

Следующий код YAML является примером создания файлов манифеста из диаграмм Helm. Обратите внимание на использование входных данных имени в первой задаче. На это имя позже ссылается шаг развертывания для указания пути к манифестам, созданным на шаге выпекания.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: someK8sSC
    namespace: default
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Примечание

Чтобы использовать Helm напрямую для управления выпусками и откатами, см. задачу Упаковка и развертывание диаграмм Helm.

Пример Kustomize

Следующий код YAML является примером создания файлов манифеста, созданных с помощью Kustomize, которые содержат kustomization.yaml файл.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from kustomization path
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Пример Kompose

Следующий код YAML является примером создания файлов манифеста, созданных с помощью Kompose, средства преобразования для Docker Compose.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Docker Compose
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Действие масштабирования

В следующем коде YAML показан пример масштабирования объектов:

steps:
- task: KubernetesManifest@0
  displayName: Scale
  inputs: 
    action: scale
    kind: deployment
    name: bootcamp-demo
    replicas: 5
    kubernetesServiceConnection: someK8sSC
    namespace: default

Действие исправления

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

steps:
- task: KubernetesManifest@0
  displayName: Patch
  inputs: 
    action: patch
    kind: pod
    name: demo-5fbc4d6cd9-pgxn4
    mergeStrategy: strategic
    patch: '{"spec":{"containers":[{"name":"demo","image":"foobar/demo:2239"}]}}'
    kubernetesServiceConnection: someK8sSC
    namespace: default

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

В этом коде YAML показан пример удаления объекта:

steps:
- task: KubernetesManifest@0
  displayName: Delete
  inputs:
    action: delete
    arguments: deployment expressapp
    kubernetesServiceConnection: someK8sSC
    namespace: default

Устранение неполадок

Мой кластер Kubernetes находится за брандмауэром, и я использую размещенные агенты. Как выполнить развертывание в этом кластере?

Вы можете предоставить размещенным агентам доступ через брандмауэр, разрешив IP-адреса для размещенных агентов. Дополнительные сведения см. в статье о диапазонах IP-адресов агента.

Как работают запросы к стабильным и вариантным маршрутам служб с канареечными развертываниями?

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

Если задача включает входные action: deploy данные и strategy: canary, для каждой рабочей нагрузки (Deployment, ReplicaSet, Pod, ...), определенных во входных файлах манифеста -baseline , создаются варианты и -canary развертывания. В этом примере во входном файле манифеста есть развертывание sampleapp , и после завершения выполнения конвейера с номером 22 стабильный вариант развертывания с именем sampleapp развертывается в кластере. При последующем запуске (в данном случае — запуск с номером 23) задача манифеста Kubernetes с action: deploy и strategy: canary приведет к созданию развертываний sampleapp-baseline и sampleapp-canary, количество реплик которых определяется произведением percentage входных данных задачи со значением требуемого количества реплик для окончательного стабильного варианта в соответствии с входными файлами манифеста sampleapp .

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

Входныеaction: promote данные и strategy: canary или action: reject и strategy: canary для задач манифеста Kubernetes можно использовать для повышения или отклонения канареечного изменения соответственно. Обратите внимание, что в любом случае в конце этого шага в кластере будет развернут только стабильный вариант рабочих нагрузок, объявленных во входных файлах манифеста, а временные базовые и канаарные версии будут очищены.

Требования

Требование Описание
Типы конвейеров YAML, классическая сборка, классический выпуск
Выполняется в Агент, DeploymentGroup
Требования Нет
Capabilities Эта задача не удовлетворяет требованиям для последующих задач в задании.
Ограничения команд Любой
Устанавливаемые переменные Любой
Версия агента Все поддерживаемые версии агента.
Категория задач Развертывание