Recreate is the simplest deployment strategy. A recreate deployment would go something like this. Version 1 of the app is deployed. Deployment starts, all pods running version 1 of the app are deleted. Immediately followed by version 2 of the application being deployed. The biggest draw back with recreate deployments is the small window of downtime.
Manual Recreate Deployment
The self healing nature of Kubernetes makes a manual recreate deployment very easy. Because the ReplicationController or ReplicaSet managing the pods of your application will replace terminated pods you can simply modify the template of them prior to deleting the pods and it will deploy newer pods for you using the updated image specified in the template.
- Edit ReplicationController or ReplicaSet.
kubectl edit replicaset archetype
- Update Pod template to use a newer image.
#within the config modify the template image #confirm settings with kubectl get replicaset archetype -o yaml
- Delete all running pods.
kubectl delete pods -l app=archetype
- ReplicationController or ReplicaSet creates new pods with update image.
kubectl get pods --show-labels
Recreate Deploys with Kubernetes Deployment Resource
The Kubernetes Deployment resource provides declarative updates to your applications. In the previous example you had to think through the update process. You had to figure out what commands to run and in which order to run them. With the Deployment resource you define the strategy you want to use and set the behaviors you want to see and Kubernetes figures out the rest. Converting our update to use the Deployment resource vs. using kubectl looks like this.
apiVersion: apps/v1 | |
kind: Deployment | |
metadata: | |
name: archetype-deployment | |
labels: | |
app: archetype | |
spec: | |
replicas: 3 | |
selector: | |
matchLabels: | |
app: archetype | |
strategy: | |
type: Recreate | |
template: | |
metadata: | |
labels: | |
app: archetype | |
spec: | |
containers: | |
- name: archetype | |
image: duffney/archetype:v1 | |
ports: | |
- containerPort: 80 |
The Deployment resource can be thought of as a wrapper around your replication controller or replicaset. By default the Deployment resources strategy is to perform a rolling update. You can change that by defining .spec.strategy.type
as Recreate. Reference line 13 in the above manifest.
- Deploy v1 of the app
kubectl apply -f archetype-deployment-and-service-recreate.yaml
- Change the .spec.template.spec.containers.image to v2
kubectl set image deployment archetype-deployment archetype=duffney/archetype:v2
- Check pods & replicaset
kubectl get pods --show-labels kubectl get replicasets #Check image version on new replicaset (replicaset name will be different) kubectl describe replicaset archetype-deployment-6d47fc67d4
What Happened?
When using a Recreate deployment strategy in Kubernetes, the following actions occur.
- The Deployment resource created a ReplicaSet that was using v1 of the container image.
- The ReplicaSet created 3 pods using v1 image.
- The image in the deployment was changed to v2.
- The Kubernetes noticed this change and created a new ReplicaSet that uses v2 of the image.
- Kubernetes set the ReplicaSet using v1 replica count to 0.
- The v1 ReplicaSet deleted all of its pods.
- Kubernetes changed the replica count on the v2 ReplicaSet to 3.
- The v2 ReplicaSet created 3 new pods all using v2 of the image.
- Update complete!
When to Use
- Your application can withstand a short amount downtime.
- When your application does not support having new and old versions of your application code running at the same time.
Labs & Code Samples
All the manifests and cost samples can be found in this repo or in the gits linked in the post.
Top comments (0)