KubernetesManifest@1 - Implementar na tarefa kubernetes v1

Utilize ficheiros de manifesto do Kubernetes para implementar em clusters ou até mesmo preparar os ficheiros de manifesto para serem utilizados para implementações com gráficos 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, (criar segredo), delete, , deploy, patchpromote, , . rejectscalecreateSecret Valor predefinido: deploy.

Especifica a ação a ser executada.

connectionType - Tipo de ligação de serviço
string. Necessário quando action != bake. Valores permitidos: azureResourceManager (Azure Resource Manager), kubernetesServiceConnection (Ligação do Serviço Kubernetes). Valor predefinido: kubernetesServiceConnection.

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

• kubernetesServiceConnection (Ligação de Serviço do Kubernetes) – permite-lhe fornecer um ficheiro KubeConfig, especificar uma Conta de Serviço ou importar uma instância do AKS com a opção Subscrição do Azure . Importar uma instância do AKS com a opção Subscrição do Azure requer acesso ao cluster do Kubernetes no tempo de configuração da Ligação de Serviço.
• azureResourceManager(Azure Resource Manager) - Permite-lhe selecionar uma instância do AKS. Não acede ao cluster do Kubernetes na hora de configuração da Ligação de Serviço.

Para obter mais informações, veja Observações.

kubernetesServiceConnection - Ligação do serviço Kubernetes
Alias de entrada: kubernetesServiceEndpoint. string. Necessário quando action != bake && connectionType = kubernetesServiceConnection.

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

azureSubscriptionConnection - Subscrição do Azure
Alias de entrada: azureSubscriptionEndpoint. string. Necessário quando action != bake && connectionType = azureResourceManager.

Selecione a subscrição do Azure Resource Manager, que contém Azure Container Registry. Nota: para configurar a nova ligação de serviço, selecione a subscrição do Azure na lista e clique em "Autorizar". Se a sua subscrição não estiver listada ou se quiser utilizar um Principal de Serviço existente, pode configurar uma ligação de serviço do Azure com o botão "Adicionar" ou "Gerir".

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

Selecione um grupo de recursos do Azure.

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

Selecione um cluster gerido do Azure.

useClusterAdmin - Utilizar credenciais de administrador de cluster
boolean. Opcional. Utilize quando connectionType = azureResourceManager. Valor predefinido: false.

Utilize credenciais de administrador de cluster em vez de credenciais de utilizador do cluster predefinidas.

namespace - Espaço de nomes
string.

Especifica o espaço de nomes dos comandos com o –namespace sinalizador. Se o espaço de nomes não for fornecido, os comandos serão executados no espaço de nomes predefinido.

strategy - Estratégia
string. Opcional. Utilize quando action = deploy || action = promote || action = reject. Valores permitidos: canary, none. Valor predefinido: none.

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

trafficSplitMethod - Método de divisão de tráfego
string. Opcional. Utilize quando strategy = canary. Valores permitidos: pod, smi. Valor predefinido: pod.

Para o valor smi, a percentagem de divisão de tráfego é efetuada ao nível do pedido através de uma malha de serviço. Uma malha de serviço tem de ser configurada por um administrador de cluster. Esta tarefa processa a orquestração de objetos SMI TrafficSplit .

Para o valor pod, a divisão percentual não é possível ao nível do pedido na ausência de uma malha de serviço. Em vez disso, a percentagem de entrada é utilizada para calcular as réplicas da linha de base e do canary. O cálculo é uma percentagem de réplicas especificadas nos manifestos de entrada para a variante estável.

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

A percentagem utilizada para calcular o número de réplicas de variantes de linha de base e de variantes canárias das cargas de trabalho contidas em ficheiros de manifesto.

Para a percentagem de entrada especificada, calcule:

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

Se o resultado não for um número inteiro, o piso matemático do resultado é utilizado quando são criadas variantes de linha de base e canários.

Por exemplo, suponha que a implementação hello-world está no ficheiro de manifesto de entrada e que as seguintes linhas estão na entrada da tarefa:

replicas: 4
strategy: canary
percentage: 25

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

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

