DEV Community: Thu Kha Kyawe

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.

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 17: Run and Compare DVC Experiments

Thu Kha Kyawe — Sun, 19 Jul 2026 05:01:39 +0000

Lab Information

The xFusionCorp Industries MLOps team needs every model training run to be reproducible, automatically tracked, and easy to compare so a chosen configuration can be promoted into version control. The fraud-detection pipeline is parameterized by max_depth, currently set shallow enough to underfit. Using DVC experiments, run three tracked experiments over different max_depth values, compare their recorded f1_score on the held-out test set, and promote the best-scoring run so its parameters, metrics, and model become the tracked workspace state.

A project exists at /root/code/fraud-detection/ with a parameterised DVC pipeline already in place. params.yaml declares n_estimators: 100 and max_depth: 4, and the baseline pipeline has been run once. src/models/train.py reads both parameters, trains the model, and evaluates it on the held-out test set, writing the real accuracy and f1_score to metrics.json. Do not modify the Python files.

Acceptance criteria:

Three DVC experiments have been run, each with a different value for max_depth across a reasonable range (for example 2, 6, and 12); each experiment retrains the model and produces a fresh metrics.json.
The experiment with the highest f1_score is applied to the workspace, so its max_depth, metrics.json, and models/model.pkl become the tracked state.

The DVC extension's EXPERIMENTS view (open the DVC panel from the Activity Bar) lists every experiment alongside its parameters and metrics, which is a convenient way to compare runs at a glance.

Lab Solutions

✅ Part 1: Lab Step-by-Step Guidelines

This lab introduces DVC Experiments (dvc exp), which let you test different parameter values without committing changes to Git.

Step 1: Move into the project

cd /root/code/fraud-detection

Step 2: Verify the current parameter

cat params.yaml

Expected:

n_estimators: 100
max_depth: 4

Step 3: Run the first experiment (max_depth=2)

dvc exp run -S max_depth=2

This will:

Update max_depth to 2 for the experiment.
Retrain the model.
Generate a new metrics.json.
Save the experiment in DVC (without changing your Git history).

Step 4: Run the second experiment (max_depth=6)

dvc exp run -S max_depth=6

Step 5: Run the third experiment (max_depth=12)

dvc exp run -S max_depth=12

Now you have three experiments, each using a different max_depth.

Step 6: Compare the experiments

Run:

apt update
apt install -y less
dvc exp show

root@controlplane fraud-detection on  main [!] ➜ dvc exp show
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────>
Experiment Created accuracy f1_score n_estimators max_depth data/processed/clean_transactions.csv data/processed/>
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────>
workspace - 0.75 0.6795 100 12 34832f8da536af18bb25236981b31c04 1d9e91ebeec0d17>
main 09:37 AM 0.71 0.5735 100 4 34832f8da536af18bb25236981b31c04 1d9e91ebeec0d17>
├── f75ec1a [lying-zigs] 09:46 AM 0.75 0.6795 100 12 34832f8da536af18bb25236981b31c04 1d9e91ebeec0d17>
├── fad90d2 [erect-flap] 09:45 AM 0.745 0.6483 100 6 34832f8da536af18bb25236981b31c04 1d9e91ebeec0d17>
└── 422a560 [stone-leas] 09:45 AM 0.6 0.2453 100 2 34832f8da536af18bb25236981b31c04 1d9e91ebeec0d17>
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────>

Step 7: Identify the best experiment

Look at the f1_score column.

Find the experiment with the highest f1_score.

For example:

exp-f75ec1a has the highest f1_score of 0.6795.

Step 8: Apply the best experiment

Apply it to your workspace:

dvc exp apply <experiment-name>

Example:

root@controlplane fraud-detection on  main [!] ➜  dvc exp apply f75ec1a
Building workspace index                                                                                             |7.00 [00:00, 1.46kentry/s]
Comparing indexes                                                                                                    |8.00 [00:00, 4.61kentry/s]
Applying changes                                                                                                      |0.00 [00:00,     ?file/s]
Changes for experiment 'f75ec1a' have been applied to your current workspace.

This updates:

params.yaml
metrics.json
models/model.pkl

to match the selected experiment.

Step 9: Verify the applied parameter

cat params.yaml

Example:

root@controlplane fraud-detection on  main [!] ➜  cat params.yaml
n_estimators: 100
max_depth: 12

Step 10: Verify the metrics

dvc metrics show

The displayed metrics should match the winning experiment.

Example:

root@controlplane fraud-detection on  main [!] ➜  dvc metrics show
Path          accuracy    f1_score
metrics.json  0.75        0.6795

