A zero-downtime update changes an application without interrupting service. Kubernetes keeps routing requests to ready Pods while new Pods start and old Pods are replaced. section 4.1.2 section 4.2.1
A reliable zero-downtime rollout combines:
- Readiness checks that remove unready or booting Pods from the Service. section 4.1.2
- A RollingUpdate strategy that creates new Pods, waits for availability, and then terminates old Pods. section 4.2.1
- Compatibility between old and new application versions while both serve traffic. section 4.2.1
Updating a three-replica Deployment
During a rollout, one timeserver Pod can fail its HTTP readiness check and leave the Service temporarily. Traffic continues through the other two healthy Pods; after the check returns HTTP 200, the Pod rejoins. Without the readiness check, repeated curl requests can show connection problems. section 4.1.2
Listing 4.1 Chapter04/4.1.2_Readiness/deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: timeserver
spec:
replicas: 3
selector:
matchLabels:
pod: timeserver-pod
template:
metadata:
labels:
pod: timeserver-pod
spec:
containers:
- name: timeserver-container
image: docker.io/wdenniss/timeserver:1
readinessProbe:
initialDelaySeconds: 15 #1
periodSeconds: 30 #2
httpGet: #3
path: / #3
port: 80 #3
scheme: HTTP #3
timeoutSeconds: 2 #4
failureThreshold: 1 #5
successThreshold: 1 #6
#1 After an initial delay
#2 Every 30 seconds
#3 Perform this HTTP request.
#4 Time out after 2 seconds.
#5 Consider one error response to indicate the container is not ready.
#6 Consider one successful response to indicate the container is ready after being considered unready.
A Deployment manifest demonstrates an HTTP readiness probe with startup delay, polling interval, timeout, and success or failure thresholds. section 4.1.2