Quando definir trafficSplitMethod como smi, a divisão de tráfego de percentagem é controlada no plano de malha de serviço. 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 implementação de entrada especifica 30 réplicas para a variante estável. Assuma também que especifica 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ário recebem metade dos 20% especificados. As variantes de linha de base e canários 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 recebe uma réplica.

manifests - Manifestos
string. Necessário quando action = deploy || action = promote || action = reject.

Especifica o caminho para os ficheiros de manifesto a utilizar para a implementação. Cada linha representa um único caminho. Um padrão de correspondência de ficheiros é um valor aceitável para cada linha.

containers - Contentores
string. Opcional. Utilize quando action = deploy || action = promote || action = bake.

Especifica o URL de recurso completamente qualificado da imagem a utilizar para substituições nos ficheiros de manifesto. O URL contosodemo.azurecr.io/helloworld:test é um exemplo.

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

Especifica uma entrada multiline em que cada linha contém o nome de um segredo do registo do Docker que já foi configurado no cluster. Cada nome de segredo é adicionado imagePullSecrets em para as cargas de trabalho que se encontram nos ficheiros de manifesto de entrada.

renderType - Motor de Composição
string. Opcional. Utilize quando action = bake. Valores permitidos: helm, , komposekustomize. Valor predefinido: helm.

Especifica o tipo de composição utilizado para produzir os ficheiros de manifesto.

dockerComposeFile - Caminho para o ficheiro de composição do Docker
string. Necessário quando action = bake && renderType = kompose.

Especifica um caminho de ficheiro docker-compose.

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

Especifica o caminho do gráfico Helm para cozer.

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

Especifica o nome de versão do Helm a utilizar.

overrideFiles - Substituir Ficheiros
string. Opcional. Utilize quando action = bake && renderType = helm.

Especifica uma entrada multiline que aceita o caminho para os ficheiros de substituição. Os ficheiros são utilizados quando os ficheiros de manifesto dos gráficos Helm são criados.

overrides - Substituições
string. Opcional. Utilize quando action = bake && renderType = helm.

Especifica os valores de substituição a definir.

kustomizationPath - Caminho da Kustomization
string. Opcional. Utilize quando action = bake && renderType = kustomize.

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

resourceToPatch - Recurso a patch
string. Necessário quando action = patch. Valores permitidos: file, name. Valor predefinido: file.

Indica um dos seguintes métodos de patch:

• Um ficheiro 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 ficheiro e nome.

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

Especifica o caminho para o ficheiro utilizado para um patch.

kind - Tipo
string. Necessário quando action = scale || resourceToPatch = name. Valores permitidos: deployment, , replicasetstatefulset.

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 a dimensionar.

mergeStrategy - Estratégia de Intercalação
string. Necessário quando action = patch. Valores permitidos: json, , mergestrategic. Valor predefinido: strategic.

Especifica o tipo de patch que está a ser fornecido.

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

Especifica os argumentos para o kubectl delete comando. 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 segredo
string. Necessário quando action = createSecret. Valores permitidos: dockerRegistry, generic. Valor predefinido: dockerRegistry.

Cria ou atualiza um genérico ou docker imagepullsecret. Especifique dockerRegistry para criar ou atualizar o imagepullsecret registo selecionado. Uma imagePullSecret é uma forma de transmitir um segredo que contém uma palavra-passe de registo de contentor para o Kubelet, para que possa solicitar uma imagem privada em nome do seu Pod.

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

Especifica o nome do segredo. Pode utilizar este nome secreto no ficheiro de configuração do YAML do Kubernetes.

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

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

dockerRegistryEndpoint - Ligação do serviço de registo do Docker
string. Opcional. Utilize quando action = createSecret && secretType = dockerRegistry.

Especifica as credenciais da ligação de serviço especificada que são utilizadas para criar um segredo do registo do Docker no cluster. Os ficheiros de manifesto no imagePullSecrets campo podem, em seguida, referir-se ao nome deste segredo.

