> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/kubernetes-rollout-step.md).

# Kubernetes Rollout Deploy step

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**.

### Rollout Deployments <a href="#rollout-deployments" id="rollout-deployments"></a>

The Rollout Deployment step performs a Kubernetes [rolling update strategy](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-concepts.md#rolling-deployment). All nodes within a single environment are incrementally added one-by-one with a new service/artifact version.

The new pods are scheduled 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 will load-balance the traffic only to available pods (an instance that is available to the users of the application) during the update.

### What Workloads Can I Deploy? <a href="#what-workloads-can-i-deploy" id="what-workloads-can-i-deploy"></a>

See [What Can I Deploy in Kubernetes?](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/what-can-i-deploy-in-kubernetes.md).

### Rolling vs Apply <a href="#rolling-vs-apply" id="rolling-vs-apply"></a>

The following table lists the differences between the Rolling Deployment step (default in a Rolling strategy) and the Apply step (which may be used with any strategy).

|                             | **Jobs** | **Rollback** |
| --------------------------- | -------- | ------------ |
| **Rolling Deployment step** | No       | Yes          |
| **Apply step**              | Yes      | No           |

### Multiple Managed Workloads <a href="#multiple-managed-workloads" id="multiple-managed-workloads"></a>

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](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/deploy-manifests-using-apply-step.md), but it is typically used for deploying Jobs controllers.

You can specify the multiple workload objects in a single manifest or in individual manifests, or any other arrangement.Here is the log from a deployment where you can see both Deployment objects deployed:

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

### Name <a href="#name" id="name"></a>

The name for the step.

### Timeout <a href="#timeout" id="timeout"></a>

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

### Skip Dry Run <a href="#skip-dry-run" id="skip-dry-run"></a>

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.

### Advanced Settings <a href="#advanced-settings" id="advanced-settings"></a>

See the following:

* [Delegate Selector](/harness-ai/use-harness-platform/delegates/delegate/manage-delegates/select-delegates-with-selectors.md)
* [Conditional Execution](/harness-ai/use-harness-platform/pipelines/step-skip-condition-settings.md)
* [Failure Strategy](/harness-ai/use-harness-platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps.md)
* [Looping Strategy](/harness-ai/use-harness-platform/pipelines/looping-strategies/looping-strategies-matrix-repeat-and-parallelism.md)
* [Command Flags](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/k8s-command-flags.md)
* [Policy Enforcement](/harness-ai/use-harness-platform/governance/policy-as-code/harness-governance-overview.md)