Metrics in Kubernetes

External

• https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/

Internal

• Kubernetes Resource Management Concepts
• Kubernetes Concepts
• Kubernetes Autoscaling Concepts
• Prometheus

Overview

Application health monitoring, resource consumption monitoring and scaling decisions require metrics to be collected and analyzed. Kubernetes facilitates metrics collection from containers, pods, services and the overall cluster via metric pipelines.

Metric Pipelines

A metric pipeline is a solution that allows metrics collection, propagation, possibly storage, and publishing. In Kubernetes, application monitoring does not depend on a single monitoring solution. Kubernetes allows for different types of metric pipelines: resource metrics pipelines and full metrics pipelines.

Resource Metrics Pipeline

https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/

A resource metrics pipeline provides a limited set of metrics - CPU and memory - that are consumed by the Horizontal Pod Autoscaler or kubectl top utility. The metrics are collected from kubelet processes by the lightweight, short-term, in-memory metrics-server and exposed via the Resource Metrics API. Also see:

Kubernetes Metrics Server

Full Metrics Pipeline

https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/#full-metrics-pipeline

A full metrics pipeline provides access to richer metrics than the resource metrics pipeline. The monitoring pipeline fetches metrics from the kubelet or other sources and then exposed them to Kubernetes via an adapter by implementing either the Custom Metrics API or External Metrics API APIs. Prometheus can be used in the implementation of a full metrics pipeline.

Metrics

Metrics are exposed via a metrics API: Resource Metrics API, Custom Metrics API or External Metrics API.

Resource Metrics

A resource metric is a numeric quantity that tracks either the CPU or memory consumed by containers and pods. The "resource" name comes from the fact that requests for such resources are declared in the "resources" section of the pod manifest. By default, the only two supported resource metrics are the CPU utilization and the memory consumed by a container. These resources do not change names from cluster to cluster and they should be available as long the Resource Metrics API is available. These metrics can be either accessed directly by user, for example by using kubectl top command, or used by a controller in the cluster, e.g. Horizontal Pod Autoscaler, to make scaling decisions.

A Resource metric is configured in the Horizontal Pod Autoscaler by specifying the 'Resource' type in the autoscaler's manifest.

CPU

CPU is reported as the average usage, in CPU cores, over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel. The kubelet chooses the window for the rate calculation. More details: https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#cpu

Memory

Memory is reported as the working set, in bytes, at the instant the metric was collected. More details: https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#memory

Resource Metrics API

The Resource Metrics API exposes the amount of resources currently used by a given node or pod. This API does not store the values. The API is discoverable through the same endpoint as the other Kubernetes APIs under /apis/metrics.k8s.io, so it is often referred to as the "metrics.k8s.io" API. The API is served at /metrics/resource/v1beta1 on the kubelet's authenticated and read-only ports. The Resource Metrics API requires the metrics server to be deployed.

kubectl get --raw /apis/metrics.k8s.io/ | jq
kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods | jq
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes | jq

Additional Resource Metrics API documentation:

• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/resource-metrics-api.md
• https://github.com/kubernetes/metrics

Custom Metrics

Aside from resource metrics, there are two other types of metrics, both of which are considered custom metrics: pod metrics and object metrics. Custom metrics track resources used by Kubernetes objects (pods or otherwise). Autoscaling solutions based on custom metrics are natively supported by v2beta2 Horizontal Pod Autoscalers.

Pod Metrics

The Pod metrics, designated by the 'Pods' type in a Horizontal Pod Autoscaler manifest, are used to refer to any other (including custom) metric related to the pod directly. For example, if a pod happens to run a message queue, the number of messages in the broker's queue could be a custom pod metric. The essential difference from a Object metric, described below, is that metrics for all pods involved are read and averaged. Also see:

How Horizontal Pod Autoscaler Works

Object Metrics

Object metrics track resources describe different objects in the same namespace, instead of describing pods. For example, pods may be scaled according to a metric of another cluster object, such as an Ingress, such as average request latency. The essential difference from a Pod metric is that for an Object metric, the autoscaler does not need to pull values for all pods and average those, it only needs to read the metric from a single object. An Object metric is designated by the 'Object' type in the Horizontal Pod Autoscaler manifest. Also see:

How Horizontal Pod Autoscaler Works

Custom Metrics API

The API is discoverable through the same endpoint as the other Kubernetes APIs under /apis/custom.metrics.k8s.io, so it is often referred to as the "custom.metrics.k8s.io" API. The custom metrics API is provided by "adapter" API servers provided by metrics solution vendors. Monitoring systems like Prometheus expose application-specific metrics to the Horizontal Pod Autoscaler controller via the Custom Metrics API.

TODO:

• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md
• https://github.com/kubernetes-sigs/custom-metrics-apiserver
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md

External Metrics

An external metric is a metric that do not have an obvious relationship to any object in Kubernetes, such as metrics describing a hosted service with no direct correlation to a Kubernetes namespace. When possible, it's preferable to use the custom metrics instead of external metrics, since it is easier for cluster administrators to secure the custom metrics API. The external metrics API potentially allows access to any metric, so cluster administrators should take care when exposing it.

TODO:

• https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects

Also see:

How Horizontal Pod Autoscaler Works

External Metrics API

The API is discoverable through the same endpoint as the other Kubernetes APIs under /apis/external.metrics.k8s.io, so it is often referred to as the "external.metrics.k8s.io" API. TODO:

• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md

Sources of Metrics

kubelet

kubelet exposes metrics collected by cAdvisor:

kubelet Metrics Collection

Kubernetes Metrics Server

Kubernetes Metrics Server

Prometheus

Prometheus

Quantities

TODO:

• https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#appendix-quantities
• https://kubernetes.io/docs/reference/glossary/?all=true#term-quantity