DEV Community: Thu Kha Kyawe

10.Troubleshoot Deployment issues in Kubernetes

Thu Kha Kyawe — Wed, 22 Apr 2026 23:30:00 +0000

Lab Information

Last week, the Nautilus DevOps team deployed a redis app on Kubernetes cluster, which was working fine so far. This morning one of the team members was making some changes in this existing setup, but he made some mistakes and the app went down. We need to fix this as soon as possible. Please take a look.

The deployment name is redis-deployment. The pods are not in running state right now, so please look into the issue and fix the same.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Check the Current State of the Deployment

First, let's see the current status of the Redis deployment and pods:

kubectl get deployments
kubectl get pods

Step 2: Examine the Pod Details

Check the detailed status of the pods to identify the issue:

kubectl describe pods

Output

thor@jumphost ~$ kubectl describe pods 
Name:             redis-deployment-54cdf4f76d-pg2f5
Namespace:        default
Priority:         0
Service Account:  default
Node:             kodekloud-control-plane/172.17.0.2
Start Time:       Tue, 28 Oct 2025 13:05:03 +0000
Labels:           app=redis
                  pod-template-hash=54cdf4f76d
Annotations:      <none>
Status:           Pending
IP:               
IPs:              <none>
Controlled By:    ReplicaSet/redis-deployment-54cdf4f76d
Containers:
  redis-container:
    Container ID:   
    Image:          redis:alpin
    Image ID:       
    Port:           6379/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       ContainerCreating
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:        300m
    Environment:  <none>
    Mounts:
      /redis-master from config (rw)
      /redis-master-data from data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-nj6db (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  data:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      redis-conig
    Optional:  false
  kube-api-access-nj6db:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason       Age                 From               Message
  ----     ------       ----                ----               -------
  Normal   Scheduled    115s                default-scheduler  Successfully assigned default/redis-deployment-54cdf4f76d-pg2f5 to kodekloud-control-plane
  Warning  FailedMount  51s (x8 over 115s)  kubelet            MountVolume.SetUp failed for volume "config" : configmap "redis-conig" not found

Step 3: Check Pod Logs

Examine the logs to see what errors are occurring:

kubectl logs $(kubectl get pods -o name | grep redis)

Step 4: Common Issues and Fixes

First, let's patch the deployment to use the correct Redis image:

kubectl patch deployment redis-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"redis-container","image":"redis:alpine"}]}}}}'

Step 5: Check if the ConfigMap is Required

Let's see if we can remove the ConfigMap volume mount since it's causing the pod to fail:

kubectl get configmaps

Step 6: Fix the ConfigMap Name in the Deployment

Let's patch the deployment to use the correct ConfigMap name:

kubectl patch deployment redis-deployment -p '{"spec":{"template":{"spec":{"volumes":[{"name":"config","configMap":{"name":"redis-config"}}]}}}}'

Step 7: Verify the Pod Status

Check if the pod is now starting properly:

kubectl get pods
kubectl get deployment redis-deployment

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

9.Deploy Node App on Kubernetes

Thu Kha Kyawe — Wed, 22 Apr 2026 15:36:42 +0000

Lab Information

The Nautilus development team has completed development of one of the node applications, which they are planning to deploy on a Kubernetes cluster. They recently had a meeting with the DevOps team to share their requirements. Based on that, the DevOps team has listed out the exact requirements to deploy the app. Find below more details:

Create a deployment using gcr.io/kodekloud/centos-ssh-enabled:node image, replica count must be 2.

Create a service to expose this app, the service type must be NodePort, targetPort must be 8080 and nodePort should be 30012.

Make sure all the pods are in Running state after the deployment.

You can check the application by clicking on NodeApp button on top bar.

You can use any labels as per your choice.

Note: The kubectl on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Create the Node.js Deployment YAML file

Create the deployment configuration file:

