> 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/kubernetes-executions/create-a-kubernetes-rolling-deployment.md). # Create a Kubernetes Rolling deployment Create a Kubernetes rolling update deployment in Harness, configure the Rollout Deployment step, and review the deployment logs. This topic describes how to perform a Kubernetes rolling update deployment in Harness. A [rolling update strategy](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-concepts.md) updates Kubernetes deployments with zero downtime by incrementally updating pod instances with your new app version. New pods are scheduled on nodes using the available resources. This method is similar to a standard Canary strategy, but different from the Harness Kubernetes Canary strategy. The Harness Kubernetes Canary strategy uses a canary phase followed by a rolling update as its final phase. Go to [Create a Kubernetes Canary deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-canary-deployment.md) to compare this rolling strategy with the Harness Canary strategy. Go to [Performing a rolling update](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/) in the Kubernetes documentation to learn more about Kubernetes rolling updates. ## What you will learn from this topic * Understand the [workloads a Rolling deployment supports](#what-workloads-can-i-deploy). * How to [define the rollout strategy](#define-rollout-strategy) for a Rolling deployment. * How to [configure the service and infrastructure](#define-the-service-and-infrastructure) for the stage. * How to [add the Rollout step](#add-the-rollout-step) to your pipeline stage. * Understand the [deployment logs](#deploy) produced by the Rolling Deployment step. * How to run the pipeline and verify a [completed Rolling deployment](#rolling-update-deployment-example). ## Before you begin Review the following topics before you configure a Kubernetes Rolling deployment: * [Kubernetes CD Quickstart](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-cd-quickstart.md) * [Add Kubernetes Manifests](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/define-kubernetes-manifests.md) * [Define Your Kubernetes Target Infrastructure](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/define-your-kubernetes-target-infrastructure.md) ## Supported workloads Stages that use Harness Canary and Blue/Green steps only support [Kubernetes Deployment workloads](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/). The Rolling Deployment step supports all workloads. In Harness, a workload is a Deployment, or DaemonSet object deployed and managed to steady state. If you deploy Kubernetes Jobs using the Rolling Deployment step, it does not manage the Job to steady state. Typically, Jobs are deployed with the Apply step. The [Apply step](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/deploy-manifests-using-apply-step.md) can deploy any workloads or objects in any strategy, including Rolling Deployment. ### Rolling Deployment step compared with Apply step 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 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. The following manifest deploys both Deployment objects: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: multiple-workloads-deployment spec: replicas: 1 selector: matchLabels: app: multiple-workloads template: metadata: labels: app: multiple-workloads spec: containers: - name: multiple-workloads image: registry.hub.docker.com/library/nginx:stable envFrom: - configMapRef: name: multiple-workloads - secretRef: name: multiple-workloads --- apiVersion: apps/v1 kind: Deployment metadata: name: multiple-workloads-deployment-1 spec: replicas: 3 selector: matchLabels: app: multiple-workloads template: metadata: labels: app: multiple-workloads spec: containers: - name: multiple-workloads image: registry.hub.docker.com/library/nginx:stable envFrom: - configMapRef: name: multiple-workloads - secretRef: name: multiple-workloads ``` ## Define rollout strategy There are no mandatory Rolling Update-specific settings for manifests in the Harness Service. You can use any Kubernetes configuration. The default Rolling Update strategy used by Harness is: ``` RollingUpdateStrategy: 25% max unavailable, 25% max surge ``` If you want to set a Rolling Update strategy that is different from the default, you can include the strategy settings in your Deployment manifest: ```yaml strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1 ``` Go to [RollingUpdateDeployment](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#deploymentstrategy-v1-apps/#rollingupdatedeployment-v1-apps) in the Kubernetes API documentation to learn more about the settings. ## Define the service and infrastructure Perform the following steps to configure the service and infrastructure for your stage: 1. Create your CD Pipeline stage. 2. Configure the Service and Infrastructure in the stage using these topics: * [Add Kubernetes Manifests](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/define-kubernetes-manifests.md) * [Define Your Kubernetes Target Infrastructure](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/define-your-kubernetes-target-infrastructure.md) ## Add the Rollout step Perform the following steps to add the Rollout Deployment step to your stage: 1. In the stage's **Execution**, click **Add Step**, and select **Rolling Deployment**. 2. To change the default settings, select the **Rolling Deployment** step. Harness performs the Kubernetes rollout using your manifests and artifacts automatically. Go to [Kubernetes Rollout step](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/kubernetes-rollout-step.md) for more information. ## Deployment logs The following deployment logs show what the **Rollout Deployment** step does. ### Apply log The Apply section deploys the manifests from the Service **Manifests** section as one file. ``` kubectl --kubeconfig=config apply --filename=manifests.yaml --record configmap/harness-example-config-3 configured deployment.apps/harness-example-deployment created Done. ``` ### Wait for steady state log The Wait for Steady State section shows the containers and pods rolled out. ``` kubectl --kubeconfig=config get events --output=custom-columns=KIND:involvedObject.kind,NAME:.involvedObject.name,MESSAGE:.message,REASON:.reason --watch-only kubectl --kubeconfig=config rollout status Deployment/harness-example-deployment --watch=true Status : Waiting for deployment "harness-example-deployment" rollout to finish: 0 of 2 updated replicas are available... Event : Pod harness-example-deployment-5674658766-6b2fw Successfully pulled image "registry.hub.docker.com/library/nginx:stable-perl" Pulled Event : Pod harness-example-deployment-5674658766-p9lpz Successfully pulled image "registry.hub.docker.com/library/nginx:stable-perl" Pulled Event : Pod harness-example-deployment-5674658766-6b2fw Created container Created Event : Pod harness-example-deployment-5674658766-p9lpz Created container Created Event : Pod harness-example-deployment-5674658766-6b2fw Started container Started Event : Pod harness-example-deployment-5674658766-p9lpz Started container Started Status : Waiting for deployment "harness-example-deployment" rollout to finish: 1 of 2 updated replicas are available... Status : deployment "harness-example-deployment" successfully rolled out Done. ``` ### Wrap Up log The Wrap Up section shows the Rolling Update strategy used. ``` ... Name: harness-example-deployment Namespace: default CreationTimestamp: Sun, 17 Feb 2019 22:03:53 +0000 Labels: Annotations: deployment.kubernetes.io/revision: 1 kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --kubeconfig=config --f... kubernetes.io/change-cause: kubectl apply --kubeconfig=config --filename=manifests.yaml --record=true Selector: app=harness-example Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge ... NewReplicaSet: harness-example-deployment-5674658766 (2/2 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 8s deployment-controller Scaled up replica set harness-example-deployment-5674658766 to 2 Done. ``` ## Rolling update deployment example After setup is complete, click **Run Pipeline**. The Pipeline is deployed. To view the completed deployment, log in to your cluster and run `kubectl get all`. The output lists the new Deployment: ``` NAME READY STATUS RESTARTS AGE pod/harness-example-deployment-5674658766-6b2fw 1/1 Running 0 34m pod/harness-example-deployment-5674658766-p9lpz 1/1 Running 0 34m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.83.240.1 443/TCP 34m NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deployment.apps/harness-example-deployment 2 2 2 2 34m NAME DESIRED CURRENT READY AGE replicaset.apps/harness-example-deployment-5674658766 2 2 2 34m ``` ## Rolling deployment considerations ### Enable Kubernetes pruning option Go to [Prune Kubernetes resources](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/prune-kubernetes-resources.md) for more information. ### Rolling Rollback step You can add a **Rolling Rollback** step to your stage to roll back the workloads deployed by the **Rollout Deployment** step. Add this step where you want to initiate a rollback. This command applies to the deployments of the Rollout Deployment command, and not the [Apply step](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/deploy-manifests-using-apply-step.md) command. ### Value of the image field in the output of the Rollout Deployment step The `image` field on the **Output** tab of the Rollout Deployment step shows the SHA256 digest of the image instead of the image tag. Kubernetes returns the SHA256 digest of the image because the digest is unique and can be used to verify the deployment. If you want to verify the deployment by using the tag, look for the tag in the deployment logs. ## Next steps * [Kubernetes CD Reference](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes.md) * [View pod status and logs](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/view-pod-status-and-logs.md): Inspect pod-level status, events, and logs for this deployment directly in the pipeline execution. {% @harness-feedback/feedback %}