When a horizontal pod autoscaler makes updates to the deployment.yaml object when there is an increase or decrease in load, doesn’t that make the source file and the file being monitored by kubectl mismatch? When using the declarative approach, the file in the source control system always matches the state of the application that is currently running. How does this work with HPA? How can we use autoscaling but also keep the deployment.yaml file that exists in github/lab in sync with the current state of the application?
1 Answers
Technically yes the number will be different than what was originally declared your config file, but ideally you should know how many replicas you need for your application to perform and set that in your initial deployment.
HPA will take effect and scale when the load on your cluster increases past the expected thresholds you have specified in the config. Even if you were to redeploy your config using the original config/replicas it was deployed with, HPA would scale up/down the number of nodes based on the resources you have declared and their usage.
Does this break the declarative way of working? Not really, because you have declared what is an acceptable level to scale to and are not waking up at 3 am to scale the nodes manually because of increased load.
just want to clarify something here: when the hpa increments/decrements the number of replicas, is it ACTUALLY writing a change to the underlying yaml file? Im guessing the answer is yes, but to the ‘local’ copy, and ideally that would have been copied from a versioned repo, ya?