cat > node-deployment.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-app-deployment
  labels:
    app: node-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: node-app
  template:
    metadata:
      labels:
        app: node-app
    spec:
      containers:
      - name: node-container
        image: gcr.io/kodekloud/centos-ssh-enabled:node
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
EOF

Step 2: Create the Node.js Service YAML file

Create the service configuration file:

cat > node-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: node-app-service
  labels:
    app: node-app
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 8080
    nodePort: 30012
  selector:
    app: node-app
EOF

Step 3: Deploy the Node.js Deployment

Apply the deployment to your Kubernetes cluster:

kubectl apply -f node-deployment.yaml

Step 4: Deploy the Node.js Service

Apply the service configuration:

kubectl apply -f node-service.yaml

Step 5: Verify the Deployment

Check if the deployment was created successfully:

kubectl get deployments

Step 6: Verify the Service

Check if the service is running:

kubectl get services

Step 7: Check the Pod Status

Verify that both pods are running:

kubectl get pods -l app=node-app

Step 8: Test the Application

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

8.Deploy Tomcat App on Kubernetes

Thu Kha Kyawe — Tue, 21 Apr 2026 15:29:49 +0000

Lab Information

A new java-based application is ready to be deployed on a Kubernetes cluster. The development team had a meeting with the DevOps team to share the requirements and application scope. The team is ready to setup an application stack for it under their existing cluster. Below you can find the details for this:

Create a namespace named tomcat-namespace-xfusion.

Create a deployment for tomcat app which should be named as tomcat-deployment-xfusion under the same namespace you created. Replica count should be 1, the container should be named as tomcat-container-xfusion, its image should be gcr.io/kodekloud/centos-ssh-enabled:tomcat and its container port should be 8080.

Create a service for tomcat app which should be named as tomcat-service-xfusion under the same namespace you created. Service type should be NodePort and nodePort should be 32227.

Before clicking on Check button please make sure the application is up and running.

You can use any labels as per your choice.

Note: The kubectl on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Create the Namespace

First, create the required namespace:

kubectl create namespace tomcat-namespace-xfusion

Verify the namespace was created:

kubectl get namespaces | grep tomcat-namespace-xfusion

Step 2: Create the Tomcat Deployment YAML file

Create the deployment configuration file:

cat > tomcat-deployment.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tomcat-deployment-xfusion
  namespace: tomcat-namespace-xfusion
  labels:
    app: tomcat-app
    team: xfusion
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tomcat-app
      team: xfusion
  template:
    metadata:
      labels:
        app: tomcat-app
        team: xfusion
    spec:
      containers:
      - name: tomcat-container-xfusion
        image: gcr.io/kodekloud/centos-ssh-enabled:tomcat
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
EOF

Step 3: Create the Tomcat Service YAML file

Create the service configuration file:

cat > tomcat-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: tomcat-service-xfusion
  namespace: tomcat-namespace-xfusion
  labels:
    app: tomcat-app
    team: xfusion
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 8080
    nodePort: 32227
  selector:
    app: tomcat-app
    team: xfusion
EOF

Step 4: Deploy the Tomcat Deployment

Apply the deployment to your Kubernetes cluster:

kubectl apply -f tomcat-deployment.yaml

Step 5: Deploy the Tomcat Service

Apply the service configuration:

kubectl apply -f tomcat-service.yaml

Step 6: Verify the Deployment (Namespace-specific)

Check if the deployment was created successfully in the correct namespace:

kubectl get deployments -n tomcat-namespace-xfusion

Step 7: Verify the Service (Namespace-specific)

Check if the service is running in the correct namespace:

kubectl get services -n tomcat-namespace-xfusion

Step 8: Check the Pod Status (Namespace-specific)

Verify that the Tomcat pod is running:

kubectl get pods -n tomcat-namespace-xfusion -l app=tomcat-app

Step 9: Verify Application is Running

Check the pod logs to ensure Tomcat is running properly:

kubectl logs -n tomcat-namespace-xfusion -l app=tomcat-app --tail=10

