Defining a Zero-Downtime Deployment
Learn the definition of a zero-downtime Deployment.
We'll cover the following...
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
.
apiVersion: apps/v1kind: Deploymentmetadata:name: go-demo-2-apispec:replicas: 3selector:matchLabels:type: apiservice: go-demo-2minReadySeconds: 1progressDeadlineSeconds: 60revisionHistoryLimit: 5strategy:type: RollingUpdaterollingUpdate:maxSurge: 1maxUnavailable: 1template:metadata:labels:type: apiservice: go-demo-2language: gospec:containers:- name: apiimage: vfarcic/go-demo-2env:- name: DBvalue: go-demo-2-dbreadinessProbe:httpGet:path: /demo/helloport: 8080periodSeconds: 1livenessProbe:httpGet:path: /demo/helloport: 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. Thereplicas
and theselector
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 to1
second. The default value is0
, meaning ...