AshiqPradeep.com

Terraformer Magic: Convert Your AWS Setup into Terraform Code in Minutes

Pradeep Kudukkil — Fri, 06 Jun 2025 13:36:57 GMT

Manually created infrastructure? No problem. With Terraformer, you can generate Terraform code for existing AWS resources in just a few commands. Let’s see how to set it up on an Amazon Linux EC2 instance.

Install Terraform

sudo yum install unzip -y
wget https://releases.hashicorp.com/terraform/1.8.4/terraform_1.8.4_linux_amd64.zip
unzip terraform_1.8.4_linux_amd64.zip
sudo mv terraform /usr/local/bin/
terraform version

Install Terraformer

wget https://github.com/GoogleCloudPlatform/terraformer/releases/download/0.8.24/terraformer-all-linux-amd64 -O terraformer
chmod +x terraformer
sudo mv terraformer /usr/local/bin/

Import EC2 Instances with One Command

terraformer import aws --resources=ec2_instance --regions=us-east-1

This pulls all EC2 instances from us-east-1 and generates Terraform files for you.

Output Structure

generated/
└── aws/
    └── ec2_instance/
        ├── main.tf
        ├── outputs.tf
        └── terraform.tfstate

Consolidate All Resources into a Single Terraform Project

By default, Terraformer creates separate folders and state files per resource type. To manage everything cleanly under one project, follow these steps:

Make a new folder for your Terraform project and Move All Terraform Files