Step 10: Test Service Accessibility

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

50% Off Official AWS Exam Vouchers (Professional & Specialty Certifications)

Thu Kha Kyawe — Tue, 21 Apr 2026 03:26:26 +0000

Noticed a strong offer from Pearson VUE, the official AWS exam provider: vouchers for AWS Professional and Specialty certifications appear to be discounted from $300 to $150.

That’s especially notable because while many candidates receive a 50% retake/next-exam benefit after passing another certification, it’s less common to see this level of discount available directly through official voucher purchase.

A few important notes:
• Applies to Professional & Specialty exams
• No discount shown for Foundational or Associate exams
• Vouchers are valid for 12 months
• Always review the full terms and conditions before purchasing

My advice: don’t buy a voucher just because it’s discounted. Only purchase if you’re genuinely committed to the study plan and ready to sit the exam.

Here is Official Link

7.Deploy Grafana on Kubernetes Cluster

Thu Kha Kyawe — Tue, 14 Apr 2026 14:03:22 +0000

Lab Information

The Nautilus DevOps teams is planning to set up a Grafana tool to collect and analyze analytics from some applications. They are planning to deploy it on Kubernetes cluster. Below you can find more details.

1.) Create a deployment named grafana-deployment-devops using any grafana image for Grafana app. Set other parameters as per your choice.

2.) Create NodePort type service with nodePort 32000 to expose the app.

You need not to make any configuration changes inside the Grafana app once deployed, just make sure you are able to access the Grafana login page.

Note: The kubectl on jump_host has been configured to work with kubernetes cluster.

Lab Solutions

Step 1: Create the Grafana Deployment YAML file

First, create a deployment configuration file:

cat > grafana-deployment.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana-deployment-devops
  labels:
    app: grafana
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:latest
        ports:
        - containerPort: 3000
        env:
        - name: GF_SECURITY_ADMIN_PASSWORD
          value: "admin123"
        resources:
          requests:
            memory: "256Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
EOF

Step 2: Create the NodePort Service YAML file

Now create the service configuration:

cat > grafana-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: grafana-service
  labels:
    app: grafana
spec:
  type: NodePort
  ports:
  - port: 3000
    targetPort: 3000
    nodePort: 32000
  selector:
    app: grafana
EOF

Step 3: Deploy the Grafana Deployment

Apply the deployment to your Kubernetes cluster:

kubectl apply -f grafana-deployment.yaml

Step 4: Deploy the NodePort Service

Apply the service configuration:

kubectl apply -f grafana-service.yaml

Step 5: Verify the Deployment

Check if the deployment was created successfully:

kubectl get deployments

Step 6: Verify the Service

Check if the service is running:

kubectl get services

Step 7: Check the Pod Status

Verify that the Grafana pod is running:

kubectl get pods -l app=grafana

Step 8: Access Grafana

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

6.Deploy Jenkins on Kubernetes

Thu Kha Kyawe — Mon, 13 Apr 2026 05:35:54 +0000

Lab Information

The Nautilus DevOps team is planning to set up a Jenkins CI server to create/manage some deployment pipelines for some of the projects. They want to set up the Jenkins server on Kubernetes cluster. Below you can find more details about the task:

1) Create a namespace jenkins

2) Create a Service for jenkins deployment. Service name should be jenkins-service under jenkins namespace, type should be NodePort, nodePort should be 30008

3) Create a Jenkins Deployment under jenkins namespace, It should be name as jenkins-deployment , labels app should be jenkins , container name should be jenkins-container , use jenkins/jenkins image , containerPort should be 8080 and replicas count should be 1.

Make sure to wait for the pods to be in running state and make sure you are able to access the Jenkins login screen in the browser before hitting the Check button.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Create the Jenkins Namespace

kubectl create namespace jenkins

Step 2: Create the Jenkins Service

Create a YAML file for the NodePort service:

cat > jenkins-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: jenkins-service
  namespace: jenkins
