Kubernetes is a powerful tool that greatly simplifies the process of deploying complex containerized applications at scale. Yet, like any powerful software platform, Kubernetes must be monitored effectively in order to do its job well. Without the right Kubernetes monitoring tools and procedures in place, teams risk sub-optimal performance or even complete failure of their Kubernetes-based workloads.
To help get started building and implementing a Kubernetes monitoring strategy, this page breaks down the different parts of Kubernetes and explains how to monitor each. It also discusses key Kubernetes monitoring metrics and offers tips on best practices that will help you get the most out of your Kubernetes monitoring strategy.
Introduction to Kubernetes
Kubernetes is composed of many different parts. To monitor Kubernetes successfully, you first need to understand what each of these parts does and how they fit together to comprise the complete Kubernetes platform.
Anatomy of Kubernetes
Here's a breakdown of the various pieces that form Kubernetes:
- Nodes: Individual servers running within a Kubernetes environment. Nodes provide the basic host infrastructure for Kubernetes. They can be physical or virtual machines.
- Clusters: A cluster is a set of servers that host a Kubernetes workload. Each Kubernetes cluster must contain at least one so-called master node (which runs the services that glue the rest of the cluster together). The rest of the cluster is comprised of worker nodes, which provide additional infrastructure resources. Typically, there is one cluster per Kubernetes installation, although it's possible to have multiple clusters within the same installation using the federation model.
- Namespaces: Namespaces allow you to define which users (or groups) can access which resources within a cluster. You can divide your Kubernetes cluster into namespaces in order to allow multiple users to share the same cluster in a secure way. Namespaces allow you to share a cluster among multiple users, instead of having to create separate clusters for each user.
- Pods: Groups of containers that are deployed to host a specific application. A pod could consist of just one container, or it could include multiple containers (such as one that hosts an application frontend, and another that facilitates access to the application data).
- ReplicaSet: A policy that you can optionally be set to tell Kubernetes to maintain a certain number of copies of the same pod.
- Deployment: A set of configuration options that tell Kubernetes how a given workload should run. Deployments include ReplicaSet specifications as well as other options.
- DaemonSets: A configuration policy that can be set to tell Kubernetes to run a copy of a pod on all nodes, or only on certain nodes. Normally, Kubernetes makes determinations about pod placement automatically, but you can use a DaemonSet to govern this behavior.
- Services: Groups of pods that host copies of the same workload. By mapping different workloads to each other based on Services instead of individual pods, you ensure that your workloads keep communicating with each other even if one pod instance is replaced by another.
Kubernetes can run on many different types of infrastructure. It works with physical servers or virtual servers running in an on-premises data center. Kubernetes can also be hosted in the cloud. You can even run it on a PC or laptop using a specialized distribution like MicroK8s or K3s, which are designed to let you set up Kubernetes environments on a local workstation for testing or learning purposes. (You would not want to host a production workload this way.)
Kubernetes is primarily a Linux technology, and master nodes have to run on Linux-based servers. However, worker nodes can be Windows or Linux systems.
Each node in a Kubernetes cluster runs a few key pieces of software, which serve to allow nodes to communicate with each other and host containerized applications:
Kubelet: An agent that allows worker nodes to communicate with the master node. The agent lets the master check to see which worker nodes are running, and it lets nodes send and receive data.
Kube Proxy: This component provides the basis for Kubernetes Services, enabling reliable and consistent communication between pods.
Container runtime software: The software that executes individual containers. Docker is the most widely known container runtime, but Kubernetes can work with a variety of other runtimes, such as rkt and runc.
Kubernetes Control Plane
Beyond software running on individual nodes, there are a few other essential software components in a Kubernetes installation. Typically, these run on the master node:
- API Server: This server exposes the Kubernetes API, which lets users interact with the Kubernetes cluster.
- Etcd: A key-value store that houses all of the data the Kubernetes cluster needs to run.
- Scheduler: This service watches for new pods and assigns them to nodes.
- Controller Manager: Software that continuously monitors Kubernetes configurations and checks them against the actual state of the cluster. When these items do not match, the Controller takes steps to correct them. In this way, Kubernetes enables a declarative approach to software management in which users create configurations that specify how the software should behave, and the software conforms to those configurations automatically.
Benefits of Kubernetes
Kubernetes offers a range of benefits. The most obvious is that it automates complex tasks that human admins would otherwise have to perform by hand, such as starting and stopping containers or deciding which nodes to host containers on. In a large-scale environment composed of dozens of containers and servers, an automation tool like Kubernetes is the only way to manage the environment effectively.
But Kubernetes's features go beyond simple orchestration. As noted above, it also allows admins to take a declarative approach to software management. This means that admins can simply specify what they want to happen, and Kubernetes figures out how to make it happen on its own. This approach is simpler, and less prone to oversights than a so-called imperative approach, in which admins would have to specify manually how each component of the software environment should operate.
Kubernetes also offers some security benefits. It provides certain features, including role-based access control and pod security settings that allow admins to build in security protections for workloads running on a Kubernetes cluster. This does not mean that Kubernetes is a security tool, or that Kubernetes alone delivers full security; it doesn't, and admins should take extra steps to protect against vulnerabilities that Kubernetes can't address (such as malicious code inside containers, or vulnerabilities on host operating systems). Still, the security features that Kubernetes offers provide some advantages that would not exist if you attempted to orchestrate your containers manually.
Finally, it is arguably an advantage that Kubernetes is a fully open-source platform, and as such is compatible with a wide range of host environments and third-party tools. The risk of being locked into one vendor is low if you use Kubernetes. Even if you adopt a Kubernetes distribution that is tied to a particular vendor (like OpenShift, which is a Red Hat platform; or Rancher), you can always migrate to a different Kubernetes distribution if you choose while taking most of your existing configuration with you.