Best Practices for Running Kubernetes in Production

Kubernetes has fueled the DevOps trend, offering a lightning-fast platform that enables developers to ship software at speeds you could once hardly dream up. With all the benefits of containerization causing a massive shift towards container apps in recent years, it's no wonder that Kubernetes has spearheaded the movement.

Endlessly popular with plenty of features to boot, Kubernetes is one of the favorite container orchestration tools on the market — but that doesn't mean it's ideal right out of the box.

If you're running in Kubernetes or thinking about making the move but committed to optimizing your environment to ensure you don't waste any money on unnecessary cloud costs, you're in luck.

Best practices for running Kubernetes

Follow these best practices of running Kubernetes in production, and you'll be well on your way to optimizing your purchase and improving performance.

1. Create Custom Health Probes

Kubernetes is fantastic when it comes to orchestrating your containerized apps, but, by nature, your team can quickly end up with an expansive, wholly distributed environment.

This is a by-product of containers, but one that's difficult to manage nonetheless.

To keep an eye on your system, especially as it grows more complex, you should set up Kubernetes health checks to run regularly.

Custom health checks will help you spot problems early and help you maintain specific standards of performance (and limitations on usage).

Two probes you should create to do this are readiness probes and liveness probes:

• Readiness probes tell you if an app is prepared to serve traffic
• Liveness probes tell you if your app is dead or alive

2. Keep a Tight Rope on Resources

More usage in Kubernetes always means higher costs.

To make sure no one container can get too far out of hand without anyone realizing it, you should get in the habit of setting limits for each individual container.

You should also divide your environments into different namespaces based on the department, apps, teams, or clients involved with them.

Generally, teams want to keep the resource usage low, as more usage means more costs, but they want to keep resource utilization as high as possible.

In other words, if your environment is "using" (i.e., paying for) resources, you should try to utilize them to 100% capacity when possible.

So, let resource utilization be a marker of how optimized your environment really is. Look at things like a container's CPU usage to track improvements.

3. Select and Enable The Right Auto-Scaler

One of the best aspects of using Kubernetes or another cloud-powered resource is that things can scale up or down dynamically, based on your actual need.

However, in order to make use of this advantage, your company has to select and enable the right auto-scaler.

Kubernetes gives you three auto-scalers to choose from:

• The horizontal pod auto-scaler will scale your environment based on perceived CPU utilization
• The vertical pod auto-scaler recommends values for CPU and memory limits and can update them automatically
• The cluster auto-scaler adjusts the pool size for worker nodes depending on the utilization

If you're unsure which auto-scaler is right for you, explore the pros and cons of each.

4. Secure Environments Using Role-Based Access

Role-based access control, often called "RBAC," enables companies to restrict access to specific users and applications.

RBAC has been part of Kubernetes since version 1.8, and it's a critical element in security.

When you begin setting up RBAC, you're able to grant access to users, specifying their permissions and setting rules to limit how they can access your Kubernetes environment and specific clusters.

When done right, RBAC will allow a company complete control over who has access to each component stored in Kubernetes.

RBAC also lets companies decide who can make changes and to what degree, creating limitations and accountability for all teams.

5. Define Network Policies

Defining network policies is another crucial part of setting up your Kubernetes environment securely and effectively.

A network policy in Kubernetes is an object that allows you to specify what traffic you will permit and what traffic you won't permit.

By doing so, you enable Kubernetes to block traffic that doesn't conform to your specifications.

When you create a network policy, you'll define authorized connections and refer to any pods you wish for the policy to apply to.

As a result, only authorized and allowed connections would get through.

Thus, even if traffic moves "to" or "from" a pod in your environment, it will only get through if your network policies permit it.

6. Appropriately Label Objects for Practicality

Labeling objects in Kubernetes is a wise habit to get into. Objects in Kubernetes, such as pods, can be assigned labels, which act as key/value pairs.

The labels are intended to identify attributes of your objects, making an association for your users that will help them quickly recall what the object is or what role it plays.

Neglecting labels is a major but common mistake when running production-grade Kubernetes environments.

Fortunately, it's easy enough to remedy, so long as someone spends the time to go through everything.

By assigning labels, you'll be able to perform queries and operations in bulk and organize objects into groups.

Grouping objects is particularly valuable, as it can help you separate pods according to the application they're part of.

These and other successful practices need to be taken into consideration for running Kubernetes in production.

If you need assistance in understanding and properly implementing the needed practices in optimizing your Kubernetes environment, reach us and learn how our team can bring efficiency to your company.