spec:
  type: NodePort
  selector:
    app: jenkins
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
      nodePort: 30008
EOF

Apply the service:

kubectl apply -f jenkins-service.yaml

Step 3: Create the Jenkins Deployment

Create a YAML file for the deployment:

cat > jenkins-deployment.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: jenkins-deployment
  namespace: jenkins
spec:
  replicas: 1
  selector:
    matchLabels:
      app: jenkins
  template:
    metadata:
      labels:
        app: jenkins
    spec:
      containers:
      - name: jenkins-container
        image: jenkins/jenkins
        ports:
        - containerPort: 8080
EOF

Apply the deployment:

kubectl apply -f jenkins-deployment.yaml

Step 4: Monitor the Deployment Progress

Check the status of the pod:

kubectl get pods -n jenkins

Wait until the pod status shows Running. This might take a few minutes as the Jenkins image needs to be pulled and the container needs to start up.

You can also check the deployment status:

kubectl get deployment -n jenkins

Step 5: Verify Service Configuration

Check that the service is properly configured:

kubectl get svc -n jenkins

Step 7: Access Jenkins

Once the pod is in Running state, you can access Jenkins:

Step 8: Final Verification Commands

Run these commands to verify everything is set up correctly:

Check all resources in jenkins namespace

kubectl get all -n jenkins

Verify pod details

kubectl describe pod -l app=jenkins -n jenkins

Verify service details

kubectl describe svc jenkins-service -n jenkins

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

5.Rolling Updates And Rolling Back Deployments in Kubernetes

Thu Kha Kyawe — Mon, 13 Apr 2026 05:20:58 +0000

Lab Information

There is a production deployment planned for next week. The Nautilus DevOps team wants to test the deployment update and rollback on Dev environment first so that they can identify the risks in advance. Below you can find more details about the plan they want to execute.

Create a namespace devops. Create a deployment called httpd-deploy under this new namespace, It should have one container called httpd, use httpd:2.4.25 image and 3 replicas. The deployment should use RollingUpdate strategy with maxSurge=1, and maxUnavailable=2. Also create a NodePort type service named httpd-service and expose the deployment on nodePort: 30008.

Now upgrade the deployment to version httpd:2.4.43 using a rolling update.

Finally, once all pods are updated undo the recent update and roll back to the previous/original version.

Note:

a. The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

b. Please make sure you only use the specified image(s) for this deployment and as per the sequence mentioned in the task description. If you mistakenly use a wrong image and fix it later, that will also distort the revision history which can eventually fail this task.

Lab Solutions

Step 1: Create the Namespace

First, create the devops namespace:

kubectl create namespace devops

Step 2: Create the Deployment

Create a YAML file for the deployment with the specified configuration:

cat > httpd-deploy.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-deploy
  namespace: devops
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 2
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd
        image: httpd:2.4.25
        ports:
        - containerPort: 80
EOF

Apply the deployment:

kubectl apply -f httpd-deploy.yaml

Step 3: Create the Service

Create a YAML file for the NodePort service:

cat > httpd-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: httpd-service
  namespace: devops
spec:
  type: NodePort
  selector:
    app: httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30008
EOF

Apply the service:

kubectl apply -f httpd-service.yaml

Step 4: Verify Initial Deployment

Check that everything is running correctly:

kubectl get all -n devops

Step 5: Upgrade the Deployment

Upgrade to the new image version using rolling update:

kubectl set image deployment/httpd-deploy httpd=httpd:2.4.43 -n devops

Monitor the rolling update progress:

kubectl rollout status deployment/httpd-deploy -n devops

Verify the upgrade:

kubectl get pods -n devops -o wide
kubectl describe deployment httpd-deploy -n devops

Step 6: Rollback to Previous Version

Undo the recent update and roll back to the original version:

kubectl rollout undo deployment/httpd-deploy -n devops

Monitor the rollback progress:

kubectl rollout status deployment/httpd-deploy -n devops

Step 7: Final Verification

