Using OpenShift with Harness Kubernetes

Updated 1 month ago by Michael Cretzman

Harness supports OpenShift for Kubernetes deployments. This topic reviews OpenShift support in the Harness Delegate and Workflows.

In this topic:

Before You Begin

Review: Kubernetes Delegate and OpenShift

Harness supports OpenShift using a Delegate running externally to the Kubernetes cluster.

For steps on connecting, see Kubernetes Cluster in Add Cloud Providers.

Harness does support running Delegates internally for OpenShift 3.11 or greater, but the cluster must be configured to allow images to run as root inside the container in order to write to the filesystem.

Typically, OpenShift is supported through an external Delegate installation (shell script installation of the Delegate outside of the Kubernetes cluster) and a service account token, entered in the Kubernetes Service Account Token field. You only need to use the Master URL and Kubernetes Service Account Token fields in the Kubernetes Cloud Provider dialog.

The following shell script is a quick method for obtaining the service account token. Run this script wherever you run kubectl to access the cluster.

Set the SERVICE_ACCOUNT_NAME and NAMESPACE values to the values in your infrastructure.

SECRET_NAME=$(kubectl get sa "${SERVICE_ACCOUNT_NAME}" --namespace "${NAMESPACE}" -o json | jq -r '.secrets[].name')
TOKEN=$(kubectl get secret "${SECRET_NAME}" --namespace "${NAMESPACE}" -o json | jq -r '.data["token"]' | base64 -D)
echo $TOKEN

Once configured, OpenShift is used by Harness as a typical Kubernetes cluster.

Review: Deployment Strategy Support

In order to successfully deploy the workloads in your Manifests section of the Harness Service, they must meet the minimum requirements of the type of deployment you are performing.

  • Canary and Blue/Green Workflow Type - Deployment workloads only.
  • Rolling Workflow Type - All workload types except Jobs. Jobs will be added soon.
  • ​Apply Step - All workload types, including Jobs.
  • Harness supports OpenShift  DeploymentConfig across Canary, Blue Green, and Rolling deployment strategies. Please use apiVersion: and not apiVersion: v1.


Next Steps

How did we do?