...

/

Defining a Zero-Downtime Deployment

Defining a Zero-Downtime Deployment

Learn the definition of a zero-downtime Deployment.

Updating a single-replica MongoDB cannot demonstrate true power behind Deployments. We need a scalable Service. It’s not that MongoDB cannot be scaled (it can), but it’s not as straightforward as an application that was designed to be scalable. We’ll jump to the second application in the stack and create a Deployment of the ReplicaSet that will create Pods based on the go-demo-2 image.

Note: Zero-downtime Deployment is a prerequisite for higher frequency releases.

Looking into the definition

Let’s take a look at the Deployment definition of the API go-demo-api.

Press + to interact
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-2-api
spec:
replicas: 3
selector:
matchLabels:
type: api
service: go-demo-2
minReadySeconds: 1
progressDeadlineSeconds: 60
revisionHistoryLimit: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
type: api
service: go-demo-2
language: go
spec:
containers:
- name: api
image: vfarcic/go-demo-2
env:
- name: DB
value: go-demo-2-db
readinessProbe:
httpGet:
path: /demo/hello
port: 8080
periodSeconds: 1
livenessProbe:
httpGet:
path: /demo/hello
port: 8080

We’ll skip explaining apiVersion, kind, and metadata, since they always follow the same pattern.

  • Lines 5–7: The spec section has a few fields we haven’t seen before and some we are familiar with. The replicas and the selector are the same as the ones we used in the ReplicaSet from the previous chapter.

  • Line 11: The minReadySeconds defines the minimum number of seconds before Kubernetes starts considering the Pods healthy. We set the value of this field to 1 second. The default value is 0, meaning ...