👁️ 😂 ☝🏼 Top 10 Kubernetes Tips and Tricks ⛄️ ✋🏼 🛀🏾

There is a lot of reference literature on the Internet, but sometimes the simplest tips become the most valuable. The Mail.ru Kubernetes aaS team has translated a selection of ten tricks and tips that the author of the article collected after a year of working with Kubernetes. Tips are not sorted by importance, but we think that everyone will find something useful for themselves.

The easiest team to work with Kubernetes

To begin with, perhaps the simplest and most useful action in working with Kubernetes. The following command enables autocompletion of commands kubectlin the bash shell:

echo "source <(kubectl completion bash)" >> ~/.bashrc

Autocomplete kubectlwill be written to the .bashrc file and will be automatically activated every time the shell starts. This speeds up a set of long commands and parameters, such as all-namespaces. See Kubernetes bash help for details .

Default restrictions on memory and CPU in namespace

If the application is not written correctly, for example, every second opens a new database connection, but never closes it, then a memory leak occurs in the cluster. And if there is no memory limit for the application during the deployment, this may lead to a node failure.

To prevent this, Kubernetes allows you to set default restrictions for each namespace. They are written in the yaml file for a specific namespace. Here is an example of such a file:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

Create such a yaml and apply to any namespace. For example, to a namespace limit-example. Now, for any container deployed in this namespace, the 512Mi limit will apply, unless another individual limit is additionally set for this container.

Garbage collection in older versions of Kubernetes

Kubelet by default starts garbage collection when var / lib / docker takes up 90% of the available disk space. This is fine, however, prior to Kubernetes 1.7 there was no default limit on the number of inodes used (inodes), which correspond to the number of files in the file system.

Potentially, your var / lib / docker container can only use 50% of the disk space, but inodes can run out, which will cause problems for workers.

In older versions of kubelet from 1.4 to 1.6, you will have to add the following flag:

--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

In 1.7 and newer versions, this flag is set by default. However, previous versions do not follow the limit of inodes.

Minikube ... a small but powerful local Kubernetes

Minikube is the easiest way to start a local Kubernetes cluster. It starts with a simple command:

minikube start

As a result of this command, a real Kubernetes cluster is running on your computer.

Source of illustration The

trick is how to build the application and run it locally in this cluster. Unless specifically instructed, the Docker image will build on your computer, not in the cluster.

To force Docker to send the image to the local Kubernetes cluster, the docker machine is given the following command:

eval $(minikube docker-env)

Now we can build applications on the local Kubernetes cluster.

Do not give kubectl access to everyone

This seems obvious, but if several teams use the same cluster for their applications (for which Kubernetes was created), you should not just give it to everyone kubectl. It’s better to separate the teams by giving each of them its own namespace and delimiting access by RBAC policies.

You can get confused by registering for each pod the rights to access, read, create, delete and other operations. But the main thing is to restrict access to secrets, allowing it only to administrators. So we distinguish between those who can administer the cluster, and those who can simply deploy in it.

Manage hearth budgets

How to guarantee no downtime for an application in a Kubernetes cluster? PodDisruptionBudget and again PodDisruptionBudget.

Clusters are periodically updated, and nodes are emptied. Nothing stands still, such is the reality. In every deployment with more than one instance, you should definitely include a PDB (PodDisruptionBudget). It is created in a simple yaml file that applies to the cluster. The coverage area of a particular PDB is determined by label selectors.

Note: The PDB budget is taken into account only in case of a voluntary disruption . In situations like hardware failures, the PDB will not work.

PDB example:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: app-a-pdb
spec:
  minAvailable: 2
  selector:
      matchLabels:
        app: app-a

Two main parameters are matchLabelsand minAvailable. The first parameter indicates which applications have a budget. For example, if I have deployments with app: app-aand tags app: app-b, then this PDB will only apply to the first.

The parameter is minAvailabletaken into account when emptying (cleaning) the unit. For example, in our example, all app: app-abut two instances are supplanted during the devastation .

This allows you to control how many instances of the application should be running at any given time.

Application Health Monitoring

Such monitoring is possible in two ways: using Readiness or Liveness samples.

The first readiness test determines whether the container is ready to receive traffic.

The second (liveness) shows whether the container is working or needs to be restarted.

Appropriate configurations are simply added to yaml for deployment. There you can specify timeouts, delay times and the number of retries. See the Kubernetes documentation for more details .

Tags everywhere

Tags are one of the fundamental concepts in Kubernetes. They allow objects to freely communicate with each other, as well as create queries based on labels. In Kubernetes, you can even go to the client and watch events by specific tags.

With the help of labels, you can do almost everything, but a good example would be to create several environments for running programs in one cluster.

Suppose you are using the same cluster for devand qa. This means that you may have an application app-arunning simultaneously in both environments qaand dev. In this case, we can access the application instance in a specific environment separately by specifying the appropriate parameter environment. For example, app: app-aand environment: devfor a single environment, and app: app-aandenvironment: qafor the second.

This allows you to access both instances of the application, for example, to simultaneously test.

Put in order

Kubernetes is a very powerful system, but any system can end up bogged down in a large number of processes. Kubelet launches all the processes and checks you specify, as well as your own.

Of course, one orphaned service will not slow down the system, and Kubernetes was originally designed to scale. But if a million appears instead of one service, the kubelet begins to choke.

If for some reason you are deleting the deployment (container, image, whatever), just be sure to completely clear it.

Get to know go

We saved the main advice in the end. Learn the Go programming language.

Kubernetes is developed on Go, all extensions are written on Go, and the client-go client library is also officially supported.

It can be used for different and interesting things. For example, to expand the Kubernetes system to your taste. So, you can use your own programs to collect data, deploy applications, or simply clean containers.

Learning the Go programming language and mastering client-go is perhaps the most important tip you can give to novice Kubernetes users.

Translated with support from Mail.ru Cloud Solutions

What else to read :

Top 10 Kubernetes Tips and Tricks