Kubernetes Best Practices to Follow

Kubernetes is one of the most widely used and popular container orchestration systems available in the market. It helps software development companies to create, maintain, and deploy an application with the latest features as this platform is the de-facto standard for the modern cloud engineer.

This is how Kubernetes master, Google staff developer advocate, and co-author of Kubernetes Up & Running (O’Reilly) Kelsey Hightower acknowledges it:

“Kubernetes does the things that the very best system administrator would do: automation, failover, centralized logging, monitoring. It takes what we’ve learned in the DevOps community and makes it the default, out of the box.” – Kelsey Hightower

In a cloud-native environment, many of the more common sysadmin duties, such as server upgrades, patch installations, network configuration, and backups, are less important. You can let your staff focus on what they do best by automating these tasks with Kubernetes. The Kubernetes core already has some of these functionalities, such as auto scaling and load balancing, while other functions are added via extensions, add-ons, and third-party applications that utilize the Kubernetes API. There is a huge and constantly expanding Kubernetes ecosystem.

Though Kubernetes is a complex system to work with, there are some of its practices that can be followed to have a solid start with the app development process. These recommendations cover issues for app governance, development, and cluster configuration. 

1. Kubernetes Best Practices

Here are some of the Kubernetes best practices developers can follow:

1.1 Kubernetes Configuration Tips

Here are the tips to configure Kubernetes:

• The very first thing to do while defining Kubernetes configurations is to specify the latest version of the stable API.
• Then the developer must see that the configuration files are getting saved in the version control before they get pushed to the Kubernetes cluster. This thing will help the development team to roll back changes in a configuration quickly and also help in the restoration and re-creation of a cluster.
• Another tip to configure Kubernetes is that objects must be grouped into a single file whenever it is possible. This helps in managing files easily.
• The developer must write the application configuration files by using  YAML technology rather than JSON. These formats can be interchanged and used in the majority of situations, but YAML is more user-friendly.
• Another tip for configuring Kubernetes is to use many kubectl commands by calling them on a directory.
• The developer must put the description in annotations if he wants to offer better introspection.
• When values are specified without requirements, even the minimal and simple configuration makes errors.

1.2 Use the Latest K8s Version

Another best practice of Kubernetes is to use the latest version. The reason behind it is that the majority of the time, developers worry about having the latest new features in the new Kubernetes version and their unfamiliarity or limited support or incompatibility with the current application setup.

For this, the most important thing to do is to update Kubernetes with the latest version that is stable and offers performance and security to all the issues. Besides this, if any issues are faced while using the latest version, the developers must find community-based support.

1.3 Use Namespaces

Using namespaces in Kubernetes is also a practice that every Kubernetes app development company must follow. For this, the developers of any company must use namespaces to organize the objects of the application and create logical partitions within the Kubernetes cluster to offer high security. In addition to this, Kubernetes comes with three different namespaces Kube-public, Kube-system, and default. In this case, RBAC is used by the developers to control the access of some specific namespaces whenever they need to reduce the group’s access to control the blast radius.

Besides this, in the Kubernetes cluster, even the LimitRange objects can be configured against namespaces. This is done to specify the container’s standard size that needs to be deployed in the namespace. Here, the developers can use ResourceQuotas to limit the total resource consumption.

YAML Example:
# this yaml is for creating namespace
apiVersion: v1
kind: Namespace
metadata:
  name: my-demo-namespace
  labels:
    name: my-demo-namespace
# this yaml is for creating pod in the above created namespace
apiVersion: v1
kind: Pod
metadata:
  name: my-demo-app
  namespace: my-demo-namespace
  labels:
    image: my-demo-app
spec: 
  containers:
    - name: my-demo-app
    image: nginx

1.4 Avoid Using HostPort and HostNetwork

Avoiding the use of hostPort and hostNetwork is another best practice of Kubernetes, here is what can be done with it:First of all the developers must create a service before deployments or ReplicaSets and before any workloads that require access. Now, whenever Kubernetes starts a container, it will offer environment variables that point to the services that are running on the container. For instance, if a service called “foo” is present, then all the containers will get the below-specified variables in their environment:

