It is said that good fences make good neighbors, it's true for applications too. Applications were typically designed to run standalone in a machine and use all of the resources at hand. But that's not the case with distributed systems (like Kubernetes) where resources (CPU/Memory, etc) are shared between applications. Every time you create a workload in Kubernetes, its very important to specify how much memory and CPU that workload is going to use. There are two ways to specify the resources and both have some drawbacks:
set the resource requests too low, which has the risk of making a normal application look like it’s using too much memory, too much CPU, and Kubernetes will kill it. Needless to say, this will make your application unreliable and cause downtime.
set the resource requests too high, where you allocate more compute power than necessary and your cloud bill can get to be much higher than it needs to.
So setting optimal values for resource requests and limits on Kubernetes workloads is very important. This is where Fairwinds' Goldilocks helps - it will suggest resource request values that are just right.
- Recommends values for resource requests and limits on Kubernetes workloads.
- Dashboard that shows recommended values for Kubernetes resources based on QoS(Quality of Service).
- Helps in optimizing Kubernetes resource utilization.
- CLI utility for analysis of Kubernetes deployment resource usage.
Goldilocks can be installed using
helm or a local binary.
All methods will require you to have a cluster running, and the
KUBECONFIG environment variable set up. If you have not yet signed up to Civo, you can sign up to apply for our managed Kubernetes beta to try this out for yourself!
kubectlTo be able to manually install Goldilocks, you would have to clone the repository and from its root directory run the following:
kubectl create namespace goldilocks kubectl -n goldilocks apply -f hack/manifests/controller kubectl -n goldilocks apply -f hack/manifests/dashboard
helm repo add fairwinds-stable https://charts.fairwinds.com/stable helm install --name goldilocks --namespace goldilocks --set installVPA=true fairwinds-stable/goldilocks
- - binary : download the binary from the release page
then use kubectl's port-forward function to access the dashboard:
kubectl -n goldilocks port-forward svc/goldilocks-dashboard 8080:80
http://localhost:8080/ to view the dashboard.
As shown in the dashboard, there are no initial recommendations for any deployment. This is because Goldilocks only provides recommendations for deployments in those namespaces which have the label
Let's assign this label to our Goldilocks namespace:
kubectl label ns goldilocks goldilocks.fairwinds.com/enabled=true.
Now you should see some recommendations for every deployment in the Goldilocks namespace.
As shown in the image above, Goldilocks provides two types of recommendations, depending on what QoS Class you desire for your deployments.
How Does Goldilocks Provide Resource Recommendations?
Behind the scenes, Goldilocks makes use of Vertical Pod Autoscaler (VPA), which contains a recommendation engine that takes into account the current resource usage of your deployments in order to provide a guideline.
The primary goal of VPA is to actually set those for you, but the company isn’t comfortable with the way it does this and prefers to use it primarily for recommendations, as Goldilocks’ creator Andy Suderman writes in a blog post.
"The way we utilize the VPA recommendation engine is simple. We run a controller in the cluster that watches for namespaces that are labelled with
goldilocks.fairwinds.com/enabled=true. Within those enabled namespaces, we look at every deployment object and create a corresponding VPA object. That VPA is set with
Mode: Offand doesn’t actually modify your resource requests and limits; it just sits there and provides a recommendation. To view these recommendations, you would have to use kubectl to query each and every VPA object. For medium to large deployments, this can get very tedious. That’s where we introduced Goldilocks dashboard which provides a visualization of the VPA recommendations."
Excluding Recommendations for Containers
Often we see clusters where every pod gets a sidecar, such as the Istio or Linkerd2 sidecars. You may not want to see resource recommendations for those containers because we may or may not have control over those values. There are two ways to exclude these containers.
The first method is global and can be set by running the dashboard with the flag
--exclude-containers "istio-proxy,linkerd-proxy". This is set by default in the Helm chart installation.
The second method is to exclude containers per deployment using a label on the deployment itself:
If you are running any other containers you wish to exclude, you can just substitute them in for the values in the examples above, or add to the list.
If you don't want to deploy Goldilocks in your Kubernetes cluster as an application running along with other workloads, you can make use of Goldilocks CLI. You can do everything described above with the CLI tool, but do note that Fairwinds primarily recommends the use of the Dashboard.