Skip to main content
Welcome. In this lesson we cover a manual Horizontal Pod Autoscaler (HPA) lab: how manually scaling a Deployment changes application behavior and what effects replica adjustments have on running pods and clients. This lab demonstrates the manual side of horizontal pod autoscaling: you will scale a Deployment’s replicas by hand, observe the pods that appear or disappear in the cluster, and note how pod hostnames (and therefore any application behavior that depends on the hostname) can change.
A presentation slide titled "Lab Overview" showing the objective to demonstrate how scaling a Kubernetes deployment (hostname changes) affects application behavior and to show the impact of increasing replicas on the application's output.

Overview and objective

Goals:
  • Manually scale a Deployment (increase and decrease replicas).
  • Observe pods being created or removed and examine their unique names.
  • Demonstrate how application output can change when pod hostnames change, and why that is generally undesirable for stateful interactions.
Example scenario: scale a simple Flask web application up to three replicas.

Manual scaling: commands and verification

Use kubectl scale to adjust the replica count on a Deployment:
Then verify pods and their status:
Example output:
Commands summary: Think of a Deployment as a neighborhood plan and pods as houses. When you scale the Deployment, Kubernetes (via the ReplicaSet managed by the Deployment) starts or stops pods to reach the requested replica count. Each pod receives a unique name (and, by default, the pod’s hostname is set to its pod name). That means a hostname for a particular instance can change whenever pods are recreated.
A slide titled "Lab Overview" showing a Kubernetes cluster and a Deployment containing several pod icons, with arrows from a user icon on the right indicating users accessing those pods. The Kubernetes logo appears at the bottom-left and the image is credited to KodeKloud.

Why pod hostnames matter

  • Pod hostnames are tied to pod names by default. When a pod is recreated, its name and hostname change.
  • If your application returns or depends on hostname-specific data, client-visible behavior may change after scaling or redeploys (for example, different responses or session binding to a pod hostname).
  • Cloud-native best practices: design stateless pods and rely on stable endpoints (Services) rather than individual pod hostnames.

When to use Service vs StatefulSet

Key takeaways

  • Changing a Deployment’s replica count is how you increase or decrease the number of running pod instances for an application.
  • Every pod has a unique, ephemeral hostname (derived from the pod name by default); these hostnames can change when pods are recreated.
  • Because of hostname ephemerality, do not rely on pod hostnames for durable identity or sticky client behavior. Use Services for stable access, externalize state (databases, object storage), or use StatefulSets when you specifically need stable pod identities and persistent volumes.
A presentation slide titled "Key Takeaways" with three colored panels—Scaling, Hostnames, and Application Behavior—each illustrated by an icon and a short note. It explains that increasing replicas adds pods, each pod gets a unique hostname, and scaling can change application behavior based on those hostnames.
Prefer Services for stable access to an application, and prefer stateless pods for easy horizontal scaling. Use StatefulSets only when you require stable pod identities or persistent storage tied to individual pods.
Important: Do not use pod hostnames for durable session affinity, unique user identity, or persistent storage binding. Those requirements need Services, external storage, or StatefulSets to ensure stability across scaling and restarts.
Understanding these behaviors is essential before introducing automated scaling (HPA), because an HPA changes replica counts dynamically based on metrics — the same considerations about ephemeral hostnames and stateful behavior still apply. Further reading and references:

Watch Video

Practice Lab