Deployment
A K8s Deployment is a declarative configuration in a .yaml or .json file to define the desired state of an containerized piece of code.
Create a basic deployment.yaml
kubectl create deploy your-deployment --image=your-image -oyaml --dry-run=client > deploy.yaml
- Modify as needed, for example you can add livenessProbes
- run
kubectl apply -f=deploy.yaml
- check run
kubectl describe deploy
Deployment Configuration Status
kubectl get deployments
kubectl describe deployment yourdeploymentname
availableReplicas
- indicates how many were configured by the ReplicaSet. This would be compared to the later value of #### readyReplicas
- which would be used to determine if all replicas have been fully generated and without error. #### observedGeneration
- shows how often the deployment has been updated. This information can be used to understand the rollout and rollback situation of the deployment.
Scaling and Rolling Updates
kubectl scale deploy/dev-web --replicas=4
Rolling Update
If you want to modify non-immutable values, you can change them in an editor.
This triggers a rolling update of the deployment. While the deployment would show an older age, a review of the Pods would show a recent update and older version of the web server application deployed.
kubectl edit deployment yourdeployment
containers:
- image: geile-app:1.8 #<<---Change version number
imagePullPolicy: IfNotPresent
name: dev-geile-app
This will update gradually replacing old pods with new ones to ensure continuous availability of the service.
It is the default update method
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
Canary Rollout
A new version of the application is deployed to a small percentage of the pods or replicas in the Kubernetes cluster. This can be achieved using a Deployment resource with specific strategies and configurations.
apiVersion: apps/v1
kind: Deployment
metadata:
name: your-app
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25% <--- incremental increase in the number of pods running the canary version.
maxUnavailable: 0
template:
metadata:
labels:
app: your-app
spec:
containers:
- name: your-app
image: your-registry/your-app:canary
Blue- Green Deployment
In a Blue-Green Deployment, two identical environments, typically referred to as "Blue" and "Green," are maintained: - one for the current production version (Blue) and
- one for the new version being deployed (Green).
The deployment process involves switching the traffic from the Blue environment to the Green environment once the new version is considered ready for production.
# blue-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: blue-deployment
spec:
replicas: 3
selector:
matchLabels:
app: your-app
color: blue
template:
metadata:
labels:
app: your-app
color: blue
spec:
containers:
- name: your-app
image: registry/your-app:blue
ports:
- containerPort: 80
# green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: green-deployment
spec:
replicas: 0 # Keeping replicas at 0 initially
selector:
matchLabels:
app: your-app
color: green
template:
metadata:
labels:
app: your-app
color: green
spec:
containers:
- name: your-app
image: registry/your-app:green
ports:
- containerPort: 80
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: your-app-service
spec:
selector:
app: your-app
ports:
- protocol: TCP
port: 80
targetPort: 80
and then deploy the first
kubectl apply -f blue-deployment.yaml
once validated and deploy the other version
kubectl apply -f green-deployment.yaml
Deployment Rollbacks
- Look what happened
kubectl rollout history deployment/mydeploy
- Check the status of the deployment
kubectl get pods
- If you need to do a rollback
kubectl rollout undo deployment/mydeploy
Further reading:
https://trainingportal.linuxfoundation.org/learn/course/kubernetes-for-developers-lfd259/
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
Top comments (0)