Mickael Alliel 5 Min read September 20th, 2022 DevOps Kubernetes

Kubernetes may provide an abundance of benefits, but those who are using it may be well aware that it often requires quite a bit (or even a lot!) of effort and skill to run the platform independently. So – rather than having to put up with it on their own, organizations are able to pay for a managed Kubernetes service instead. This is where Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), and Amazon Elastic Kubernetes Service (EKS) come in.

Helm is a deployment tool for Kubernetes objects that supports package management, dependencies, and templating. In this article, we will explore how to optimize your Helm charts. To follow along, you’ll need a basic understanding of Helm and will have ideally written and deployed some basic Helm charts.

Kubernetes is currently the de-facto container orchestration system on the market. Both small and large companies adopt it, and all major cloud providers offer it as a service. However, Kubernetes is a complex and layered platform, so you can’t just jump into it. There are three essential stages for each application: design, deployment, and operation. This blog post will focus on operation, where you need to monitor and troubleshoot your deployed applications.

Kubernetes is today’s leading container management platform, due to its comprehensive API and developer-friendly features. Using Kubernetes, you can create scalable and reliable applications that run on-premises systems and public clouds. Its out-of-the-box features allow it to distribute hundreds of instances over data centers and keep them up and running. In order to catch up with the automation level of Kubernetes, developing and deploying applications requires more autonomy.

When you’re using an application or tool, it’s very important to make sure things are working as they should. For this reason, health checks are critical. A health check is when an application or tool checks its own components and dependencies, then either publishes or exposes a notification method if there is a problem.

Kubernetes has become the de-facto container management solution of the last decade—and we have no doubt it will stay that way in the upcoming years. It provides a solid abstraction between the infrastructure layer and applications, so that developers can quickly develop, deploy, and operate their applications. Kubernetes is designed as a set of APIs that work together. If you deploy simple applications and make them run, Kubernetes will do it for you.

A month and a half ago we released ValidKube, our first OS project that fused the capabilities of three other popular OS tools (kubeval, kubectl-neat and trivy) in a single easy-to-use microsite. Using the microsite, any user could ensure the security and hygiene of their K8s YAML, with just a few clicks of the button, pretty much on the fly. ValidKube was born out of a straightforward concept and we were happy to see its user-friendly approach resonate almost immediately.

Kubernetes. Nowadays it seems companies in the industry are divided into two pools: those that already use it heavily for their production workloads and those that are migrating their workloads into it. The issue with Kubernetes is that it is not a single system the way Redis RabbitMQ or PostgreSQL are. It is a combination of several control plane components (for example etcd, api server) that run our workloads on the user (data) plane over a fleet of VMs.

Recently we had the privilege of being named a Gartner Cool Vendor in the Monitoring and Observability category. The funny thing is, while this is definitely the closest Gartner category for our solution, we aren’t really used to thinking about Komodor as a monitoring and observability tool.