Среда — ресурс Kubernetes
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
В представлении ресурсов Kubernetes отображается состояние объектов в пространстве имен, сопоставленных с ресурсом. Представление ресурсов также накладывает трассировку конвейера, чтобы выполнить трассировку обратно из объекта Kubernetes в конвейер, а затем вернуться к фиксации.
Используйте ресурсы Kubernetes для целевых кластеров Kubernetes в среде для развертывания. Используйте конвейеры для развертывания в Служба Azure Kubernetes (AKS) и кластерах любого другого поставщика облачных служб.
Ресурсы Kubernetes можно использовать с общедоступными или частными кластерами. Дополнительные сведения о работе ресурсов см. в ресурсах в YAML и безопасности с ресурсами.
Обзор
См. следующие преимущества использования представлений ресурсов Kubernetes в средах:
Трассировка конвейера — задача манифеста Kubernetes, используемая для развертываний, добавляет дополнительные заметки для отображения трассировки конвейера в представлениях ресурсов. Трассировка конвейера помогает определить исходную организацию, проект и конвейер Azure DevOps, отвечающий за обновления, внесенные в объект в пространстве имен.
Диагностика работоспособности ресурсов. Состояние рабочей нагрузки может быть полезно для быстрой отладки ошибок или регрессий, которые были введены новым развертыванием. Например, для ненастроенных образовPullSecrets , что приводит к ошибкам ImagePullBackOff, сведения о состоянии pod помогут определить первопричину проблемы.
Проверка приложения— проверка работы приложения путем развертывания каждого запроса на вытягивание из репозитория Git в динамический ресурс Kubernetes в среде. Рецензенты могут узнать, как эти изменения выглядят и работают с другими зависимыми службами, прежде чем они объединены в целевую ветвь и развернуты в рабочей среде.
Применение службы контейнеров Azure
ServiceAccount создается в выбранном кластере и пространстве имен при использовании Служба Azure Kubernetes (AKS). Для кластера с поддержкой Kubernetes RBAC рольBinding также создается, чтобы ограничить область созданной учетной записи службы выбранным пространством имен. Для отключенного кластера Kubernetes RBAC служба ServiceAccount создала права на уровне кластера (в разных пространствах имен).
Добавление ресурса Kubernetes AKS
На странице сведений о среде выберите "Добавить ресурс " и выберите Kubernetes.
Выберите Служба Azure Kubernetes в раскрывающемся списке поставщика.
Выберите подписку Azure, кластер и пространство имен (новое или существующее).
Выберите " Проверить и создать ", чтобы создать ресурс Kubernetes.
Убедитесь, что в среде отображается кластер. Вы увидите текст "Никогда не развернутый", если вы еще не развернули код в кластере.
Использование существующей учетной записи службы
Служба Azure Kubernetes сопоставляет ресурс Kubernetes в среде с пространством имен.
Дополнительные сведения о настройке подключения службы Kubernetes за пределами среды см. в разделе подключения к службе Kubernetes.
Совет
Используйте универсальный поставщик (существующую учетную запись службы), чтобы сопоставить ресурс Kubernetes с пространством имен из кластера, отличного от AKS.
Добавление ресурса Kubernetes, отличного от AKS
На странице сведений о среде выберите "Добавить ресурс " и выберите Kubernetes.
Выберите универсальный поставщик (существующая учетная запись службы) для поставщика.
Добавьте значения имени кластера и пространства имен.
Добавьте URL-адрес сервера. URL-адрес можно получить с помощью следующей команды:
kubectl config view --minify -o 'jsonpath={.clusters[0].cluster.server}'
Получение секретного объекта.
Kubernetes 1.22+
Замените
service-account-name
имя учетной записи.kubectl get secret -n <namespace> -o jsonpath='{.items[?(@.metadata.annotations.kubernetes\.io/service-account\.name==\"service-account-name\")]}'
Если вы ничего не получаете, см . раздел "Создание маркера API с длительным сроком действия" для ServiceAccount.
Kubernetes 1.22 и ниже:
- Поиск имени секрета учетной записи службы
kubectl get serviceAccounts <service-account-name> -n <namespace> -o 'jsonpath={.secrets[*].name}'
- замените
<service-account-secret-name>
значением предыдущей команды в этой команде
kubectl get secret <service-account-secret-name> -n <namespace> -o json
Получите секретный объект с помощью выходных данных предыдущего шага.
kubectl get secret <service-account-secret-name> -n <namespace> -o json
Скопируйте и вставьте объект Secret, извлекаемый в формате JSON, в поле Secret.
Выберите " Проверить и создать ", чтобы создать ресурс Kubernetes.
Ссылка на ресурсы Kubernetes в конвейере
Если вы используете Служба Azure Kubernetes и создаете конвейер YAML, самый простой способ настройки конвейера — использовать шаблон. Подключитесь к репозиторию и выберите один из следующих двух параметров службы Kubernetes:
- Развертывание в шаблоне Служба Azure Kubernetes
- Развертывание в Kubernetes— проверка приложения с помощью Azure DevSpaces
Шаблоны позволяют настроить приложение проверки без необходимости писать код YAML с нуля или вручную создавать явные привязки ролей.
Настройка приложения проверки
В следующем примере первое задание развертывания выполняется для ветвей, отличных от PR, и выполняет развертывание в обычных ресурсах Kubernetes в средах. Второе задание выполняется только для ветвей pr и развертывает ресурсы приложения (пространства имен в кластере Kubernetes), созданные по требованию. Ресурсы получают метку "Рецензирование" в представлении списка ресурсов среды. Определите переменные, используемые в конвейере. Если вы используете шаблон deploy to Служба Azure Kubernetes s, эти переменные определяются для вас.
# Build and push image to Azure Container Registry; Deploy to Azure Kubernetes Service
trigger:
- main
resources:
- repo: self
variables:
# Container registry service connection established during pipeline creation
dockerRegistryServiceConnection: '12345' # Docker service connection identifier
envName: 'myEnv' # name of your environment
imageRepository: 'name-of-image-repository' # name of image repository
containerRegistry: 'mycontainer.azurecr.io' # path to container registry
dockerfilePath: '**/Dockerfile'
tag: '$(Build.BuildId)'
imagePullSecret: 'my-app-secret' # image pull secret
# Agent VM image name
vmImageName: 'ubuntu-latest'
# Name of the new namespace being created to deploy the PR changes.
k8sNamespaceForPR: 'review-app-$(System.PullRequest.PullRequestId)'
stages:
- stage: Build
displayName: Build stage
jobs:
- job: Build
displayName: Build
pool:
vmImage: $(vmImageName)
steps:
- task: Docker@2
displayName: Build and push an image to container registry
inputs:
command: buildAndPush
repository: $(imageRepository)
dockerfile: $(dockerfilePath)
containerRegistry: $(dockerRegistryServiceConnection)
tags: |
$(tag)
- upload: manifests
artifact: manifests
- stage: Production
displayName: Deploy stage
dependsOn: Build
jobs:
- deployment: Production
condition: and(succeeded(), not(startsWith(variables['Build.SourceBranch'], 'refs/pull/')))
displayName: Production
pool:
vmImage: $(vmImageName)
environment:
name: $(envName).$(resourceName)
resourceType: Kubernetes
strategy:
runOnce:
deploy:
steps:
- task: KubernetesManifest@0
displayName: Create imagePullSecret
inputs:
action: createSecret
secretName: $(imagePullSecret)
dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
- task: KubernetesManifest@0
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
manifests: |
$(Pipeline.Workspace)/manifests/deployment.yml
$(Pipeline.Workspace)/manifests/service.yml
imagePullSecrets: |
$(imagePullSecret)
containers: |
$(containerRegistry)/$(imageRepository):$(tag)
- deployment: DeployPullRequest
displayName: Deploy Pull request
condition: and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/pull/'))
pool:
vmImage: $(vmImageName)
environment:
name: $(envName).$(resourceName)
resourceType: Kubernetes
strategy:
runOnce:
deploy:
steps:
- reviewApp: default
- task: Kubernetes@1
displayName: 'Create a new namespace for the pull request'
inputs:
command: apply
useConfigurationFile: true
inline: '{ "kind": "Namespace", "apiVersion": "v1", "metadata": { "name": "$(k8sNamespaceForPR)" }}'
- task: KubernetesManifest@0
displayName: Create imagePullSecret
inputs:
action: createSecret
secretName: $(imagePullSecret)
namespace: $(k8sNamespaceForPR)
dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
- task: KubernetesManifest@0
displayName: Deploy to the new namespace in the Kubernetes cluster
inputs:
action: deploy
namespace: $(k8sNamespaceForPR)
manifests: |
$(Pipeline.Workspace)/manifests/deployment.yml
$(Pipeline.Workspace)/manifests/service.yml
imagePullSecrets: |
$(imagePullSecret)
containers: |
$(containerRegistry)/$(imageRepository):$(tag)
- task: Kubernetes@1
name: get
displayName: 'Get services in the new namespace'
continueOnError: true
inputs:
command: get
namespace: $(k8sNamespaceForPR)
arguments: svc
outputFormat: jsonpath='http://{.items[0].status.loadBalancer.ingress[0].ip}:{.items[0].spec.ports[0].port}'
# Getting the IP of the deployed service and writing it to a variable for posting comment
- script: |
url="$(get.KubectlOutput)"
message="Your review app has been deployed"
if [ ! -z "$url" -a "$url" != "http://:" ]
then
message="${message} and is available at $url.<br><br>[Learn More](https://aka.ms/testwithreviewapps) about how to test and provide feedback for the app."
fi
echo "##vso[task.setvariable variable=GITHUB_COMMENT]$message"
Чтобы использовать это задание в существующем конвейере, необходимо изменить подключение службы, поддерживаемое обычным ресурсом среды Kubernetes, на "Использовать учетные данные администратора кластера". В противном случае привязки ролей необходимо создать для базовой учетной записи службы в пространстве имен "Просмотр приложения".