DEV Community: Thu Kha Kyawe

10.Fix Python App Deployed on Kubernetes Cluster

Thu Kha Kyawe — Thu, 20 Aug 2026 16:10:22 +0000

Step 1: Check Current Deployment Status

First, let's see what's currently deployed:

# Check all deployments
kubectl get deployments

# Check the specific deployment
kubectl get deployment python-deployment-datacenter

# Check pods status
kubectl get pods

# Check services
kubectl get services

Step 2: Examine Detailed Information

Let's look at the deployment and service configuration:

# Get detailed deployment information
kubectl describe deployment python-deployment-datacenter

# Get pod details (look for any error messages)
kubectl describe pods python-deployment-datacenter-6fdb496d59-df826 

# Get service details
kubectl describe service python-service-datacenter

Output

thor@jumphost ~$ kubectl describe deployment python-deployment-datacenter
Name:                   python-deployment-datacenter
Namespace:              default
CreationTimestamp:      Sat, 08 Nov 2025 03:56:27 +0000
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=python_app
Replicas:               1 desired | 1 updated | 1 total | 0 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=python_app
  Containers:
   python-container-datacenter:
    Image:         poroko/flask-app-demo
    Port:          5000/TCP
    Host Port:     0/TCP
    Environment:   <none>
    Mounts:        <none>
  Volumes:         <none>
  Node-Selectors:  <none>
  Tolerations:     <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      False   MinimumReplicasUnavailable
  Progressing    False   ProgressDeadlineExceeded
