Project 5: Kubernetes Production Deployment

The diagram below displays the cluster architecture details of a single-node Minikube deployment, mapping how client tools interface with API managers and route incoming requests.

STEP 1

Install the Kubectl Client Command Line Utility

Download and deploy the Kubernetes command-line interface executable to query host cluster managers.

$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

This command downloads the latest stable kubectl client binary from the official Google Kubernetes storage mirrors.

$ sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl && kubectl version --client

This command installs the kubectl binary globally with execute permissions and prints the client version to verify installation.

STEP 2

Install and Initialize a Local Minikube Single-Node Cluster

Verify CPU nested hardware virtualization support, download Minikube, and start the local Kubernetes cluster using the Docker driver.

$ egrep -c '(vmx|svm)' /proc/cpuinfo

This command checks the processor attributes for hardware virtualization (VT-x or AMD-V) support inside the guest VM kernel. If it returns 0, you must enable nested hardware virtualization in your host settings before starting Minikube.

$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

This command downloads the latest stable Minikube binary, which enables running a local single-node cluster.

$ sudo install minikube-linux-amd64 /usr/local/bin/minikube

This command installs the Minikube manager binary globally to the system execution path, making the "minikube" CLI command available.

$ sudo systemctl start docker && minikube start --driver=docker

This command starts the local Docker service daemon to ensure the container socket is active, then starts the single-node Minikube cluster using the Docker container driver.

$ kubectl get nodes

This command queries the cluster API server for a status list of all active nodes, verifying that the node is running.

STEP 3

Install the Helm Package Manager

$ curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null

This command downloads and imports Helm's GPG keys, enabling apt to verify the authenticity of downloaded packages.

$ echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list

This command writes Helm's repository listing into the apt source configuration directories, making Helm packages available.

$ sudo apt update && sudo apt install helm -y && helm version

This command updates repository indexes, installs the Helm package manager, and prints the version to verify installation.

STEP 4

Deploy Nginx Web Servers and Expose Network Routes

Apply manifest files to run replication controllers and configure service ports to route web traffic.

$ kubectl apply -f deployment.yml && kubectl apply -f service.yml

This command applies configuration templates to provision Nginx replicas and configure a NodePort service to route traffic.

$ kubectl get pods -l app=nginx && kubectl get svc nginx-service

This command queries the API server to verify that the Nginx pods are running and lists the service IP address.

$ minikube service nginx-service --url

This command starts a tunnel linking the exposed NodePort to a host system URL, allowing you to access the web server from your browser.

STEP 5

Execute a Rolling Upgrade without Downtime

Update container image versions and track status logs as the cluster performs a rolling update.

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.25.1 --record

This command updates the deployment's container image version to 1.25.1 and records the change in the rollout history.

$ kubectl rollout status deployment/nginx-deployment

This command monitors the update progress in real-time, confirming that new pods start successfully before old ones are terminated.

The diagram below outlines the rolling update sequence. The cluster replaces pods one-by-one, maintaining service availability throughout the upgrade.

To deploy the application to your Kubernetes cluster, we will write a deployment manifest and a service manifest. Below is a step-by-step breakdown of how these manifest configurations are constructed, followed by the final combined files.

Step-by-Step Manifest Construction

Step 1

Define the Deployment Metadata and Replica Selector

Setup the manifest API headers and declare the labels used to discover the application pods.

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 2 selector: matchLabels: app: nginx

This block targets the apps/v1 schema, sets the workload kind to Deployment, defines the resource name, requests 2 active pod replicas, and configures selectors to manage pods labeled app: nginx.

Step 2

Define Pod Template Specs and Resource Limits

Configure pod container images, ports, and execution safety limits.

template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.24 ports: - containerPort: 80 resources: limits: memory: "128Mi" cpu: "200m"

This configures the Pod blueprint, specifies using the nginx:1.24 container image, exposes container port 80, and enforces limits (128 Megabytes RAM, 0.2 CPU cores) to prevent resource hogging.

Step 3

Write the NodePort Service Manifest

Map cluster network routes, linking external node ports to the container ports.

apiVersion: v1 kind: Service metadata: name: nginx-service spec: type: NodePort selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 30080

This service definition routes external traffic hitting host port 30080 to container port 80 using the label selector to balance loads across matching pods.

Combined Complete Manifest Files

Create these files in your project directory (~/Projects) and apply them to the cluster:

1. deployment.yml

2. service.yml

Verify that the following configurations and outputs exist inside your cluster environment.

Created Files / Templates

/home/devops/Projects/deployment.yml - Kubernetes replication set schema file.
/home/devops/Projects/service.yml - NodePort networking service definition file.

Verification Artifacts / Execution Proof

Output of kubectl get nodes confirming the Minikube node status is Ready.
Output of kubectl rollout history deployment/nginx-deployment showing version revisions.
Successful HTTP request response from host browser accessing http://[Minikube-IP]:30080.

Architectural Intent & Operational Impact

Why We Did This

Kubernetes abstracts infrastructure dependencies, deploying services across available nodes automatically.
Declarative manifest files record your infrastructure configurations in code, enabling reproducible cluster states.
NodePort services expose containerized applications to external clients by mapping traffic across cluster nodes.

What This Accomplishes

Establishes an isolated container orchestration environment to schedule, scale, and manage workloads locally.
Maintains service availability during upgrades by rolling out image versions sequentially.
Enables external access to your cluster application via NodePort mappings.

Kubernetes Cluster & Service Deployments