Step 11: Verify the model

ls -l models/model.pkl

The model file should have been regenerated for the applied experiment.

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

What is a DVC Experiment?

Normally, if you want to test a new model configuration, you would:

Edit params.yaml.
Run dvc repro.
Record the results.
Repeat.

This becomes tedious and makes it hard to compare experiments.

DVC Experiments automate this process.

Why run multiple experiments?

Different values of max_depth can affect model performance.

For example:

max_depth = 2

A very shallow tree may underfit the data.

max_depth = 6

May provide a good balance.

max_depth = 12

A deeper tree may overfit.

The goal is to find the value that gives the best f1_score.

What does dvc exp run do?

When you run:

dvc exp run -S max_depth=6

DVC temporarily changes:

max_depth: 6

runs the pipeline, records the metrics, and saves the results as a named experiment.

Your Git history remains unchanged.

Why use dvc exp show?

Instead of opening each metrics.json manually, DVC displays all experiments together.

Example:

Experiment max_depth accuracy f1_score

exp-A 2 0.88 0.84
exp-B 6 0.94 0.92
exp-C 12 0.93 0.90

This makes it easy to compare different parameter values.

What does dvc exp apply do?

Once you've found the experiment with the highest f1_score, apply it:

dvc exp apply exp-B

This updates your workspace so that it reflects the best experiment:

params.yaml uses the winning max_depth.
metrics.json contains the winning metrics.
models/model.pkl is the model trained with those parameters.

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 16: Track ML Metrics with DVC

Thu Kha Kyawe — Sun, 19 Jul 2026 04:57:28 +0000

Lab Information

After training a model, the xFusionCorp Industries ML team requires DVC to surface model metrics through dvc metrics show. Although the fraud-detection pipeline successfully trains a model and generates a metrics.json file, DVC currently does not recognize this file as a metric. Ensure that the metrics.json file is properly configured to be recognized by DVC.

A project exists at /root/code/fraud-detection/ with a three-stage DVC pipeline (process_data, split_data, train). The train stage runs src/models/train.py, which writes the model to models/model.pkl and metrics to metrics.json. Do not modify the Python files.

Acceptance criteria:

The train stage in dvc.yaml declares metrics.json as a DVC metric output rather than a regular file output, with cache: false so the JSON lives in Git for diff history rather than in the DVC cache.
The pipeline has been reproduced so the metric registration takes effect, and dvc metrics show reports the accuracy and f1_score values from metrics.json.

Tip: once the metric is registered, dvc metrics diff compares its values across Git commits, which is useful when iterating on the model.

Lab Solutions

✅ Part 1: Lab Step-by-Step Guidelines

Step 1: Move into the project

cd /root/code/fraud-detection

Step 2: Inspect the current train stage

Open dvc.yaml:

cat dvc.yaml

Notice that metrics.json is missing.

Step 3: Modify the train stage

Add a metrics section.

stages:
  process_data:
    cmd: python3 src/data/process_data.py
    deps:
      - data/raw/transactions.csv
      - src/data/process_data.py
    outs:
      - data/processed/clean_transactions.csv

  split_data:
    cmd: python3 src/data/split_data.py
    deps:
      - data/processed/clean_transactions.csv
      - src/data/split_data.py
    outs:
      - data/processed/train.csv
      - data/processed/test.csv

  train:
    cmd: python3 src/models/train.py
    deps:
      - data/processed/train.csv
      - src/models/train.py
    params:
      - n_estimators
    outs:
      - models/model.pkl
    metrics:
      - metrics.json:
          cache: false

Important: Do not put metrics.json under outs:. The lab specifically requires it to be declared as a metric with cache: false.

Step 4: Save dvc.yaml and add params.yaml if it doesn't exist.

Verify the file:

cat dvc.yaml
cat > params.yaml <<EOF
n_estimators: 100
EOF

Step 5: Reproduce the pipeline

Run:

dvc repro

This regenerates:

models/model.pkl
metrics.json
dvc.lock

Step 6: Verify the metric

Run:

dvc metrics show

Expected output will look similar to:

Path accuracy f1_score
metrics.json 1.0 1.0

The exact values will vary.

Step 7: Verify the metric file

cat metrics.json

Example:

{
"accuracy": 1.0,
"f1_score": 1.0
}

Step 8: Verify dvc.lock

(Optional)

cat dvc.lock

You should see metrics.json recorded under the train stage.

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

What is metrics.json?

After training the model, the Python script creates a file called:

metrics.json

It contains information about how well the model performed.