rolloutStatusTimeout - Tempo limite para o estado de implementação
string. Opcional. Utilize quando action = deploy || action = patch || action = scale || action = promote. Valor predefinido: 0.

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

Opções de controlo de tarefas

Todas as tarefas têm opções de controlo para além das entradas de tarefas. Para obter mais informações, veja Opções de controlo e propriedades de tarefas comuns.

Variáveis de saída

Esta tarefa define as seguintes variáveis de saída, que pode consumir em passos, tarefas e fases a jusante.

manifestsBundle
A localização dos pacotes de manifesto criados pela ação de cozedura

Observações

Considerações sobre a Ligação de Serviço do Kubernetes ao aceder ao AKS

Pode criar uma ligação de serviço do Kubernetes com qualquer uma das seguintes opções.

• KubeConfig
• Conta de Serviço
• Subscrição do Azure

Ao selecionar a opção Subscrição do Azure , o Kubernetes tem de estar acessível ao Azure DevOps no momento da configuração da ligação de serviço. Podem existir vários motivos pelos quais não é possível criar uma ligação de serviço, por exemplo , criou um cluster privado ou o cluster tem contas locais desativadas. Nestes casos, o Azure DevOps não consegue ligar-se ao cluster no momento da configuração da ligação de serviço e verá um ecrã Desativado a carregar espaços de nomes .

A partir do Kubernetes 1.24, os tokens de longa duração já não são criados por predefinição. O Kubernetes recomenda que não utilize tokens de longa duração. Como resultado, as tarefas que utilizam uma ligação de serviço do Kubernetes criada com a opção Subscrição do Azure não têm acesso ao token permanente necessário para autenticar e não podem aceder ao cluster do Kubernetes. Isto também resulta na caixa de diálogo Carregar espaços de nomes congelados .

Utilizar a Ligação do Serviço Resource Manager do Azure para aceder ao AKS

Para os clientes do AKS, o tipo de ligação de serviço do Azure Resource Manager fornece o melhor método para ligar a um cluster privado ou a um cluster com contas locais desativadas. Este método não depende da conectividade do cluster no momento em que criar uma ligação de serviço. O acesso ao AKS é diferido para o runtime do pipeline, que tem as seguintes vantagens:

• O acesso a um cluster do AKS (privado) pode ser efetuado a partir de um agente autoalojado ou de um conjunto de dimensionamento com linha de visão para o cluster.
• É criado um token para cada tarefa que utiliza uma ligação de serviço do Azure Resource Manager. Isto garante que está a ligar ao Kubernetes com um token de curta duração, que é a recomendação do Kubernetes.
• O AKS pode ser acedido mesmo quando as contas locais estão desativadas.

FAQ da ligaçã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á a acontecer?

Está a utilizar a ligação do serviço Kubernetes com a opção Subscrição do Azure. Estamos a atualizar este método para criar tokens de longa duração. Espera-se que esteja disponível em meados de maio. No entanto, é recomendado começar a utilizar o tipo de ligação de serviço do Azure e não utilizar tokens de longa duração de acordo com a documentação de orientação do Kubernetes.

Estou a utilizar o AKS e não quero alterar nada, posso continuar a utilizar tarefas com a ligação do serviço Kubernetes?

Estamos a atualizar este método para criar tokens de longa duração. Espera-se que esteja disponível em meados de maio. No entanto, tenha em atenção que esta abordagem é contra a orientação do Kubernetes.

Estou a utilizar as tarefas do Kubernetes e a ligação do serviço Kubernetes, mas não o AKS. Devo preocupar-me?

As tarefas continuarão a funcionar como anteriormente.

O tipo de ligação do serviço Kubernetes será removido?

As nossas tarefas do Kubernetes funcionam com qualquer cluster do Kubernetes, independentemente do local onde estão a ser executadas. A ligação do serviço Kubernetes continuará a existir.

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

Não há necessidade de mudar nada. Se estiver a utilizar a ligação do serviço Kubernetes e tiver selecionado a Subscrição do Azure durante a criação, deve estar ciente da documentação de orientação do Kubernetes sobre a utilização de tokens de longa duração.

