Kubernetes manifest task

• 11/06/2019
• 10 minutes to read
• • 

Use this task in a build or release pipeline to bake and deploy manifests to Kubernetes clusters.

Overview

Following are the key benefits of this task -

• Artifact substitution - The deploy action takes as input a list of container images which can be specified along with their tags or digests. The same is substituted into the non-templatized version of manifest files before application to the cluster to ensure that the right version of the image is pulled by the cluster nodes.

• Manifest stability - Rollout status is checked for the Kubernetes objects deployed. This is done to incorporate stability checks while computing the task status as success/failure.

• Traceability annotations - Annotations are added to the deployed Kubernetes objects to superimpose traceability information in the form of following annotations -

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

• Secret handling - The createSecret action enables creation of docker-registry secrets using Docker Registry Service Connections and generic secrets using plain-text/secret variables. The secrets input can be used along with deploy action so that the manifest files specified as inputs are augmented with appropriate imagePullSecrets before deploying to the cluster.

• Bake manifest - The bake action of the task allows for baking Helm charts into Kubernetes manifest files so that the same can be applied onto the cluster.

• Deployment strategy - Choosing canary strategy with deploy action leads to creation of workloads suffixed with '-baseline' and '-canary'. There are two methods of traffic splitting supported in the task:

  • Service Mesh Interface - Service Mesh Interface abstraction allows for plug-and-play configuration with service mesh providers such as Linkerd and Istio. Meanwhile, the KubernetesManifest task takes away the hard work of mapping SMI's TrafficSplit objects to the stable, baseline and canary services during the lifecycle of the deployment strategy. Service mesh based canary deployments using this task are more accurate as service mesh providers enable granular percentage traffic split (via service registry and sidecar containers injected into pods alongside application containers).
  • Only Kubernetes (no service mesh)- In the absence of service mesh, while it may not be possible to achieve exact percentage split at the request level, it is still possible to perform canary deployments by deploying -baseline and -canary workload variants next to the stable variant. The service routes requests to pods of all three workload variants as the selector-label constraints are met (KubernetesManifest will honor these when creating -baseline and -canary variants). This achieves the intended effect of routing only a portion of total requests to the canary.

  The -baseline and -canary workloads can be compared using a ManualIntervention task) in release pipelines or using a Delay task in YAML pipeline before utilizing the promote/reject action of the task.

Deploy action

Following is an example YAML snippet for deploying to a Kubernetes namespace using manifest files -

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

In the above example, the tasks tries to find matches for the image foobar/demo in the image fields of manifest files. If a match is found, the value of tagVariable is appended as tag to the image name. Note that it is also possible to specify digests in the containers input for artifact substitution.

Promote and reject actions

Create secret action

Following is an example YAML snippet for creation of docker registry secrets using Docker Registry service connection-

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

Following is an example YAML snippet for creation of generic secrets -

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

Bake action

Following is an example YAML snippet for baking manifest files from Helm charts. Note the usage of name input in the first task which is later referenced from the subsequent deploy step for specifying path to the manifests that were produced by the bake step -

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

Scale action

Following is an example YAML snippet for scaling objects -

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

Patch action

Following is an example YAML snippet for patching an object -

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

Delete action

Following is an example YAML snippet for deleting objects -

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

Open source

This task is open source on GitHub. Feedback and contributions are welcome.