As an administrator of the VRO platform, I want to ensure that deployments which can tolerate multiple replicas are setup with horizontal pod autoscalers (HPAs), so that they are more resilient to fluctuations in request volume. HPA ensures that the application can handle varying levels of load efficiently.
Acceptance Criteria
All applications deployable through Helm have been evaluated for their ability to tolerate multiple running replicas and the results of this evaluation have been documented in a new wiki page.
Those applications found in the prior step to tolerate multiple replicas have installed HPAs in the K8s cluster across all of our environments.
Assuming there is at least one application which tolerates multiple replicas, a follow-up ticket has been created for creating Pod Disruption Budgets for those same applications.
Regardless of the method for defining HPAs, HPA specs are checked in as code into the repo.
For 2, Mason has a hypothesis that this can be completed through manipulation of Helm charts. If this is true, this ticket can be created without VA network access, though it will likely require a team member with access to verify on behalf of the engineer executing this ticket. In the case that this hypothesis is not true, VA network access will be required in order to install the HPAs directly through kubectl
msnwatson
commented
7 months ago
User Story
As an administrator of the VRO platform, I want to ensure that deployments which can tolerate multiple replicas are setup with horizontal pod autoscalers (HPAs), so that they are more resilient to fluctuations in request volume. HPA ensures that the application can handle varying levels of load efficiently.
Acceptance Criteria
Notes about work Helpful link for constructing Helm charts: https://doc.kaas.thalesdigital.io/docs/BestPractices/BYOHelmchart
kubectl