Verify that the rollback was successful:

kubectl get pods -n devops -o wide
kubectl describe deployment httpd-deploy -n devops

Check the rollout history:

kubectl rollout history deployment/httpd-deploy -n devops

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

4.Print Environment Variables

Thu Kha Kyawe — Mon, 13 Apr 2026 05:14:55 +0000

Lab Information

The Nautilus DevOps team is working on to setup some pre-requisites for an application that will send the greetings to different users. There is a sample deployment, that needs to be tested. Below is a scenario which needs to be configured on Kubernetes cluster. Please find below more details about it.

Create a pod named print-envars-greeting.

Configure spec as, the container name should be print-env-container and use bash image.

Create three environment variables:

a. GREETING and its value should be Welcome to

b. COMPANY and its value should be DevOps

c. GROUP and its value should be Datacenter

Use command ["/bin/sh", "-c", 'echo "$(GREETING) $(COMPANY) $(GROUP)"'] (please use this exact command), also set its restartPolicy policy to Never to avoid crash loop back.

You can check the output using kubectl logs -f print-envars-greeting command.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Create the Pod YAML configuration

Create a file named print-envars-greeting.yaml:

cat > print-envars-greeting.yaml << 'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: print-envars-greeting
spec:
  containers:
  - name: print-env-container
    image: bash
    command: ["/bin/sh", "-c", 'echo "$GREETING $COMPANY $GROUP"']
    env:
    - name: GREETING
      value: "Welcome to"
    - name: COMPANY
      value: "DevOps"
    - name: GROUP
      value: "Datacenter"
  restartPolicy: Never
EOF

Step 2: Create the Pod

Apply the configuration to create the pod:

kubectl apply -f print-envars-greeting.yaml

Step 3: Check the Pod Status

Monitor the pod status to see when it completes:

kubectl get pod print-envars-greeting

You'll see the status change from Pending → Running → Completed (or Succeeded).

Step 4: View the Output

Check the logs to see the output of the command:

kubectl logs print-envars-greeting

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

3.Deploy Nginx Web Server on Kubernetes Cluster

Thu Kha Kyawe — Sun, 12 Apr 2026 15:10:17 +0000

Lab Information

Some of the Nautilus team developers are developing a static website and they want to deploy it on Kubernetes cluster. They want it to be highly available and scalable. Therefore, based on the requirements, the DevOps team has decided to create a deployment for it with multiple replicas. Below you can find more details about it:

Create a deployment using nginx image with latest tag only and remember to mention the tag i.e nginx:latest. Name it as nginx-deployment. The container should be named as nginx-container, also make sure replica counts are 3.

Create a NodePort type service named nginx-service. The nodePort should be 30011.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Create the Deployment YAML configuration

Create a file named nginx-deployment.yaml:

cat > nginx-deployment.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-container
        image: nginx:latest
        ports:
        - containerPort: 80
EOF

Step 2: Create the Deployment

Apply the deployment configuration:

kubectl apply -f nginx-deployment.yaml

Step 3: Verify the Deployment

Check if the deployment is created and all replicas are running:

kubectl get deployment nginx-deployment

Step 4: Verify the Pods

Check the pods created by the deployment:

kubectl get pods -l app=nginx

Step 5: Create the Service YAML configuration

Create a file named nginx-service.yaml:

cat > nginx-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30011
EOF

Step 6: Create the Service

Apply the service configuration:

kubectl apply -f nginx-service.yaml

Step 7: Verify the Service

Check if the service is created correctly:

kubectl get service nginx-service

Step 8: Detailed Service Verification

Get more details about the service:

kubectl describe service nginx-service

Step 9: Test the Setup

Test if the service is working by accessing it. Since this is a Kubernetes cluster, you can test using:

Using curl from inside the cluster

Get the Cluster IP of the service

CLUSTER_IP=$(kubectl get service nginx-service -o jsonpath='{.spec.clusterIP}')

Test access using Cluster IP