OldReplicaSets:  <none>
NewReplicaSet:   python-deployment-datacenter-6fdb496d59 (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  20m   deployment-controller  Scaled up replica set python-deployment-datacenter-6fdb496d59 to 1

thor@jumphost ~$ kubectl describe pods python-deployment-datacenter-6fdb496d59-df826 
Name:             python-deployment-datacenter-6fdb496d59-df826
Namespace:        default
Priority:         0
Service Account:  default
Node:             kodekloud-control-plane/172.17.0.2
Start Time:       Sat, 08 Nov 2025 03:56:27 +0000
Labels:           app=python_app
                  pod-template-hash=6fdb496d59
Annotations:      <none>
Status:           Pending
IP:               10.244.0.5
IPs:
  IP:           10.244.0.5
Controlled By:  ReplicaSet/python-deployment-datacenter-6fdb496d59
Containers:
  python-container-datacenter:
    Container ID:   
    Image:          poroko/flask-app-demo
    Image ID:       
    Port:           5000/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-gfps4 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  kube-api-access-gfps4:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
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  22m                   default-scheduler  Successfully assigned default/python-deployment-datacenter-6fdb496d59-df826 to kodekloud-control-plane
  Normal   Pulling    20m (x4 over 22m)     kubelet            Pulling image "poroko/flask-app-demo"
  Warning  Failed     20m (x4 over 22m)     kubelet            Failed to pull image "poroko/flask-app-demo": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/poroko/flask-app-demo:latest": failed to resolve reference "docker.io/poroko/flask-app-demo:latest": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
  Warning  Failed     20m (x4 over 22m)     kubelet            Error: ErrImagePull
  Warning  Failed     20m (x6 over 22m)     kubelet            Error: ImagePullBackOff
  Normal   BackOff    2m25s (x86 over 22m)  kubelet            Back-off pulling image "poroko/flask-app-demo"

thor@jumphost ~$ kubectl describe service python-service-datacenter 
Name:                     python-service-datacenter
Namespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=python_app
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.96.237.132
IPs:                      10.96.237.132
Port:                     <unset>  8080/TCP
TargetPort:               8080/TCP
NodePort:                 <unset>  32345/TCP
Endpoints:                
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

Issues Identified:

Wrong image name: The deployment is using poroko/flask-app-demo but it should be poroko/flask-demo-app

Port mismatch: The service has targetPort 8080 but the Flask app runs on port 5000

Step 3: Fix the Image Name

Let's correct the image name in the deployment:

kubectl set image deployment/python-deployment-datacenter python-container-datacenter=poroko/flask-demo-app

Step 4: Fix the Service Port Configuration

The service needs to target port 5000 (Flask default) instead of 8080:

kubectl patch service python-service-datacenter -p '{"spec":{"ports":[{"port":8080,"targetPort":5000,"nodePort":32345}]}}'

Step 5: Verify the Fixes

# Check pod status
kubectl get pods

# Check deployment status
kubectl get deployment python-deployment-datacenter

# Check service endpoints (should now show the pod IP)
kubectl describe service python-service-datacenter

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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 Iron Gallery App on Kubernetes

Thu Kha Kyawe — Thu, 20 Aug 2026 16:05:45 +0000

Lab Information

There is an iron gallery app that the Nautilus DevOps team was developing. They have recently customized the app and are going to deploy the same on the Kubernetes cluster. Below you can find more details:

Create a namespace iron-namespace-nautilus

Create a deployment iron-gallery-deployment-nautilus for iron gallery under the same namespace you created.

:- Labels run should be iron-gallery.

:- Replicas count should be 1.

:- Selector's matchLabels run should be iron-gallery.

:- Template labels run should be iron-gallery under metadata.

:- The container should be named as iron-gallery-container-nautilus, use kodekloud/irongallery:2.0 image ( use exact image name / tag ).

:- Resources limits for memory should be 100Mi and for CPU should be 50m.

:- First volumeMount name should be config, its mountPath should be /usr/share/nginx/html/data.

:- Second volumeMount name should be images, its mountPath should be /usr/share/nginx/html/uploads.

:- First volume name should be config and give it emptyDir and second volume name should be images, also give it emptyDir.

Create a deployment iron-db-deployment-nautilus for iron db under the same namespace.

:- Labels db should be mariadb.

:- Replicas count should be 1.

:- Selector's matchLabels db should be mariadb.

:- Template labels db should be mariadb under metadata.

:- The container name should be iron-db-container-nautilus, use kodekloud/irondb:2.0 image ( use exact image name / tag ).

:- Define environment, set MYSQL_DATABASE its value should be database_apache, set MYSQL_ROOT_PASSWORD and MYSQL_PASSWORD value should be with some complex passwords for DB connections, and MYSQL_USER value should be any custom user ( except root ).

:- Volume mount name should be db and its mountPath should be /var/lib/mysql. Volume name should be db and give it an emptyDir.

Create a service for iron db which should be named iron-db-service-nautilus under the same namespace. Configure spec as selector's db should be mariadb. Protocol should be TCP, port and targetPort should be 3306 and its type should be ClusterIP.

Create a service for iron gallery which should be named iron-gallery-service-nautilus under the same namespace. Configure spec as selector's run should be iron-gallery. Protocol should be TCP, port and targetPort should be 80, nodePort should be 32678 and its type should be NodePort.

Note:

We don't need to make connection b/w database and front-end now, if the installation page is coming up it should be enough for now.

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

Lab Solutions

Step 1: Create the Namespace

vi iron-namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: iron-namespace-nautilus

Apply the namespace:

kubectl apply -f iron-namespace.yaml

Step 2: Create the Iron Gallery Deployment

vi iron-gallery-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iron-gallery-deployment-nautilus
  namespace: iron-namespace-nautilus
spec:
  replicas: 1
  selector:
    matchLabels:
      run: iron-gallery
  template:
    metadata:
      labels:
        run: iron-gallery
    spec:
      containers:
      - name: iron-gallery-container-nautilus
        image: kodekloud/irongallery:2.0
        resources:
          limits:
            memory: "100Mi"
            cpu: "50m"
        volumeMounts:
        - name: config
          mountPath: /usr/share/nginx/html/data
        - name: images
          mountPath: /usr/share/nginx/html/uploads
      volumes:
      - name: config
        emptyDir: {}
      - name: images
        emptyDir: {}

Step 3: Create the Iron DB Deployment

vi iron-db-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iron-db-deployment-nautilus
  namespace: iron-namespace-nautilus
spec:
  replicas: 1
  selector:
    matchLabels:
      db: mariadb
  template:
    metadata:
      labels:
        db: mariadb
    spec:
      containers:
      - name: iron-db-container-nautilus
        image: kodekloud/irondb:2.0
        env:
        - name: MYSQL_DATABASE
          value: "database_apache"
        - name: MYSQL_ROOT_PASSWORD
          value: "RootPassword123!"
        - name: MYSQL_PASSWORD
          value: "UserPassword123!"
        - name: MYSQL_USER
          value: "ironuser"
        volumeMounts:
        - name: db
          mountPath: /var/lib/mysql
      volumes:
      - name: db
        emptyDir: {}

Step 4: Create the Services

vi iron-services.yaml

apiVersion: v1
kind: Service
metadata:
  name: iron-db-service-nautilus
  namespace: iron-namespace-nautilus
spec:
  selector:
    db: mariadb
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  name: iron-gallery-service-nautilus
  namespace: iron-namespace-nautilus
spec:
  type: NodePort
  selector:
    run: iron-gallery
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 32678

Step 5: Apply All Resources

Now let's apply all the YAML files:

# Apply namespace
kubectl apply -f iron-namespace.yaml

# Apply deployments
kubectl apply -f iron-gallery-deployment.yaml
kubectl apply -f iron-db-deployment.yaml

# Apply services
kubectl apply -f iron-services.yaml

Step 6: Verification

Let's verify that all resources are created correctly:

# Check namespace
kubectl get namespace iron-namespace-nautilus

# Check all resources in the namespace
kubectl get all -n iron-namespace-nautilus

# Check deployments
kubectl get deployments -n iron-namespace-nautilus

# Check pods
kubectl get pods -n iron-namespace-nautilus

# Check services
kubectl get services -n iron-namespace-nautilus

# Check pod details to ensure everything is running correctly
kubectl describe pod -n iron-namespace-nautilus -l run=iron-gallery
kubectl describe pod -n iron-namespace-nautilus -l db=mariadb

Output

thor@jumphost ~$ kubectl describe pod -n iron-namespace-nautilus -l run=iron-gallery
Name:             iron-gallery-deployment-nautilus-7cf86c44d7-6qzkt
Namespace:        iron-namespace-nautilus
Priority:         0
Service Account:  default
Node:             kodekloud-control-plane/172.17.0.2
Start Time:       Fri, 07 Nov 2025 11:27:42 +0000
Labels:           pod-template-hash=7cf86c44d7
                  run=iron-gallery
Annotations:      <none>
Status:           Running
IP:               10.244.0.5
IPs:
  IP:           10.244.0.5
Controlled By:  ReplicaSet/iron-gallery-deployment-nautilus-7cf86c44d7
Containers:
  iron-gallery-container-nautilus:
    Container ID:   containerd://6983760721d6b4cdf17c22e001b61596ff1e4e406d58cf8b66fb6487cc3a9fde
    Image:          kodekloud/irongallery:2.0
    Image ID:       docker.io/kodekloud/irongallery@sha256:677aded1f2397f8168bf7061646630e153a68187a6026587c881feb79436d468
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Fri, 07 Nov 2025 11:27:54 +0000
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     50m
      memory:  100Mi
    Requests:
      cpu:        50m
      memory:     100Mi
    Environment:  <none>
    Mounts:
      /usr/share/nginx/html/data from config (rw)
      /usr/share/nginx/html/uploads from images (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-4n2v4 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  config:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  images:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  kube-api-access-4n2v4:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Guaranteed
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  2m12s  default-scheduler  Successfully assigned iron-namespace-nautilus/iron-gallery-deployment-nautilus-7cf86c44d7-6qzkt to kodekloud-control-plane
  Normal  Pulling    2m10s  kubelet            Pulling image "kodekloud/irongallery:2.0"
  Normal  Pulled     2m1s   kubelet            Successfully pulled image "kodekloud/irongallery:2.0" in 9.671382144s (9.671467974s including waiting)
  Normal  Created    2m1s   kubelet            Created container iron-gallery-container-nautilus
  Normal  Started    2m     kubelet            Started container iron-gallery-container-nautilus


thor@jumphost ~$ kubectl describe pod -n iron-namespace-nautilus -l db=mariadb
Name:             iron-db-deployment-nautilus-765f55859c-fc9dw
Namespace:        iron-namespace-nautilus
Priority:         0
Service Account:  default
Node:             kodekloud-control-plane/172.17.0.2
Start Time:       Fri, 07 Nov 2025 11:27:50 +0000
Labels:           db=mariadb
                  pod-template-hash=765f55859c
Annotations:      <none>
Status:           Running
IP:               10.244.0.6
IPs:
  IP:           10.244.0.6
Controlled By:  ReplicaSet/iron-db-deployment-nautilus-765f55859c
Containers:
  iron-db-container-nautilus:
    Container ID:   containerd://3e78fa187d014e0db5b56c452951576b3d83b189aae97e231183d0b0f244f6cf
    Image:          kodekloud/irondb:2.0
    Image ID:       docker.io/kodekloud/irondb@sha256:fa72f29b927307e2a678a2f5056ee5be1f50ae249dbdbd4e47e4abb88e0e5953
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Fri, 07 Nov 2025 11:28:07 +0000
    Ready:          True
    Restart Count:  0
    Environment:
      MYSQL_DATABASE:       database_apache
      MYSQL_ROOT_PASSWORD:  RootPassword123!
      MYSQL_PASSWORD:       UserPassword123!
      MYSQL_USER:           ironuser
    Mounts:
      /var/lib/mysql from db (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-qclp4 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  db:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  kube-api-access-qclp4:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
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  2m25s  default-scheduler  Successfully assigned iron-namespace-nautilus/iron-db-deployment-nautilus-765f55859c-fc9dw to kodekloud-control-plane
  Normal  Pulling    2m23s  kubelet            Pulling image "kodekloud/irondb:2.0"
  Normal  Pulled     2m9s   kubelet            Successfully pulled image "kodekloud/irondb:2.0" in 12.973625003s (14.740476439s including waiting)
  Normal  Created    2m9s   kubelet            Created container iron-db-container-nautilus
  Normal  Started    2m8s   kubelet            Started container iron-db-container-nautilus

Testing the Application

Once deployed, you should be able to access the Iron Gallery application using button from console.

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.Kubernetes Troubleshooting

Thu Kha Kyawe — Thu, 20 Aug 2026 16:01:40 +0000

Lab Information

One of the Nautilus DevOps team members was working on to update an existing Kubernetes template. Somehow, he made some mistakes in the template and it is failing while applying. We need to fix this as soon as possible, so take a look into it and make sure you are able to apply it without any issues. Also, do not remove any component from the template like pods/deployments/volumes etc.

/home/thor/mysql_deployment.yml is the template that needs to be fixed.

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

Lab Solutions

Step 1. Check yaml file

cat mysql_deployment.yml

Output

thor@jumphost ~$ cat mysql_deployment.yml 
apiVersion: apps/v1 
kind: PersistentVolume            
metadata:
  name: mysql-pv
  labels: 
  type: local 
spec:
  storageClassName: standard      
  capacity:
    storage: 250Mi
  accessModes: 
    - ReadWriteOnce
  hostPath:                       
  path: "/mnt/data" 
  persistentVolumeReclaimPolicy:  
  -  Retain  
---    
apiVersion: apps/v1 
kind: PersistentVolumeClaim 
metadata:                          
  name: mysql-pv-claim
  labels:
  app: mysql-app 
spec:                              
  storageClassName: standard       
  accessModes:
    - ReadWriteOnce                
  resources:
    requests: 
      storage: 250MB 
---
apiVersion: v1                    
kind: Service                      
metadata:
  name: mysql         
  labels:             
    app: mysql-app
spec:
  type: NodePort
  ports:
    - targetPort: 3306
      port: 3306
      nodePort: 30011
  selector:    
    app: mysql-app
  tier: mysql
---
apiVersion: v1 
kind: Deployment            
metadata:
  name: mysql-deployment       
  labels:                       
    app: mysql-app 
spec:
  selector:
    matchLabels:
      app: mysql-app
    tier: mysql 
  strategy:
    type: Recreate
  template:                    
    metadata:
      labels:                  
        app: mysql-app
      tier: mysql 
    spec:                       
      containers: 
      - images: mysql:5.6 
        name: mysql
        env:                        
        - name: MYSQL_ROOT_PASSWORD 
          valueFrom:                
          secretKeyRef: 
            name: mysql-root-pass 
              key: password 
        - name: MYSQL_DATABASE
          valueFrom:
          secretKeyRef: 
            name: mysql-db-url 
              key: database 
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mysql-user-pass
              key: username
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-user-pass
              key: password
        ports:
        - containerPort: 3306        
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage 
          mountPath: /var/lib/mysql
      volumes:                       
      - name: mysql-persistent-storage
          persistentVolumeClaim:
          claimName: mysql-pv-claim

Step 2: Errors in the Original YAML

mysql_deployment.yml contains the following errors, which need to be corrected:

Wrong apiVersion for PersistentVolume:

apiVersion: apps/v1
kind: PersistentVolume

Issue: PersistentVolume is a core API resource and must use apiVersion: v1. Fix: Change to apiVersion: v1.

Misplaced labels in PersistentVolume:

labels:
type: local

Issue: Indentation is incorrect. Fix: Ensure proper indentation under metadata.

hostPath indentation error:

hostPath:
path: "/mnt/data"

Issue: The path field are not indented correctly under hostPath. Fix: Properly indent path under hostPath.

Wrong format for persistentVolumeReclaimPolicy:

persistentVolumeReclaimPolicy:
  - Retain

Issue: This field takes a string, not a list. Fix: Use persistentVolumeReclaimPolicy: Retain.

PVC storage unit typo:

storage: 250MB

Issue: Kubernetes uses binary SI units (e.g., Mi, Gi), not MB. Fix: Change to storage: 250Mi.

Wrong apiVersion for Deployment:

apiVersion: v1
kind: Deployment

Issue: Deployments are under apps/v1, not v1. Fix: Change to apiVersion: apps/v1.

Misplaced tier labels in selector:

selector:
  matchLabels:
    app: mysql-app
  tier: mysql

Issue: tier is incorrectly placed outside matchLabels. Fix: Move tier: mysql under matchLabels.

Wrong field name in Deployment container:

- images: mysql:5.6

Issue: The field must be image, not images. Fix: Change to image: mysql:5.6.

Indentation of secretKeyRef in env:

- name: MYSQL_ROOT_PASSWORD
  valueFrom:
  secretKeyRef:
    name: mysql-root-pass
      key: password

Issue: secretKeyRef is not properly indented under valueFrom, and key is indented too far. Fix: Correct indentation for secretKeyRef and its subfields.

Volumes section mis-indented:

volumes:
- name: mysql-persistent-storage
    persistentVolumeClaim:
    claimName: mysql-pv-claim

Issue: persistentVolumeClaim is not properly indented under the volume. Fix: Correct indentation for persistentVolumeClaim.

Step 2: Update With Correct Configuration

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
  labels:
    type: local
spec:
  storageClassName: standard
  capacity:
    storage: 250Mi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
  persistentVolumeReclaimPolicy: Retain
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: mysql-app
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 250Mi
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql-app
spec:
  type: NodePort
  ports:
    - targetPort: 3306
      port: 3306
      nodePort: 30011
  selector:
    app: mysql-app
    tier: mysql
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-deployment
  labels:
    app: mysql-app
spec:
  selector:
    matchLabels:
      app: mysql-app
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql-app
        tier: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-root-pass
              key: password
        - name: MYSQL_DATABASE
          valueFrom:
            secretKeyRef:
              name: mysql-db-url
              key: database
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mysql-user-pass
              key: username
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-user-pass
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

Step 3: Apply Configuration

kubectl apply -f /home/thor/mysql_deployment.yml

Step 4: Verify Resources

kubectl get pv,pvc
kubectl get svc mysql
kubectl get deploy mysql-deployment
kubectl get pod -l app=mysql-app
kubectl get secrets
echo "Username:"
kubectl get secret mysql-user-pass -o jsonpath='{.data.username}' | base64 --decode && echo
echo "Password:"
kubectl get secret mysql-user-pass -o jsonpath='{.data.password}' | base64 --decode && echo

Step 5: Verify MySQL Accessibility

POD=$(kubectl get pod -l app=mysql-app -o jsonpath='{.items[0].metadata.name}')
kubectl exec $POD -- mysqladmin -u kodekloud_pop -pRc5C9EyvbU status

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.

7.Kubernetes LEMP Setup

Thu Kha Kyawe — Fri, 24 Jul 2026 15:14:35 +0000

Lab Information

The Nautilus DevOps team want to deploy a static website on Kubernetes cluster. They are going to use Nginx, phpfpm and MySQL for the database. The team had already gathered the requirements and now they want to make this website live. Below you can find more details:

Create some secrets for MySQL.

Create a secret named mysql-root-pass wih key/value pairs as below:

Create a secret named mysql-user-pass with key/value pairs as below:

Create a secret named mysql-db-url with key/value pairs as below:

Create a secret named mysql-host with key/value pairs as below:

Create a config map php-config for php.ini with variables_order = "EGPCS" data.

Create a deployment named lemp-wp.

Create two containers under it. First container must be nginx-php-container using image webdevops/php-nginx:alpine-3-php7 and second container must be mysql-container from image mysql:5.6. Mount php-config configmap in nginx container at /opt/docker/etc/php/php.ini location.

5) Add some environment variables for both containers:

MYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD and MYSQL_HOST. Take their values from the secrets you created. Please make sure to use env field (do not use envFrom) to define the name-value pair of environment variables.

6) Create a node port type service lemp-service to expose the web application, nodePort must be 30008.

7) Create a service for mysql named mysql-service and its port must be 3306.

