KubernetesManifest@1 – Implantar na tarefa do Kubernetes v1

Use arquivos de manifesto do Kubernetes para implantar em clusters ou até mesmo assar os arquivos de manifesto a serem usados para implantações usando gráficos do Helm.

Syntax

# 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.

Entradas

action - Ação
string. Valores permitidos: bake, createSecret (criar segredo), delete, deploy, patch, promote, scale, reject. Valor padrão: deploy.

Especifica a ação a ser executada.

connectionType - Tipo de conexão de serviço
string. Obrigatório quando action != bake. Valores permitidos: azureResourceManager (Azure Resource Manager), kubernetesServiceConnection (Conexão de Serviço do Kubernetes). Valor padrão: kubernetesServiceConnection.

Selecione um tipo de conexão de serviço do Kubernetes.

• kubernetesServiceConnection (Conexão de Serviço do Kubernetes) – permite que você forneça um arquivo KubeConfig, especifique uma Conta de Serviço ou importe uma instância do AKS com a opção Assinatura do Azure . Importar uma instância do AKS com a opção Assinatura do Azure requer acesso ao cluster do Kubernetes no momento da configuração da Conexão de Serviço.
• azureResourceManager(Azure Resource Manager) – permite selecionar uma instância do AKS. Não acessa o cluster do Kubernetes no momento da configuração da Conexão de Serviço.

Para obter mais informações, consulte Comentários.

kubernetesServiceConnection - Conexão de serviço do Kubernetes
Alias de entrada: kubernetesServiceEndpoint. string. Obrigatório quando action != bake && connectionType = kubernetesServiceConnection.

Especifica uma conexão de serviço do Kubernetes.

azureSubscriptionConnection - Assinatura do Azure
Alias de entrada: azureSubscriptionEndpoint. string. Obrigatório quando action != bake && connectionType = azureResourceManager.

Selecione a assinatura Resource Manager do Azure, que contém Registro de Contêiner do Azure. Observação: para configurar a nova conexão de serviço, selecione a assinatura do Azure na lista e clique em 'Autorizar'. Se a sua assinatura não estiver listada ou se você quiser usar uma Entidade de Serviço existente, você poderá configurar uma conexão de serviço do Azure usando o botão "Adicionar" ou "Gerenciar".

azureResourceGroup - Grupo de recursos
string. Obrigatório quando action != bake && connectionType = azureResourceManager.

Selecione um grupo de recursos do Azure.

kubernetesCluster - Cluster do Kubernetes
string. Obrigatório quando action != bake && connectionType = azureResourceManager.

Selecione um cluster gerenciado do Azure.

useClusterAdmin - Usar credenciais de administrador de cluster
boolean. Opcional. Use quando connectionType = azureResourceManager. Valor padrão: false.

Use credenciais de administrador de cluster em vez de credenciais de usuário de cluster padrão.

namespace - Namespace
string.

Especifica o namespace para os comandos usando o –namespace sinalizador . Se o namespace não for fornecido, os comandos serão executados no namespace padrão.

strategy - Estratégia
string. Opcional. Use quando action = deploy || action = promote || action = reject. Valores Permitidos: canary e none. Valor padrão: none.

Especifica a estratégia de implantação usada na ação deploy antes de uma promote ação ou reject ação. Atualmente, canary é a única estratégia de implantação aceitável.

trafficSplitMethod - Método de divisão de tráfego
string. Opcional. Use quando strategy = canary. Valores Permitidos: pod e smi. Valor padrão: pod.

Para o valor smi, a divisão de tráfego percentual é feita no nível da solicitação usando uma malha de serviço. Uma malha de serviço deve ser configurada por um administrador de cluster. Essa tarefa manipula a orquestração de objetos TrafficSplit do SMI.

Para o valor pod, a divisão percentual não é possível no nível da solicitação na ausência de uma malha de serviço. Em vez disso, a entrada percentual é usada para calcular as réplicas para linha de base e canário. O cálculo é um percentual de réplicas especificadas nos manifestos de entrada para a variante estável.

percentage - Porcentagem
string. Obrigatório quando strategy = Canary && action = deploy. Valor padrão: 0.

