We recently released version 3.0.0 of Goldilocks with a lot of really big changes. I wanted to take a minute to showcase the hard work that Harrison Katz has done over the last several months to make this a possibility.
In the event that you're reading this and you haven’t heard of Goldilocks, it is a tool that allows you to see recommendations for setting resource requests and limits on your Kubernetes deployments. It does this via a controller that manages vertical pod autoscalers (VPAs), and presents a dashboard that summarizes the recommendations contained in those VPAs. GitHub
Try Fairwinds Insights to get the benefits of Goldilocks at enterprise scale.
See how Insights and Goldilocks compare.
The majority of clusters I work with are in the range of 10-50 nodes with only a dozen namespaces or so. This meant that when initially testing and implementing Goldilocks, I didn't have a large amount of data to sift through when presenting it to the dashboard. What Harrison found is that in really large clusters with hundreds of namespaces and hundreds of Vertical Pod Autoscaler (VPA) objects, the dashboard would take a really long time to load and sometimes not load at all.
To solve this, Goldilocks had to undergo a lot of changes. Most notably from the frontend side of things, you now just see a list of namespaces. You can either view all of them at once, or drill down into individual namespaces.
The last major change that we made in 3.0.0 was not to Goldilocks itself, but to the way we deploy Goldilocks. In the old chart, vertical-pod-autoscaler (VPA) could be installed via hooks that called the bash scripts in the VPA repo `hack` directory. This caused lots of different issues, and had no options to configure the vertical-pod-autoscaler. For this release we created a VPA chart that you can use to install the VPA controller and the necessary resources for it. This chart allows for customization of your VPA install.
Goldilocks was my first big project that was written in Go. Because of this, when I looked back at the code, I would question the way I had done certain things and the way a lot of the code was organized. I originally wrote it to try and make my own life easier, and was really surprised when Goldilocks got the level of feedback and adoption that it did.
So when Harrison approached us and said that he and his colleagues had fixed a lot of the major issues around large clusters, I was ecstatic. We then embarked on a long series of pull requests, reviews, revisions, and waiting on each other. Overall, it was a wonderful experience having such a large external contribution to one of our open source projects. It's great to see companies giving their engineers the time and space to contribute back to open source projects that they find valuable.
Goldilocks 3.0 performs much better in large clusters with lots of namespaces, resource recommendations can be viewed for a single namespace, and installing the VPA is much simpler.
A ton of great things are happening in the Goldilocks codebase, and I'm excited to see where it goes in the future. Again, a thousand thanks to Harrison for his hard work and patience.