- Recreate: terminate the old version and release the new one
- Pro: application state entirely renewed
- Cons: downtime that depends on both shutdown and boot duration of the application
- Rolling update: New pods are added gradually, and old pods are terminated gradually.
- Pro:
- version is slowly released across instances
- convenient for stateful applications that can handle rebalancing of the data
- Cons:
- rollout/rollback can take time
- supporting multiple APIs is hard
- no control over traffic
- Pro:
Recreate
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
strategy:
type: Recreate
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80kubectl apply -f recreate-deployment.yaml
kubectl rollout status deployment/nginx-deployment
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --recordRolling Update
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 4
maxUnavailable: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80kubectl apply -f recreate-deployment.yaml
kubectl rollout status deployment/nginx-deployment
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record-. maxSurge: The number of pods that can be created above the desired amount of pods during an update
-. maxUnavailable: The number of pods that can be unavailable during the update process
- blue/green: release a new version alongside the old version then switch traffic
- canary: release a new version to a subset of users, then proceed to a full rollout