We already have a /tmp/index.php file on jump_host server.

    Copy this file into the nginx container under document root i.e /app and replace the dummy values for mysql related variables with the environment variables you have set for mysql related parameters. Please make sure you do not hard code the mysql related details in this file, you must use the environment variables to fetch those values.

    Once done, you must be able to access this website using Website button on the top bar, please note that you should see Connected successfully message while accessing this page.

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

Lab Solutions

Step 1: Create Secrets using YAML files

Create yaml file by using `vi` commands

mysql-root-pass-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysql-root-pass
type: Opaque
data:
  password: UjAwdA==  # R00t base64 encoded

mysql-user-pass-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysql-user-pass
type: Opaque
data:
  username: a29kZWtsb3VkX2NhcA==  # kodekloud_cap base64 encoded
  password: UmM1QzlFeXZiVQ==       # Rc5C9EyvbU base64 encoded

mysql-db-url-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysql-db-url
type: Opaque
data:
  database: a29kZWtsb3VkX2RiOA==  # kodekloud_db8 base64 encoded

mysql-host-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysql-host
type: Opaque
data:
  host: bXlzcWwtc2VydmljZQ==  # mysql-service base64 encoded

Apply the secrets:

kubectl apply -f mysql-root-pass-secret.yaml
kubectl apply -f mysql-user-pass-secret.yaml
kubectl apply -f mysql-db-url-secret.yaml
kubectl apply -f mysql-host-secret.yaml

Step 2: Create ConfigMap using YAML file

php-config-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: php-config
data:
  php.ini: |
    variables_order = "EGPCS"

Apply the configmap:

kubectl apply -f php-config-configmap.yaml

Step 3: Create the Deployment

lemp-wp-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: lemp-wp
spec:
  selector:
    matchLabels:
      app: lemp-wp
  template:
    metadata:
      labels:
        app: lemp-wp
    spec:
      containers:
      # Nginx-PHP container
      - name: nginx-php-container
        image: webdevops/php-nginx:alpine-3-php7
        volumeMounts:
        - name: php-config
          mountPath: /opt/docker/etc/php/php.ini
          subPath: php.ini
        - name: app-volume
          mountPath: /app
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-root-pass
              key: password
        - name: MYSQL_DATABASE
          valueFrom:
            secretKeyRef:
              name: mysql-db-url
              key: database
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mysql-user-pass
              key: username
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-user-pass
              key: password
        - name: MYSQL_HOST
          valueFrom:
            secretKeyRef:
              name: mysql-host
              key: host

      # MySQL container
      - name: mysql-container
        image: mysql:5.6
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-root-pass
              key: password
        - name: MYSQL_DATABASE
          valueFrom:
            secretKeyRef:
              name: mysql-db-url
              key: database
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mysql-user-pass
              key: username
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-user-pass
              key: password

      volumes:
      - name: php-config
        configMap:
          name: php-config
      - name: app-volume
        emptyDir: {}

