A replica is a running copy of a service component. In Kubernetes, a Deployment declares the desired number of replicas, and its managed ReplicaSet creates pods to maintain that number. More replicas can handle more requests and leave a running copy available if one pod fails. section 2.3.1 section 2.3.3 section 2.4.1
To inspect and change the Conference application’s frontend:
- Run `kubectl get deployments` to see ready and available counts. Use `kubectl describe deploy conference-frontend-deployment` for desired versus available replicas and events when the counts do not match. section 2.3.1 section 2.3.2
- Run `kubectl scale --replicas=2 deployments/conference-frontend-deployment`, then `kubectl get pods`. Two frontend pods should appear. Scale down when the extra capacity is not needed. section 2.3.3
What a failed replica changes
With two frontend pods running, delete one using `kubectl delete pod <POD_ID>`. The ReplicaSet starts a replacement; while it starts, the remaining pod can answer requests. Repeat with only one replica and there is no backup while its replacement starts. If no frontend pod is available, a browser request can return `503 Service Temporarily Unavailable`. Two replicas reduce this downtime risk; they do not make replacement instantaneous. section 2.4.1
Replication also tests application design. Kubernetes can send requests to either replica, so state held only in one pod’s memory can produce different answers depending on which pod responds. The Agenda and Call for Proposals services instead use Redis and PostgreSQL outside pod memory. When adding replicas, review database connection-pool settings: each replica can add connections. section 2.4.3
A Deployment also coordinates rolling updates. Changing its pod configuration triggers an update of the managed pods; its update strategy controls how many replicas may be unavailable or added during that process. ReplicaSets are normally managed through the Deployment rather than edited directly. section 2.3.1 section 2.3.3
