Kubernetes Rollout Deploy step

Define the Kubernetes Rollout Deploy step settings and behavior

This topic provides settings and permissions for the Kubernetes Rollout Deployment step. In Pipeline Studio, the step is labeled Rollout Deployment. On inspection, the step is labeled K8s Rollout Deploy.

---

What you will learn from this topic

• How rollout deployments apply a Kubernetes rolling update strategy

• Which workloads you can deploy with this step

• How Rolling vs Apply differs for Jobs and rollback

• How multiple managed workloads behave in one Rollout Deployment step

• How to configure Name, Timeout, Skip Dry Run, and Advanced settings

---

Before you begin

Confirm the following before you add a Rollout Deployment step:

• Kubernetes Deploy stage: Add a Deploy stage with the Kubernetes deployment type and a service that includes Kubernetes manifests. Go to What can I deploy in Kubernetes? to review supported workloads.

• Cluster access: A Harness Delegate that can reach the target Kubernetes cluster, and an infrastructure definition that points at that cluster.

• Pipeline permissions: You need permission to create and edit pipelines. Go to the permissions reference to review required permissions.

---

Rollout deployments

The Rollout Deployment step performs a Kubernetes rolling update strategy. All nodes within a single environment are incrementally updated one-by-one with a new service or artifact version.

Harness schedules the new pods on nodes with available resources. The rolling update Deployment uses the number of pods you specified in the Service Definition Manifests (number of replicas).

Similar to application scaling, during a rolling update of a Deployment, the Kubernetes service load-balances traffic only to available pods (instances that are available to users of the application) during the update.

---

Supported workloads

Go to What can I deploy in Kubernetes? to review the workloads Harness can deploy.

---

Rolling vs Apply

The following table lists the differences between the Rolling Deployment step (default in a Rolling strategy) and the Apply step (which you can use with any strategy).

	Jobs	Rollback
Rolling Deployment step	No	Yes
Apply step	Yes	No

---

Multiple managed workloads

With the Rolling Deployment step, you can deploy multiple managed workloads.

For Canary and Blue/Green steps, only one managed object may be deployed per step by default.

You can deploy additional objects using the Apply step. The Apply step is typically used for deploying Jobs controllers.

You can specify multiple workload objects in a single manifest, in individual manifests, or in any other arrangement. The following sample shows two Deployment objects in one manifest. The deployment log shows both Deployment objects deployed.

Sample: multiple Deployment objects

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-multiple-workloads-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sample-multiple-workloads
  template:
    metadata:
      labels:
        app: sample-multiple-workloads
    spec:
      containers:
      - name: sample-multiple-workloads
        image: registry.hub.docker.com/library/nginx:stable
        envFrom:
        - configMapRef:
            name: sample-multiple-workloads
        - secretRef:
            name: sample-multiple-workloads
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-multiple-workloads-deployment-1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-multiple-workloads
  template:
    metadata:
      labels:
        app: sample-multiple-workloads
    spec:
      containers:
      - name: sample-multiple-workloads
        image: registry.hub.docker.com/library/nginx:stable
        envFrom:
        - configMapRef:
            name: sample-multiple-workloads
        - secretRef:
            name: sample-multiple-workloads

---

Step settings

Configure the following settings on the Rollout Deployment step.

Name

The name for the step.

Timeout

How long Harness should wait for this step to complete before failing it.

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 sending it. If you select Skip Dry Run, Harness does not use the --dry-run flag.

Advanced settings

Configure the following advanced options when you need them:

• Delegate Selector: Restrict which delegates can run the step.

• Conditional Execution: Skip or run the step based on conditions.

• Failure Strategy: Define what happens when the step fails.

• Looping Strategy: Run the step with matrix, repeat, or parallelism.

• Command Flags: Pass additional kubectl flags for this step.

• Policy Enforcement: Apply OPA policies to the step.

---

Troubleshooting

Rollout Deployment fails during dry run

Clear Skip Dry Run only when you intend to skip validation. If dry run fails, fix the manifest or RBAC issue reported in the step logs, then rerun. If dry run succeeds but apply fails, compare cluster permissions and API versions with the manifest.

Only one workload updates in Canary or Blue/Green

Canary and Blue/Green steps deploy one managed object per step by default. Use a Rollout Deployment step for multiple managed workloads, or add an Apply step for additional objects such as Jobs.

---

Next steps

• What can I deploy in Kubernetes?: Review supported Kubernetes workloads.

• Deployment concepts: Review rolling update behavior.

• Deploy manifests using the Apply step: Deploy Jobs and additional objects.

• Kubernetes command flags: Pass additional kubectl flags.