FOO_SERVICE_HOST=<the host the Service is running on>
FOO_SERVICE_PORT=<the port the Service is running on>

• This implies ordering requirements or services that a Pod requires to access the environment. Here, the DNS must not have any restrictions.
• Besides this, the developers can also add an optional cluster add-on is a DNS server. This will help the DNS server to look after the Kubernetes API for all the new Services that are created. It also helps in creating a set of DNS records for each cluster.
• Another best practice is to avoid the use of hostNetwork along with hostPort. The main reason behind not specifying a hostPort for a Pod is that when a Pod is bound to a hostPort, it will start limiting the number of places the Pod is being scheduled as each combination in the hostPort must be unique.
• The developer must also consider the use of headless services to discover the service when there is no need for kube-proxy load balancing.

1.5 Using kubectl

Using kubectl is also a practice that can be considered by Kubernetes developers. Here, the development team can make use of the following things:

• First of all, the developers must consider using kubectl apply -f <directory>. This is essential for configuring Kubernetes in all .yml, .yaml, and .json files in <directory>.
• Then, Use kubectl create deployment and kubectl expose to quickly create single-container Deployments and Services.
• Here, the label selectors must be used to get and delete operations. This can be used instead of specific object names.

1.6 Use Role-based Access Control (RBAC)

Using RBAC is another best practice that helps develop and create Kubernetes applications with ease. The general approach while working with Kubernetes is that minimal RBAC rights must be assigned to service accounts and users. Only Permissions Explicitly required for the use of operation should be used.  Here, as each cluster will be different, some general rules can be applied to all, and they are:

• Whenever possible, the development team must avoid offering wildcard permissions to all the resources. The reason behind this is that as Kubernetes is an extensible system when rights are given to all object types of the current system version, the object types of the future system version will also be assigned to the users.
• Permission must be assigned at the namespace level if possible by using RoleBindings instead of ClusterRoleBindings to offer rights as per the namespace.
• The development team must avoid adding users to the master group of the system as any user who is a member of this group gets the authority to bypass all the RBAC rights.
• Unless it is not required, cluster-admin accounts must not be used by the administrators. The reason behind this is that when the low-privileged account is offered with impersonation rights, it can help avoid accidental modification of cluster resources.

YAML Example:
# this yaml is for creating role named “pod-reading-role”
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reading-role
rules:
- apiGroups: [""]      # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

# This yaml is for creating role binding that allows user "demo" to read pods in the "default" namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: demo-user-read-pods
  namespace: default
subjects:
- kind: User
  name: demo    #name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reading-role   # this must match the name of the Role
  apiGroup: rbac.authorization.k8s.io

1.7 Follow GitOps Workflow

Another Kubernetes best practice is to follow GitOps workflow. This means that to have a successful deployment of Kubernetes, developers must give thought to the workflow of the application. For this, the use of git-based workflow is an ideal choice as it helps in offering automation by using CI/CD (Continuous Integration / Continuous Delivery) pipelines. This also helps in increasing the application deployment process with efficiency. In addition to this, when CI/CD is used, it tends to offer an audit trail to the developers for the software deployment process.

1.8 Don’t Use “Naked” Pods

Not using naked pods is another best practice that must be considered. Here, there are a few points to look out for and they are as below:

• Naked pods must not be used if avoidable as it will not be rescheduled if the node fails in an event.
• Generally, deployment helps in creating a ReplicaSet to make sure that the number of Pods that are required are available and specifying a strategy that can help in replacing Pods. In this case, naked pods can create an issue.

YAML Example:
apiVersion: apps/v1
kind: Deployment
metadata:
   name: my-demo-deployment
spec:
   template:
      metadata:
         name: my-demo-app
         namespace: my-demo-namespace
	     labels:
            image: my-demo-app
      spec:
         containers:
          - name: my-demo-app
            image: nginx

