Ambiente – Recurso do Kubernetes
Serviços de DevOps do Azure | Azure DevOps Server 2022 | Azure DevOps Server 2020
A visualização de recursos do Kubernetes mostra o status dos objetos dentro do namespace que são mapeados para o recurso. A visualização de recursos também sobrepõe a rastreabilidade do pipeline para que você possa rastrear de um objeto Kubernetes para o pipeline e, em seguida, de volta para a confirmação.
Use os recursos do Kubernetes para direcionar clusters do Kubernetes em um ambiente para implantação. Use pipelines para implantar no Serviço Kubernetes do Azure (AKS) 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 no YAML e Segurança com recursos.
Descrição geral
Veja as seguintes vantagens de usar visualizações de recursos do Kubernetes em ambientes:
Rastreabilidade de pipeline - A tarefa de manifesto do Kubernetes, usada para implantações, adiciona mais anotações para mostrar a rastreabilidade do pipeline em exibições de recursos. A rastreabilidade do 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 da 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 resultando em erros ImagePullBackOff, as informações de status do pod podem ajudá-lo a identificar a causa raiz do problema.
Aplicativo de revisão - O aplicativo de revisão funciona implantando cada solicitação pull do seu repositório Git em um recurso dinâmico do Kubernetes no ambiente. Os revisores podem ver a aparência dessas alterações e trabalhar com outros serviços dependentes antes de serem mescladas na ramificação de destino e implantadas na produção.
Usar o Serviço Kubernetes do Azure
Uma ServiceAccount é criada no cluster e namespace escolhidos quando você usa o Serviço Kubernetes do Azure (AKS). Para um cluster habilitado para Kubernetes RBAC, 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 AKS
Na página de detalhes do ambiente, selecione Adicionar recurso e escolha Kubernetes.
Selecione Serviço 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 Kubernetes.
Verifique se você vê um cluster para seu ambiente. Você verá o texto "Nunca implantado" se ainda não tiver implantado o código no cluster.
Utilizar uma conta de serviço existente
O Serviço Kubernetes do Azure mapeia um recurso Kubernetes em seu ambiente para um namespace.
Para obter mais informações sobre como configurar uma conexão de serviço Kubernetes fora de um ambiente, consulte a seção Conexão de serviço Kubernetes em Conexões de serviço.
Gorjeta
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 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 do namespace.
Adicione o 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 abaixo:
- Localizar o nome secreto da conta de serviço
kubectl get serviceAccounts <service-account-name> -n <namespace> -o 'jsonpath={.secrets[*].name}'- substituir
<service-account-secret-name>pelo valor no 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 e cole o objeto Secret buscado no formulário JSON no campo Secret.
Selecione Validar e criar para criar o recurso Kubernetes.
Referenciar seus recursos do Kubernetes em um pipeline
Se você estiver usando o Serviço 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 opções de Serviço Kubernetes a seguir:
- Implantar no modelo de Serviços Kubernetes do Azure
- Implantar no Kubernetes - Revise o aplicativo com o Azure DevSpaces
Os modelos permitem que você configure o Review App sem precisar escrever código YAML do zero ou criar manualmente associações de função explícitas.
Configurar a aplicação Rever
No exemplo a seguir, o primeiro trabalho de implantação é executado para ramificações que não são de RP e faz implantações em um recurso Kubernetes regular em ambientes. O segundo trabalho é executado apenas para ramificações de RP e implantado em recursos do Aplicativo de Revisão (namespaces dentro do cluster Kubernetes) gerados sob demanda. Os recursos são rotulados com "Revisão" na exibição de listagem de recursos do ambiente. Defina variáveis a serem usadas no pipeline. Se você usar o modelo Implantar nos Serviços 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 Kubernetes regular deve ser modificada para "Usar credenciais de administrador de cluster". Caso contrário, as associações de função devem ser criadas para a conta de serviço subjacente ao namespace Review App.