深刻理解kubernetes容器指标

经过cAdvisor收集容器指标

Google的cAdvisor项目最初是一个独立项目，用于从节点上收集运行的容器的资源和性能指标。在Kubernetes中，cAdvisor嵌入到kubelet中。kubelet控制着集群中每一个节点上的全部容器。这就很方便了，由于不须要在每一个节点中都运行另外一个进程来收集容器指标。

kubelet以Prometheus指标格式在/metrics端点上公开了全部运行时指标和全部cAdvisor指标。

从cAdvisor提供的“容器”度量标准最终是底层Linux cgroup提供报告的度量标准。就像节点指标同样，它们众多且详细。可是，咱们关注基础节点提供的资源的容器使用。具体来讲，咱们对CPU，内存，网络和磁盘感兴趣。一样，在处理资源时，最好在选择这些指标的报告时使用USE方法。

容器指标概述

因为这些度量标准的来源从节点（node_exporter）更改成容器（cAdvisor），所以度量标准的名称也将更改。此外，每一个指标都是集群中全部容器的报告。要得到应用程序的总体视图，必须在Prometheus中使用sum方法。

在开始讨论各个资源指标以前，咱们须要讨论Kubernetes中的一项功能，该功能将使饱和度的计算更加容易。此功能是资源“requests”和“limits”。

Requests 和 Limits

Kubernetes系统的核心是一个调度程序，它将容器调度在节点上。就像用不一样大小的物品包装一堆不一样大小的盒子同样，调度程序须要知道节点的容量以及放在这些节点上的容器的大小。在不知道容器的“大小”的状况下，您能够轻松地对群集中的节点进行过分配置，从而由​​于拥挤而致使性能问题。

请求和限制将做为部署的一部分应用于容器规范。从Kubernetes 1.10开始，能够设置两种资源类型的请求和限制; CPU和内存。将CPU指定为core数，并以字节为单位指定内存。

请求是对容器将须要的最少资源量。请求并无说明您将使用多少资源，而是须要多少资源。您正在告诉调度程序容器需​​要多少资源来完成其工做。请求由Kubernetes调度程序用于调度。对于CPU请求，它们还用于配置Linux内核如何调度容器。

限制是您的容器将要使用的最大资源量。限制必须大于或等于请求。若是仅设置限制，则请求将与限制相同。

限制容许容器有必定的余量来超过资源请求。限制为您提供了一个旋钮，能够过分使用节点上的资源，由于Kubernetes调度程序不考虑限制。话虽如此，若是您的容器超出了限制，则操做取决于资源；若是您超过CPU限制，将受到限制；若是超过内存限制，将被杀死。

CPU Utilization, Saturation, 和 Errors

对于CPU利用率，Kubernetes仅为咱们提供了每一个容器的三个指标:

1. container_cpu_user_seconds_total--“user”时间总数（即，不在内核中花费的时间）
2. container_cpu_system_seconds_total--“system”时间的总数（即在内核中花费的时间）
3. container_cpu_usage_seconds_total--以上的总和。在Kubernetes 1.9以前的版本中，将为全部节点中的每一个CPU报告此错误。在1.10中发生了变化。

全部这些指标都是计数器，须要对其应用rate。该查询将为咱们提供每一个容器正在使用的核心数。对于整个系统中该名称的全部容器：

sum(
    rate(container_cpu_usage_seconds_total[5m]))
by (container_name)

当使用CPU限制运行时，因为定义了CPU使用上限，饱和度的计算变得容易得多。当容器超出其CPU限制时，Linux运行时将“限制”该容器并在container_cpu_cfs_throttled_seconds_total系列中记录其被限制的时间。再次按容器跟踪每一个容器，所以采用一个比率：

sum(
    rate(container_cpu_cfs_throttled_seconds_total[5m])) 
by (container_name)

这是跟踪具备CPU限制的运行时间的重要指标。

就像node_exporter同样，cAdvisor不会暴露CPU错误。

内存 Utilization, Saturation 和Errors

cAdvisor中跟踪的内存指标是从node_exporter公开的43个内存指标的子集。如下是容器内存指标：

container_memory_cache -- Number of bytes of page cache memory.
container_memory_rss -- Size of RSS in bytes.
container_memory_swap -- Container swap usage in bytes.
container_memory_usage_bytes -- Current memory usage in bytes,       
                                including all memory regardless of
                                when it was accessed.
container_memory_max_usage_bytes -- Maximum memory usage recorded 
                                    in bytes.
container_memory_working_set_bytes -- Current working set in bytes.
container_memory_failcnt -- Number of memory usage hits limits.
container_memory_failures_total -- Cumulative count of memory 
                                   allocation failures.

您可能认为能够经过container_memory_usage_bytes轻松跟踪内存利用率，可是，该指标还包括能够在内存压力下驱逐的缓存（认为是文件系统缓存）项。更好的指标是container_memory_working_set_bytes，由于这是OOM杀手正在关注的对象。

要计算容器的内存利用率，咱们使用：

sum(container_memory_working_set_bytes{name!~"POD"})
  by (name)

在上述查询中，咱们须要排除名称中包含“POD”的容器。这是此容器的父级cgroup，将跟踪pod中全部容器的统计信息。

在有内存限制的状况下运行时，容器的内存饱和度会变得更容易。咱们将从饱和度定义饱和度为可用内存量：

sum(container_memory_working_set_bytes) by (container_name) / sum(label_join(kube_pod_container_resource_limits_memory_bytes,
    "container_name", "", "container")) by (container_name)

在这里，咱们必须加入两个系列，一个来自cAdvisor，一个来自kube-state-metrics。不幸的是，容器名称标签没有对齐，可是PromQL在这里可使用label_join帮助。

kubelet不会暴露内存错误。

磁盘 Utilization, Saturation, 和Errors

在处理磁盘I / O时，咱们首先经过查找以及读取和写入跟踪全部磁盘利用率。 cAdvisor具备针对container_fs_io_time_seconds_total和container_fs_io_time_weighted_seconds_total的系列。这些应该在节点级别跟踪类似的指标，可是在个人安装中，它们始终为零。

最基本的磁盘I/O利用率是读/写的字节数：

sum(rate(container_fs_writes_bytes_total[5m])) by (container_name,device)
sum(rate(container_fs_reads_bytes_total[5m])) by (container_name,device)

对这些求和求和，以得到每一个容器的整体磁盘I/O利用率。

Kubelet没有公开足够的细节，没法对容器磁盘饱和或错误进行有意义的查询。

网络 Utilization, Saturation 和Errors

您能够在容器级别的网络利用率之间进行选择，以字节或数据包为单位进行发送和接收。该查询有些不一样，由于全部网络记账都在Pod级别上进行，而不是在容器上进行！

此查询将按Pod名称显示每一个Pod的网络利用率：

sum(rate(container_network_receive_bytes_total[5m])) by (name)
sum(rate(container_network_transmit_bytes_total[5m])) by (name)

一样，在不知道最大网络带宽是多少的状况下，网络的饱和度定义不明确。您也许可使用丢弃的数据包做为代理。 cAdvisor会同时提供container_network_receive_packets_dropped_total和container_network_transmit_packets_dropped_total。

cAdvisor还将显示系列container_network_receive_errors_total和container_network_transmit_errors_total的错误数量。