1.9 Configure Least-Privilege Access to Secrets

Configuring least-privilege access to secrets is also a best practice as it helps developers plan the access control mechanism like Kubernetes RBAC (Role-based Access Control). In this case, the developers must follow the below-given guidelines to access Secret objects.

• Humans: In this case, the software development teams must restrict watch, get, or list access to Secrets. Cluster administrators are the only ones that should be allowed access.
• Components: Here, the list or watch access must be restricted access to only the most privileged components of the system.

Basically, in Kubernetes, the user who has access to create a Pod uses a Secret and can see the value of that particular Secret. Here, even if the Kubernetes cluster default policies don’t allow the user to react to the Secret, the same user can get access to the Secret when he runs the Pod. For this, limiting the impact caused by Secret data exposure is why the following recommendations should be considered:

• Implementation of audit rules that alert the admin on some specific events.
• Secrets that are used must be short-lived.

1.10 Use Readiness and Liveness Probes

Readiness and Liveness probes are known as the most important parts of the health checks in Kubernetes. They help the developers to check the health of the application.

A readiness probe is a popular approach that enables the development team to make sure that the requests sent to a pod are only directed when the pod is ready to serve it. If the pod is not ready to serve a request, it should be directed somewhere else. On the other hand, the Liveness probe is a concept that helps in testing if the application is running as expected by the health check protocols.

YAML Example:
apiVersion: apps/v1
kind: Deployment
metadata:
   name: my-demo-deployment
spec:
   template:
      metadata:
         name: my-demo-app
         namespace: my-demo-namespace
	     labels:
            image: my-demo-app
      spec:
         containers:
          - name: my-demo-app
            image: nginx:1.14.2
            readinessProbe:
               httpGet:
                  path: /ready
                  port: 9090
	   initialDelaySeconds: 30
	   periodSeconds: 5
	livenessProbe:
               httpGet:
                  path: /health
                  port: 9090
	   initialDelaySeconds: 30
	   periodSeconds: 5

1.11 Use a Cloud Service to Host K8s

Kubernetes cluster hosting on the hardware can be a bit complex but its cloud services can offer platform as a service (PaaS) like EKS (Amazon Elastic Kubernetes Service) on Amazon Web Services and AKS (Azure Kubernetes Service) on Azure. This means that the infrastructure of the application can be handled by the cloud provider along with other tasks like adding and removing nodes from the cluster can also be achieved by cloud services.

1.12 Monitor the Cluster Resources

Another Kubernetes best practice is to monitor cluster resource components in the Kubernetes version control system to keep them under control. As the control plane is known as the core of the Kubernetes, these components can help in keeping the system up and running. Besides this, Kubelet, Kubernetes API, controller-manager, etcd, kube-dns, and Kube-proxy make up the control plane.

1.13 Secure Network Using Kubernetes Firewall

The last in our list of Kubernetes best practices is securing the network using a Kubernetes firewall and using network policies to restrict internal traffic. When the firewall is put in front of the Kubernetes cluster, it will help restrict resource requests that are sent to the API server.

2. Conclusion

As seen in this blog, many different best practices can be considered to design, run, and maintain the Kubernetes cluster. These practices help developers in putting modern applications into the world. But which practice to put into action and which practice will help the application become a success needs to be decided by the Kubernetes app developers for which the engineers need to be experts in Kubernetes.

3. FAQs:

What is the main benefit of Kubernetes?

Some of the main benefits of Kubernetes are efficient use of namespaces, robust security through Firewall & RBAC, and monitoring control panel components. 

How do I improve Kubernetes?

To improve Kubernetes performance, the developer needs to focus on using optimized container images, defining resource limits, and more. 

What is a cluster in Kubernetes?

In Kubernetes, the cluster is an approach that contains a set of worker machines called nodes. 

What is the biggest problem with Kubernetes?

The biggest issue with Kubernetes is its vulnerability and complexity.