8 - Kubernetes Workflow Commands

Updated 3 days ago by Michael Cretzman

This topic lists some of the Kubernetes Workflow commands. It does not include the commands added automatically in Canary, Rolling Update, and Blue/Green Workflows.

Deploy Manifests Separately using Apply Step

By default, the Harness Kubernetes Workflow will deploy all of the resources you have set up in the Service Manifests section. In some cases, you might have resources that you do not want to deploy as part of the main Workflow deployment. For example, you might want to deploy an additional resource only after Harness has verified the deployment of the main resources in the Service Manifests section.

We can accomplish this use two Harness features:

  • Harness Kubernetes Services allow you to use a special comment to ignore a resource in the Service Manifests section:

    # harness.io/skip-file-for-deploy
  • Workflows include an Apply step that allows you to deploy any resource you have set up in the Service Manifests section, including those with the comment:

     # harness.io/skip-file-for-deploy 
The Apply step does not version ConfigMap and Secret objects. ConfigMap and Secret objects are overwritten on each deployment. This is the same as when ConfigMap and Secret objects are marked as unversioned in typical rollouts (harness.io/skip-versioning: true). See Versioning and Annotations.

What Kubernetes Workloads Can I Include?

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.

Apply Step Examples

The Apply Step is primarily used for deploying Jobs controllers, but it can be used for other resources. Typically, when you want to deploy multiple workloads (Deployment, StatefulSet, and DaemonSet) you will use separate Workflows for each.

Deploying a resource out of sync with the main resource deployment in a Workflow can be useful if a specific resource requires some external service processing that is orchestrated around your main rollout, such as database migration.

One reason why a Job controller object is a good use of the Apply step is that represents a finite task that runs to completion rather than managing an ongoing desired state. You can run a Job to do perform work outside of the primary object deployment, such as large computation and batch-oriented tasks.

In another example, let's say you have two services, serviceA calls serviceB to populate a product page. The main Workflow rollout deploys serviceB successfully and then the Apply step deploys serviceA next, ensuring serviceA only calls serviceB after serviceB is deployed successfully.

Another example of the use of the Apply step is service mesh traffic shifting. Your main Workflow rollout can deploy your services and then an Apply step can apply the resource that modifies the service mesh for the deployed services (for example, in an Istio-enabled cluster, VirtualService).

Ignore a Manifest File

To have a Workflow ignore a resource file in a Service Manifest section, you add the comment # harness.io/skip-file-for-deploy to the top of the file. For example, here is a ConfigMap file using the comment:

Now, when this Service is deployed by a Workflow, this ConfigMap resource will not applied.

The comment # harness.io/skip-file-for-deploy must be at the top of the file. If it is on the second line it will not work and the resource will be deployed as part of the main Workflow rollout.

Apply Step

The Apply step applies to Service Manifests that are local or added remotely using the Kubernetes Resource Specs in YAML format option.

The Workflow Apply step will apply any resource in a Service Manifest section explicitly. You must provide the path and name of the file in Apply, and Harness will deploy the resource.

For example, the following image shows a Jobs resource in a Service Manifest section that uses the ignore comment # harness.io/skip-file-for-deploy so that the Workflow does not apply it as part of its main Deploy steps, and the Apply step that specifies the same Jobs resource:

The File paths field in the Apply step must include the folder name and the file name. In the above example, the folder templates is included with the file name jobs.yamltemplates/jobs.yaml.

You can include multiple resource files in the Apply step File paths field by separating them with commas, for example: templates/jobs.yaml, templates/statefulSet.yaml

If you apply the ignore comment # harness.io/skip-file-for-deploy to a resource but do not use the resource in an Apply step, the resource is never deployed.

Skip Dry Run

By default, Harness uses the --dry-run flag on the kubectl apply command, which prints the object that would be sent to the cluster without really sending it. If the Skip Dry Run option is selected, Harness will not use the --dry-run flag.

Apply Step Rollback

It is important to note that when you use Apply Step to deploy additional objects, these objects are not rolled back by default. The Workflow will rollback the primary object it deployed only.

For example, let’s say you have a Canary Workflow for a Harness Service that has manifests for Deployment and StatefulSet objects. You can have the Workflow deploy Deployment and then use an Apply State step to deploy a StatefulSet object.

If the Workflow fails and there is a rollback, only the Deployment object is rolled back. To roll back the StatefulSet object, you can add a Shell Script to the Phase's Rollback Steps section that executes kubectl commands.

Delete and Scale Commands

Kubernetes Workflows include two important commands that help you manage resources, Delete and Scale.

Delete Command

The Delete command removes the resources you identify.

There are a few ways to specify the resource to be removed:

  • Using the Harness built-in variable, ${k8s.canaryWorkload}. At runtime, this will resolve to something like Deployment/harness-example-deployment-canary.
  • Using the name of the resource in the format Kind/[Namespace/]Name, with Namespace optional. For example, Deployment/harness-example-deployment-canary, or to delete a specific namespace, .
  • Using an asterisk (*) deletes all of the releases in the Release Name you specified in the Infrastructure Definition used by the Workflow. The namespace is not deleted.

Here is an example of the log from a Delete command:

Resources to delete are:
- Deployment/harness-example-deployment-canary

Canary Delete and Traffic Management

If you are using the Traffic Split step or doing Istio traffic shifting using the Apply step, move the Canary Delete step from Wrap Up section of the Canary phase to the Wrap Up section of the Primary phase.

Moving the Canary Delete step to the Wrap Up section of the Primary phase will prevent any traffic from being routed to deleted pods before traffic is routed to stable pods in the Primary phase.

For more information, see Canary Delete Step.

Scale Command

The Scale command updates the number of instances running, either by count or percentage. You use it to scale up or down from the number of instances specified before the Scale command. The number could come from the Service manifest or a previous Workflow step, whichever set the number of instances right before the Scale command.

The following Scale command increases the number of instances to 4.

If you have an odd number of instances, such as 3 instances, and then enter 50% in Scale, the number of instances is scaled down to 2.

You can scale down to 0 to remove all instances.

In the Workload field in Scale, you can enter the Harness built-in variable ${k8s.canaryWorkload} or the name of the resource in the format Kind/[Namespace/]Name, with Namespace optional. For example, Deployment/harness-example-deployment-canary. You can scale Deployment, DaemonSet, or StatefulSet.

Next Steps

How did we do?