For example:

{
"accuracy": 1.0,
"f1_score": 1.0
}

These numbers help you evaluate the model.

Why doesn't DVC recognize it automatically?

DVC only knows about files that are declared in dvc.yaml.

Currently, DVC knows about:

input files (deps)
output files (outs)
parameters (params)

It doesn't know that metrics.json contains evaluation metrics.

Why use metrics: instead of outs:?

Regular outputs:

outs:

models/model.pkl

are treated as artifacts (files produced by the pipeline).

Metrics are different—they are values you want to compare between experiments.

So we use:

metrics:

metrics.json: cache: false

This tells DVC:

metrics.json contains evaluation metrics.
Keep it in Git (cache: false) instead of storing it in the DVC cache.
Allow commands like dvc metrics show and dvc metrics diff to read it.

Why cache: false?

Normally, DVC stores outputs in its cache.

For metrics, we want the JSON file to stay in the Git repository because:

it's small,
it's easy to compare between commits,
Git can track its history.

That's why the lab requires:

cache: false

What does dvc metrics show do?

After running:

dvc repro

you can execute:

dvc metrics show

Instead of opening metrics.json manually, DVC displays the important values in a table, for example:

Path accuracy f1_score
metrics.json 1.0 1.0

What is dvc metrics diff?

As you experiment with different model parameters (such as n_estimators), the metrics may change.

Running:

dvc metrics diff

compares the metric values across Git commits, making it easy to see whether the new model performed better or worse.

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 15: Parameterize a DVC Pipeline

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

Lab Information

The xFusionCorp Industries ML team manages model hyperparameters using params.yaml, enabling experiments to be conducted without altering the code. In the fraud-detection project, the train stage retrieves the n_estimators parameter from params.yaml, but this parameter is not declared to DVC, which means that changing its value does not initiate retraining. Integrate the parameter into the pipeline and illustrate the concept of parameter-driven reproducibility.

A project exists at /root/code/fraud-detection/ with a three-stage DVC pipeline (process_data, split_data, train) and a params.yaml declaring n_estimators: 100. src/models/train.py already reads n_estimators from params.yaml. Do not modify the Python files.

The train stage in dvc.yaml has no params: section, so DVC does not track n_estimators — changing it would not re-run the stage. Add a params: entry to the train stage that lists n_estimators (edit dvc.yaml, or use dvc stage add --force … -p n_estimators …).

Run the full pipeline with dvc repro.

Demonstrate parameter-driven retraining: change n_estimators to a different value (for example 200) and run dvc repro again. Only the train stage should re-execute, the new value must be recorded in dvc.lock, and models/model.pkl must be regenerated.

dvc params diff reports changes to the tracked parameter values across Git commits, which is useful when comparing experiments.

Lab Solutions

✅ Part 1: Lab Step-by-Step Guidelines

Step 1: Move into the repository

cd /root/code/fraud-detection

Step 2: Inspect the current pipeline

Open dvc.yaml:

cat dvc.yaml

Locate the train stage.

It will look similar to:

stages:
  process_data:
    cmd: python3 src/data/process_data.py
    deps:
      - data/raw/transactions.csv
      - src/data/process_data.py
    outs:
      - data/processed/clean_transactions.csv

  split_data:
    cmd: python3 src/data/split_data.py
    deps:
      - data/processed/clean_transactions.csv
      - src/data/split_data.py
    outs:
      - data/processed/train.csv
      - data/processed/test.csv

  train:
    cmd: python3 src/models/train.py
    deps:
      - data/processed/train.csv
      - src/models/train.py
    outs:
      - models/model.pkl

Step 3: Verify params.yaml

cat params.yaml

Expected:

n_estimators: 100

Step 4: Add the parameter to the train stage

Edit dvc.yaml:

vi dvc.yaml

Add the highlighted section:

train:
  cmd: python3 src/models/train.py

  deps:
    - data/processed/train.csv
    - src/models/train.py

  params:
    - n_estimators

  outs:
    - models/model.pkl

Save the file.

Step 5: Run the pipeline

Execute:

dvc repro

Expected:

root@controlplane fraud-detection on  main ➜  dvc repro
Running stage 'process_data':                                                  
> python3 src/data/process_data.py
Processed 15 rows
Generating lock file 'dvc.lock'                                                
Updating lock file 'dvc.lock'

Running stage 'split_data':                                                    
> python3 src/data/split_data.py
Train: 12 rows, Test: 3 rows
Updating lock file 'dvc.lock'                                                  

