Specify Replicas in Deployments or Statefulsets?
Explore how Kubernetes HorizontalPodAutoscaler manages replicas in Deployments and StatefulSets, and understand how to properly configure replicas to prevent conflicts during auto-scaling and rolling updates. This lesson helps you optimize resource scaling by deciding when to define replicas for dynamic application performance.
Knowing that HorizontalPodAutoscaler (HPA) manages auto-scaling of our applications, the question might arise regarding replicas. Should we define them in our Deployments and StatefulSets, or should we rely solely on HPA to manage them? Instead of answering that question directly, we’ll explore different combinations and, based on results, define the strategy.
HPA modifies the Deployment
First, let’s see how many Pods we have in our cluster right now.
kubectl -n go-demo-5 get pods
The output is as follows.
NAME READY STATUS RESTARTS AGE
api-... 1/1 Running 0 27m
api-... 1/1 Running 2 31m
db-0 2/2 Running 0 20m
db-1 2/2 Running 0 20m
db-2 2/2 Running 0 21m
We can see that there are two replicas of the api Deployment, and three replicas of the db StatefulSets.
Let’s say that we want to roll out a new release of our go-demo-5 application. The definition we’ll use is as follows.
cat scaling/go-demo-5-replicas-10.yml
The output, limited to the relevant parts, is as follows.
...
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
namespace: go-demo-5
spec:
replicas: 10
...
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: api
namespace: go-demo-5
spec:
scaleTargetRef:
...