The default deployment strategy is RollingUpdate<\/div>\n<\/div>\n
RollingUpdate<\/h4>\n
When using this strategy, the new pods will be created one after another by deleting the old pods one by one.<\/p>\n
For example, if the deployment has 3 pods when a change is made, it terminates one old pod and creates a new pod.<\/p>\n
When the new pod starts running, it then again deletes another old pod and creates a new one. This process is repeated until all pods are rolled out.<\/p>\n
We can control the maximum number of pods that can be unavailable using maxUnavailable<\/code> and the maximum pods that can be created above the desired replica using maxSurge<\/code>.<\/p>\nspec:\n strategy:\n type: RollingUpdate\n rollingUpdate:\n maxSurge: 1\n maxUnavailable: 1<\/code><\/pre>\nRecreate<\/h4>\n
If you are using this strategy, when a new change is made, it deletes all pods at once and creates new pods.<\/p>\n
strategy:\n type: Recreate<\/code><\/pre>\nUsing ConfigMap and Secret in Deployments<\/h3>\n
It’s very important not to hardcode sensitive data and configuration values in application code.<\/p>\n
That’s where ConfigMap and Secret help you, use secrets to store sensitive data and configmaps to store non-sensitive configuration values.<\/p>\n
When creating a deployment, you can either use the data in a secret, a configmap, and an environment variable or mount them as a volume.<\/p>\n
An example of using data in a secret and a configmap as an environment variable is shown below.<\/p>\n
spec:\n containers:\n envFrom:\n - configMapRef:\n name: app-config\n - secretRef:\n name: app-secrets\n<\/code><\/pre>\nSetting Resource Requests and Limits<\/h3>\n
Setting up resource requests and limits in deployment is important, it tells the cluster how much CPU and memory each deployment’s pods are going to use.<\/p>\n
\n- Resource request<\/strong> – minimum resources the pods are going to use.<\/li>\n
- Resource limit<\/strong> – maximum resource it can use.<\/li>\n<\/ul>\n
An example of a resource request and limit block is given below.<\/p>\n
spec:\n containers:\n resources:\n requests:\n memory: \"64Mi\"\n cpu: \"250m\"\n limits:\n memory: \"128Mi\"\n cpu: \"500m\"<\/code><\/pre>\nAdding Health Check Probes<\/h3>\n
There are three health check probes, they are:<\/p>\n
startupProbe<\/h4>\n
We use a startup probe for an application that takes more time to start, and other health check probes won’t start until the startup probe check is successful.<\/p>\n
If this probe fails, the pod gets terminated, and a new pod will be created.<\/p>\n
livenessProbe<\/h4>\n
This probe is used to check if the application is running without any issues.<\/p>\n
If the application is not running or crashed, the pod gets restarted.<\/p>\n
readinessProbe<\/h4>\n
This probe checks if the application is receiving traffic.<\/p>\n
If the application fails to receive traffic, the pod will be removed from the service endpoint.<\/p>\n
Given below is an example of how the health check probes are used in a deployment.<\/p>\n
spec:\n containers:\n \n startupProbe:\n httpGet:\n path: \/startup\n port: 8080\n failureThreshold: 30\n periodSeconds: 10\n \n livenessProbe:\n httpGet:\n path: \/health\n port: 8080\n initialDelaySeconds: 5\n periodSeconds: 10\n readinessProbe:\n httpGet:\n path: \/ready\n port: 8080\n initialDelaySeconds: 5\n periodSeconds: 10\n<\/code><\/pre>\nMounting Persistent Volume<\/h3>\n
Applications need storage to store their data so the data is persistent even if the pods get restarted.<\/p>\n
You can create PV and PVC and mount the volume in the directory where your application writes its data.<\/p>\n
Below is an example of mounting PV in your application.<\/p>\n
spec:\n template:\n spec:\n containers:\n volumeMounts:\n - name: test-storage\n mountPath: \/data\n volumes:\n - name: test-storage\n persistentVolumeClaim:\n claimName: test-pvc\n<\/code><\/pre>\nNot just PV, you can also mount secrets and configmaps as volumes.<\/p>\n
Kubernetes Example Deployment<\/h2>\n
Since we have looked at the basics let start with an example deployment. We will do the following in this section.<\/p>\n
\n- Create a namespace<\/li>\n
- Create a Nginx Deployment<\/li>\n
- Create a Nginx Service<\/li>\n
- Expose and access the Nginx Service<\/li>\n<\/ol>\n
Note:<\/strong> Few of the operations we perform in this example can be performed with just kubectl and without a YAML Declaration. However, we are using the YAML specifications for all operations to understand it better.<\/em><\/p>\nExercise Folder<\/h4>\n
To begin the exercise, create a folder names deployment-demo and cd into that folder. Create all the exercise files in this folder.<\/p>\n
mkdir deployment-demo && cd deployment-demo<\/code><\/pre>\nCreate a Namespace<\/h4>\n
Let’s create a YAML named namespace.yaml<\/strong> file for creating the namespace.<\/p>\napiVersion: v1\nkind: Namespace\nmetadata:\n name: deployment-demo\n labels:\n apps: web-based\n annotations:\n type: demo<\/code><\/pre>\nUse kubectl command to create the namespace.<\/p>\n
kubectl create -f namespace.yaml<\/code><\/pre>\nEquivalent kubectl command<\/p>\n
kubectl create namespace deployment-demo<\/code><\/pre>\nAssign Resource Quota To Namespace<\/h4>\n
Now let’s assign some resource quota limits to our newly created namespace. This will make sure the pods deployed in this namespace will not consume more system resources than mentioned in the resource quota.<\/p>\n
Create a file named resourceQuota.yaml<\/strong>. Here is the resource quota YAML contents.<\/p>\napiVersion: v1\nkind: ResourceQuota\nmetadata:\n name: mem-cpu-quota\n namespace: deployment-demo\nspec:\n hard:\n requests.cpu: \"4\"\n requests.memory: 8Gi\n limits.cpu: \"8\"\n limits.memory: 16Gi<\/code><\/pre>\nCreate the resource quota using the YAML.<\/p>\n
kubectl create -f resourceQuota.yaml<\/code><\/pre>\nNow, let’s describe the namespace to check if the resource quota has been applied to the deployment-demo namespace.<\/p>\n
kubectl describe ns deployment-demo<\/code><\/pre>\nThe output should look like the following.<\/p>\n
Name: deployment-demo\nLabels: apps=web-based\nAnnotations: type=demo\nStatus: Active\n\nResource Quotas\n Name: mem-cpu-quota\n Resource Used Hard\n -------- --- ---\n limits.cpu 0 2\n limits.memory 0 2Gi\n requests.cpu 0 1\n requests.memory 0 1Gi<\/code><\/pre>\nCreate a Deployment<\/h3>\n
We will use the public Nginx image for this deployment.<\/p>\n
Create a file named deployment.yaml<\/strong> and copy the following YAML to the file.<\/p>\nNote<\/strong>: This deployment YAML has minimal required information we discussed above. You can have more specification in the deployment YAML based on the requirement.<\/em><\/p>\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: nginx\n labels:\n app: nginx\n namespace: deployment-demo\n annotations:\n monitoring: \"true\"\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: nginx\n template:\n metadata:\n labels:\n app: nginx\n spec:\n containers:\n - image: nginx\n name: nginx\n ports:\n - containerPort: 80\n resources:\n limits:\n memory: \"2Gi\"\n cpu: \"1000m\"\n requests: \n memory: \"1Gi\"\n cpu: \"500m\"<\/code><\/pre>\nUnder containers, we have defined its resource limits, requests and container port (one exposed in Dockerfile).<\/p>\n
Create the deployment using kubectl<\/p>\n
kubectl create -f deployment.yaml<\/code><\/pre>\nCheck the deployment<\/p>\n
kubectl get deployments -n deployment-demo<\/code><\/pre>\nEven though we have added minimal information, after deployment, Kubernetes will add more information to the deployment such as resourceVersion, uid, status etc.<\/p>\n
You can check it by describing the deployment in YAML format using the kubectl command.<\/p>\n
kubectl get deployment nginx -n deployment-demo --output yaml<\/code><\/pre>\nCreate a Service and Expose The Deployment<\/h3>\n
Now that we have a running deployment, we will create a Kubernetes service of type NodePort ( 30500) pointing to the nginx deployment. Using NodePort you will be able to access the Nginx service on all the kubernetes node on port 30500.<\/p>\n
Create a file named service.yaml<\/strong> and copy the following contents.<\/p>\napiVersion: v1\nkind: Service\nmetadata:\n labels:\n app: nginx\n name: nginx\n namespace: deployment-demo\nspec:\n ports:\n - nodePort: 30500\n port: 80\n protocol: TCP\n targetPort: 80\n selector:\n app: nginx\n type: NodePort<\/code><\/pre>\nService is the best example for explaining labels and selectors<\/strong>. In this service, we have a selector with “app” = “nginx” label. Using this, the service will be able to match the pods in our nginx deployment as the deployment and the pods have the same label. So automatically all the requests coming to the nginx service will be sent to the nginx deployment.<\/p>\nLet’s create the service using kubectl command.<\/p>\n
kubectl create -f service.yaml<\/code><\/pre>\nYou can view the service created using kubectl command.<\/p>\n
kubectl get services -n deployment-demo<\/code><\/pre>\nNow, you will be able to access the nginx service on any one of the kubernetes node IP on port 30500<\/p>\n
For example,<\/p>\n
http:\/\/35.134.110.153:30500\/<\/code><\/pre>\n
\nNgu\u1ed3n:<\/strong> Kubernetes Deployment Tutorial For Beginners – Understanding YAML \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Source: https:\/\/devopscube.com\/kubernetes-deployment-tutorial\/<\/p>\n","protected":false},"author":1,"featured_media":517,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-516","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/516","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=516"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/516\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/517"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=516"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=516"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=516"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Kubernetes](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/08\/deployment.png\")
<\/figure>\n