History
Kubernetes, also known as K8s, is an orchestration service for containerized applications. It was originally developed by a small team of Google engineers in 2014, under the influence of the Borg cluster manager, and has since become one of the most recognized open source projects with over 39K forks as of writing.
K8s aids in software development, deployment, and management, specifically tailored for large applications at scale, offering a wide range of services focused around networking, load balancing, and processing allocation. Large applications will often be separated into a dozen or more microservices, each representing unique functionality. In a containerized infrastructure, a single service may be deployed across hundreds or even thousands of containers.
With large platforms like leading eCommerce sites and financial institutions, these microservice architectures, often comprising tens of thousands of containers, handle millions of users a day. Carefully designed and executed management of these systems is crucial, and requires sophisticated orchestration to facilitate everything from efficient resource allocation and downtime to security and CI/CD operations.
The Problem
While K8s serves as the industry leading solution to this challenge, it comes with many hurdles of its own. K8s is notorious for its steep learning curve and complexity, resulting in high onboarding costs, lower supply of experienced engineers, and teams that are frequently overworked. Updates are regular, and although documentation is thorough, the implications of implementation are wide ranging. With thousands of moving parts, and millions of daily users, migration can easily run the risk of extending into the next update cycle, especially with smaller or understaffed teams.
Let’s consider for a moment where an update might occur. K8s itself goes through typical versioning, as expected, but what about all of the parts that comprise it? In essence, K8s is an API consisting of other APIs, each exposing the multitude of orchestration services available to your microservices, as well as all of the APIs that allow your containers to communicate with each other. Given the sale that we’ve discussed, It’s easy to see that a given cluster can have thousands of points of failure and each of these points/APIs can live at various stages of their own versioning, including deprecation. Updating then becomes less of a simple click of a button and more of a complicated and timely discussion of compatibility and the implications on maintainability and growth, accounting for a meaningful portion of the labor required to maintain a K8s orchestration.
The KAT Solution
After extensive research and discussion with K8s engineers, we found that it might be useful, rather than spending hours a week reading through documentation to stay on top of the versioning status of all the APIs in your cluster, to have a simple, no-fluff tool that will scan your cluster or helm chart (before you even install it), and that not only tells you if an API has an update available or is deprecated, but provides a snippet of official K8s documentation regarding the versioning status, all in a single pane of glass, in just seconds.
So, we went ahead and built that.
Our approach can be summed up in three steps:
- Scan .yaml files for apiVersion
- Compare those versions to official K8s API documentation
- Provide a quick, simple summary of each APIs versioning status
Our first objective was to be able to scan a user’s local cluster, and there was discussion on how this product should be available. Should we host it online and allow users to create accounts and track historical data or should we build it as an Electron desktop app so users can run it locally? The prior opened the door to permissions and security risks that we felt were unacceptable. It would also necessitate a database, OAuth, containerization, and the deployment and maintenance overhead for cloud hosting. Furthermore, the latter stuck more to our original intention of providing a no-frills, at-your-fingertips, developer-friendly tool.
As we began development down this path, that simple-solution mindset drove us further toward the product that you have now. Even a desktop app began to feel over the top. Developers don’t want or need any more tools, in fact the overabundance of third-party apps has become a point of contention for many system admins in this space. We went back to the wireframe and user story and asked ourselves, ‘What if a developer could simply run a CLI command from their cluster’s root directory and the product was served, without any other input or clicking?’. So, that’s what we did. You simply clone our repo into the root directory of your cluster, execute ‘npm kat’, and our product is served on your localhost.
The next order of business was to provide this same functionality on Helm charts, before you install them. So, we did that too. With both products taking a similar approach, we were able to glob locally and regex through Helm dry-run installs to serve a normalized data model to our frontend so that each are displayed identically within the same interface. All written in TypeScript, using Express and React, without a database or the need for OAuth or permissions configuration, we’ve packaged this product into a lightweight, user-friendly repo available here as an open-source product.
We sincerely appreciate you reading our brief and hope that we’re able to provide meaningful value to you and your team. This project is a work in progress and we wish to hear from you about your experience and any ideas or suggestions you may have. Thank you again and we look forward to your feedback!