Running stage 'train':                                                         
> python3 src/models/train.py
Trained RandomForestClassifier with n_estimators=100
Updating lock file 'dvc.lock'                                                  

To track the changes with git, run:

        git add data/processed/.gitignore dvc.lock models/.gitignore

To enable auto staging, run:

        dvc config core.autostage true
Use `dvc push` to send your updates to remote storage.

Step 6: Verify dvc.lock

Search for the parameter:

grep -A5 params dvc.lock

You should see something like:

root@controlplane fraud-detection on  main [!?] ➜  grep -A5 params dvc.lock
    params:
      params.yaml:
        n_estimators: 100
    outs:
    - path: models/model.pkl
      hash: md5
      md5: ba2187225d8642cbbcd4b127310ced91

This confirms DVC is now tracking the parameter.

Step 7: Change the parameter

Edit:

vi params.yaml

Change:

n_estimators: 100

n_estimators: 200

Save the file.

Step 8: Run the pipeline again

dvc repro

Expected:

root@controlplane fraud-detection on  main [!?] ➜  dvc repro
Stage 'process_data' didn't change, skipping                                   
Stage 'split_data' didn't change, skipping                                     
Running stage 'train':                                                         
> python3 src/models/train.py
Trained RandomForestClassifier with n_estimators=200
Updating lock file 'dvc.lock'                                                  

To track the changes with git, run:

        git add dvc.lock

To enable auto staging, run:

        dvc config core.autostage true
Use `dvc push` to send your updates to remote storage.

Step 9: Verify dvc.lock

grep -A5 params dvc.lock

Expected:

    params:
      params.yaml:
        n_estimators: 200
    outs:
    - path: models/model.pkl
      hash: md5
      md5: c74b4c9de3ba10fc6f8c3789964ec187

Step 11: View parameter differences

Run:

dvc params diff

Expected:

root@controlplane fraud-detection on  main [!?] ➜  dvc params diff
Path         Param         HEAD    workspace
params.yaml  n_estimators  100     200

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

What is params.yaml?

Instead of hardcoding values like:

n_estimators = 100

the project stores them in a separate file:

n_estimators: 100

The training script reads this value automatically.

This makes it easy to try different settings without changing the Python code.

Why isn't changing params.yaml enough?

Even though train.py reads params.yaml, DVC doesn't automatically know that the train stage depends on it.

If the params: section is missing from dvc.yaml, DVC thinks:

"Nothing important changed."

So running:

dvc repro

may skip the training stage.

What does the params: section do?

Adding:

params:

n_estimators

tells DVC:

"The train stage depends on the value of n_estimators."

Now, whenever n_estimators changes, DVC knows the model needs to be retrained.

What happens after changing the parameter?

Initially:

n_estimators: 100

After editing:

n_estimators: 200

When you run:

dvc repro

DVC compares the tracked parameter values and notices that n_estimators has changed.

Since only the training configuration changed:

✅ train runs again.
✅ process_data is skipped.
✅ split_data is skipped.

This saves time by only rerunning the stage that is affected.

What is dvc.lock?

After each successful run, DVC records the parameter value used.

Example:

params:
params.yaml:
n_estimators: 200

This allows anyone to reproduce the exact experiment later using the same parameter values.

What does dvc params diff do?

The command:

dvc params diff

shows how parameter values changed between Git commits.

For example:

Path Param Old New
params.yaml n_estimators 100 200

This is useful for comparing different experiments and understanding what changed between model versions.

DEV Community: Thu Kha Kyawe

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

Credits

• All labs are from: KodeKloud

• I sincerely appreciate your provision of these valuable resources.

5.Manage Secrets in Kubernetes

Lab Information

Lab Solutions

Step 1: Check the Secret Key File

Step 2: Create the Kubernetes Secret

Step 3: Verify the Secret was Created

Step 4: Create the Pod Configuration

Step 5: Deploy the Pod

Step 6: Verify the Pod is Running

Step 7: Verify the Secret is Mounted Correctly

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

Lab Information

Lab Solutions

Step 2: Apply Configuration

Step 3: Verify PersistentVolume and Claim

Step 4: Verify Pod

Step 5: Verify Service

Step 6: 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.

3.Init Containers in Kubernetes

Lab Information

Lab Solutions

Step 1: Create the Deployment YAML File

Step 2: Apply the Deployment

Step 3: Verify the Deployment

Step 4: Check the Pod Status

Step 5: Verify Init Container Execution

Step 6: Verify Main Container Operation

Step 7: Detailed Verification

Step 8: Continuous Monitoring

Create yaml file by using `vi` commands