Ambiente - Recurso do Kubernetes
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
A exibição de recursos do Kubernetes exibe o status de objetos dentro do namespace mapeados para o recurso. A exibição de recursos também sobrepõe a rastreabilidade do pipeline para que você possa rastrear de volta de um objeto Kubernetes para o pipeline e, em seguida, voltar para o commit.
Use os recursos do Kubernetes para direcionar clusters do Kubernetes em um ambiente para implantação. Use pipelines para implantar no AKS (Serviço de Kubernetes do Azure) e clusters de qualquer outro provedor de nuvem.
Você pode usar recursos do Kubernetes com clusters públicos ou privados. Para obter mais informações sobre como os recursos funcionam, consulte recursos em YAML e segurança com recursos.
Visão geral
Confira as seguintes vantagens de usar exibições de recursos do Kubernetes em ambientes:
Rastreabilidade do pipeline – a tarefa de manifesto do Kubernetes, usada para implantações, adiciona mais anotações para mostrar a rastreabilidade do pipeline nas exibições de recursos. A rastreabilidade de pipeline ajuda a identificar a organização, o projeto e o pipeline do Azure DevOps de origem responsáveis pelas atualizações feitas em um objeto dentro do namespace.
Diagnosticar a integridade do recurso: o status de carga de trabalho pode ser útil para depurar rapidamente erros ou regressões que foram introduzidos por uma nova implantação. Por exemplo, para imagePullSecrets não configurados que resultam em erros ImagePullBackOff, as informações de status do pod podem ajudar você a identificar a causa raiz do problema.
Examinar aplicativo – Examinar aplicativo funciona implantando cada solicitação de pull do repositório Git em um recurso dinâmico do Kubernetes no ambiente. Os revisores podem ver a aparência dessas alterações e como elas funcionam com outros serviços dependentes antes de serem mescladas no branch de destino e implantadas em produção.
Usar o Serviço de Kubernetes do Azure
Uma ServiceAccount é criada no cluster e no namespace escolhidos quando você usa o AKS (Serviço de Kubernetes do Azure). Para um cluster habilitado para RBAC do Kubernetes, RoleBinding também é criado para limitar o escopo da conta de serviço criada ao namespace escolhido. Para um cluster desabilitado para RBAC do Kubernetes, a ServiceAccount criada tem privilégios em todo o cluster (entre namespaces).
Adicionar um recurso do Kubernetes do AKS
Na página de detalhes do ambiente, selecione Adicionar recurso e escolha Kubernetes.
Selecione Serviço de Kubernetes do Azure na lista suspensa Provedor.
Escolha a assinatura, o cluster e o namespace do Azure (novo/existente).
Selecione Validar e criar para criar o recurso do Kubernetes.
Verifique se você vê um cluster para o seu ambiente. Você verá o texto “Nunca implantado” se ainda não tiver implantado o código no cluster.
Usar uma conta de serviço existente
O Serviço de Kubernetes do Azure mapeia um recurso do Kubernetes em seu ambiente para um namespace.
Para obter mais informações sobre como configurar uma conexão de serviço do Kubernetes fora de um ambiente, confira a seção Conexão de serviço do Kubernetes em Conexões de serviço.
Dica
Use o provedor genérico (conta de serviço existente) para mapear um recurso do Kubernetes para um namespace de um cluster não AKS.
Adicionar um recurso do Kubernetes não AKS
Na página de detalhes do ambiente, selecione Adicionar recurso e escolha Kubernetes.
Selecione Provedor genérico (conta de serviço existente) para seu provedor.
Adicione o nome do cluster e os valores de namespace.
Adicione a URL do servidor. Você pode obter a URL com o seguinte comando:
kubectl config view --minify -o 'jsonpath={.clusters[0].cluster.server}'Para obter o objeto secreto.
Kubernetes 1.22+
Substitua
service-account-namepelo nome da sua conta.kubectl get secret -n <namespace> -o jsonpath='{.items[?(@.metadata.annotations.kubernetes\.io/service-account\.name==\"service-account-name\")]}'Se você não receber nada, consulte Criar manualmente um token de API de longa duração para uma ServiceAccount.
Kubernetes 1.22 e inferior:
- Localizar o nome secreto da conta de serviço
kubectl get serviceAccounts <service-account-name> -n <namespace> -o 'jsonpath={.secrets[*].name}'- Substitua
<service-account-secret-name>pelo valor do comando anterior neste comando
kubectl get secret <service-account-secret-name> -n <namespace> -o jsonObtenha o objeto secreto usando a saída da etapa anterior.
kubectl get secret <service-account-secret-name> -n <namespace> -o jsonCopie o objeto Secret buscado no formato JSON e cole-o no campo Segredo.
Selecione Validar e criar para criar o recurso do Kubernetes.
Referenciar seus recursos do Kubernetes em um pipeline
Se você estiver usando Serviço de Kubernetes do Azure e criando um pipeline YAML, a maneira mais fácil de configurar seu pipeline é usar um modelo. Conecte-se ao repositório e selecione uma das duas seguintes opções do Serviço de Kubernetes:
- Implantar no modelo do Serviço de Kubernetes do Azure
- Implantar no Kubernetes – Examinar o aplicativo com o Azure DevSpaces
Os modelos permitem que você configure o Aplicativo de Revisão sem a necessidade de escrever código YAML do zero ou criar manualmente associações de função explícitas.
Configurar Revisar aplicativo
No exemplo a seguir, o primeiro trabalho de implantação é executado para branches sem solicitação de pull e faz implantações em um recurso regular do Kubernetes em ambientes. O segundo trabalho é executado apenas para branches de solicitação de pull e implanta em recursos de Revisar aplicativo (namespaces dentro do cluster do Kubernetes) gerados sob demanda. Os recursos são rotulados com "Revisão" na exibição de listagem de recursos do ambiente. Defina as variáveis a serem usadas no pipeline. Se você usar o modelo Implantar nos Serviços de Kubernetes do Azure, essas variáveis serão definidas para você.
# 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"
Para usar esse trabalho em um pipeline existente, a conexão de serviço que dá suporte ao recurso de ambiente do Kubernetes regular precisa ser modificada para "Usar credenciais de administrador de cluster". Caso contrário, as associações de função precisam ser criadas para a conta de serviço subjacente para o namespace Examinar aplicativo.