Estou a criar um Ambiente do Kubernetes e não tenho opção de utilizar ligações de serviço

Caso não consiga aceder ao AKS durante a hora de criação do ambiente, pode utilizar um ambiente vazio e definir a connectionType entrada para uma ligação de serviço do Azure Resource Manager.

Configurei o AKS com o RBAC do Azure Active Directory e o meu pipeline não funciona. Estas atualizações irão resolver este problema?

Aceder ao Kubernetes quando o RBAC do AAD está ativado não está relacionado com a criação de tokens. Para impedir um pedido interativo, iremos suportar o kubelogin numa atualização futura.

Utilize uma tarefa de manifesto do Kubernetes num pipeline de compilação ou versão para criar e implementar manifestos em clusters do Kubernetes.

Esta tarefa suporta o seguinte:

• Substituição de artefactos: a ação de implementação é tomada como entrada de uma lista de imagens de contentor que pode especificar juntamente com as respetivas etiquetas e resumos. A mesma entrada é substituída nos ficheiros de manifesto não modelados antes da aplicação para o cluster. Esta substituição garante que os nós de cluster solicitam a versão certa da imagem.

• Estabilidade do manifesto: o estado de implementação dos objetos do Kubernetes implementados é verificado. As verificações de estabilidade são incorporadas para determinar se o estado da tarefa é um êxito ou uma falha.

• Anotações de rastreabilidade: as anotações são adicionadas aos objetos do Kubernetes implementados para sobrepor informações de rastreabilidade. São suportadas 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

• Processamento de segredos: createSecret a ação permite que os segredos do registo do Docker sejam criados com ligações do serviço de registo do Docker. Também permite a criação de segredos genéricos com variáveis de texto simples ou variáveis secretas. Antes da implementação no cluster, pode utilizar a secrets entrada juntamente com a deploy ação para aumentar os ficheiros de manifesto de entrada com o valor adequado imagePullSecrets .

• Manifesto do Bake: a bake ação da tarefa permite cozer modelos em ficheiros de manifesto do Kubernetes. A ação utiliza ferramentas como Helm, Compose e Kustomize. Com a cozedura, estes ficheiros de manifesto do Kubernetes são utilizáveis para implementações no cluster.

• Estratégia de implementação: escolher a canary estratégia com a ação deploy leva à criação de nomes de cargas de trabalho sufixados com -baseline e -canary. A tarefa suporta dois métodos de divisão de tráfego:

  • Interface do Service Mesh: a abstração do Service Mesh Interface (SMI) permite a configuração com fornecedores de malha de serviços 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ários durante o ciclo de vida da estratégia de implementação.

    As implementações canary baseadas numa malha de serviço e que utilizam esta tarefa são mais precisas. Esta precisão deve-se à forma como os fornecedores de malha de serviços ativam a divisão granular baseada em percentagem do tráfego. A malha de serviço utiliza o registo de serviços e os contentores de sidecar que são injetados em pods. Esta injeção ocorre juntamente com os contentores de aplicações para alcançar a divisão de tráfego granular.

  • Kubernetes sem malha de serviço: na ausência de uma malha de serviço, poderá não obter a divisão de percentagem exata que pretende ao nível do pedido. No entanto, pode efetuar implementações canárias com variantes de linha de base e canário junto à variante estável.

    O serviço envia pedidos para pods das três variantes de carga de trabalho à medida que as restrições de seletor-etiqueta são cumpridas. O Manifesto do Kubernetes honra estes pedidos ao criar variantes de linha de base e canários. Este comportamento de encaminhamento obtém o efeito pretendido de encaminhar apenas uma parte do total de pedidos para o canário.

  Compare as cargas de trabalho de linha de base e canários com uma tarefa de Intervenção Manual em pipelines de versão ou uma tarefa Atraso em pipelines YAML. Faça a comparação antes de utilizar a ação promover ou rejeitar a tarefa.

Implementar ação

