Skip to main content

What Can I Deploy in Kubernetes?

Harness deployments involve different strategies and steps. These strategies and steps support different Kubernetes objects as managed and unmanaged workloads.

This topic describes the differences between Harness managed and unmanaged workloads and the objects supported by each deployment strategy.

Managed and Unmanaged Workloads

In Harness, a managed Kubernetes workload is a Kubernetes object deployed and managed to steady state. If steady state is not reached, the deployment is considered a failure and the Failure Strategy is executed (typically rollback).

An unmanaged workload is a workload deployed separate from your primary workload, such as Kubernetes Jobs. Harness does not track these workload versions or perform rollback on them.

Canary and Blue/Green Strategies

Harness Canary and Blue/Green steps support a single Deployment or StatefulSet workload as a managed entity. You cannot deploy 0 or more than 1 Deployment or StatefulSet workload.

Rolling (Rollout) Strategy

Rolling strategy steps support Deployment, StatefulSet, or DaemonSet as managed workloads, but not other workloads such as Jobs.

Apply Step

The Apply Step can deploy any workloads or objects in any strategy as a managed workload. You can select whether or not to skip steady state check.

OpenShift

Harness supports OpenShift DeploymentConfig in OpenShift clusters as a managed workload across Canary, Blue Green, and Rolling deployment strategies. Please use apiVersion: apps.openshift.io/v1 and not apiVersion: v1.

Deploy Unmanaged Workloads using Annotation

To deploy an object outside of the managed workloads in any strategy, you use the Harness annotation to make it unmanaged: harness.io/direct-apply: "true"|"false". Set to true to make a manifest an unmanaged workload.

For example, Harness Canary and Blue/Green steps support a single Deployment or StatefulSet workload as a managed entity, but you can deploy additional workloads as unmanaged using the harness.io/direct-apply annotation.

The following tables list the differences between the managed and unmanaged workloads for the different Kubernetes steps.

Managed Workloads Table

In Harness, a managed Kubernetes workload is a Kubernetes object deployed and managed to steady state. If steady state is not reached, the deployment is considered a failure and the Failure Strategy is executed (typically rollback).

ApplyRollingRollbackBlue GreenCanaryScale
DeploymentYesYesYesYes:
1 Deployment or StatefulSet mandatory/allowed
Yes:
1 Deployment or StatefulSet mandatory/allowed
Yes
StatefulSetYesYesYesYes:
1 Deployment or StatefulSet mandatory/allowed
Yes:
1 Deployment or StatefulSet mandatory/allowed
Yes
DaemonSetYesYesYesNoNoYes
CRDsYesYesYesNoNoNo
Any ObjectYesNoNoNoNoNo

Unmanaged Workloads Table

To deploy an object outside of the managed workloads in any strategy, you use the Harness annotation to make it unmanaged: harness.io/direct-apply: "true"|"false". Set to true to make a manifest an unmanaged workload.

For example, Harness Canary and Blue/Green steps support a single Deployment or StatefulSet workload as a managed entity, but you can deploy additional workloads as unmanaged using the harness.io/direct-apply:true annotation.

ApplyRollingRollbackBlue GreenCanaryScale
Any ObjectYesYesNoYes:
1 Deployment or StatefulSet mandatory/allowed
Yes:
1 Deployment or StatefulSet mandatory/allowed
No