A full-stack web application architecture on Kubernetes consists of distinct tiers, each typically encapsulated in sets of pods. These tiers include front-end web servers, back-end application servers, in-memory data stores like Redis, and persistent databases like MySQL. Seamless communication between these layers is critical for application functionality. The front-end requires connectivity to the back-end, and the back-end must interact with both the caching and database layers.
Establishing reliable connectivity between these tiers presents a challenge due to the ephemeral nature of pods.
Fundamentals of Kubernetes Services A Kubernetes Service is an abstraction that defines a logical set of Pods and a policy by which to access them—typically via a stable virtual IP (ClusterIP), DNS name, and optional load balancing. It decouples pod lifecycle from client access, allowing pods to be added, removed, or restarted without changing how other components reach the service. Without services, pod IP addresses are ephemeral - that means - when a pod dies and is replaced, its IP changes.
Kubernetes Networking Fundamentals Single-Node Networking In a single-node Kubernetes cluster, the node possesses a physical or virtual IP address (e.g., 192.168.1.2) used for administrative access via SSH. In local environments like Minikube, this address refers to the virtual machine (VM) within the hypervisor, distinct from the host machine’s IP.
Unlike Docker, where IP addresses are assigned to individual containers, Kubernetes assigns a unique internal IP address to the Pod. A Pod acts as a logical host for one or more containers.
In a production environment, the ability to update applications without interrupting service is critical. Kubernetes achieves this through the Deployment object, which acts as a high-level manager for Replica Sets and Pods. This article provides a detailed technical explanation of how Kubernetes handles application updates, the strategies it employs to maintain availability, and the mechanisms used to recover from failed deployments.
Understanding the Deployment Architecture To understand rollouts, one must first understand the relationship between three components: the Deployment, the Replica Set, and the Pod.
Deploying a production‑grade web service requires multiple concurrent instances and a controlled upgrade path. Rolling updates let you replace pods incrementally, preserving availability, while the rollback feature restores the previous revision if a new version introduces errors. The pause/resume mechanism lets you stage several changes—such as image upgrades, replica count adjustments, or resource limit modifications—and apply them as a single rollout.
Kubernetes implements these capabilities through the Deployment object, which sits above ReplicaSets in the resource hierarchy.
ReplicaController in Kubernetes Overview The ReplicaController (RC) is a legacy workload API object that maintains a stable set of pod replicas. It continuously monitors the current state and creates or deletes pods to match the desired replica count defined in its spec. RCs are still supported for backward compatibility but are superseded by ReplicaSets and Deployments for most use‑cases. Even if you have single pod you can still use replica controller so that the pod is redeployed if it is crashed.
Kubernetes Hands-On Mini Lab Goal By the end, you’ll know how to:
Create & manage workloads Debug pods Expose services Scale & update apps Work with namespaces & configs Step 0: Setup Start a cluster (example with Minikube) 1 minikube start Verify:
1 2 kubectl cluster-info kubectl get nodes Step 1: Create a Namespace 1 2 kubectl create namespace lab kubectl get namespaces Use it:
1 kubectl config set-context --current --namespace=lab Step 2: Create a Deployment 1 kubectl create deployment nginx --image=nginx Check:
Kubernetes CLI Reference Core Resource Management View Resources
kubectl get – List resources
Basic: kubectl get pods -n default Wide output: kubectl get pods nginxpod -o wide (shows node placement, pod IP) Label selector: kubectl get pods -l app=k8s-web-app Node details: kubectl get pods -o wide reveals the nodes where the pods are running from and ip details for the pods. kubectl describe pod pod-name reveals image used, node details, number of containers deployed, find why a pod launch failed (under events section) and other details Container status: Output like 1/1 or 1/2 indicates running containers / total containers; values like 0/1 signal container failures kubectl describe – Detailed resource inspection
Building a Flask Image for Minikube Write the application 1 2 3 4 5 6 7 8 9 10 11 12 # app.py from flask import Flask import os app = Flask(__name__) @app.route('/') def home(): return f"Running from pod {os.getenv('POD_NAME', 'unknown')}" if __name__ == '__main__': app.run(host='0.0.0.0', port=80) Create the Dockerfile 1 2 3 4 5 6 FROM python:3.9-slim WORKDIR /app COPY app.py . RUN pip install flask EXPOSE 80 CMD ["python", "app.
Kubernetes definition files, commonly referred to as YAML manifests, are the core mechanism for declaring the desired state of your application and its supporting infrastructure within a Kubernetes cluster. They are not scripts or executable code, but rather data files specifying the configuration of Kubernetes objects.
Core Concepts:
Declarative Configuration: Kubernetes operates on a declarative model. You define what you want, not how to achieve it. The Kubernetes control plane continuously works to reconcile the actual state with the desired state defined in these files.