kubectl run test-pod --image=nginx:latest --rm -it --restart=Never -- bash -c "curl http://$CLUSTER_IP"

Step 10: Verify Endpoints

Check that the service is correctly targeting all 3 pods:

kubectl get endpoints nginx-service

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

2.Kubernetes Sidecar Containers

Thu Kha Kyawe — Sun, 12 Apr 2026 15:03:43 +0000

Task Information

We have a web server container running the nginx image. The access and error logs generated by the web server are not critical enough to be placed on a persistent volume. However, Nautilus developers need access to the last 24 hours of logs so that they can trace issues and bugs. Therefore, we need to ship the access and error logs for the web server to a log-aggregation service. Following the separation of concerns principle, we implement the Sidecar pattern by deploying a second container that ships the error and access logs from nginx. Nginx does one thing, and it does it well—serving web pages. The second container also specializes in its task—shipping logs. Since containers are running on the same Pod, we can use a shared emptyDir volume to read and write logs.

Create a pod named webserver.

Create an emptyDir volume shared-logs.

Create two containers from nginx and ubuntu images with latest tag only and remember to mention tag i.e nginx:latest, nginx container name should be nginx-container and ubuntu container name should be sidecar-container on webserver pod.

Add command on sidecar-container "sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done"

Mount the volume shared-logs on both containers at location /var/log/nginx, all containers should be up and running.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Task Solutions

Step 1: Create the Pod YAML configuration

Create a file named webserver-pod.yaml:

cat > webserver-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx

  - name: sidecar-container
    image: ubuntu:latest
    command: ["sh", "-c", "while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done"]
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx

  volumes:
  - name: shared-logs
    emptyDir: {}
EOF

Step 2: Create the pod

Apply the configuration to create the pod:

kubectl apply -f webserver-pod.yaml

Step 3: Verify the pod is running

Check if the pod is created and both containers are running:

kubectl get pod webserver

Step 4: Check the detailed status of the pod

Verify both containers are properly configured:

kubectl describe pod webserver

Step 5: Test the sidecar container logs

Check the logs of the sidecar container to see if it's reading the nginx logs:

kubectl logs webserver -c sidecar-container

Step 6: Generate some web traffic to create logs

Let's generate some access to the nginx server to create log entries:

First, find the nginx container's IP

kubectl get pod webserver -o wide

Then access the nginx server (you can use the pod IP or port-forward):

Using port-forward

In one terminal, set up port forwarding

kubectl port-forward webserver 8080:80

Step 7: Verify the sidecar is shipping logs

After generating some traffic, check the sidecar container logs again:

kubectl logs webserver -c sidecar-container

Step 8: Verify volume mounting

Check that both containers have the volume mounted correctly:

Check nginx container

kubectl exec -it webserver -c nginx-container -- ls -la /var/log/nginx/

Check sidecar container

kubectl exec -it webserver -c sidecar-container -- ls -la /var/log/nginx/

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

1.Kubernetes Shared Volumes

Thu Kha Kyawe — Mon, 06 Apr 2026 14:32:03 +0000

Lab Information

We are working on an application that will be deployed on multiple containers within a pod on Kubernetes cluster. There is a requirement to share a volume among the containers to save some temporary data. The Nautilus DevOps team is developing a similar template to replicate the scenario. Below you can find more details about it.

Create a pod named volume-share-devops.

For the first container, use image fedora with latest tag only and remember to mention the tag i.e fedora:latest, container should be named as volume-container-devops-1, and run a sleep command for it so that it remains in running state. Volume volume-share should be mounted at path /tmp/beta.

For the second container, use image fedora with the latest tag only and remember to mention the tag i.e fedora:latest, container should be named as volume-container-devops-2, and again run a sleep command for it so that it remains in running state. Volume volume-share should be mounted at path /tmp/cluster.

Volume name should be volume-share of type emptyDir.

