漫谈Kubernetes monitoring解决方案

漫谈Kubernetes monitoring解决方案

在云时代，Prometheus基本就是monitoring解决方案的事实上的标准。具体可参考零君以前写的一篇关于用Prometheus构建云时代的monitoring解决方案的文章（见如下链接）。

Prometheus + Grafana构建云时代的monitoring解决方案

众所周知，Kubernetes基本是云时代最流行（没有之一）的容器、微服务管理平台。那么Kubernetes又是如何解决monitoring问题的呢？与Prometheus有什么区别和联系？这就是本文要探讨的话题。

概述

Prometheus基本最流行的monitoring解决方案平台，而Kubernetes又是最流行的容器、微服务管理平台；相比而言，Kubernetes流行程度、热度远远高于Prometheus。

Scheduler是Kubernetes最核心的业务之一，当Scheduler在决定要将Pod调度到哪一个node时，依据的就是metrics，而metrics就是由monitoring子系统来提供。对于Kubernetes最核心的服务（如Scheduler等）依赖的monitoring子系统，Kubernetes没有依赖第三方的解决方案（如Prometheus），而是完全自己实现的。之所以如此，原因无外乎两点：

1、正如前面所说，Kubernetes不太可能使自己最核心的服务（如Scheduler）依赖于第三方的解决方案；2、通常的monitoring解决方案都是周期性（如30s）的获取各种metrics，而Scheduler对各种metrics的延迟极度敏感，所以On-demand的metrics对Scheduler更有意义。

但是毕竟Kubernetes的定位不是做monitoring的，而且实际应用的需求又五花八门，所以Kubernetes同时也定义了开放接口，以便与第三方monitoring系统集成。

核心metrics接口

Kubernetes的核心metrics接口为metrics.k8s.io，在如下路径下：

/apis/metrics.k8s.io/

核心metrics接口是为Kubernetes自己实现的monitoring子系统设计的。先给出Kubernetes的monitoring实现的架构图，然后再慢慢解释：

首先，metrics的源头来自于每个node上运行的kubelet。其实metrics是由集成到kubelet内的cAdvisor提供的。

关于cAdvisor的详细信息，参考如下链接：https://github.com/google/cadvisor

Summary API是kubelet对外暴露的获取metrics的接口。metrics-server是该系统中的关键服务，它实现了metrics.k8s.io接口，是cluster-wide的metrics数据聚合点；通过Summary API从各个kubelet上获取metrics数据。

关于metrics API，参考如下链接：https://github.com/kubernetes/metrics

metrics-server通过aggregation layer向API server注册。API server收到的任何对metrics.k8s.io接口的查询都会被aggregation layer转发到metrics-server。

关于aggregation layer，参考：https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/关于metrics-server，参考：https://github.com/kubernetes-incubator/metrics-server

图中最上面的三个框中表示是metrics的使用者。HPA是Horizontal Pod Autoscaler，其功能就是根据metrics数据（如CPU，memory使用情况）自动scale目标POD的数量。Scheduler是Kubernetes的核心服务之一，根据收集到的metrics数据决定要将POD调度到哪一个node上。kubectl top则是命令行工具查看metrics数据。

扩展metrics接口

扩展metrics接口包含custom.metrics.k8s.io和external.metrics.k8s.io，分别在如下路径下：：

/apis/custom.metrics.k8s.io//apis/external.metrics.k8s.io/

external metrics API是为了集成k8s cluster之外的metrics。custom metrics adapter也可以实现external.metrics.k8s.io接口。下面主要介绍custom metrics接口。custom metrics接口主要是为了与第三方monitoring系统（如Prometheus）集成。先给出架构图：

Prometheus对外提供了一组HTTP API，具体参考如下链接：

https://prometheus.io/docs/prometheus/latest/querying/api/

而Kubernetes针对custom metrics定义了一套完全不同的API，所以要将Kubernetes与Prometheus集成起来，中间自然就需要一个Adapter，来适配两边的API。上图中的HPA API Adapter就是用来适配Prometheus和Kubernetes的API；其主要功能就是利用Prometheus提供的HTTP API，从Prometheus中查询各种metrics数据，然后转化成Kubernetes理解的custom.metrics.k8s.io接口格式。关于Adapter设计模式，可参考零君以前写的一篇文章《[设计模式] Abstract Server模式与Adapter模式》。

任何人都可以实现自己的API adapter，来集成第三方的monitoring系统，如Prometheus, sensu等。Kubernetes为了开发人员更容易的开发adapter，开发了一个framework（参考如下链接）。基于这个framework，可以更容易的实现custom metrics API。

https://github.com/kubernetes-incubator/custom-metrics-apiserver

而这个framework （custom-metrics-apiserver）的主要开发人员DirectXMan12又基于该framework开发了用于集成Prometheus的adapter，如下：

https://github.com/directxman12/k8s-prometheus-adapter

同样，custom metrics adatper通过aggregation layer向API server注册。API server收到的任何对custom.metrics.k8s.io接口的查询都会被aggregation layer转发到adapter。

HPA的版本autoscaling/v2beta2可以基于CPU、Memory以及custom metrics来auto scaling目标POD。对于custom metrics，就是通过custom.metrics.k8s.io接口来获取metrics。

值得一提的是，metrics-server和custom-metrics-api都作为实验品集成到了prometheus-operator中了，参考如下链接：

https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus/experimental/custom-metrics-api

prometheus-operator也正在尝试针对k8s cluster monitoring提供e2e的解决方案，不过目前还在实验阶段，具体参考：

https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus

总结

Kubernetes与Prometheus之间有千丝万缕的联系。任何project都不可能闭门造车，如何与其它流行的项目集成，从而融入更大的生态圈，对任何project都是至关重要的。但另外一方面，不能无节制的开放融合，也要坚守自己的底线。稍微过度引申一下，这里体现了The Open-Closed Principal，针对自己的核心业务Closed，而针对第三方又Open。具体可参考零君以前写的《面向对象设计的5条原则》

Kubernetes针对自己的 核心业务（如Scheduler）实现了自己的一套monitoring系统，同时又定义了扩展API，用于集成第三方的monitoring系统。不仅如此，还实现了framework，以便使第三方系统更容易与Kubernetes集成。显然，这里体现了The Dependency Inversion Principal；Kubernetes作为一个流行的platform，不可能直接依赖第三方的API，而是定义一套接口，让所以第三方来遵守。

虽然Kubernetes针对Prometheus实现了一个custom metrics adapter。但零君认为开发这个adapter应该是Prometheus团队的工作，所以Kubernetes是替Prometheus开发了这个adapter。其实这是个灰色地带，并不是绝对一定要由某一方开发。Kubernetes的本意是自己指定规则，而由第三方来遵守并实现规则，结果Kubernetes替Prometheus来实现了规则；从这一点也看出Prometheus也业界的地位。Kubernetes的核心模块（如API Server）直接提供Prometheus的metrics也体现了这一点。而Prometheus针对Kubernetes提出了e2e的解决方案，更是体现了Kubernetes在业界的地位。

最后，值得一提的是，Kubernetes主动放弃heapster也是很具有大智慧的。毕竟Kubernetes的核心业务不是做monitoring。明白自己业务的边界，该做什么，不该做什么，这一点很重要。在任何项目中，善于做减法往往更重要。

https://github.com/kubernetes-retired/heapster

--END--