Apply the deployment:

kubectl apply -f lemp-wp-deployment.yaml

Step 4: Create Services

services.yaml

apiVersion: v1
kind: Service
metadata:
  name: lemp-service
spec:
  type: NodePort
  selector:
    app: lemp-wp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30008
---
apiVersion: v1
kind: Service
metadata:
  name: mysql-service
spec:
  selector:
    app: lemp-wp
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306

Apply the services:

kubectl apply -f services.yaml

Step 5: Copy and Modify index.php

cat /tmp/index.php

sudo chmod 777 /tmp/index.php   **Password:** `mjolnir123
vi index.php

<?php
$dbname = getenv('MYSQL_DATABASE');
$dbuser = getenv('MYSQL_USER');
$dbpass = getenv('MYSQL_PASSWORD');
$dbhost = getenv('MYSQL_HOST');

$connect = mysqli_connect($dbhost, $dbuser, $dbpass, $dbname);

if (!$connect) {
    die("Connection failed: " . mysqli_connect_error());
}
echo "Connected successfully";
?>

Copy the file to the container:

# Get the pod name
POD_NAME=$(kubectl get pods -l app=lemp-wp -o jsonpath='{.items[0].metadata.name}')

# Copy the modified file
kubectl cp /tmp/index.php $POD_NAME:/app -c nginx-php-container

Step 6: Verify Resources

kubectl get secret mysql-root-pass mysql-user-pass mysql-db-url mysql-host
kubectl get configmap php-config
kubectl get deploy lemp-wp
kubectl get pod -l app=lemp-wp
kubectl get svc lemp-service mysql-service

Step 7: Verify Application Accessibility

Access the Application:

Click the Website button in the lab interface.

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.Environment Variables in Kubernetes

Thu Kha Kyawe — Fri, 24 Jul 2026 15:02:09 +0000

Lab Information

There are a number of parameters that are used by the applications. We need to define these as environment variables, so that we can use them as needed within different configs. Below is a scenario which needs to be configured on Kubernetes cluster. Please find below more details about the same.

Create a pod named envars.

Container name should be fieldref-container, use image busybox preferable latest tag, use command 'sh', '-c' and args should be

'while true; do
echo -en '/n';
printenv NODE_NAME POD_NAME;
printenv POD_IP POD_SERVICE_ACCOUNT;
sleep 10;
done;'

(Note: please take care of indentations)

Define Four environment variables as mentioned below:

a.) The first env should be named as NODE_NAME, set valueFrom fieldref and fieldPath should be spec.nodeName.

b.) The second env should be named as POD_NAME, set valueFrom fieldref and fieldPath should be metadata.name.

c.) The third env should be named as POD_IP, set valueFrom fieldref and fieldPath should be status.podIP.

d.) The fourth env should be named as POD_SERVICE_ACCOUNT, set valueFrom fieldref and fieldPath shoulbe be spec.serviceAccountName.

Set restart policy to Never.

To check the output, exec into the pod and use printenv command.

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

Lab Solutions

Step 1: Create the Pod Configuration

Create a file named envars-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: envars
spec:
  containers:
  - name: fieldref-container
    image: busybox:latest
    command: 
      - 'sh'
      - '-c'
    args:
      - |
        while true; do
          echo -en '\n';
          printenv NODE_NAME POD_NAME;
          printenv POD_IP POD_SERVICE_ACCOUNT;
          sleep 10;
        done;
    env:
    - name: NODE_NAME
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: POD_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    - name: POD_SERVICE_ACCOUNT
      valueFrom:
        fieldRef:
          fieldPath: spec.serviceAccountName
  restartPolicy: Never

Step 2: Apply the Pod Configuration

Deploy the pod to the Kubernetes cluster:

kubectl apply -f envars-pod.yaml

Step 3: Verify the Pod is Running

Check the pod status:

kubectl get pods

Step 4: Check the Pod Logs

Since the container is running a continuous loop that prints environment variables, you can check the logs to see the output:

kubectl logs envars

Step 5: Exec into the Pod and Verify Environment Variables

Execute into the pod to manually check the environment variables:

kubectl exec -it envars -- /bin/sh

#Once inside the container, run:
printenv

#Exit the container:
exit

Step 6: Detailed Verification

Let's verify all components are correctly configured:
Check pod details:

kubectl describe pod envars

Output

thor@jumphost ~$ kubectl describe pod envars
Name:             envars
Namespace:        default
Priority:         0
Service Account:  default
Node:             kodekloud-control-plane/172.17.0.2
Start Time:       Tue, 04 Nov 2025 10:37:43 +0000
Labels:           <none>
Annotations:      <none>
Status:           Running
IP:               10.244.0.5
IPs:
  IP:  10.244.0.5
Containers:
  fieldref-container:
    Container ID:  containerd://5c07316533aab139456369be9719d5d5bf8b25850aa7123700ee6e0af29277d4
    Image:         busybox:latest
    Image ID:      docker.io/library/busybox@sha256:e3652a00a2fabd16ce889f0aa32c38eec347b997e73bd09e69c962ec7f8732ee
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
      -c
    Args:
      while true; do
        echo -en '\n';
        printenv NODE_NAME POD_NAME;
        printenv POD_IP POD_SERVICE_ACCOUNT;
        sleep 10;
      done;

    State:          Running
      Started:      Tue, 04 Nov 2025 10:37:44 +0000
    Ready:          True
    Restart Count:  0
    Environment:
      NODE_NAME:             (v1:spec.nodeName)
      POD_NAME:             envars (v1:metadata.name)
      POD_IP:                (v1:status.podIP)
      POD_SERVICE_ACCOUNT:   (v1:spec.serviceAccountName)
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-mvs4m (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-mvs4m:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
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  3m20s  default-scheduler  Successfully assigned default/envars to kodekloud-control-plane
  Normal  Pulling    3m19s  kubelet            Pulling image "busybox:latest"
  Normal  Pulled     3m19s  kubelet            Successfully pulled image "busybox:latest" in 315.653926ms (315.66919ms including waiting)
  Normal  Created    3m19s  kubelet            Created container fieldref-container
  Normal  Started    3m19s  kubelet            Started container fieldref-container

Check the environment variables in the pod spec:

kubectl get pod envars -o yaml | grep -A 20 "env:"

Step 7: Understanding the Field References

The environment variables are set using Downward API field references:

NODE_NAME: spec.nodeName - Gets the name of the node where the pod is running

POD_NAME: metadata.name - Gets the name of the pod (envars)

POD_IP: status.podIP - Gets the IP address assigned to the pod

POD_SERVICE_ACCOUNT: spec.serviceAccountName - Gets the service account name (defaults to default)

Step 8: Continuous Monitoring

To watch the logs in real-time:

kubectl logs envars -f

Press Ctrl+C to exit the log view.

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.Manage Secrets in Kubernetes

Thu Kha Kyawe — Fri, 24 Jul 2026 14:57:04 +0000

Lab Information

The Nautilus DevOps team is working to deploy some tools in Kubernetes cluster. Some of the tools are licence based so that licence information needs to be stored securely within Kubernetes cluster. Therefore, the team wants to utilize Kubernetes secrets to store those secrets. Below you can find more details about the requirements:

We already have a secret key file official.txt under /opt location on jump host. Create a generic secret named official, it should contain the password/license-number present in official.txt file.

Also create a pod named secret-devops.

Configure pod's spec as container name should be secret-container-devops, image should be fedora with latest tag (remember to mention the tag with image). Use sleep command for container so that it remains in running state. Consume the created secret and mount it under /opt/demo within the container.

To verify you can exec into the container secret-container-devops, to check the secret key under the mounted path /opt/demo. Before hitting the Check button please make sure pod/pods are in running state, also validation can take some time to complete so keep patience.

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

Lab Solutions

Step 1: Check the Secret Key File

First, let's verify the content of the official.txt file:

cat /opt/official.txt

This will show you the password/license-number that needs to be stored as a secret.

Step 2: Create the Kubernetes Secret

Create a generic secret named official from the file:

kubectl create secret generic official --from-file=official=/opt/official.txt

Step 3: Verify the Secret was Created

Check if the secret was created successfully:

kubectl get secrets

To see more details:

kubectl describe secret official

Step 4: Create the Pod Configuration

Create a file named secret-devops.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: secret-devops
spec:
  containers:
  - name: secret-container-devops
    image: fedora:latest
    command: ["/bin/bash", "-c", "sleep infinity"]
    volumeMounts:
    - name: secret-volume
      mountPath: /opt/demo
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: official

Step 5: Deploy the Pod

Apply the pod configuration:

kubectl apply -f secret-devops.yaml

Step 6: Verify the Pod is Running

Check the pod status:

kubectl get pods

Step 7: Verify the Secret is Mounted Correctly

# Once the pod is running, execute into the container to verify the secret:
kubectl exec -it secret-devops -- /bin/bash


# Inside the container, check the mounted secret:
ls -la /opt/demo/

# You should see the secret file. Then check its content:
cat /opt/demo/official

# Exit the container:
exit

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.Persistent Volumes in Kubernetes

Thu Kha Kyawe — Fri, 24 Jul 2026 14:52:15 +0000

Lab Information

The Nautilus DevOps team is working on a Kubernetes template to deploy a web application on the cluster. There are some requirements to create/use persistent volumes to store the application code, and the template needs to be designed accordingly. Please find more details below:

Create a PersistentVolume named as pv-devops. Configure the spec as storage class should be manual, set capacity to 5Gi, set access mode to ReadWriteOnce, volume type should be hostPath and set path to /mnt/sysops (this directory is already created, you might not be able to access it directly, so you need not to worry about it).

Create a PersistentVolumeClaim named as pvc-devops. Configure the spec as storage class should be manual, request 1Gi of the storage, set access mode to ReadWriteOnce.

Create a pod named as pod-devops, mount the persistent volume you created with claim name pvc-devops at document root of the web server, the container within the pod should be named as container-devops using image httpd with latest tag only (remember to mention the tag i.e httpd:latest).

Create a node port type service named web-devops using node port 30008 to expose the web server running within the pod.

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

Lab Solutions

Step 2: Create Configuration File
Create a file named devops-deployment.yaml:

# Define PersistentVolume for storage
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-devops
spec:
  storageClassName: "manual"
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/sysops
---
# Define PersistentVolumeClaim to request storage
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-devops
spec:
  storageClassName: "manual"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
# Define Pod with Apache web server
apiVersion: v1
kind: Pod
metadata:
  name: pod-devops
  labels:
    app: web-devops
spec:
  containers:
    - name: container-devops
      image: httpd:latest
      volumeMounts:
        - mountPath: /usr/local/apache2/htdocs
          name: web-storage
  volumes:
    - name: web-storage
      persistentVolumeClaim:
        claimName: pvc-devops
---
# Define NodePort service to expose the web server
apiVersion: v1
kind: Service
metadata:
  name: web-devops
spec:
  type: NodePort
  selector:
    app: web-devops
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30008

Step 2: Apply Configuration

kubectl apply -f devops-deployment.yaml

Step 3: Verify PersistentVolume and Claim

kubectl get pv pv-devops

Verification: Confirm the PersistentVolume is bound to pvc-datacenter.

kubectl get pvc pvc-devops

Step 4: Verify Pod

kubectl get pod pod-devops

Step 5: Verify Service

kubectl get svc web-devops

Verification: Confirm the service uses NodePort 30008.

Step 6: Verify Application Accessibility

Access the Application:

Click on the App or Website button in the lab interface.

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.Init Containers in Kubernetes

Thu Kha Kyawe — Thu, 23 Jul 2026 14:54:45 +0000

Lab Information

There are some applications that need to be deployed on Kubernetes cluster and these apps have some pre-requisites where some configurations need to be changed before deploying the app container. Some of these changes cannot be made inside the images so the DevOps team has come up with a solution to use init containers to perform these tasks during deployment. Below is a sample scenario that the team is going to test first.

Create a Deployment named as ic-deploy-devops.

Configure spec as replicas should be 1, labels app should be ic-devops, template's metadata lables app should be the same ic-devops.

The initContainers should be named as ic-msg-devops, use image fedora with latest tag and use command '/bin/bash', '-c' and 'echo Init Done - Welcome to xFusionCorp Industries > /ic/blog'. The volume mount should be named as ic-volume-devops and mount path should be /ic.

Main container should be named as ic-main-devops, use image fedora with latest tag and use command '/bin/bash', '-c' and 'while true; do cat /ic/blog; sleep 5; done'. The volume mount should be named as ic-volume-devops and mount path should be /ic.

Volume to be named as ic-volume-devops and it should be an emptyDir type.

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

Lab Solutions

Step 1: Create the Deployment YAML File

Create a file named ic-deploy-devops.yaml with the following content:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ic-deploy-devops
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ic-devops
  template:
    metadata:
      labels:
        app: ic-devops
    spec:
      initContainers:
      - name: ic-msg-devops
        image: fedora:latest
        command: ['/bin/bash', '-c', 'echo Init Done - Welcome to xFusionCorp Industries > /ic/blog']
        volumeMounts:
        - name: ic-volume-devops
          mountPath: /ic
      containers:
      - name: ic-main-devops
        image: fedora:latest
        command: ['/bin/bash', '-c', 'while true; do cat /ic/blog; sleep 5; done']
        volumeMounts:
        - name: ic-volume-devops
          mountPath: /ic
      volumes:
      - name: ic-volume-devops
        emptyDir: {}

Step 2: Apply the Deployment

Deploy the configuration to your Kubernetes cluster:

kubectl apply -f ic-deploy-devops.yaml

Step 3: Verify the Deployment

Check if the deployment was created successfully:

kubectl get deployment ic-deploy-devops

Step 4: Check the Pod Status

Monitor the pod creation and init container execution:

kubectl get pods -l app=ic-devops

Step 5: Verify Init Container Execution

Check the init container logs to ensure it ran successfully:

# Get the pod name first
POD_NAME=$(kubectl get pods -l app=ic-devops -o jsonpath='{.items[0].metadata.name}')

# Check init container logs
kubectl logs $POD_NAME -c ic-msg-devops

Step 6: Verify Main Container Operation

Check the main container logs to see the continuous output:

kubectl logs $POD_NAME -c ic-main-devops

The main container should be printing the message every 5 seconds.

Step 7: Detailed Verification

Let's verify all components are correctly configured:

# Check the deployment details:
kubectl describe deployment ic-deploy-devops

# Check the pod details:
kubectl describe pod $POD_NAME

# Verify the volume mount:
kubectl exec $POD_NAME -c ic-main-devops -- ls -la /ic/

# Check the file content directly:
kubectl exec $POD_NAME -c ic-main-devops -- cat /ic/blog

Output

thor@jumphost ~$ kubectl describe deployment ic-deploy-devops
Name:                   ic-deploy-devops
Namespace:              default
CreationTimestamp:      Fri, 31 Oct 2025 13:43:39 +0000
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=ic-devops
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=ic-devops
  Init Containers:
   ic-msg-devops:
    Image:      fedora:latest
    Port:       <none>
    Host Port:  <none>
    Command:
      /bin/bash
      -c
      echo Init Done - Welcome to xFusionCorp Industries > /ic/blog
    Environment:  <none>
    Mounts:
      /ic from ic-volume-devops (rw)
  Containers:
   ic-main-devops:
    Image:      fedora:latest
    Port:       <none>
    Host Port:  <none>
    Command:
      /bin/bash
      -c
      while true; do cat /ic/blog; sleep 5; done
    Environment:  <none>
    Mounts:
      /ic from ic-volume-devops (rw)
  Volumes:
   ic-volume-devops:
    Type:          EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:        
    SizeLimit:     <unset>
  Node-Selectors:  <none>
  Tolerations:     <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   ic-deploy-devops-68789fbb69 (1/1 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  3m55s  deployment-controller  Scaled up replica set ic-deploy-devops-68789fbb69 to 1
thor@jumphost ~$ kubectl describe pod $POD_NAME
Name:             ic-deploy-devops-68789fbb69-n46fh
Namespace:        default
Priority:         0
Service Account:  default
Node:             kodekloud-control-plane/172.17.0.2
Start Time:       Fri, 31 Oct 2025 13:43:39 +0000
Labels:           app=ic-devops
                  pod-template-hash=68789fbb69
Annotations:      <none>
Status:           Running
IP:               10.244.0.5
IPs:
  IP:           10.244.0.5
Controlled By:  ReplicaSet/ic-deploy-devops-68789fbb69
Init Containers:
  ic-msg-devops:
    Container ID:  containerd://fda2d6a406793fce4784b97fbd48e04fc4562a26b6153f877bedff8460ffa44e
    Image:         fedora:latest
    Image ID:      docker.io/library/fedora@sha256:aa7befe5cfd1f0e062728c16453cd1c479d4134c7b85eac00172f3025ab0d522
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/bash
      -c
      echo Init Done - Welcome to xFusionCorp Industries > /ic/blog
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Fri, 31 Oct 2025 13:43:46 +0000
      Finished:     Fri, 31 Oct 2025 13:43:46 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /ic from ic-volume-devops (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-mqkwp (ro)
Containers:
  ic-main-devops:
    Container ID:  containerd://dbc7396b61602a895278a5ebf5eb61bc231ef702bd607c39237866dd6c5a5b5a
    Image:         fedora:latest
    Image ID:      docker.io/library/fedora@sha256:aa7befe5cfd1f0e062728c16453cd1c479d4134c7b85eac00172f3025ab0d522
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/bash
      -c
      while true; do cat /ic/blog; sleep 5; done
    State:          Running
      Started:      Fri, 31 Oct 2025 13:43:47 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /ic from ic-volume-devops (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-mqkwp (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  ic-volume-devops:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  kube-api-access-mqkwp:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
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  4m3s   default-scheduler  Successfully assigned default/ic-deploy-devops-68789fbb69-n46fh to kodekloud-control-plane
  Normal  Pulling    4m2s   kubelet            Pulling image "fedora:latest"
  Normal  Pulled     3m57s  kubelet            Successfully pulled image "fedora:latest" in 5.558670958s (5.558686183s including waiting)
  Normal  Created    3m57s  kubelet            Created container ic-msg-devops
  Normal  Started    3m56s  kubelet            Started container ic-msg-devops
  Normal  Pulling    3m56s  kubelet            Pulling image "fedora:latest"
  Normal  Pulled     3m55s  kubelet            Successfully pulled image "fedora:latest" in 144.822007ms (144.841997ms including waiting)
  Normal  Created    3m55s  kubelet            Created container ic-main-devops
  Normal  Started    3m55s  kubelet            Started container ic-main-devops
thor@jumphost ~$ kubectl exec $POD_NAME -c ic-main-devops -- ls -la /ic/
total 12
drwxrwxrwx 2 root root 4096 Oct 31 13:43 .
drwxr-xr-x 1 root root 4096 Oct 31 13:43 ..
-rw-r--r-- 1 root root   46 Oct 31 13:43 blog
thor@jumphost ~$ kubectl exec $POD_NAME -c ic-main-devops -- cat /ic/blog
Init Done - Welcome to xFusionCorp Industries

Step 8: Continuous Monitoring

To see the real-time output from the main container:

kubectl logs $POD_NAME -c ic-main-devops -f

Press Ctrl+C to exit the continuous log view.

Explanation of the Solution

Init Container (ic-msg-devops):

Runs before the main container starts

Creates a file /ic/blog with the welcome message

Uses the shared volume ic-volume-devops

Main Container (ic-main-devops):

Starts after the init container completes successfully

Reads the file created by the init container every 5 seconds

Shares the same volume mount

Volume (ic-volume-devops):

emptyDir type creates a temporary directory that survives container restarts

Shared between init container and main container

Data persists for the lifetime of the pod

Workflow:

Init container writes message to file → Init container completes → Main container starts → Main container reads file repeatedly

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.Deploy Lamp Stack on Kubernetes Cluster

Thu Kha Kyawe — Thu, 23 Jul 2026 14:51:19 +0000

Lab Information

The Nautilus DevOps team want to deploy a PHP website on Kubernetes cluster. They are going to use Apache as a web server and Mysql for database. The team had already gathered the requirements and now they want to make this website live. Below you can find more details:

1) Create a config map php-config for php.ini with variables_order = "EGPCS" data.

2) Create a deployment named lamp-wp.

3) Create two containers under it. First container must be httpd-php-container using image webdevops/php-apache:alpine-3-php7 and second container must be mysql-container from image mysql:5.6. Mount php-config configmap in httpd container at /opt/docker/etc/php/php.ini location.

4) Create kubernetes generic secrets for mysql related values like myql root password, mysql user, mysql password, mysql host and mysql database. Set any values of your choice.

5) Add some environment variables for both containers:

a) MYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD and MYSQL_HOST. Take their values from the secrets you created. Please make sure to use env field (do not use envFrom) to define the name-value pair of environment variables.

6) Create a node port type service lamp-service to expose the web application, nodePort must be 30008.

7) Create a service for mysql named mysql-service and its port must be 3306.

8) We already have /tmp/index.php file on jump_host server.

a) Copy this file into httpd container under Apache document root i.e /app and replace the dummy values for mysql related variables with the environment variables you have set for mysql related parameters. Please make sure you do not hard code the mysql related details in this file, you must use the environment variables to fetch those values.

b) You must be able to access this index.php on node port 30008 at the end, please note that you should see Connected successfully message while accessing this page.

Note:

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

Lab Solutions

Step 1: Create the ConfigMap for php.ini

First, create the php-config ConfigMap with the required php.ini setting:

kubectl create configmap php-config --from-literal=php.ini='variables_order = "EGPCS"'

Verify the ConfigMap was created:

kubectl get configmap php-config -o yaml

ဋ Step 2: Create MySQL Secrets

Create a generic secret for MySQL credentials:

kubectl create secret generic mysql-secrets \
  --from-literal=mysql-root-password=rootpass123 \
  --from-literal=mysql-user=wpuser \
  --from-literal=mysql-password=wppass123 \
  --from-literal=mysql-database=wordpress \
  --from-literal=mysql-host=mysql-service

Verify the secret:

kubectl get secret mysql-secrets -o yaml

Step 3: Create the Deployment

Create a file named lamp-wp-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: lamp-wp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: lamp-wp
  template:
    metadata:
      labels:
        app: lamp-wp
    spec:
      containers:
      - name: httpd-php-container
        image: webdevops/php-apache:alpine-3-php7
        ports:
        - containerPort: 80
        volumeMounts:
        - name: php-config
          mountPath: /opt/docker/etc/php/php.ini
          subPath: php.ini
        - name: app-volume
          mountPath: /app
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secrets
              key: mysql-root-password
        - name: MYSQL_DATABASE
          valueFrom:
            secretKeyRef:
              name: mysql-secrets
              key: mysql-database
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mysql-secrets
              key: mysql-user
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secrets
              key: mysql-password
        - name: MYSQL_HOST
          valueFrom:
            secretKeyRef:
              name: mysql-secrets
              key: mysql-host
      - name: mysql-container
        image: mysql:5.6
        ports:
        - containerPort: 3306
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secrets
              key: mysql-root-password
        - name: MYSQL_DATABASE
          valueFrom:
            secretKeyRef:
              name: mysql-secrets
              key: mysql-database
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mysql-secrets
              key: mysql-user
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secrets
              key: mysql-password
      volumes:
      - name: php-config
        configMap:
          name: php-config
      - name: app-volume
        emptyDir: {}

Apply the deployment:

kubectl apply -f lamp-wp-deployment.yaml

Step 4: Create the Services

Create a file named services.yaml:

apiVersion: v1
kind: Service
metadata:
  name: lamp-service
spec:
  type: NodePort
  selector:
    app: lamp-wp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30008
---
apiVersion: v1
kind: Service
metadata:
  name: mysql-service
spec:
  selector:
    app: lamp-wp
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306

Apply the services:

kubectl apply -f services.yaml

Step 5: Prepare and Copy index.php

First, let's check the original index.php file:

cat /tmp/index.php

Output

Now, let's update modified version that uses environment variables. Create a new file /tmp/index-modified.php:

<?php
$servername = getenv("MYSQL_HOST");
$username = getenv("MYSQL_USER");
$password = getenv("MYSQL_PASSWORD");
$dbname = getenv("MYSQL_DATABASE");

// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);

// Check connection
if ($conn->connect_error) {
    die("Connection failed: " . $conn->connect_error);
}
echo "Connected successfully";
?>

If permission issues occur, fix them:

sudo chmod 777 /tmp/index.php

Password: mjolnir123

Step 6: Copy index.php to Apache Container

kubectl cp /tmp/index.php lamp-wp-7ccc97bf65-6nhv6:/app/index.php -c httpd-php-container

Explanation of Commands:

    Command 1: POD=$(kubectl get pod -l app=lamp-app -o jsonpath='{.items[0].metadata.name}')
        Purpose: Retrieves the name of the first pod with the label app=lamp-app and stores it in the POD variable.
        Details:
            kubectl get pod: Lists pods in the current namespace.
            -l app=lamp-app: Filters pods with the label app=lamp-app, matching the deployment's selector.
            -o jsonpath='{.items[0].metadata.name}': Extracts the name of the first pod using JSONPath.
            POD=$(): Stores the pod name (e.g., lamp-wp-5f7b8d4c5-xyz12) in the POD variable.
        Why Needed: Pod names are dynamically generated by Kubernetes, so this command dynamically retrieves the correct pod name for the file copy operation.

    Command 2: kubectl cp /tmp/index.php $POD:/app -c httpd-php-container
        Purpose: Copies the index.php file from the jump host's /tmp directory to the /app directory in the httpd-php-container of the specified pod.
        Details:
            kubectl cp: Copies files between the local filesystem and a container.
            /tmp/index.php: Source file on the jump host.
            $POD:/app: Destination path, where $POD is the pod name and /app is the Apache document root.
            -c httpd-php-container: Specifies the target container within the pod (since the pod has both httpd-php-container and mysql-container).
        Why Needed: The index.php file contains the PHP code for the website, which must be placed in the Apache document root to make the application functional.

Step 7: Verify Deployment and Services

kubectl get configmap php-config
kubectl get secret mysql-secrets
kubectl get deploy lamp-wp
kubectl get pods
kubectl get svc

Step 8: Verify Application Accessibility

Access the Application:

Click on the App button in the lab interface.

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.Deploy Apache Web Server on Kubernetes Cluster

Thu Kha Kyawe — Thu, 23 Jul 2026 14:51:02 +0000

Lab Information

There is an application that needs to be deployed on Kubernetes cluster under Apache web server. The Nautilus application development team has asked the DevOps team to deploy it. We need to develop a template as per requirements mentioned below:

Create a namespace named as httpd-namespace-devops.

Create a deployment named as httpd-deployment-devops under newly created namespace. For the deployment use httpd image with latest tag only and remember to mention the tag i.e httpd:latest, and make sure replica counts are 2.

Create a service named as httpd-service-devops under same namespace to expose the deployment, nodePort should be 30004.

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

Lab Solutions

Step 1: Create the Namespace

First, let's create the required namespace:

kubectl create namespace httpd-namespace-devops

Verify the namespace was created:

kubectl get namespaces

Step 2: Create the Deployment

Create a YAML file for the deployment. Let's create a file called httpd-deployment.yaml:

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

Apply the deployment:

kubectl apply -f httpd-deployment.yaml

Step 3: Create the Service

Create a YAML file for the service. Let's create a file called httpd-service.yaml:

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

Apply the service:

kubectl apply -f httpd-service.yaml

Step 4: Verify All Resources

Let's verify everything was created correctly:

Check the deployments:

kubectl get deployment -n httpd-namespace-devops
kubectl get pods -n httpd-namespace-devops
kubectl get service -n httpd-namespace-devops
kubectl get all -n httpd-namespace-devops

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.

Day 19: Complete a Production DVC Pipeline with SeaweedFS Remote

Thu Kha Kyawe — Sun, 19 Jul 2026 05:10:53 +0000

Lab Information

Complete the xFusionCorp Industries fraud-detection production DVC pipeline. Three stages are already wired in dvc.yaml, two remain, and the pipeline must finish as a reproducible, SeaweedFS-backed, v1.0-tagged release.

A project exists at /root/code/ml-pipeline/ with Git and DVC initialised. The params.yaml is in place and the .dvc/config is pre-configured to push to the SeaweedFS bucket dvc-storage at http://localhost:8333.

The ingest, validate, and preprocess stages are already declared in dvc.yaml, but one of them is misconfigured and prevents dvc repro from completing — run dvc repro to see it fail. The two scripts for the remaining stages are pre-staged at /root/code/ml-pipeline/scripts-staging/train.py and scripts-staging/evaluate.py, and belong in scripts/.

Acceptance criteria:

The misconfigured existing stage is corrected so dvc repro can complete.
Two further stages are declared in dvc.yaml:
    train – Depends on the preprocessed dataset and scripts/train.py; reads n_estimators, max_depth, test_size, and random_seed from params.yaml; outputs models/model.pkl and data/processed/test_split.csv; declares metrics.json as a DVC metric with cache: false.
    evaluate – Depends on models/model.pkl, data/processed/test_split.csv, and scripts/evaluate.py; outputs reports/evaluation.json declared with cache: false.
The full pipeline has been reproduced, the cache pushed to the SeaweedFS remote, and the current state tagged v1.0.
Every change is committed to Git so the release is fully captured.

Open the SeaweedFS Filer button at the top of the lab and navigate to /buckets/dvc-storage/ to confirm that the bucket holds the pushed artefacts under the files/md5/... layout.

Lab Solutions

✅ Part 1: Lab Step-by-Step Guidelines

Step 1: Enter the project

cd /root/code/ml-pipeline

Step 2: Run the pipeline once

The lab tells you one stage is intentionally broken.

Run:

dvc repro

Don't fix anything yet.

Read the error carefully.

Examples:

Missing dependency
Output mismatch
Script not found
Wrong filename

The error will tell you exactly which existing stage is misconfigured.

Step 3: Inspect the existing pipeline

cat dvc.yaml

Output:

root@controlplane ml-pipeline on  main [?] ✖ cat dvc.yaml
stages:
  ingest:
    cmd: python3 scripts/ingest.py
    deps:
      - scripts/ingest.py
      - data/raw/data.csv

  validate:
    cmd: python3 scripts/validate.py
    deps:
      - data/raw/data.csv
      - scripts/validate.py
    outs:
      - reports/validation.json:
          cache: false

  preprocess:
    cmd: python3 scripts/preprocess.py
    deps:
      - data/raw/data.csv
      - scripts/preprocess.py
    outs:
      - data/processed/cleaned.csv

Step 4: Check what preprocess.py actually created

Run:

ls -l data/processed

Output:

root@controlplane ml-pipeline on  main [?] ➜  ls -l data/processed
total 4
-rw-r--r-- 1 root root 702 Jul 19 00:15 clean.csv

Step 5: Fix the preprocess output path.

Open dvc.yaml in the VS Code editor. In the preprocess stage, change the last line from:

  - data/processed/cleaned.csv

to:

  - data/processed/clean.csv

Save the file (Ctrl+S).

Step 6: Copy the remaining scripts into scripts/.

cp scripts-staging/train.py    scripts/train.py
cp scripts-staging/evaluate.py scripts/evaluate.py

Add the train and evaluate stages to dvc.yaml.

Step 7: Declare the train and evaluate stages with dvc stage add.

Train stage:

dvc stage add -n train \
  -d data/processed/clean.csv -d scripts/train.py \
  -p n_estimators,max_depth,test_size,random_seed \
  -o models/model.pkl -o data/processed/test_split.csv \
  -M metrics.json \
  python3 scripts/train.py

Evaluate stage:

dvc stage add -n evaluate \
  -d models/model.pkl -d data/processed/test_split.csv -d scripts/evaluate.py \
  -O reports/evaluation.json \
  python3 scripts/evaluate.py

Run:

dvc repro

Push to SeaweedFS:

dvc push

Commit everything:

git add .
git commit -m "Complete production DVC pipeline"

Tag the release:

git tag v1.0

Step 8: Verify the SeaweedFS bucket

🧠 Part 2: Simple Step-by-Step Explanation (Beginner Friendly)

In this lab, the ingest and validate stages completed successfully, but the pipeline stopped during the preprocess stage.

When you ran:

dvc repro

DVC executed the preprocess.py script successfully, and the script printed:

Preprocessed: 20 clean rows

However, DVC then displayed the following error:

ERROR: failed to reproduce 'preprocess':
output 'data/processed/cleaned.csv' does not exist

This tells us that the Python script itself did not fail. Instead, DVC could not find the output file that was defined in dvc.yaml.

To investigate, we opened the pipeline configuration:

cat dvc.yaml

Inside the preprocess stage, the output was configured as:

outs:

data/processed/cleaned.csv

Next, we checked the actual contents of the data/processed directory:

ls -l data/processed

The output showed:

clean.csv

This revealed the problem: the script created clean.csv, but dvc.yaml expected cleaned.csv.

Because DVC verifies that every declared output exists after a stage finishes, it stopped the pipeline when it couldn't find cleaned.csv.

To fix the issue, we updated the outs section of the preprocess stage so that it matched the file actually produced by the script:

preprocess:
cmd: python3 scripts/preprocess.py
deps:
- data/raw/data.csv
- scripts/preprocess.py
outs:
- data/processed/clean.csv

After saving the change, running:

dvc repro

again allows DVC to locate the correct output file and continue executing the remaining stages of the pipeline.

Key Takeaway

A very common DVC error is:

output '' does not exist

When you see this message, the first thing to check is whether the output filename in dvc.yaml exactly matches the filename created by the script. Even a small difference—such as clean.csv versus cleaned.csv—is enough to cause the pipeline to fail. Always verify the actual output file (for example, using ls) before updating the pipeline configuration.

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.

Day 18: Version Datasets and Models Across Git Branches

Thu Kha Kyawe — Sun, 19 Jul 2026 05:04:56 +0000

Lab Information

The xFusionCorp Industries MLOps team versions datasets and models on separate Git branches so it can reproduce and roll between versions cleanly. Tag the current state as v1.0, create a v2-improved branch built on a newer dataset (which retrains the model), and confirm that switching back restores the original data and model.

A project exists at /root/code/fraud-detection/ with a working DVC pipeline (it processes the data and trains a model) and the baseline data/raw/transactions.csv already tracked.

An improved dataset has been pre-staged at /root/code/fraud-detection/data/raw/transactions_v2.csv and is visible in the file explorer. Do not delete this file.

Acceptance criteria:

On the main branch, the current state is tagged v1.0.
A branch named v2-improved holds the v2 state: the tracked dataset carries the contents of the v2 file (re-tracked with DVC), the pipeline has been re-run so models/model.pkl is retrained and versioned alongside the dataset, and the changes are committed.
Back on the main branch, the v1 dataset and model are restored on disk, matching the hashes recorded by the v1.0 tag.

The DVC extension's DVC TRACKED section in the EXPLORER panel reflects the tracked dataset and model for the branch you currently have checked out. To compare the exact hashes recorded on each branch, use git show <ref>:dvc.lock or dvc status.

Lab Solutions

✅ Part 1: Lab Step-by-Step Guidelines

This is one of the most realistic DVC labs. You'll combine Git branches + DVC + pipeline reproducibility.

Step 1: Go to the project

cd /root/code/fraud-detection

Step 2: Make sure everything is committed

git status

Expected:

On branch main
nothing to commit, working tree clean

If not clean, commit your changes before continuing.

Step 3: Tag the current version

The lab requires the current main branch to be tagged as v1.0.

git tag v1.0

Verify:

git tag

Expected:

v1.0

Step 4: Create the new branch

git checkout -b v2-improved

Verify:

git branch

Expected:

v2-improved main

Step 5: Replace the tracked dataset with the new version

The improved dataset already exists:

data/raw/transactions_v2.csv

Replace the original dataset:

cp data/raw/transactions_v2.csv data/raw/transactions.csv

Step 6: Update DVC tracking

Since the tracked file changed, update the DVC metadata:

dvc add data/raw/transactions.csv

This updates:

transactions.csv.dvc
DVC cache

Step 7: Retrain the pipeline

Run:

dvc repro

This should rerun:

process_data
split_data
train

and regenerate:

models/model.pkl
metrics.json
dvc.lock

Step 8: Check Git status

git status

You should see changes similar to:

modified: data/raw/transactions.csv.dvc
modified: dvc.lock
modified: metrics.json
modified: models/model.pkl.dvc (if model is DVC tracked)

Note: The exact files may differ depending on how the lab repository is set up.

Step 9: Commit the v2 state

Stage everything:

git add .

Commit:

git commit -m "Update dataset to v2 and retrain model"

Step 10: Return to main

git checkout main

Step 11: Restore the DVC-tracked files

After switching branches, restore the correct dataset and model:

dvc checkout

Step 12: Verify

Check the dataset:

md5sum data/raw/transactions.csv

Check the model:

ls -l models/model.pkl

Verify DVC:

dvc status

Expected:

Data and pipelines are up to date.

🧠 Part 2: Simple Step-by-Step Explanation (Beginner Friendly)

Why do we create a Git tag?

The command:

git tag v1.0

creates a permanent label for the current project state.

Think of it as taking a snapshot:

main
│
├── v1.0 ← Snapshot

You can always return to exactly this version later.

Why create a new branch?

Instead of changing the main branch directly, we create:

v2-improved

This allows us to safely experiment with a new dataset.

The structure becomes:

main
│
└── v2-improved

Why run dvc add again?

The file name stays the same:

transactions.csv

but its contents change because you copied in the improved dataset.

DVC tracks file contents (using hashes), not just filenames.

Running:

dvc add data/raw/transactions.csv

updates the .dvc pointer to reference the new dataset version.

Why rerun the pipeline?

The dataset changed.

That means:

transactions.csv
│
▼
process_data
▼
split_data
▼
train
▼
model.pkl

Every downstream stage depends on the dataset, so DVC reruns the pipeline to produce a model trained on the new data.

Why use dvc checkout?

When you switch back to:

git checkout main

Git restores:

dvc.yaml
.dvc files
dvc.lock

However, Git does not restore the actual dataset or model, because DVC manages those files.

Running:

dvc checkout

reads the .dvc files and restores the correct versions of:

transactions.csv
model.pkl

from the DVC cache.

DEV Community: Thu Kha Kyawe

10.Fix Python App Deployed on Kubernetes Cluster

Step 1: Check Current Deployment Status

Step 2: Examine Detailed Information

Step 3: Fix the Image Name

Step 4: Fix the Service Port Configuration

Step 5: Verify the Fixes

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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 Iron Gallery App on Kubernetes

Lab Information

Lab Solutions

Step 1: Create the Namespace

Step 2: Create the Iron Gallery Deployment

Step 3: Create the Iron DB Deployment

Step 4: Create the Services

Step 5: Apply All Resources

Step 6: Verification

Testing the Application

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.Kubernetes Troubleshooting

Lab Information

Lab Solutions

Step 1. Check yaml file

Step 2: Errors in the Original YAML

Step 2: Update With Correct Configuration

Step 3: Apply Configuration

Step 4: Verify Resources

Step 5: Verify MySQL Accessibility

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.

7.Kubernetes LEMP Setup

Lab Information

Lab Solutions

Step 1: Create Secrets using YAML files

Create yaml file by using vi commands

Step 2: Create ConfigMap using YAML file

Step 3: Create the Deployment

Step 4: Create Services

Step 5: Copy and Modify index.php

Step 6: Verify Resources

Step 7: Verify Application Accessibility

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

💬 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.Environment Variables in Kubernetes

Lab Information

Lab Solutions

Step 1: Create the Pod Configuration

Step 2: Apply the Pod Configuration

Step 3: Verify the Pod is Running

Step 4: Check the Pod Logs

Step 5: Exec into the Pod and Verify Environment Variables

Step 6: Detailed Verification

Step 7: Understanding the Field References

Step 8: Continuous Monitoring

Resources & Next Steps

📦 Full Code Repository: KodeKloud Learning Labs

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

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

Create yaml file by using `vi` commands