O seguinte código YAML é um exemplo de implementação num espaço de nomes do Kubernetes com ficheiros 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 ficheiros de manifesto. Para cada correspondência encontrada, o valor de ou tagVariable1tagVariable2 é acrescentado como uma etiqueta ao nome da imagem. Também pode especificar resumos na entrada de contentores para substituição de artefactos.

Nota

Embora possa criar deploy, promotee reject ações com entrada YAML relacionadas com a estratégia de implementação, o suporte para uma tarefa de Intervenção Manual está atualmente indisponível para pipelines de compilação.

Para pipelines de versão, recomendamos que utilize ações e entradas relacionadas com a estratégia de implementação na sequência seguinte:

1. Uma ação de implementação especificada com strategy: canary e percentage: $(someValue).
2. Uma tarefa de Intervenção Manual para que possa colocar o pipeline em pausa e comparar a variante de linha de base com a variante canary.
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 seguinte código YAML mostra uma criação de exemplo dos segredos do registo do Docker através da ligação do serviço de Registo 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 de cozedura

O seguinte código YAML é um exemplo de ficheiros de manifesto de assar a partir de gráficos Helm. Tenha em atenção a utilização de uma entrada de nome na primeira tarefa. Este nome é posteriormente referenciado a partir do passo de implementação para especificar o caminho para os manifestos que foram produzidos pelo passo de cozedura.

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

Nota

Para utilizar o Helm diretamente para gerir versões e reversões, veja a tarefa Package and deploy Helm charts (Empacotar e implementar gráficos Helm).

Exemplo de Kustomize

O seguinte código YAML é um exemplo de ficheiros de manifesto de cozedura gerados com o Kustomize que contêm um kustomization.yaml ficheiro.

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 seguinte código YAML é um exemplo de ficheiros de manifesto de assar 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 dimensionamento

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

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 seguinte código YAML 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

Eliminar ação

Este código YAML mostra uma eliminação de objetos de exemplo:

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

Resolução de problemas

O cluster My Kubernetes está protegido por uma firewall e eu estou a utilizar agentes alojados. Como posso implementar neste cluster?

Pode conceder acesso a agentes alojados através da firewall, ao permitir os endereços IP para os agentes alojados. 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 utiliza-o para implementações de proteção.

Se a tarefa incluir as entradas de e strategy: canary, para cada carga de action: deploy trabalho (Implementação, ReplicaSet, Pod, ...) definidas nos ficheiros de manifesto de entrada, é criada uma variante e -canary uma -baseline variante da implementação. Neste exemplo, existe uma implementação sampleapp no ficheiro de manifesto de entrada e que, após a conclusão do número de execução 22 do pipeline, a variante estável desta implementação com o nome sampleapp é implementada 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 implementações sampleapp-baseline e sampleapp-canary cujo número de réplicas é determinado pelo produto da entrada de percentage tarefas com o valor do número pretendido de réplicas para a variante estável final de de acordo com os ficheiros de manifesto de sampleapp 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 canary tem as novas alterações que estão a ser introduzidas pela execução atual (neste caso, execute o número 23). Se for configurada uma intervenção manual no pipeline após o passo mencionado acima, permitirá uma oportunidade de colocar o pipeline em pausa para que o administrador do pipeline possa avaliar as métricas-chave das 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 implementação completa.

strategy: canary Asaction: promote e ou action: reject e entradas strategy: canary das tarefas de manifesto do Kubernetes podem ser utilizadas para promover ou rejeitar as alterações canárias, respetivamente. Tenha em atenção que, em ambos os casos, no final deste passo, apenas a variante estável das cargas de trabalho declaradas nos ficheiros de manifesto de entrada permanecerá implementada no cluster, enquanto a linha de base efémera e as versões canary são limpas.

Requisitos

Requisito	Description
Tipos de pipeline	YAML, Compilação clássica, Versão clássica
É executado em	Agente, DeploymentGroup
Exigências	Nenhuma
Capacidades	Esta tarefa não satisfaz quaisquer exigências para tarefas subsequentes na tarefa.
Restrições de comandos	Qualquer
Variáveis de tabelas definidas	Qualquer
Versão do agente	Todas as versões de agente suportadas.
Categoria da tarefa	Implementação