After creating the pod, exec into the first container i.e volume-container-devops-1, and just for testing create a file beta.txt with any content under the mounted path of first container i.e /tmp/beta.

The file beta.txt should be present under the mounted path /tmp/cluster on the second container volume-container-devops-2 as well, since they are using a shared volume.

Note: The kubectl utility on jump_host has been configured to work with the kubernetes cluster.

Lab Solutions

Step 1: Create the Pod YAML configuration

Create a file named volume-share-pod.yaml:

cat > volume-share-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: volume-share-devops
spec:
  containers:
  - name: volume-container-devops-1
    image: fedora:latest
    command: ["/bin/sleep"]
    args: ["3650d"]
    volumeMounts:
    - name: volume-share
      mountPath: /tmp/beta

  - name: volume-container-devops-2
    image: fedora:latest
    command: ["/bin/sleep"]
    args: ["3650d"]
    volumeMounts:
    - name: volume-share
      mountPath: /tmp/cluster

  volumes:
  - name: volume-share
    emptyDir: {}
EOF

Step 2: Create the pod

Apply the configuration to create the pod:

kubectl apply -f volume-share-pod.yaml

Step 3: Verify the pod is running

Check if the pod is created and running:

kubectl get pods volume-share-devops

Step 4: Create test file in first container

Execute into the first container and create the test file:

kubectl exec -it volume-share-devops -c volume-container-devops-1 -- /bin/bash

Once inside the container, create the file:

echo "This is a test file for shared volume" > /tmp/beta/beta.txt

Exit the container:
exit

Step 5: Verify file exists in second container

Check if the file is accessible from the second container:

kubectl exec -it volume-share-devops -c volume-container-devops-2 -- cat /tmp/cluster/beta.txt

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

📖 More Deep Dives: Whispering Cloud Insights - Read other technical articles

💬 Join Discussion: DEV Community - Share your thoughts and questions

💼 Let's Connect: LinkedIn - I'd love to connect with you

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

A Useful Resource If You’re Preparing for AWS, CompTIA, Microsoft Certifications

Thu Kha Kyawe — Sat, 04 Apr 2026 13:28:40 +0000

Udemy is now offering AWS, CompTIA and Microsoft exam vouchers with optional retake packages:

🔗 https://www.udemy.com/all-certification-vouchers/

I checked a couple of exams, and the pricing structure is actually more interesting than it first looks.

Example 1 — AWS Certified Solutions Architect (Associate)

Exam Voucher → $148.99
Exam Voucher + Retake → $181.99

👉 That’s roughly $33 more for a second attempt

Example 2 — AWS Certified DevOps Engineer (Professional)

Exam Voucher → $296.99
Exam Voucher + Retake → $329.99

👉 Again, about $33 more for a retake

My takeaway

This is where it gets interesting.

At first glance, Udemy shows a very large discount on the “voucher + retake” option (because it compares against a much higher original price).

But in reality, the decision is much simpler:

👉 You’re paying about $30–$35 extra for a second attempt

That’s actually not a bad deal if:

you’re not 100% confident yet
you want to reduce the risk of paying full price again
or you just want less pressure on exam day

Important details

From the voucher page:

Exam Voucher (one attempt)
→ valid for at least 9 months after purchase
Voucher + Retake (two attempts)
→ first attempt must be completed by Dec 31, 2026
→ retake must be completed by Jan 31, 2027
Works for:
- Associate exams
- Professional & Specialty exams
- Online or in-person testing

What to watch out for

This does not combine with other AWS benefits (e.g. 50% off vouchers)
It’s not the same as “free retake” promotions
Pricing may vary depending on your region / tax / currency

Final thought

This is one of those cases where the real value is hidden behind the marketing.

Ignore the big discount labels and just ask:

👉 “Is a second attempt worth ~$30 for me?”

If yes, the retake option actually makes a lot of sense.

AWS #AWSCertification #CloudComputing #DevOps #SolutionsArchitect #Certification #CareerGrowth #Upskilling #TechCareers