Harness Kubernetes V2 Changes

Updated 1 year ago by Michael Cretzman

The new version of Kubernetes deployments in Harness (labeled as Kubernetes V2 in Harness Manager) includes the changes described below.

Kubernetes and Helm Service Separated

Kubernetes and Helm are now supported as separate Harness Service types. This separation is not part of Harness Kubernetes Version 2 features, but is important to note, as it is a major change from how Kubernetes and Helm deployments were created in Version 1.

When you create a new Harness Service, you select the Deployment Type for the Service as Kubernetes or Helm:

Service Configuration using Manifest Files

Kubernetes Service definition now supports any type of manifest file to configure your Kubernetes microservice in Services.

Written in YAML, manifest files describe the desired state of your microservice in terms of Kubernetes API objects, such as a Kubernetes Deployment object.

Manifests can be organized in multiple files or single manifest files can include one or more API object descriptions. For example. the default spec.yaml in the Service contains both ConfigMap and Deployment object descriptions, demarcated with the YAML document delimiter ---.

All Kubernetes resources are defined in manifests. There is no automatic creation of Kubernetes namespace, configMap, Secret, and ImagePullSecret.

A Kubernetes Service supports local (in Harness Manager) and remote (Git repo) manifest files. Remote files are pulled from the repo and used at deployment runtime.

Go Templating for Manifests

The Harness Service supports Go Templating for the files in its Manifests section, and automatically installs the Go text template package during deployment. You define variables in a values.yaml template file and then use those predefined variables in your manifests. A simple example would be the name variable in values.yaml:

name: harness-example

In a manifest, such as a Deployment manifest, you reference the name variable like this:

...
spec:
  containers:
  - name: {{.Values.name}}
...

When the manifest is used during deployment, the output contains the name variable value:

INFO   2019-02-12 17:00:47        spec:
INFO   2019-02-12 17:00:47          containers:
INFO   2019-02-12 17:00:47          - name: harness-example

Deployment Strategies

The following deployment strategies are supported in Version 2 Workflows:

  • Canary - This is a two-Phase Workflow. In first Phase, Harness creates a Canary version of the Kubernetes Deployment. Once that Deployment is verified, we delete it by default. In the second Phase, called Primary, the actual Deployment is updated using a Kubernetes RollingUpdate method.
If you are new to Kubernetes RollingUpdate deployments, see Performing a Rolling Update from Kubernetes. That guide summaries RollingUpdate and provides an interactive, online tutorial.
  • Blue/Green - Blue/Green deployment is a method that reduces downtime and risk by running two identical environments called Blue and Green, both hosting different versions of the same app, and swaps networking routing between them to support primary (live) and stage application delivery. In the Harness deployment, a primary and a stage Kubernetes service are swapped.
  • Rolling Update - This is a Kubernetes-native RollingUpdate deployment. If you are new to Kubernetes RollingUpdate deployments, see Performing a Rolling Update from Kubernetes.

All deployment methods are covered in Harness documentation.

How did we do?