KubernetesManifest@0 – Implantar na tarefa do Kubernetes v0

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

Syntax

# Deploy to Kubernetes v0
# Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts.
- task: KubernetesManifest@0
  inputs:
    #action: 'deploy' # 'bake' | 'createSecret' | 'delete' | 'deploy' | 'patch' | 'promote' | 'scale' | 'reject'. Action. Default: deploy.
    #kubernetesServiceConnection: # string. Required when action != bake. Kubernetes service connection. 
    #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.

kubernetesServiceConnection - Conexão de serviço do Kubernetes
string. Obrigatório quando action != bake.

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

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éplica 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, eles 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 único 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 arquivos de manifesto de gráficos do Helm são assados.

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 de 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
Especifica o local dos pacotes de manifesto criados pela ação bake.

Comentários

Observação

Há uma versão mais recente dessa tarefa disponível que fornece suporte adicional para direcionar um cluster do Kubernetes de diferentes maneiras, usando a connectionType propriedade . Para obter mais informações, consulte comentários deconexão de serviço de KubernetesManifest@1 e KubernetesManifest@1

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

Esta 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 certa da imagem.

• Estabilidade do manifesto: a status de distribuição dos objetos kubernetes implantados está marcada. 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 as 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

• Tratamento de segredos: a createSecret ação permite que os segredos do Registro do Docker sejam criados usando conexões de serviço do Registro do Docker. Ele 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árias 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 percentual de tráfego. A malha de serviço usa o registro de serviço e os contêineres de sidecar que são 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 percentual 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 obtém 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 Atraso 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 encontrar 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

Este 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 código YAML a seguir é um exemplo de arquivos de manifesto de panificação 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 que foram produzidos pela etapa 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, consulte 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 o 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, uma e -canary variante -baseline da implantação serão criadas. 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 da entrada de percentage tarefa com o valor do número desejado de réplicas para a variante estável final de de sampleapp acordo com os arquivos de 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: canarystrategy: canary ou action: reject e 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árias serão limpas.

Requisitos

Requisito	Descrição
Tipos de pipeline	YAML, build clássico, versão clássica
É executado em	Agent, DeploymentGroup
Demandas	Nenhum
Funcionalidades	Essa tarefa não atende a nenhuma demanda por 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