Popular Kubernetes Tools

5 min readJul 12, 2023

Kubernetes for Developers: Part VI

Photo by Dan Cristian Pădureț on Unsplash

Welcome to Part VI of the “Kubernetes for Developer” series!

So far, we’ve covered some fundamental Docker and Kubernetes concepts from pods to resource management. Today we move from the theory to more practical matters, going over some popular Kubernetes tools. Some keen readers might have noticed that previous articles did not really dive deep into Kubernetes manifests or deploying components. That was intentional, because for the most part, you will not be interacting with them directly. Most likely, you’ll be using either open-source or home-grown tools that the infra teams have already installed on your behalf.

The goal of this series is to help you become more comfortable and productive with using Kubernetes. By going over some popular Kubernetes tools, the hope is to:

Help you identify what is a native Kubernetes concept vs. an abstraction/wrapper/tooling layer built on top.
Guide you towards existing projects so you don’t have to reinvent the wheel.
Let you know what addons/plugins/tools exist to help get your work done faster or know what questions to ask.

So let’s get to it!

This series is brought to you by DevZero.

DevZero’s platform provides cloud-hosted development environments. With DevZero, you can reuse your existing infrastructure configuration to configure production-like environments for development and testing.

Check out DevZero at devzero.io to get started today!

Helm

Helm is a package manager for Kubernetes applications that provides templating and versioning capabilities for distribution. Helm is important to know because it is by far the most popular package manager for Kubernetes and other deployment tooling often provides robust integration for it.

For developers, you’ll most likely interact with Helm in one of two ways:

You will need to package your application for deployment by creating your own Helm chart.
You will use an existing Helm chart (either open-source or private, internal) to deploy other services or dependencies (e.g., database, cache, message queue) for integration or end-to-end testing.

The specifics as to how Helm is used in your application may vary in your organization. Some teams may have a CLI tool to help bootstrap a Helm chart. Others may have a “standard” template for you to use and override some values. Other teams may also have a more fully-featured dashboard or portal to guide you through the experience.

But at the end of the day, Helm is simply a wrapper around Kubernetes manifests (e.g., deployments, statefulsets, services, etc) that we’ve learned in previous lessons into logical packages called charts. As long as you can distinguish what is a Kubernetes-native concept versus the templating engine provided by Helm or related tools on top, you’ll be able to pick up what’s happening quickly.

For a deep dive into Helm, check out Helm 101 for Developers.

Other popular tools: kustomize, cdk8s

Kubernetes Distribution for Local Development

Unless you work at a large organization where a remote development environment is set up for you, you’ll likely encounter some distribution of Kubernetes for local development. There are a ton of options in this space ranging from Docker Desktop, minikube, kind, k3s, and more. Even if you are still using Docker or Docker Compose locally for development and testing, you may see these options running in CI.

The important thing to know about these different Kubernetes distributions are that since they are primarily designed to run locally (i.e., more constrained, non-prod-like environments) or in CI for testing, Kubernetes functionality may behave slightly differently. For example, some workarounds may be implemented to support ingress or load balancer functionalities.

If you’re curious about some of these options, check out Kubernetes for Local Development.

Common Cluster Components

Next, we have a list of common cluster components that are hopefully already installed on your cluster. Work with your infra team to get these (or similar components) installed to make your life easier!

Cluster autoscaler: While Kubernetes comes with autoscaling capabilities for pods, you need to install a separate cluster autoscaler to scale the underlying nodes. Some managed Kubernetes providers like GKE package this into their offering. For others, you’ll need to install and configure Kubernetes Autoscaler for nodes or even pods (if you want vertical scaling). If you are running on EKS, check out Karpenter.
Cert-manager & external-dns: For web applications needing external access, one of the more time-consuming and menial tasks are 1) configuring DNS to point to your service, and 2) configuring TLS certs to encrypt your endpoint. While this can all be controlled external to Kubernetes via Terraform or SDK, you can also use cert-manager and external-dns to automate this process by adding annotations to your Kubernetes services.
Secret management: Another practical concern with running applications on Kubernetes is fetching secrets for your applications to use. While Kubernetes provides native support for secrets management, it is simply stored as base64 encoded plaintext by default. You can configure the cluster to encrypt them at rest, but it doesn’t provide sophisticated control and audit mechanisms of secret management solutions like Vault or cloud-provider’s products. Instead of fetching these secrets from your services in some startup or init-container, use a tool like Secrets Store CSI Driver to automate that for you.
Back up & migrations: Finally, if you are running stateful applications with persistent volumes, you will need to periodically backup your data for disaster recovery or safer migrations. Look no further than velero to automate this. For a deep-dive, you can read this guide on Disaster Recovery on Kubernetes.

Others

Finally, we’ll end with a collection of nice-to-have tools to make interacting with Kubernetes easier:

Command line tools: kube-ps1 for kubectl prompt strings, kubectx to switch between clusters and namespaces.
Port-forwarding: kube-forwarder to easily manage endpoints to port-forward.
IDE: OpenLens for a nice console experience to manage and interact with Kubernetes clusters.

Wrapping Up

The Kubernetes ecosystem is massive with new tools and projects being added every day. You can google “awesome-kubernetes” to get a sense of all the work that’s being done. However, for most of you, your interaction with Kubernetes will be somewhat curated based on what your infra team has set up. For some, it may be closer to the bare minimum Kubernetes cluster with a few helper tools. For others, it may be abstracted away behind your organization’s framework or tool. In either case, as long as you know your Kubernetes basic concepts, you can distinguish whether to look for answers in the general Kubernetes wiki or from the tooling repos. As LLMs mature, we may be able to ask these questions in one place soon, but until then, we need to have a starting point to unravel the Kubernetes stack.

Next week, we’ll take a look at the state of Kubernetes: where it is being used, how it is being used, etc. Stay tuned!

Kubernetes for Developers Series