Tools that should be used in every Kubernetes cluster
Every web developer nowadays should be aware of Kubernetes. It is the de-facto standard for orchestrating large websites that are built out of several microservices. Especially in on-prem environments.
In this post, I will show you some extra tools that you should be aware of when creating a new Kubernetes cluster. They will simplify the daily work of all developers using your cluster by automating a lot of common tasks.
Simplify deploying of new apps
Let’s start with the way you should use to deploy your apps and all kinds of apps and resources: ArgoCD!
To be honest, the first time I was using it, it annoyed me, because I thought keeping the kubectl apply within the GitLab CI/CD pipeline should be fine and I don’t want to use any other tool making deployments more complex without giving any value.
I gave it a try and I quickly noticed it is not as complex as I thought. It clearly follows the GitOps principles that make it much easier to follow what state of your resources is deployed to your cluster. Even more interesting for me is the fact that ArgoCD also has a nice UI (and CLI) giving you a great overview of all the apps you have installed and also all resources that these apps created.
By the way: When using ArgoCD it doesn’t matter if your developers want to use raw Kubernetes YAML files, Kustomize, or Helm charts. Let every team use what they like and ArgoCD will do the rest.
Load balancer for your on-prem clusters
If you run Kubernetes on-prem and not within a cloud you most likely don’t have support for load balancer services, but as soon as you will deploy an application that should be accessible outside of the cluster (e.g. via ingress or via dedicated IP and port like a database) you will notice, that you need a load balancer that simplifies the access when using multiple nodes. Thus you should definitely have a look at MetalLB that provides you a way to use load balancer services also on your on-prem setup.
Even if MetalLB is officially still declared as a beta it is already used in several production systems.
Managing your secrets
Kubernetes provides a way to manage secrets, but often companies are using external systems to manage their secrets that will do this much better than Kubernetes. Especially if you are in a cloud environment you will most likely use the secret manager provided by your cloud (e.g. AWS Secrets Manager or Azure Key Vault) and if not you might have a Vault instance running somewhere.
To synchronize these secrets with your Kubernetes instance I recommend using the external-secrets operator that will add a new custom resource definition (CRD) to easily query secrets from your external secret manager and populates it safely as Kubernetes native secret usable within your applications. Pay attention that you will still need to configure encryption at rest and should also set up appropriate RBAC rules.
In a nutshell, you create an ExternalSecret resource that refers to a secret defined in your management tool and the operator will create a native Secret resource out of it that you then can use as usual in your app.
NB: If you just use Vault it might be enough for you to use the Vault Agent Injector. However, I personally would still prefer the external-secrets operator.
Certificate management the easy way
This one is probably my favorite: cert-manager.
It adds a new CRD that lets you easily retrieve or create new certificates. Additionally, with annotations (e.g. on your ingresses), you can directly retrieve certificates without the need for an own Certificateresource. This makes it super simple for your developers to get the expected certificate to get rid of unencrypted HTTP traffic.
It supports various ways to get your certificates. For example, it can create self-signed certificates, use Vault, or use any ACME service like Let’s Encrypt to get the certificate your developers need on the fly.
Managing your DNS
Do you quickly need a subdomain available in your public DNS server pointing to a new service or ingress someone deployed? Then have a look at the external-dns operator!
Having this one in place your developers just need to annotate their services and the operator will take care of updating your public DNS server. You can even define a template that will be used to automatically create DNS entries (e.g. {service}.{namespace}.example.com) and then all your services are automatically accessible via DNS outside of your cluster, isn’t that kinda cool?!
Summary
Let me briefly summarize the extensions to your Kubernetes cluster that you should definitely use:
- ArgoCD for deploying your resources the GitOps way
- MetalLB in case you need a load balancer when running Kubernetes on-prem and not in a cloud
- external-secrets to easily sync the secrets of your external secret manager with your Kubernetes cluster
- cert-manager to easily retrieve and/or generate new certificates on the fly
- external-dns to manage your DNS entries automatically
Having all these tools available in your cluster gives your developers the power to easily deploy apps that are directly reachable via DNS in a secure way using a certificate. The secrets (like database credentials) required by their apps are safely stored in the secret manager of your choice. On top of that, your on-prem cluster supports load balancing, so even non-HTTP apps can easily be deployed!
Side note
Especially when it comes to microservices in your Kubernetes cluster a service mesh like Istio will often be used. Anyway, due to its complexity, I wouldn’t argue it is a must-have in each Kubernetes cluster. Compared to the mentioned tools it has a much bigger impact on your applications. Thus you should be aware of the complexity if you want to use it, often it is worth it.
Something not useful? Have I forgotten anything? What is your favorite Kubernetes extension? Please let me know in the comments or on Twitter!