mkdir terraform
cd terraform
cp ../generated/aws/*/*.tf .
terraform init

Re-import Resources into the New Project

terraform import . 

Repeat for each resource using the correct identifiers.

Final Result

All resources are now in a single terraform folder with one terraform.tfstate file — making it easier to manage, version, and collaborate with your team.

Modern CI with Podman: Build & Push Images to Docker Hub via GitHub Actions

Pradeep Kudukkil — Fri, 04 Apr 2025 04:34:24 GMT

Use Podman, a lightweight and secure Docker alternative, to build and push images in GitHub Actions directly to Docker Hub.

GitHub Actions Workflow

Create .github/workflows/podman-ci.yml:

name: Build & Push Podman Image

on:
  push:
    branches: [ main ]

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install Podman
        run: sudo apt update && sudo apt install -y podman

      - name: Login to Docker Hub
        run: |
          echo "${{ secrets.DOCKER_PASSWORD }}" | podman login -u "${{ secrets.DOCKER_USERNAME }}" --password-stdin docker.io

      - name: Build & Push Image
        run: |
          podman build -t docker.io/yourdockerhubusername/podman-app:latest .
          podman push docker.io/yourdockerhubusername/podman-app:latest

GitHub Secrets Required

Set these in your repo:

DOCKER_USERNAME
DOCKER_PASSWORD

Dockerfile

FROM nginx:alpine
COPY webcontent/ /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Sample index.html

Place this in webcontent/index.html



Podman App

  Hello from Podman! 🚀

Why Podman?

No Daemon Needed
Secure & Rootless
Docker-Compatible CLI
Lightweight & Fast

Once pushed, your GitHub Action will build the image and push it to Docker Hub.

How to Use Docker Hub with Podman – A Docker Alternative

Pradeep Kudukkil — Fri, 04 Apr 2025 03:39:14 GMT

If you're exploring a Docker alternative, Podman is a powerful and secure choice. It’s a daemonless container engine that fully supports Docker image formats and registries like Docker Hub.

This guide shows how to build an image with Podman, tag it properly, and push/pull it from Docker Hub.

Install Podman on Ubuntu

Run the following commands:

sudo apt update
sudo apt -y install podman

Check the version to confirm installation:

podman --version

Sample Dockerfile

FROM alpine:latest

# Install bash (optional but useful)
RUN apk add --no-cache bash

# Keep the container running with an infinite loop
CMD ["bash", "-c", "while true; do echo 'Podman is running...'; sleep 5; done"]

Step 1: Login to Docker Hub

podman login docker.io

Enter your Docker Hub username and password/token when prompted.

Step 2: Build the Image Using Podman

podman build -t myimage:latest .

Step 3: Tag the Image for Docker Hub

podman tag myimage docker.io/yourdockerhubusername/myimage:latest

Step 4: Push the Image to Docker Hub

podman push docker.io/yourdockerhubusername/myimage:latest

Step 5: Pull the Image from Docker Hub

podman pull docker.io/yourdockerhubusername/myimage:latest

Run it:

podman run docker.io/yourdockerhubusername/myimage:latest

Create and Host Your Own Helm Charts with GitHub Pages!

Pradeep Kudukkil — Wed, 02 Apr 2025 06:00:41 GMT

Helm is a powerful package manager for Kubernetes, making it easy to deploy applications. In this guide, we'll show you how to create a custom Helm repository, host it on GitHub Pages, and make it publicly accessible.

What You Need

Helm
Git
A GitHub account
A Kubernetes cluster (MicroK8s, Minikube, or cloud-based)

Step 1: Create a Helm Chart

Run the following command to create a Helm chart:

helm create my-first-project

This creates a my-first-project directory with a sample Helm chart. You can modify the default configurations, add new templates, or update the values.yaml file to fit your application's needs.

Step 2: Package the Helm Chart

To prepare your chart for publishing, package it:

helm package my-first-project

This creates a .tgz file, e.g., my-first-project-0.1.0.tgz.

Step 3: Create a Helm Repository Index

Generate an index file for your repository:

helm repo index .

This creates index.yaml, which Helm uses to find charts.

Step 4: Set Up a GitHub Repository

Go to GitHub and create a public repository (e.g., helm).

Clone it to your local machine:
git clone https://github.com/YOUR_GITHUB_USERNAME/helm.git
cd helm

Move your chart package and index file into the repository:
cp ../my-first-project-0.1.0.tgz .
cp ../index.yaml .

Commit and push the files:
git add .
git commit -m "Initial commit"
git push origin main

Step 5: Enable GitHub Pages

Open your GitHub repository.
Click Settings > Pages.
Under Source, select main or gh-pages.
Under Branch, select the branch where your files are stored (/root or /docs).
Save the settings.
Copy your repository URL (e.g., https://YOUR_GITHUB_USERNAME.github.io/helm/).

Step 6: Add the Helm Repository

Tell Helm to use your new repository:
helm repo add my-repo https://YOUR_GITHUB_USERNAME.github.io/helm/

Check if it's added:
helm repo list

Step 7: Install the Helm Chart

Deploy your chart from your custom repository:
helm install myrelease my-repo/my-first-project

Conclusion

That's it! You've successfully set up a public Helm repository using GitHub Pages. Now, anyone can use your charts with just a URL. Happy Helm charting!

Horizontal Pod Autoscaler (HPA): Scaling Workloads in Kubernetes

Pradeep Kudukkil — Sun, 30 Mar 2025 16:44:23 GMT

Kubernetes provides a built-in Horizontal Pod Autoscaler (HPA) to manage workload scaling dynamically. HPA adjusts the number of pods based on CPU, memory, or custom metrics, optimizing performance and cost.

How HPA Works

Monitors resource utilization via the Kubernetes Metrics Server.
Adjusts pod counts based on predefined thresholds.
Continuously evaluates demand and scales accordingly.

Setting Up HPA

Install Metrics Server

HPA requires the Metrics Server:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Deploy a Sample Application

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: alpine
        command: ["/bin/sh"]
        args: ["-c", "apk add --no-cache stress-ng && stress-ng --cpu 1 --timeout 600s"]
        resources:
          requests:
            cpu: "200m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

Configure HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Apply the configuration:
kubectl apply -f my-app-hpa.yaml

Monitoring HPA
Watch HPA activity:
kubectl get hpa --watch

Monitor pod scaling:
kubectl get pods -w

Deploy Applications with ArgoCD on a Kubernetes Cluster | GitOps in Kubernetes

Pradeep Kudukkil — Sun, 30 Mar 2025 07:11:40 GMT

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. In this guide, we will install Argo CD on a Kubernetes cluster, configure it to sync with a Git repository, and deploy applications automatically.

Prerequisites

Ensure you have the following installed on your system:
Kubernetes cluster
kubectl command-line tool
Internet access to download Argo CD

Step 1: Install Argo CD

First, create a namespace for Argo CD:

kubectl create namespace argocd

Then, apply the Argo CD installation manifest:

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Step 2: Install Argo CD CLI

Download and install the Argo CD CLI:

curl -sLO https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x argocd-linux-amd64
sudo mv argocd-linux-amd64 /usr/local/bin/argocd

Step 3: Verify Argo CD Installation

Check if the Argo CD pods are running:

kubectl get pods -n argocd

List the services:

kubectl get svc -n argocd

Step 4: Expose Argo CD Server

Forward the Argo CD server port to access it from your local machine:

kubectl port-forward svc/argocd-server -n argocd 8080:443 --address 0.0.0.0 &

Step 5: Retrieve the Initial Admin Password

Get the initial admin password and decode it:

kubectl get secret argocd-initial-admin-secret -n argocd -o yaml

echo provide-pass-got-from-the-above-command | base64 -d

Step 6: Login to Argo CD

Authenticate with Argo CD using the admin credentials:

argocd login localhost:8080 --username admin --password  --insecure

Step 7: Connect Argo CD to Your Git Repository

Add your Git repository to Argo CD:

argocd repo add https://github.com/pradeep-kudukkil/kubernetes.git \
  --username your-user-name \
  --password

Verify the repository connection:

argocd repo list

Step 8: Create and Deploy an Application

Create an application in Argo CD:

argocd app create my-app \
  --repo https://github.com/pradeep-kudukkil/kubernetes.git \
  --path workload \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace default

Enable automatic synchronization:

argocd app set my-app --sync-policy automated --auto-prune --self-heal

Verify deployment:

kubectl get pods
argocd app get my-app

Step 9: Delete an Application (If Needed)

To remove an application, run:

argocd app delete my-app

Track & Audit AWS CLI Commands with Azure DevOps

Pradeep Kudukkil — Wed, 12 Mar 2025 06:31:59 GMT

Who ran it? Captured automatically in the logs.
Command Status? Success / Failure – Recorded instantly.

This Azure DevOps pipeline dynamically executes AWS CLI commands and logs who triggered the command and its status in an S3-hosted CSV file. With automated logging, you gain full visibility, transparency, and auditability in your cloud operations.

Every run is tracked—no more guessing.

Youtube Link:https://youtu.be/mLIYsHW3qNE

trigger: none

pool:
  vmImage: 'ubuntu-latest'

variables:
  AWS_REGION: 'ap-south-1'
  S3_BUCKET: 'aws-cli-tracker'
  LOG_FILE: 'cli-execution.csv'

parameters:
  - name: awsCliCommand
    displayName: "Enter AWS CLI Command"
    type: string
    default: "aws s3 ls"

steps:
  - task: AWSShellScript@1
    inputs:
      awsCredentials: 'Pradeep-AWS'
      regionName: $(AWS_REGION)
      scriptType: 'inline'
      inlineScript: |
        # Capture execution details
        if [ -n "$(Build.QueuedBy)" ]; then
          EXECUTOR="\"$(Build.QueuedBy)\""  # Using QueuedBy and quoting to handle spaces
        else
          EXECUTOR="\"Unknown\""  # Fallback if no value
        fi

        echo "QueuedBy: $(Build.QueuedBy)"
        
        TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
        CLI_COMMAND="${{ parameters.awsCliCommand }}"
        
        # Run command and capture result
        OUTPUT_FILE="aws_output.txt"
        ERROR_FILE="aws_error.txt"
        $CLI_COMMAND > $OUTPUT_FILE 2> $ERROR_FILE
        if [ $? -eq 0 ]; then
          RESULT="success"
          cat $OUTPUT_FILE
        else
          RESULT="fail"
          cat $ERROR_FILE
        fi

        # Prepare log entry in CSV format
        LOG_ENTRY="$EXECUTOR,$TIMESTAMP,\"$CLI_COMMAND\",$RESULT"

        # Download existing CSV log file from S3 (if exists)
        aws s3 cp s3://$S3_BUCKET/$LOG_FILE $LOG_FILE || touch $LOG_FILE

        # Append new row to the CSV log
        echo "$LOG_ENTRY" >> $LOG_FILE

        # Upload updated CSV back to S3
        aws s3 cp $LOG_FILE s3://$S3_BUCKET/$LOG_FILE
    displayName: 'Run AWS CLI and Upload Logs to S3'

Kubernetes Network Policy: Allow DNS Resolution for Both Internal and External Services, Block All Other Traffic

Pradeep Kudukkil — Sat, 08 Mar 2025 07:36:32 GMT

Allowing DNS resolution for both internal and external services while blocking all other traffic helps secure your Kubernetes environment. This setup ensures that pods can resolve domain names like google.com for external services and kubernetes.default.svc.cluster.local for internal services, but no HTTP, HTTPS, or other non-DNS traffic is allowed.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-only
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
    - ports:
      - protocol: UDP
        port: 53
      - protocol: TCP
        port: 53

Explanation:
podSelector: Selects all pods in the default namespace.
policyTypes: Specifies that the policy applies only to egress traffic.
egress: Allows traffic to port 53 (DNS) for both UDP and TCP protocols. This ensures DNS resolution for both internal and external domains.

Testing the Policy:

Create a test pod:
kubectl run dns-tester --image=busybox --restart=Never -- sleep 3600

Access the dns-tester pod and test external DNS resolution (e.g., google.com):
kubectl exec -it dns-tester -- sh
nslookup google.com

DNS resolution for external domains (e.g., google.com) should succeed 

Test HTTP/HTTPS (Should Fail):
wget http://google.com

Accessing websites over HTTP or HTTPS should fail, as only DNS resolution is allowed, and all other traffic is blocked.

Deleting Pod and Network Policy:

kubectl delete pod dns-tester
kubectl delete networkpolicy allow-dns-only -n default

Kubernetes Network Policy: Control Outbound Traffic to Specific APIs

Pradeep Kudukkil — Sat, 08 Mar 2025 07:13:16 GMT

Real-World Use Case: Controlling outbound traffic from your client pods by limiting their connections to specific APIs ensures that your pods are not sending data to unauthorized or malicious destinations.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-external-api
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: client
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: Nginx-pod-ip/32  # IP of your Nginx pod - first complete below pods creation command
    ports:
    - protocol: TCP
      port: 80

Testing the Policy:

Deploy a client pod:
kubectl run client --image=busybox --restart=Never --labels=app=client -- sleep 3600

Deploy a Nginx pod:
kubectl run Nginx-pod --image=nginx 

Access the client pod and try to connect to the Nginx pod:
kubectl exec -it client -- sh
wget -qO- http://Nginx-pod-ip

Expected Result: The request should succeed, and any other outbound connections should fail.

Deleting Pods and Network Policy:

kubectl delete pod client
kubectl delete pod Nginx-pod
kubectl delete networkpolicy allow-external-api -n default

Kubernetes Network Policy Allow Only HTTP Traffic to Your Web Application

Pradeep Kudukkil — Sat, 08 Mar 2025 07:02:58 GMT

Real-World Use Case: Restricting inbound traffic to your web application by allowing only HTTP (port 80) ensures that no other ports are exposed, reducing the attack surface for potential malicious activities.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-http
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}
    ports:
    - protocol: TCP
      port: 80

Testing the Policy:

Deploy a web pod:
kubectl run web --image=nginx --labels=app=web --port=80 --restart=Never

Deploy a test client pod:
kubectl run test-client --image=busybox --restart=Never -- sleep 3600

Access the test-client pod and try to access the web pod:
kubectl exec -it test-client -- sh
wget -qO- http://web-ip

Expected Result: The request should succeed because port 80 is open.

Deleting Pods and Network Policy:

kubectl delete pod web
kubectl delete pod test-client
kubectl delete networkpolicy allow-http -n default

Kubernetes Network Policy: Limit Traffic Between Frontend and Backend Pods

Pradeep Kudukkil — Sat, 08 Mar 2025 06:54:23 GMT

Real-World Use Case: Restricting traffic to backend services by only allowing communication from the frontend namespace helps ensure a secure separation of duties, where only trusted services can interact with sensitive backend applications.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend

Testing the Policy:

Create pods in both namespaces:

kubectl create ns frontend
kubectl create ns backend
kubectl label namespaces frontend name=frontend
kubectl run backend-pod --image=busybox --restart=Never --labels=app=backend -n backend -- sleep 3600
kubectl run frontend-pod --image=busybox --restart=Never -n frontend -- sleep 3600

Access the frontend pod and try to connect to the backend pod

kubectl exec -n frontend -it frontend-pod -- sh
ping backend-ip

Expected Result: The ping should succeed since the frontend pod is allowed to connect to the backend pod.

Deleting Pods, Namespaces, and Network Policy:

kubectl delete pod frontend-pod -n frontend
kubectl delete pod backend-pod -n backend
kubectl delete ns frontend
kubectl delete ns backend
kubectl delete networkpolicy allow-frontend -n backend

Kubernetes Network Policy: Deny All Traffic for Better Cluster Isolation

Pradeep Kudukkil — Sat, 08 Mar 2025 06:46:03 GMT

Real-World Use Case: Implementing a deny-all traffic policy ensures that no pod can communicate with others unless explicitly allowed, offering maximum isolation and enhanced security in your Kubernetes cluster.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Testing the Policy:

Create two pods:

kubectl run pod-a --image=busybox --restart=Never -- sleep 3600
kubectl run pod-b --image=busybox --restart=Never -- sleep 3600

Access pod-a and try to communicate with pod-b:

kubectl exec -it pod-a -- sh
ping pod-b-ip

Expected Result: The ping should fail due to the deny-all policy blocking all traffic.

Deleting Pods and Network Policy:

kubectl delete pod pod-a
kubectl delete pod pod-b
kubectl delete networkpolicy deny-all -n default

How to Install MicroK8s on Ubuntu

Pradeep Kudukkil — Thu, 06 Mar 2025 10:50:35 GMT

MicroK8s is a lightweight Kubernetes distribution designed for developers and small-scale deployments. This guide will walk you through the steps to install MicroK8s on Ubuntu.

Step 1: Update System Packages

Before installing MicroK8s, update your system to ensure all packages are up to date:

sudo apt update && sudo apt upgrade -y

Step 2: Install MicroK8s

Install MicroK8s using Snap:

sudo snap install microk8s --classic

Step 3: Add User to MicroK8s Group

To avoid using sudo for MicroK8s commands, add your user to the microk8s group:

sudo usermod -aG microk8s $USER
newgrp microk8s

Step 4: Verify Installation

Check the status of MicroK8s:

microk8s status --wait-ready

Step 5: Enable Essential Add-ons

MicroK8s provides various add-ons that enhance its functionality. Enable some essential ones:

microk8s enable dns storage dashboard

Step 6: Access Kubernetes with MicroK8s

By default, MicroK8s uses its own version of kubectl. You can run:

microk8s kubectl get nodes

If you prefer using kubectl directly, create an alias:

alias kubectl='microk8s kubectl'

To make this alias persistent, add it to your shell configuration file:

echo "alias kubectl='microk8s kubectl'" >> ~/.bashrc
source ~/.bashrc

Step 7: Check Cluster Information

To verify cluster details, run:

microk8s kubectl cluster-info

Optional: Enable MicroK8s on System Startup

If you want MicroK8s to start automatically after a reboot, enable it:

sudo snap enable microk8s

Uninstalling MicroK8s

If you need to remove MicroK8s from your system, use:

sudo snap remove microk8s

Enhance Your Kubernetes Security with AppArmor: Deny Write Access to Sensitive Files

Pradeep Kudukkil — Thu, 06 Mar 2025 05:36:20 GMT

What is AppArmor?
AppArmor is a security module that restricts what applications can do on a system by enforcing security policies. In Kubernetes, it helps control container access to specific system files and directories, adding an extra layer of security.

Why Use AppArmor?
Even though containers are isolated, they might still access sensitive system files or directories. AppArmor lets you restrict access to prevent potential security risks by enforcing stricter boundaries for your containers.

Prevent Write Access to Sensitive Areas
To prevent containers from modifying sensitive files, such as those in the /etc/ directory, you can define an AppArmor profile that blocks write access.

Create the AppArmor Profile
Create a profile that denies write access to /etc/**:

apparmor_parser -q <

profile block-etc-write flags=(attach_disconnected) { 
  #include 

  file,

  # Deny all file writes.
  deny /etc/** w, 
}
EOF

In this profile:
deny /etc/** w: This rule ensures that no files within the /etc/ directory can be written to by the container.

Apply the Profile in Kubernetes
Once the profile is created, apply it to your Kubernetes deployment using annotations. Here's the configuration:

apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
  annotations:
    container.apparmor.security.beta.kubernetes.io/hello: localhost/block-etc-write
spec:
  containers:
  - name: hello
    image: busybox
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

The annotation container.apparmor.security.beta.kubernetes.io/hello: localhost/block-etc-write applies the block-etc-write AppArmor profile to the container.

The container runs a simple busybox container with a shell command that prints "Hello AppArmor!" and then sleeps for an hour.

Apply the Pod Configuration
Deploy the updated configuration:

kubectl apply -f hello-armor.yaml

Why It Matters

Blocking write access to critical directories, like /etc/, ensures:
Protection from accidental or malicious changes to system files.
Increased security by reducing the risk of unauthorized modifications.

Conclusion
With AppArmor, you can easily restrict container access to sensitive areas, like /etc/, adding another layer of protection to your Kubernetes environment.

Simple Kubernetes CronJob for System Monitoring

Pradeep Kudukkil — Sat, 09 Nov 2024 15:00:24 GMT

This example demonstrates a straightforward Kubernetes CronJob that periodically runs top to display basic system information.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: basic-system-monitor
spec:
  schedule: "*/10 * * * *"  # Runs every 10 minutes
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: system-monitor
              image: busybox  # Lightweight image with basic utilities
              args:
                - /bin/sh
                - -c
                - "top -bn1"
          restartPolicy: OnFailure

schedule: Runs every 10 minutes (*/10 * * * *).
image: Uses busybox, which includes essential utilities like top.
args: Runs the top -bn1 command to output basic system information once.

Steps to Deploy and Verify

Deploy the CronJob: Apply the YAML configuration:
kubectl apply -f system-health-check.yaml

Verify Execution:
kubectl get cronjob
kubectl get jobs --watch

Check Logs:
kubectl logs pod-name

Remove the CronJob after testing:
kubectl delete cronjob system-health-check