I am excited to share that we’ve just launched our first open source project called ValidKube. The idea behind Validkube is to fuse together the capabilities of three other popular open-source projects (kubeval, kubectl-neat and trivy by Aqua) and present them in a single view, providing users with a way to ensure YAML code hygiene and security, all at the same time and with just a few clicks of the button.
This article is based on a true story. The names of the company and people involved were changed to protect the innocent 🙂 . A few weeks ago, we were contacted by a pretty big e-commerce company. We can’t really share their name but, for the purpose of this story, let’s call them “KubeCorp Inc”. They reached out to us following an edge-case incident they had, which resulted in severe downtime.
Let’s face it – Kubernetes can (and is) oftentimes very complex. This means that you’re bound to make a cluster configuration mistake along the way – apart from it impacting your cluster’s performance and security, it can also heavily affect your ability to enforce visibility and troubleshooting. There is, however, a light at the end of the tunnel.
More than anything else, Kubernetes troubleshooting relies on the ability to quickly contextualize the problem with what’s happening in the rest of the cluster. As complicated as this may sound, SPEED is really the name of the game. After all, more often than not, you will be conducting your investigation under the glow of fires burning bright in production. Getting relevant context quickly and seeing things holistically is exactly what Komodor was created for.
Kubernetes has evolved into the leading platform to build your microservices systems. Given its increased maturity over the past few years as well as the robust ecosystem which has been built around its technology, Kubernetes has become more production-ready than ever. Nevertheless, it still has its own unique set of challenges. In particular, it brings a lot of complexity into play with its adoption.
