Create a Kubernetes Rolling Deployment

Updated 1 month ago by Michael Cretzman

A rolling update strategy updates Kubernetes deployments with zero downtime by incrementally updating pod instances with new ones. 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. See Create a Kubernetes Canary Deployment for more information.

For a detailed explanation of Kubernetes rolling updates, see  Performing a Rolling Update from Kubernetes.

In this topic:

Before You Begin

Review: What Workloads Can I Deploy?

Stages using Harness Canary and Blue/Green steps only support Kubernetes Deployment workloads.

The Rolling Deployment step supports all workloads except Jobs.

The Apply Step can deploy any workloads or objects in any strategy including Rolling Deployment.

In Harness, a workload is a Deployment, StatefulSet, or DaemonSet object deployed and managed to steady state.

Rolling vs Apply

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, 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:

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

Step 1: 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:

strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1

For details on the settings, see RollingUpdateDeployment in the Kubernetes API.

Step 2: Define the Service and Infrastructure

Create your CD Pipeline stage.

To set up your Service and Infrastructure in the stage, follow the steps in these topics:

Step 3: Add the Rollout Step

In the stage's Execution, click Add Step, and select Rolling Deployment.

That's it. Harness will perform the Kubernetes rollout using your manifests and artifacts.

To change the default settings, click the Rolling Deployment step.

See Kubernetes Rollout Step for settings.

Step 4: Deploy

Let's look at what the Rollout Deployment step does in the deployment logs.

Apply

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

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

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: <none>
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.

Example: Rolling Update Deployment

Now that the setup is complete, you can click Run Pipeline.

The Pipeline is deployed.

To see the completed deployment, log into 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 <none> 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

Notes

  • Rolling Rollback step: you can add a Rolling Rollback step to your stage to roll back the workloads deployed by the Rollout Deployment step.
    Simply add this step where you want to initiate a rollback. Note that this command applies to the deployments of the Rollout Deployment command, and not the Apply Step command.

Next Steps


Please Provide Feedback