We have seen a lot of options for deploying and configuring the Kubernetes cluster via the command line. When working with DevOps, however, changes need to be applied in a continuous way.

For this, there is the Kubernetes manifest task within Azure DevOps, which contains a lot of functionalities to manage a Kubernetes cluster:

task: KubernetesManifest@0
  inputs:
  action: 'deploy'
  kubernetesServiceConnection: '[service connection name]'
  manifests: '[path to your deployment file]'
  containers: 'msftazuredevops.azurecr.io/azuredevops:$(Build.BuildID)'

In the preceding example, the following is configured:

• action: The kind of action to we want to perform. In this example, the deploy action is used because we want to deploy/apply a deployment file.
• kubernetesServiceConnection: The service connection to the Kubernetes cluster.
• manifests: The path to the manifest file. As we are using the deploy action, this should be a reference to the deployment file.
• containers: A special field where you can override the version of the container being deployed. By specifying the above, every image is specified in the deployment manifest with the msftazuredevops.azurecr.io reference and the azuredevops repository is replaced by the new value as configured in this field.

Using a Kubernetes destination environment within Azure DevOps pipelines also has the advantage of seeing the environment running within Azure DevOps. This will show the number of running pods within the cluster.

Try it out with the following stage configuration for a build that will publish the deployment files to the artifact location of Azure DevOps:

stages:
  - stage : Build
    displayName : Build
    jobs:
     - job:
       pool:
           vmImage: 'ubuntu-latest'
       continueOnError: false
       steps:
       - task: Docker@2
         inputs:
           containerRegistry: '[Container Registry service connection]'
           repository: 'azuredevops'
           command: 'buildAndPush'
           Dockerfile: '**/Dockerfile'
           buildContext: '$(System.DefaultWorkingDirectory)/[folder path
 for docker]'
       - task: CopyFiles@2
         inputs:
           SourceFolder: '$(system.defaultworkingdirectory)/[path to the
 deployment manifest files]'
           Contents: '*'
           TargetFolder: '$(build.artifactstagingdirectory)'
           flattenFolders: true
       - task: PublishBuildArtifacts@1
         inputs:
           PathtoPublish: '$(Build.ArtifactStagingDirectory)'
           ArtifactName: 'drop'
           publishLocation: 'Container'

Next to the build stage, add the following release stage. Following the initial execution of the pipeline, a new environment will be available within Azure DevOps. In the environment created by the release, attach the Kubernetes cluster to see information on the running pods:

- stage : Release
    displayName : Release
    jobs:
     - deployment: KubernetesDeploy
       displayName: Deploy Kubernetes
       pool:
         vmImage: 'ubuntu-latest'
       environment: 'Kubernetes'
       strategy:
         runOnce:
           deploy:
             steps:
             - task: DownloadPipelineArtifact@2
               displayName: 'Download pipeline artifacts'
               inputs:
                 buildType: 'current'
                 targetPath: '$(Pipeline.Workspace)'
             - task: KubernetesManifest@0
               inputs:
                 action: 'deploy'
                 kubernetesServiceConnection: '[Kubernetes service
 connection]'
                 manifests: '$(Pipeline.Workspace)[deployment manifest]’
                 containers: '[container registry]:$(Build.BuildID)'

In the example, two stages are specified for a multi-stage pipeline. The first stage will build the container image via the Docker task and publish it to a container registry. After publishing the image, it also publishes a number of build artifacts, in this case, the Kubernetes manifests.

The second stage deploys to a specific environment called Kubernetes. This environment will also be created in Azure DevOps if it has not already been added. During the remainder of the process, it retrieves the published artifacts of the build stage and uses the Kubernetes manifest task to deploy the Kubernetes resources.