If you’re just getting started with Kubernetes, it can be very overwhelming if you’re learning how to implement the platform yourself. Although Kubernetes comes with its own set of industry standards and best practices, there are some decisions that may be unique to your web application.
Our team of public cloud infrastructure consultants have recorded some things that they’ve done to make setting up and running Kubernetes easier. Here are 4 ways to make Kubernetes easier for your team.
Spend the time to set up good logging tools
Kubernetes has a diverse set of integrations that can help you set up custom logging dashboards to monitor your cluster. Spend some time making good log dashboards and practise diving through the logs using your monitoring tools before putting your app into production.
In an emergency, you don’t want to be searching through your UI trying to figure out where it went wrong. If you have premade dashboards, you’ll have a better idea of where to look and how to trace down an error.
If you want to take your risk mitigation a step further, consider setting up alerts to detect common issues in your infrastructure such as:
A cluster hasn’t written any log entries within the last several minutes (generally, a cluster writes log entries all the time, so if the cluster hasn’t written an entry in awhile, the logging stack may be broken).
An auto-scaler has reached its maximum number of pods or Kubernetes cluster nodes, meaning that your app may be unable to meet customer demand.
A database or other critical backups have failed, potentially putting key business data at risk.
A database is running out of disk space, potentially leading to a database outage if it hits 100 percent usage.
Some of our favourite tools for logging dashboards and alert integration include Grafana, Prometheus, and Kibana. Many of these open-source tools will have large repositories of premade dashboards created by the community. For example, some custom Grafana dashboards can be found here.
Use a managed Kubernetes service
A managed Kubernetes service allows you to use Kubernetes as you would without having to manage the Kubernetes master services. The managed service provider will take care of significant portions of your setup and maintenance, so that you can spend more time using Kubernetes than configuring it. As we’ve previously discussed, Kubernetes is best when it’s being used.
A managed Kubernetes service like Amazon Elastic Kubernetes Service (EKS) gives you all of the benefits of Kubernetes, without having to solve problems that other people have already solved. By adopting a managed Kubernetes service, you’ll save a lot of time and money that would have been spent on setting up Kubernetes from scratch. At the end of the day, you’ll still need a DevOps person as there’s still work to be done. However, your team member won’t have to waste their time with basic setup tasks and making sure your cluster has the right default settings, and can instead focus on actual work.
Manage your cluster using Terraform
Terraform is a tool for building, changing, and versioning infrastructure. It is a well-known, open-source industry standard for many businesses that have adopted Kubernetes. Managing your cluster with Terraform can for the most part guarantee that:
No one who shouldn’t have touched your cluster has touched your cluster, accidentally breaking things without your knowledge.
Changes made on your cluster are done in a repeatable, safe manner. Since all changes are made by Terraform, you know that they will happen the same way, every time, without human error.
If something breaks and diverges from its intended configuration, you can just return it to its previous state with just one command.
Don’t treat everything like a nail
“If all you have is a hammer, everything looks like a nail”
In this case, Kubernetes is your hammer, and your infrastructure components are the nails… or maybe not nails. If Kubernetes is the right fit for your web application, it’ll really be the right fit, pretty much taking care of (almost) all of your infrastructure needs. But in reality, not everything needs Kubernetes.
When assessing whether a component of your infrastructure should be contained in a Kubernetes cluster, consider both of the following points:
1) Is the infrastructure component compatible with Kubernetes?
Some components of your infrastructure just aren’t compatible with Kubernetes. For example, databases almost never mesh with the container orchestration platform.
Even at their cores, Kubernetes runs on the assumption that things can die at any moment, whereas databases run on the need that things can NOT die at any moment. The sheer complexity of making these two run in conjunction is enough to deter anyone from porting their database over to Kubernetes.
2) Are the benefits of using Kubernetes going to be ongoing and consistent?
Your infrastructure components may be compatible with Kubernetes, but will you be getting a sizeable return on your investment?
For example, if you follow the e-commerce calendar and regularly need scaling, you might want to consider the container orchestration platform. However, if only need scaling for 1 day during the entire year, then Kubernetes might not be the right fit.
Do you want to ensure that you set Kubernetes up the right way the first time? Send us a message.