Kubernetes Metrics Server

With a system as large and complicated as Kubernetes, monitoring can often become troublesome.Monitoring is always a tricky business because on one hand you don’t want to miss out on critical bugs and failures on the other hand you don’t want to get drowned into an ocean of trivial errors being triggered not because of your application nor affecting it in anyway.

With its own stack of schedulers and controllers, Kubernetes can recover from minor failures, nodes failing or apps crashing from inside their pods. However, if a lot of crashes happen it may have nothing to do with the infrastructure but everything to do with your app which Kubernetes may try to restart over and over, but since the code is at fault the fault will persist and may even go unnoticed.

The kind of bugs that go unnoticed most of the times are the ones where apps don’t crash but end up over utilizing system resources and hurting the clusters over all performance. These are the especially nasty cases and Kubernetes Metrics Server can be a useful tool in keeping an eye on them.

The project is officially a part of Kubernetes project but doesn’t come pre-enabled in most Kubernetes-certified distros. It has two important parts worth discussing the Metrics API and the Metrics Server itself. But first let’s provision it onto our Kubernetes (K8) cluster.

An Experimental Kubernetes Setup

As of July 2018, Docker for Mac and Windows both come with a Kubernetes certified implementation of K8 itself. Making it as easy as installing K8 on a Linux distro. You can go to Docker Settings and if the Docker instance is up-to-date you will find a Kubernetes tab in the menu. Just enable Kubernetes instead of Docker Swarm and you will have a single node cluster up and running ready for experimentations.

Next, we need some simple set of applications up and running for our use case. Create a folder called Deployments and inside it let’s create a nginx-deployment.yaml files which would deploy stateless Nginx pods.

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
: Deployment
: nginx-deployment
: nginx
: 2 # tells deployment to run 2 pods matching the template
: nginx
– name
: nginx
: nginx:1.7.9
– containerPort
: 80

Save the file and in the same directory where this file is, run the command:

$ kubectl create -f nginx-deployment.yaml

We might have to wait a few minutes to let Kubernetes download the container images, provision the containers and do a bit of miscellaneous bookkeeping. Once that is done you can see the list of pods as:

$ kubectl get pods

As you can see we have two instances of the pod, as the .yaml file had prescribed.

Now that we have something to monitor we need to enable Metrics Server. First, check the version of Kubernetes that you are running. If the version is 1.8 or above then we would run a different deployment and if it is 1.7 then we resort back to the legacy one :

$ kubectl version

You can get the official image and get started by cloning this GitHub repo and then inside the repository’s root run the kubectl create -f with the appropriate .yaml depending on the K8 version that you are running.

$ git clone https://github.com/kubernetes-incubator/metrics-server.git
$ cd metrics-server
# If you are running Kubernetes version 1.8 or higher
$ kubectl create -f deploy/1.8+/
# If the version is 1.7, then
$ kubectl create -f deploy/1.7/

Give the kubernetes a while to download the images and spin up the metrics server. It might take a few minutes. Once that is done, you are now ready to run the metrics server. The basic command is inspired from the top command that is often run to monitor a Linux system. But it has two variants one for check the resource utilizations on the compute nodes and second to gauge the resource consumed by the deployed pods and the. Here’s how to see those two details:

$ kubectl top node
$ kubectl top pod

You can see how much a pod is taxing your system in terms of memory or CPU time and using the Metrics API you can set up alerts according, as well.

Where will it go from here?

The emerging use cases from the metrics server are going to be crucial in the future of Kubernetes. This project is still in version 0.2.x, once it matures and gets integrated into the mainstream Kubernetes architecture it will collect important data for the scheduler, helping it efficiently allocate pods to nodes in a much more efficient manner.

Similarly, Horizontal Pod Autoscaler will greatly benefit from the project and will help you scale up or scale down so that the resources are used optimally by the applications.


  1. Nginx Deployments
  2. Kubernetes Metrics Server
  3. Design Docs for the Metrics API can found here and similar you can find information about the Metrics Server here.
ONET IDC thành lập vào năm 2012, là công ty chuyên nghiệp tại Việt Nam trong lĩnh vực cung cấp dịch vụ Hosting, VPS, máy chủ vật lý, dịch vụ Firewall Anti DDoS, SSL… Với 10 năm xây dựng và phát triển, ứng dụng nhiều công nghệ hiện đại, ONET IDC đã giúp hàng ngàn khách hàng tin tưởng lựa chọn, mang lại sự ổn định tuyệt đối cho website của khách hàng để thúc đẩy việc kinh doanh đạt được hiệu quả và thành công.
Bài viết liên quan

Setup a Kubernetes Cluster on DigitalOcean

Kubernetes is one of the few technologies that people struggle with not because it is complicated and hard to understand,...

Kubernetes Horizontal Pod Autoscaler

Pods can be created as stand alone objects, or as a part of a scalable replica set or a deployment. Each of the latter...

Install Minikube on Ubuntu

In this article I will show you how to install Minikube to test and learn Kubernetes locally on Ubuntu. I am using Ubuntu...
Bài Viết

Bài Viết Mới Cập Nhật

Check proxy trên trang nào chuẩn nhất❓

Thuê Proxy chạy Google Ads / Cần chú ý gì khi chọn proxy và email chạy G.G ads?

Thuê proxy 4G ở đâu uy tín, giá rẻ, chất lượng?

Vì sao cần thuê proxy xoay? Địa chỉ cung cấp proxy xoay uy tín

Thuê proxy v6 kéo view Youtube ở đâu uy tín, chất lượng?