7 Best Practices in Kubernetes
The growing use of containers has led to a subsequent rise in the demand for Container Orchestration Platforms like Kubernetes. Using containers to package applications has dramatically streamlined the process of shipping applications from Development to Production. No doubt, Kubernetes as a platform orchestrator by introducing its profound ways has further simplified the process.
Today, I want to talk about some of the good practices that I learned while using Kubernetes that can enable secure deployments and drive the efficiency of clusters.
So, let’s begin.
1. Use Namespaces
Kubernetes provides an efficient resource for large teams to isolate their work called a Namespace. You should leverage the ability of namespaces to separate different teams’ work on a single Kubernetes cluster. Namespaces also help in isolating individual applications so that managing them becomes easier.
One can have proper standards implemented indicating which namespace should be used for what kind of work, simplifying management. It also avoids clutter by not having to keep everything under one roof.
2. Use Secrets and Configmaps
Most applications require configuration details including some confidential data like secret keys, passwords, or userids. A quick solution is to pass these details via environment variables.
However, this practice is a lot less secure and you should use secrets and configmaps. This not only secures applications but also provides a way to edit these details individually in respective YAML files without having to change the main-application deployment file.
3. Leverage RBAC features
Kubernetes has implemented a rather rich feature of RBAC to define individuals, teams, or applications’ access to the cluster. Kubernetes Roles is a resource to specify the allowed actions in the cluster. These roles are bound to Users or Applications (Service Accounts) using RoleBindings. This way of defining restricted access to clusters implements a layer of access management.
Having said this, one must keep in mind to use these features wisely. An application requesting a namespace-scoped pod view only permission must not be given access to cluster-wide pod listing permission. And a user/teammate should not be given access to secrets he/she is not concerned with. A strict access management layer keeps the cluster away from unexpected mishaps.
4. Specify Resource Limits
It is a good practice to set resource usage limits for applications. It allows keeping the resources of the cluster under check and eliminates opportunities for excessive drainage of resources by a single application, which can seriously impact the performance of other applications. These limits of CPU or Memory usage can be defined for each container in the spec of a Kubernetes Pod/Deployment/StatefulSet.
5. Use of initContainers
An initContainer exhibits an attractive feature. It runs to completion before the main application container is started. For this reason, people see it as a potential helper that can run custom utilities and setup code that is not a part of the main image.
It is a good practice to use initContainers in cases of performing tasks like pulling code from repositories or using commands like ‘sed’, ‘awk’ for setup. It allows eliminating extra layers in the image by not having to include these steps in the image build process.
6. Use readiness & liveness Probes
Kubernetes Probes are defined for Pods. Readiness Probe checks whether a pod is ready to accept traffic or not. A Pod is considered ready when all of its containers are ready. This information is important as it is used to decide whether or not to add a Pod from the list of load-balanced servers behind a Kubernetes Service.
Liveness Probes helps restart a Pod in case it does not give a healthy response. Sometimes applications break and besides restarting, there is no other option. Liveness Probe is useful in that case.
It should also be acknowledged that the default value of periodSeconds(how often to perform the probe) is 10 seconds and the initialDelaySeconds(number of seconds to wait after the container has started to perform the probe) is 0.
These values are not suitable for every situation. Heavy applications that you suspect will take time to start should not undergo unnecessary restarts. Thus, each of the values along with the type of liveness Probe(liveness command, liveness HTTP request, TCP liveness probe) should be custom set.
7. Monitoring & Logging
Keeping an eye on the Kubernetes Cluster produces better management and quicker debugging in times of a breakdown. Hence, one should have a reliable monitoring and logging mechanism in place for a transparent view of the entire cluster.
That’s a wrap.
Every tool serves a purpose and Kubernetes is a game-changer in the world of containerization. Adhering to some specific practices ensures that we leverage the best capabilities in the best possible way.