O percentual usado para calcular o número de réplicas de variante de linha de base e de variante canário das cargas de trabalho contidas em arquivos de manifesto.

Para a entrada percentual especificada, calcule:

(percentual × número de réplicas) / 100

Se o resultado não for um inteiro, o piso matemático do resultado será usado quando as variantes de linha de base e canário forem criadas.

Por exemplo, suponha que a implantação hello-world esteja no arquivo de manifesto de entrada e que as seguintes linhas estejam na entrada da tarefa:

replicas: 4
strategy: canary
percentage: 25

Nesse caso, as implantações hello-world-baseline e hello-world-canary são criadas com uma réplica cada. A variante de linha de base é criada com a mesma imagem e marca que a versão estável, que é a variante de quatro réplicas antes da implantação. A variante canário é criada com a imagem e a marca correspondentes às alterações implantadas recentemente.

baselineAndCanaryReplicas - Réplicas de linha de base e canário
string. Obrigatório quando strategy = Canary && action = deploy && trafficSplitMethod = SMI. Valor padrão: 1.

Quando você define trafficSplitMethod como smi, a divisão de tráfego percentual é controlada no plano de malha de serviço. Você pode controlar o número real de réplicas para variantes canário e de linha de base independentemente da divisão de tráfego.

Por exemplo, suponha que o manifesto de implantação de entrada especifique 30 réplicas para a variante estável. Suponha também que você especifique a seguinte entrada para a tarefa:

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

Nesse caso, a variante estável recebe 80% do tráfego, enquanto as variantes de linha de base e canário recebem metade dos 20% especificados. As variantes de linha de base e canário não recebem três réplicas cada. Em vez disso, recebem o número especificado de réplicas, o que significa que cada uma delas recebe uma réplica.

manifests - Manifestos
string. Obrigatório quando action = deploy || action = promote || action = reject.

Especifica o caminho para os arquivos de manifesto a serem usados para implantação. Cada linha representa um só caminho. Um padrão de correspondência de arquivo é um valor aceitável para cada linha.

containers - Recipientes
string. Opcional. Use quando action = deploy || action = promote || action = bake.

Especifica a URL de recurso totalmente qualificada da imagem a ser usada para substituições nos arquivos de manifesto. A URL contosodemo.azurecr.io/helloworld:test é um exemplo.

imagePullSecrets - ImagePullSecrets
string. Opcional. Use quando action = deploy || action = promote.

Especifica uma entrada de várias linhas em que cada linha contém o nome de um segredo do Registro do Docker que já foi configurado dentro do cluster. Cada nome de segredo é adicionado imagePullSecrets em para as cargas de trabalho encontradas nos arquivos de manifesto de entrada.

renderType - Renderizar Mecanismo
string. Opcional. Use quando action = bake. Valores permitidos: helm, kompose, kustomize. Valor padrão: helm.

Especifica o tipo de renderização usado para produzir os arquivos de manifesto.

dockerComposeFile - Caminho para o arquivo de redação do Docker
string. Obrigatório quando action = bake && renderType = kompose.

Especifica um caminho de arquivo docker-compose.

helmChart - Gráfico do Helm
string. Obrigatório quando action = bake && renderType = helm.

Especifica o caminho do gráfico do Helm para assar.

releaseName - Nome da versão do Helm
string. Opcional. Use quando action = bake && renderType = helm.

Especifica o nome da versão do Helm a ser usado.

overrideFiles - Substituir arquivos
string. Opcional. Use quando action = bake && renderType = helm.

Especifica uma entrada de várias linhas que aceita o caminho para os arquivos de substituição. Os arquivos são usados quando é feito o bake dos arquivos de manifesto dos gráficos do Helm.

overrides - Substitui
string. Opcional. Use quando action = bake && renderType = helm.

Especifica os valores de substituição a serem definidos.

kustomizationPath - Caminho de Kustomization
string. Opcional. Use quando action = bake && renderType = kustomize.

Especifica o argumento que deve ser o caminho para o diretório que contém o arquivo ou uma URL do repositório git com um sufixo de caminho especificando same em relação à raiz do repositório.

