Scaling a Deployment in Kubernetes is very simple.
You can do it using a command or using YAML, below examle show how we can do it via command.✔ --replicas=3 updates the Deployment
✔ Deployment updates the ReplicaSet
✔ ReplicaSet creates Pods
✔ Final result = 3 Pods running
✔ Kubernetes service will load-balance traffic across all 3 Pods.
Even though the minikube service nginx-web --url command gives you a single IP address and port (http://192.168.49.2:31404), the Kubernetes is responsible for distributing incoming traffic across your three running Pods.
The magic is done by the Kubernetes Service itself, specifically by the kube-proxy component running on the Node.
1. The Service IP and Port
The external access point (
http://192.168.49.2:31404) points to thenginx-webService, which has the type NodePort.The Service acts as a stable, single entry point for all three of your Nginx Pods.
2. Internal Load Balancing
When a request hits the service on port $31404$, the
kube-proxycomponent intercepts the traffic.kube-proxyuses a load balancing algorithm (usually Round Robin) to forward the traffic to one of the available, ready Pods in the Deployment:nginx-web-b9c74675f-2gwnvnginx-web-b9c74675f-sclncnginx-web-b9c74675f-vtvt5
This process happens automatically and is transparent to the user and the Pods. This provides high availability and scalability for your Nginx application.
nginx-web, has a desired state of 3 replicas. So if you delete one Pod Kubernets will automatically create pod.✅ Yes, Kubernetes Automatically Recreates It
When you create an application using a Deployment (like your nginx-web deployment), you are telling Kubernetes the desired state—in your case, three running replicas of the Nginx Pod
The Deployment Controller manages an underlying ReplicaSet.
The ReplicaSet Controller constantly monitors the cluster and compares the current state (how many Pods are running) with the desired state (the number of replicas defined in the Deployment, which is 3).
If you manually delete a Pod, the ReplicaSet immediately notices the current count drop to 2 (or less).
The ReplicaSet controller takes action to match the desired state by automatically creating a new replacement Pod.
The replacement Pod will have a new, unique name and will be scheduled onto a Node to maintain the guaranteed number of application instances.
Step 1: Current State (3 Pods Running)
Step 3: Kubernetes Recreates the Pod
If you immediately run minikube kubectl -- get pods again, you will quickly see a new Pod being created to replace the one you deleted:
you cannot directly stop and restart a Pod in the same way you would stop and restart a traditional server or a Docker container. 🚫
A Kubernetes Pod is designed to be ephemeral (temporary) and its lifecycle is managed entirely by higher-level controllers like Deployments or ReplicaSets.
🛑 Why You Can't Stop/Start a Pod.
1. Pods Are Designed to Be Disposable
When a Pod fails, finishes its job, or is manually deleted, Kubernetes doesn't try to reuse it. Instead, the controlling resource (the ReplicaSet) notices the Pod's death and creates a brand new replacement Pod to maintain the desired application count.
2. No "Stop" State for a Pod
There is no "stop" command in the Kubernetes API for a running Pod. The closest actions are:
Deletion: You can terminate it using
kubectl delete pod <name>.Failure: The container inside the Pod can fail, causing the Pod's status to change (e.g., to
ErrororCrashLoopBackOff).
3. The Controller Manages the State
If you try to delete a Pod that belongs to a Deployment (like your nginx-web), the Deployment's controller immediately sees that the current number of running Pods is less than the desired state (e.g., 3), and it automatically spins up a new Pod to take its place. This is the self-healing feature of Kubernetes.
No comments:
Post a Comment