Scaling Applications: Manually Adjusting Kubernetes Workloads with kubectl

Previously in this course, we explored deployments-declarative-updates-for-kubernetes-applications, where we learned how to manage application versions and perform rolling updates. In this lesson, we add the ability to dynamically adjust the capacity of those deployments to meet real-world traffic requirements.

The Concept of Scaling

In a production environment, traffic is rarely static. You might experience a "flash sale," a marketing push, or simply a predictable daily peak. In the old days of virtual machines, "scaling" meant spinning up a new server, installing dependencies, and configuring load balancers—a process that took minutes or hours.

In Kubernetes, Scaling is the process of increasing or decreasing the number of Pods running your application. Because we are using deployments-declarative-updates-for-kubernetes-applications, Kubernetes treats the number of replicas as a desired state. When you change that number, the Control Plane immediately reconciles the cluster to match your request.

Worked Example: Scaling a Deployment

We will use the kubectl scale command to adjust the number of running instances of a sample Nginx deployment.

Assuming you have a deployment named nginx-deployment running, follow these steps to manage its load capacity:

1. Check your current status: First, see how many replicas are currently running:

   Bash
   kubectl get deployment nginx-deployment
   

   You should see a READY status showing something like 2/2.

2. Scale up to handle increased load: If you anticipate high traffic, increase the replicas:

   Bash
   kubectl scale deployment nginx-deployment --replicas=5
   

3. Observe the change: Immediately verify that Kubernetes is provisioning the new Pods:

   Bash
   kubectl get pods -l app=nginx
   

   You will see the new Pods transitioning from Pending to ContainerCreating and finally Running.

4. Scale down: Once the traffic subsides, you can save resources by scaling back down:

   Bash
   kubectl scale deployment nginx-deployment --replicas=1
   

Hands-on Exercise

To solidify your understanding of how Kubernetes handles load, perform this exercise in your local cluster:

1. Create a deployment with 3 replicas using a simple Nginx image.
2. Run kubectl get pods -w in one terminal window to watch the status in real-time.
3. In a second terminal, execute kubectl scale deployment <your-deployment-name> --replicas=10.
4. Observe the watch output. Notice how the controller manages the scheduling of multiple new Pods simultaneously.
5. Scale the deployment down to 0 replicas and observe the Pods terminating.

Common Pitfalls

• Forgetting your Replicas: If you manually scale a Deployment using kubectl scale, the change is recorded in the live state of the cluster. However, if you don't update your original YAML manifest file, the next time you run kubectl apply, your manual scaling will be overwritten by the value in your file. Always update your YAML files to match your desired cluster state.
• Assuming Instant Availability: While Kubernetes creates Pods quickly, they may not be "Ready" to receive traffic immediately. If you have readiness-probes-controlling-traffic-flow-in-kubernetes configured, the service will wait until the container passes its health checks before sending traffic to the newly scaled Pods.
• Resource Exhaustion: Scaling up requires available CPU and Memory on your nodes. If you don't have enough cluster capacity, your new Pods will remain in a Pending state. Use kubectl describe pod <pod-name> to debug scheduling issues.

Frequently Asked Questions (FAQ)

Q: Does scaling cause downtime? A: No. Kubernetes performs a rolling scale-up/down. It keeps the existing Pods running until the new ones are ready (when scaling up) or gracefully terminates them (when scaling down).

Q: Can I scale Services? A: No, you scale the Deployments (the pods). The Service object acts as a stable entry point that automatically detects the new Pods via labels-and-selectors and starts routing traffic to them.

Q: Why use kubectl scale instead of just editing the YAML? A: kubectl scale is excellent for emergency, short-term adjustments to handle an unexpected surge in traffic. For permanent changes to your architecture, updating the YAML manifest is considered best practice.

Recap

Scaling is a fundamental operational task in Kubernetes. By leveraging the ReplicaSet controller managed by your Deployment, you can quickly react to changes in demand. Remember that while kubectl scale provides an immediate, imperative fix, keeping your source-of-truth YAML files synchronized is critical for long-term cluster health.

Up next: We will dive into Understanding Service DNS, where we explore how Kubernetes resolves service names internally so your components can talk to each other reliably.