resourceToPatch - Recurso a ser corrigido
string. Obrigatório quando action = patch. Valores Permitidos: file e name. Valor padrão: file.

Indica um dos seguintes métodos de patch:

• Um arquivo de manifesto identifica os objetos a serem corrigidos.
• Um objeto individual é identificado por tipo e nome como o destino do patch.

Os valores aceitáveis são arquivo e nome.

resourceFileToPatch - Caminho do arquivo
string. Obrigatório quando action = patch && resourceToPatch = file.

Especifica o caminho para o arquivo usado para um patch.

kind - Tipo
string. Obrigatório quando action = scale || resourceToPatch = name. Valores permitidos: deployment, replicaset, statefulset.

Especifica o tipo de objeto K8s, como deployment, replicaSet e muito mais.

name - Nome
string. Obrigatório quando action = scale || resourceToPatch = name.

Especifica o nome do objeto K8s.

replicas - Contagem de réplicas
string. Obrigatório quando action = scale.

Especifica o número de réplicas para as quais dimensionar.

mergeStrategy - Estratégia de mesclagem
string. Obrigatório quando action = patch. Valores permitidos: json, merge, strategic. Valor padrão: strategic.

Especifica o tipo de patch que está sendo fornecido.

arguments - Argumentos
string. Opcional. Use quando action = delete.

Especifica os argumentos para o kubectl delete comando . Um exemplo é: arguments: deployment hello-world foo-bar

patch - Patch
string. Obrigatório quando action = patch.

Especifica o conteúdo do patch.

secretType - Tipo de segredo
string. Obrigatório quando action = createSecret. Valores Permitidos: dockerRegistry e generic. Valor padrão: dockerRegistry.

Cria ou atualiza um genérico ou docker imagepullsecret. Especifique dockerRegistry para criar ou atualizar o imagepullsecret do registro selecionado. Um imagePullSecret é uma maneira de passar um segredo que contém uma senha do registro de contêiner para o Kubelet, para que ele possa efetuar pull de uma imagem privada em nome do pod.

secretName - Nome do segredo
string. Opcional. Use quando action = createSecret.

Especifica o nome do segredo. Você pode usar esse nome de segredo no arquivo de configuração YAML do Kubernetes.

secretArguments - Argumentos
string. Opcional. Use quando action = createSecret && secretType = generic.

Especifica chaves e valores literais a serem inseridos em segredo. Por exemplo, --from-literal=key1=value1--from-literal=key2="top secret".

dockerRegistryEndpoint - Conexão do serviço de registro do Docker
string. Opcional. Use quando action = createSecret && secretType = dockerRegistry.

Especifica as credenciais da conexão de serviço especificada que são usadas para criar um segredo do Registro do Docker dentro do cluster. Os arquivos de manifesto no imagePullSecrets campo podem fazer referência ao nome desse segredo.

rolloutStatusTimeout - Tempo limite para distribuição status
string. Opcional. Use quando action = deploy || action = patch || action = scale || action = promote. Valor padrão: 0.

Especifica o período de tempo (em segundos) para aguardar antes de terminar watch on rollout status.

Opções de controle da tarefa

Todas as tarefas têm opções de controle além de suas entradas de tarefa. Para obter mais informações, consulte Opções de controle e propriedades comuns da tarefa.

Variáveis de saída

Essa tarefa define as variáveis de saída a seguir, que você pode consumir em etapas downstream, trabalhos e estágios.

manifestsBundle
O local dos pacotes de manifesto criados pela ação bake

Comentários

Considerações sobre a Conexão de Serviço do Kubernetes ao acessar o AKS

Você pode criar uma conexão de serviço do Kubernetes com qualquer uma das opções a seguir.

• KubeConfig
• Conta de serviço
• Assinatura do Azure

Ao selecionar a opção Assinatura do Azure , o Kubernetes precisa estar acessível ao Azure DevOps no momento da configuração da conexão de serviço. Pode haver vários motivos pelos quais uma conexão de serviço não pode ser criada, por exemplo, você criou um cluster privado ou o cluster tem contas locais desabilitadas. Nesses casos, o Azure DevOps não pode se conectar ao cluster no momento da configuração da conexão de serviço e você verá uma tela carregando namespaces paralisada.

