Scaling and disruption boundaries

Work out what adding a replica changes

Imagine a stateless page taking no shared writes. Two ready replicas can handle requests independently, but putting both on one node still leaves one node failure able to stop both. Horizontal scaling adds replicas; vertical scaling changes resources per replica; node scaling adds machines. Each addresses a different limit.

An illustrative HPA calculation uses desired replicas ≈ ceil(current replicas × current metric / target metric), subject to the controller's readiness, missing-metric, tolerance, rate, and stabilization rules. With two eligible replicas averaging 80% CPU utilization and a 50% target, the simple calculation is ceil(2 × 80 / 50) = 4. Utilization is measured relative to requests, not limits: the same usage can represent a different percentage if the request changes. This is arithmetic, not a promise that four replicas will fix the workload.

Practise manual scaling first

In .local/classroom.yaml, change the web Deployment from one to two replicas. Apply it, wait for its rollout, and inspect Pods with -o wide plus the Service's EndpointSlices. Expect two ready replicas if there is enough room, with two backing addresses; on the single-node kind cluster both will be on the same node. Repeat the request through the Service. The page's body is identical, so a successful response alone cannot tell you which replica answered.

Change the file back to one, apply, and wait. Keeping the desired count in the file avoids a later apply unexpectedly undoing an imperative scale command. Before installing an HPA, decide who owns this count: repeatedly applying a fixed replica value can conflict with an autoscaler.

For a paper disruption exercise, one ready replica plus minAvailable: 1 permits zero voluntary evictions. Two ready replicas plus that minimum can permit one, subject to the actual budget state. A PDB does not manage a Deployment's rolling update strategy and does not prevent a node suddenly failing. Readiness, spare capacity, placement, and data safety must support the availability goal together.

Scaling changes concurrency

Kubernetes can increase replicas without proving the application is safe with more concurrent workers. MicroBank's Accounts publisher and Ledger consumer both interact with shared data and queues. The current lab does not verify concurrent consumer correctness. Review transaction isolation, duplicate delivery, ordering, and schema compatibility before treating more replicas as increased reliable capacity.

A HorizontalPodAutoscaler adjusts a workload's desired scale based on configured metrics. CPU utilization targets depend on CPU requests and a working resource metrics pipeline. A fresh kind cluster may lack Metrics Server. Scaling Pods does not automatically add nodes or replicate PostgreSQL.

Distinguish availability mechanisms

Readiness determines whether a Pod is eligible to receive Service traffic. A PodDisruptionBudget constrains certain voluntary disruptions. Anti-affinity/topology rules influence placement. None alone makes a single-node cluster highly available. A minimum-available budget on a single replica can block a voluntary eviction without creating somewhere else to run it.

A one-control-plane/one-worker kubeadm exercise teaches operations but does not tolerate every control-plane or worker failure. Keep that limitation explicit in your notes.

Try it as an inspection exercise

Read the actual local Deployment requests, limits, replica count, and node capacity. Check whether the metrics API exists before trying kubectl top. Then sketch a bounded HPA for a separate stateless test fixture, defining minimum/maximum replicas and the metric's failure behavior. Do not attach it to MicroBank's transaction workers as an untested shortcut.

Describe what happens during a drain with one replica and a restrictive disruption budget. Use the separate kubeadm operating exercise if you later test it, retaining a recovery path and enough capacity. Do not drain an unrelated cluster.

Checkpoint and revision

Explain why a scaling action could worsen a queue or database problem. Identify the tests needed before scaling MicroBank: duplicate-request behavior, concurrent withdrawals, settlement ordering, and recovery after interrupted processing. Assess resource demand, application correctness, and disruption tolerance separately; evidence for one does not establish the others.

Checkpoint answer: adding API or consumer replicas can increase database connections, lock contention, duplicate-processing races, and retry volume. Establish those application behaviors before testing whether capacity increases. Finish the classroom exercise by deleting only its namespace after saving the manifest: kubectl --context kind-microbank-advanced delete namespace classroom. This removes the disposable page and ConfigMap. You are now ready for the MicroBank Kubernetes lab, where each object has an application responsibility.

Sources

Kubernetes HPA↗, Disruptions and budgets↗, Metrics Server↗.