KubernetesManifest@0 - Tarefa Implantar no Kubernetes v0

Use uma tarefa de manifesto do Kubernetes em um pipeline de compilação ou liberação para compilar e implantar manifestos em clusters do Kubernetes usando gráficos Helm.

Esta versão da tarefa foi preterida; use o KubernetesManifest@1 para aproveitar os recursos mais recentes, como federação de identidades de carga de trabalho.

Sintaxe

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

Insumos

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 - de conexão de serviço Kubernetes
string. Necessário quando action != bake.

Especifica uma conexão de serviço Kubernetes.

namespace - Namespace
string.

Especifica o namespace para os comandos usando o sinalizador –namespace. 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, none. Valor padrão: none.

Especifica a estratégia de implantação usada na ação deploy antes de uma ação promote 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, smi. Valor padrão: pod.

Para o valor smi, a divisão percentual de tráfego é 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. Esta tarefa lida com a orquestração de objetos SMI TrafficSplit.

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 é uma porcentagem de réplicas especificadas nos manifestos de entrada para a variante estável.

percentage - Percentagem
string. Necessário quando strategy = Canary && action = deploy. Valor padrão: 0.

A porcentagem usada para calcular o número de réplicas de variante de linha de base e variante canária das cargas de trabalho contidas em arquivos de manifesto.

Para a entrada percentual especificada, calcule:

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

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

Por exemplo, suponha que o hello-world de implantação 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 da versão estável, que é a variante de quatro réplicas antes da implantação. A variante canary é criada com a imagem e a tag correspondentes às alterações recém-implantadas.

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

Quando você define trafficSplitMethod como smi, a porcentagem de divisão de tráfego é controlada no plano de malha de serviço. Você pode controlar o número real de réplicas para variantes canárias 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

Neste caso, a variante estável recebe 80% do tráfego, enquanto as variantes de linha de base e canárias recebem cada uma metade dos 20%especificados. As variantes de linha de base e canárias 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 um recebe uma réplica.

manifests - Manifesta
string. Necessá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 - Contentores
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. O 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 no cluster. Cada nome secreto é adicionado em imagePullSecrets para as cargas de trabalho encontradas nos arquivos de manifesto de entrada.

renderType - Render Engine
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 composição do docker
string. Necessário quando action = bake && renderType = kompose.

Especifica um caminho de arquivo docker-compose.

helmChart - Helm Chart
string. Necessário quando action = bake && renderType = helm.

Especifica o caminho do gráfico de leme a ser assado.

releaseName - Helm Release Name
string. Opcional. Use quando action = bake && renderType = helm.

Especifica o nome da versão 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 Helm são cozidos.

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

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

kustomizationPath - Caminho de Kustomização
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 para corrigir
string. Necessário quando action = patch. Valores permitidos: file, 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 de arquivo e nome.

resourceFileToPatch - Caminho do arquivo
string. Necessário quando action = patch && resourceToPatch = file.

Especifica o caminho para o arquivo usado para um patch.

kind - Tipo
string. Necessá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. Necessário quando action = scale || resourceToPatch = name.

Especifica o nome do objeto K8s.

replicas - Contagem de réplicas
string. Necessário quando action = scale.

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

mergeStrategy - Estratégia de fusão
string. Necessá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 comando kubectl delete. Um exemplo é: arguments: deployment hello-world foo-bar

patch - Patch
string. Necessário quando action = patch.

Especifica o conteúdo do patch.

secretType - Tipo de secreta
string. Necessário quando action = createSecret. Valores permitidos: dockerRegistry, generic. Valor padrão: dockerRegistry.

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

secretName - Nome secreto
string. Opcional. Use quando action = createSecret.

Especifica o nome do segredo. Você pode usar esse nome secreto 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 - de 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 sob o campo imagePullSecrets podem então se referir ao nome desse segredo.

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

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

Opções de controlo de tarefas

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

Variáveis de saída

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

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

Observações

Observação

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

Use uma tarefa de manifesto do Kubernetes em um pipeline de compilação ou liberação para compilar e implantar manifestos em clusters do Kubernetes.

Esta tarefa suporta o 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 tags e resumos. A mesma entrada é substituída nos arquivos de manifesto não templatizados antes da aplicação no cluster. Essa substituição garante que os nós do cluster puxem a versão correta da imagem.

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