A partir do Kubernetes 1.24, os tokens de longa duração não são mais criados por padrão. O Kubernetes recomenda não usar tokens de longa duração. Como resultado, as tarefas que usam uma conexão de serviço do Kubernetes criada com a opção Assinatura do Azure não têm acesso ao token permanente necessário para autenticar e não podem acessar o cluster do Kubernetes. Isso também resulta na caixa de diálogo Carregar namespaces congelados .

Usar a Conexão de Serviço Resource Manager do Azure para acessar o AKS

Para clientes do AKS, o tipo de conexão de serviço do Azure Resource Manager fornece o melhor método para se conectar a um cluster privado ou um cluster que tem contas locais desabilitadas. Esse método não depende da conectividade de cluster no momento em que você cria uma conexão de serviço. O acesso ao AKS é adiado para o runtime de pipeline, que tem as seguintes vantagens:

• O acesso a um cluster do AKS (privado) pode ser executado de um agente auto-hospedado ou de conjunto de dimensionamento com linha de visão para o cluster.
• Um token é criado para cada tarefa que usa uma conexão de serviço do Azure Resource Manager. Isso garante que você esteja se conectando ao Kubernetes com um token de curta duração, que é a recomendação do Kubernetes.
• O AKS pode ser acessado mesmo quando as contas locais estão desabilitadas.

Perguntas frequentes sobre a conexão de serviço

Recebo a seguinte mensagem de erro: Não foi possível localizar nenhum segredo associado à conta de serviço. O que está acontecendo?

Você está usando a opção Conexão de serviço do Kubernetes com a Assinatura do Azure. Estamos atualizando esse método para criar tokens de longa duração. Espera-se que isso esteja disponível em meados de maio. No entanto, é recomendável começar a usar o tipo de conexão de serviço do Azure e não usar tokens de longa duração de acordo com as diretrizes do Kubernetes.

Estou usando o AKS e não quero alterar nada, posso continuar a usar tarefas com a conexão de serviço do Kubernetes?

Estamos atualizando esse método para criar tokens de longa duração. Espera-se que isso esteja disponível em meados de maio. No entanto, lembre-se de que essa abordagem é contra as diretrizes do Kubernetes.

Estou usando as tarefas do Kubernetes e a conexão de serviço do Kubernetes, mas não o AKS. Devo me preocupar?

As tarefas continuarão funcionando como antes.

O tipo de conexão do serviço kubernetes será removido?

Nossas tarefas do Kubernetes funcionam com qualquer cluster do Kubernetes, independentemente de onde estão sendo executadas. A conexão de serviço do Kubernetes continuará a existir.

Sou um cliente do AKS e tudo está funcionando bem, devo agir?

Não há necessidade de mudar nada. Se você estiver usando a conexão de serviço do Kubernetes e a Assinatura do Azure selecionada durante a criação, deverá estar ciente das diretrizes do Kubernetes sobre como usar tokens de longa duração.

Estou criando um Ambiente do Kubernetes e não tenho nenhuma opção para usar conexões de serviço

Caso não seja possível acessar o AKS durante o tempo de criação do ambiente, você pode usar um ambiente vazio e definir a connectionType entrada para uma conexão de serviço do Azure Resource Manager.

Tenho o AKS configurado com o RBAC do Azure Active Directory e meu pipeline não funciona. Essas atualizações resolve isso?

Acessar o Kubernetes quando o RBAC do AAD está habilitado não está relacionado à criação de token. Para evitar um prompt interativo, daremos suporte ao kubelogin em uma atualização futura.

Use uma tarefa de manifesto do Kubernetes em um pipeline de build ou lançamento para criar e implantar manifestos em clusters do Kubernetes.

Essa tarefa dá suporte ao seguinte:

• Substituição de artefato: a ação de implantação usa como entrada uma lista de imagens de contêiner que você pode especificar junto com suas marcas e resumos. A mesma entrada é substituída nos arquivos de manifesto não traduzidos antes do aplicativo para o cluster. Essa substituição garante que os nós de cluster efetuem pull da versão correta da imagem.

