Flag over-provisioned kubernetes namespaces
Problem to solve
Users will often times guess/estimate what the resource needs are for Kubernetes namespaces and allocate resources based on that. After the first deployment, users are good at increasing resources as they run into problems but not the other way around. Over-provisioned namespaces don't throw recognizable flags so users are often unaware that they are wasting resources, and therefore money, on resources that could be more efficiently allocated elsewhere.
Target audience
Operators, developers
Further details
Original Proposal
List deployments which are over-provisioned. Using kube-state-metrics
and Prometheus:
-
Calculate the average and maximum usage of CPU/Memory for each deployment.
-
Compare that to the resource requests for that deployment.
-
Calculate how much they are over-provisioned, and represent that on the group cluster page in some form. (Ideally sorted)
- Note you generally want to over-provision RAM a bit but under-provision CPU.
Updated MVC Proposal (WIP)
Iteration 1: Display CPU and Memory consumption by namespace for a cluster. IF the namespace has been specifically provisioned, also display this information. If it has not, leave that information blank. For the MVC, we will NOT be including metrics on how much something is under or over-provisioned, nor will we be including recommendations
WIP design proposal: Introduce a Cluster Resources section
Configure is in the process of re-designing this page to have tabs. When this is completed, the cluster resource section will have it's own tab.
Ideally, if Configure is able to prioritize introducing the tabs first, then we can slot in the cluster resources graph/table into its pre-defined tab. If that won't be possible, we can add the graphs into the existing page as described in the image above.
What does success look like, and how can we measure that?
Links / references
We can just list the deployments which are over-provisioned, and someone can manually track it down for now.
We already have all of the data needed from . We would:
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.