• Anotações de rastreabilidade: As anotações são adicionadas aos objetos Kubernetes implantados para sobrepor informações de rastreabilidade. As seguintes anotações são suportadas:

  • azure-pipelines/org
  • azure-pipelines/projeto
  • azure-pipelines/pipeline
  • azure-pipelines/pipelineId
  • azure-pipelines/execução
  • azure-pipelines/executionuri
  • azure-pipelines/jobName

• Secret handling: A ação createSecret permite que segredos de registro do Docker sejam criados usando conexões do serviço de registro do Docker. Ele também permite que segredos genéricos sejam criados usando variáveis de texto simples ou variáveis secretas. Antes da implantação no cluster, você pode usar a entrada secrets juntamente com a ação deploy para aumentar os arquivos de manifesto de entrada com o valor de imagePullSecrets apropriado.

• Bake manifest: A ação bake da tarefa permite baking templates 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 estratégia de canary com a ação deploy leva à criação de nomes de carga de trabalho sufixados com -baseline e -canary. A tarefa suporta dois métodos de divisão de tráfego:

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

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

  • Kubernetes sem malha de serviço: Na ausência de uma malha de serviço, você pode não obter a divisão de porcentagem exata desejada no nível de solicitação. No entanto, você pode fazer implantações canárias usando variantes linha de base e canárias 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 do rótulo seletor são atendidas. O Kubernetes Manifest honra essas solicitações ao criar variantes de linha de base e canário. Esse comportamento de roteamento alcança 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árias usando um de tarefas de Intervenção Manual de em pipelines de liberação ou uma tarefa de Atraso de em pipelines YAML. Faça a comparação antes de usar a ação de promoção ou rejeição da tarefa.

Ação de implantação

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

Observação

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

Para pipelines de versão, 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ária.
3. Uma ação de promoção que é executada se uma tarefa de Intervenção Manual for retomada e uma ação de rejeição que é 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 conexão do serviço 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 um exemplo de criação 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 de assar

O código YAML a seguir é um exemplo de baking de arquivos de manifesto de gráficos Helm. Observe o uso de uma entrada de nome na primeira tarefa. Esse nome é posteriormente referenciado na etapa de implantação para especificar o caminho para os manifestos que foram 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, consulte a tarefa Empacotar e implantar gráficos Helm.

Exemplo de Kustomize

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

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 gerados com o Kompose, uma ferramenta de conversão para o 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 do patch

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

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 neste cluster?

Você pode conceder acesso aos agentes hospedados por meio do firewall permitindo os endereços IP dos agentes hospedados. Para obter mais detalhes, veja Intervalos de IP do agente.

Como é que os pedidos funcionam para rotas de serviço estáveis e de variantes com implementações de proteção?

A relação do seletor de etiquetas entre pods e serviços no Kubernetes permite a configuração de implementações para que um único serviço encaminhe os pedidos para as variantes estáveis e de proteção. A tarefa de manifesto do Kubernetes usa isso para implantações canárias.

Se a tarefa incluir as entradas de action: deploy e strategy: canary, para cada carga de trabalho (Deployment, ReplicaSet, Pod, ...) definida nos arquivos de manifesto de entrada, uma -baseline e -canary variante da implantação serão criadas. Neste exemplo, há um sampleapp de implantação no arquivo de manifesto de entrada e que, após a conclusão do número de execução 22 do pipeline, a variante estável dessa implantação chamada sampleapp é implantada no cluster. Na execução subsequente (neste caso, executar 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 é determinado pelo produto de percentage entrada de tarefa com o valor do número desejado de réplicas para a variante estável final de sampleapp de 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ária tem as novas alterações que estão sendo introduzidas pela execução atual (neste caso, o número de execução 23). Se uma intervenção manual for configurada no pipeline após a etapa acima mencionada, 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 canary e tomar a decisão sobre se as alterações canárias são seguras e boas o suficiente para uma implantação completa.

As entradasaction: promote 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árias, respectivamente. Observe que, em ambos os casos, no final desta etapa, apenas a variante estável das cargas de trabalho declaradas nos arquivos de manifesto de entrada permanecerá implantada no cluster, enquanto as versões efêmeras de linha de base e canárias serão limpas.

Requerimentos

Requisito	Descrição
Tipos de pipeline	YAML, Construção clássica, Versão clássica
Funciona em	Agente, DeploymentGroup
Exigências	Nenhum
Capacidades	Esta tarefa não satisfaz quaisquer exigências para tarefas subsequentes no trabalho.
Restrições de comando	Qualquer
Variáveis configuráveis	Qualquer
Versão do agente	Todas as versões de agente suportadas.
Categoria de tarefa	Desplegar