Harness Kubernetes V2 Changes
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 ---.
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-exampleDeployment 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.
- 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.