• Estabilidade do manifesto: a distribuição status dos objetos Kubernetes implantados é verificada. As verificações de estabilidade são incorporadas para determinar se a tarefa status é um sucesso ou uma falha.

• Anotações de rastreabilidade: as anotações são adicionadas aos objetos do Kubernetes implantados para sobrepor informações de rastreabilidade. Há suporte para as seguintes anotações:

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

• Manipulação de segredo: a createSecret ação permite que os segredos do Registro do Docker sejam criados usando conexões de serviço de registro do Docker. Também permite que segredos genéricos sejam criados usando variáveis de texto sem formatação ou variáveis secretas. Antes da implantação no cluster, você pode usar a secrets entrada junto com a ação deploy para aumentar os arquivos de manifesto de entrada com o valor apropriado imagePullSecrets .

• Manifesto do bake: bake a ação da tarefa permite a panificação de modelos em arquivos de manifesto do Kubernetes. A ação usa ferramentas como Helm, Compose e Kustomize. Com o baking, esses arquivos de manifesto do Kubernetes são utilizáveis para implantações no cluster.

• Estratégia de implantação: escolher a canary estratégia com a ação deploy leva à criação de nomes de carga de trabalho sufixos com -baseline e -canary. A tarefa dá suporte a dois métodos de divisão de tráfego:

  • Interface de Malha de Serviço: a abstração da Interface de Malha de Serviço (SMI) permite a configuração com provedores de malha de serviço como Linkerd e .Istio A tarefa Manifesto do Kubernetes mapeia objetos SMI TrafficSplit para os serviços estáveis, de linha de base e canário durante o ciclo de vida da estratégia de implantação.

    As implantações canário baseadas em uma malha de serviço e que usam essa tarefa são mais precisas. Essa precisão se deve à forma como os provedores de malha de serviço habilitam a divisão granular baseada em porcentagem do tráfego. A malha de serviço usa o registro de serviço e os contêineres sidecar injetados em pods. Essa injeção ocorre junto com contêineres de aplicativo para obter a divisão de tráfego granular.

  • Kubernetes sem malha de serviço: na ausência de uma malha de serviço, talvez você não obtenha a divisão de porcentagem exata desejada no nível da solicitação. No entanto, você pode fazer implantações canário usando variantes de linha de base e canário ao lado da variante estável.

    O serviço envia solicitações para pods de todas as três variantes de carga de trabalho à medida que as restrições de rótulo de seletor são atendidas. O Manifesto do Kubernetes respeita essas solicitações ao criar variantes de linha de base e canário. Esse comportamento de roteamento atinge o efeito pretendido de rotear apenas uma parte do total de solicitações para o canário.

  Compare as cargas de trabalho de linha de base e canário usando uma tarefa de Intervenção Manual em pipelines de lançamento ou uma tarefa Atrasar em pipelines YAML. Faça a comparação antes de usar a ação promover ou rejeitar da tarefa.

Ação implantar

O código YAML a seguir é um exemplo de implantação em um namespace do Kubernetes usando arquivos de manifesto:

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

No exemplo acima, a tarefa tenta localizar correspondências para as imagens foo/demo e bar/demo nos campos de imagem dos arquivos de manifesto. Para cada correspondência encontrada, o valor de tagVariable1 ou tagVariable2 é acrescentado como uma marca ao nome da imagem. Você também pode especificar resumos na entrada de contêineres para substituição de artefato.

Observação

Embora você possa criar deployações , promotee reject com entrada YAML relacionada à estratégia de implantação, o suporte para uma tarefa de Intervenção Manual não está disponível atualmente para pipelines de build.

Para pipelines de lançamento, recomendamos que você use ações e entradas relacionadas à estratégia de implantação na seguinte sequência:

1. Uma ação de implantação especificada com strategy: canary e percentage: $(someValue).
2. Uma tarefa de Intervenção Manual para que você possa pausar o pipeline e comparar a variante de linha de base com a variante canário.
3. Uma ação de promoção que será executada se uma tarefa de Intervenção Manual for retomada e uma ação de rejeição que será executada se uma tarefa de Intervenção Manual for rejeitada.

Criar ação secreta

O código YAML a seguir mostra uma criação de exemplo de segredos do Registro do Docker usando a conexão de serviço do Registro do Docker:

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

Esse código YAML mostra uma criação de exemplo de segredos genéricos:

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

Ação bake

O seguinte código YAML é um exemplo de arquivos de manifesto com bake de gráficos do Helm. Observe o uso de uma entrada de nome na primeira tarefa. Esse nome é referenciado posteriormente da etapa de implantação para especificar o caminho para os manifestos produzidos pela etapa de bake.

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

Observação

Para usar o Helm diretamente para gerenciar versões e reversões, confira a tarefa Empacotar e implantar gráficos do Helm.

Exemplo de Kustomize

O código YAML a seguir é um exemplo de arquivos de manifesto de panificação gerados com Kustomize que contêm um kustomization.yaml arquivo.

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)

Exemplo de Kompose

O código YAML a seguir é um exemplo de arquivos de manifesto de panificação gerados com Kompose, uma ferramenta de conversão para 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)

Ação de escala

O código YAML a seguir mostra um exemplo de dimensionamento de objetos:

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

Ação de patch

O código YAML a seguir mostra um exemplo de aplicação de patch de objeto:

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

Ação de exclusão

Este código YAML mostra uma exclusão de objeto de exemplo:

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

Solução de problemas

Meu cluster Kubernetes está protegido por um firewall e estou usando agentes hospedados. Como posso implantar nesse cluster?

Você pode conceder acesso de agentes hospedados por meio do firewall, permitindo os endereços IP para os agentes hospedados. Para obter mais detalhes, confira Intervalos de IP do Agente.

Como as solicitações funcionam em rotas de serviço estáveis e variantes com implantações canárias?

O relacionamento do seletor de rótulos entre pods e serviços no Kubernetes permite configurar implantações para que um único serviço encaminhe solicitações para as variantes estável e canário. A tarefa de manifesto do Kubernetes usa isso para implantações do canário.

Se a tarefa incluir as entradas de e strategy: canary, para cada carga de action: deploy trabalho (Implantação, ReplicaSet, Pod, ...) definida nos arquivos de manifesto de entrada, um e -canary uma -baseline variante da implantação serão criados. Neste exemplo, há uma implantação sampleapp no arquivo de manifesto de entrada e que, após a conclusão da execução número 22 do pipeline, a variante estável dessa implantação chamada sampleapp é implantada no cluster. Na execução subsequente (neste caso, execute o número 23), a tarefa de manifesto do Kubernetes com action: deploy e strategy: canary resultaria na criação de implantações sampleapp-baseline e sampleapp-canary cujo número de réplicas são determinadas pelo produto de entrada de percentage tarefa com o valor do número desejado de réplicas para a variante estável final de de acordo com os arquivos de sampleapp manifesto de entrada.

Excluindo o número de réplicas, a versão de linha de base tem a mesma configuração que a variante estável, enquanto a versão canário tem as novas alterações que estão sendo introduzidas pela execução atual (nesse caso, execute o número 23). Se uma intervenção manual for configurada no pipeline após a etapa mencionada acima, isso permitirá uma oportunidade de pausar o pipeline para que o administrador do pipeline possa avaliar as principais métricas para as versões de linha de base e canário e tomar a decisão sobre se as alterações canárias são seguras e boas o suficiente para uma distribuição completa.

Asaction: promote entradas e strategy: canary ou action: reject e strategy: canary das tarefas de manifesto do Kubernetes podem ser usadas para promover ou rejeitar as alterações canário, respectivamente. Observe que, em ambos os casos, no final desta etapa, somente a variante estável das cargas de trabalho declaradas nos arquivos de manifesto de entrada permanecerá implantada no cluster, enquanto a linha de base efêmera e as versões canário serão limpas.

Requisitos

Requisito	Descrição
Tipos de pipeline	YAML, build clássico, versão clássica
Executa em	Agent, DeploymentGroup
Demandas	Nenhum
Funcionalidades	Essa tarefa não atende a nenhuma demanda para tarefas subsequentes no trabalho.
Restrições de comando	Qualquer
Variáveis configuráveis	Qualquer
Versão do agente	Todas as versões do agente com suporte.
Categoria da tarefa	Implantar