Kubernetes调研

1. 简介

Kubernetes是Google开源的容器集群管理系统,其提供应用部署、维护、 扩展机制等功能,利用Kubernetes能方便地管理跨机器运行容器化的应用,其主要功能如下:

  • 使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。
  • 以集群的方式运行、管理跨机器的容器。
  • 解决Docker跨机器容器之间的通讯问题。
  • Kubernetes的自我修复机制使得容器集群总是运行在用户期望的状态。

2. 主要概念

框架图

图2-1 Kubernete框架图

Kubernetes Master

集群拥有一个Kubernetes Master。Kubernetes Master提供集群的独特视角,并且拥有一系列组件,比如Kubernetes API Server。master节点包括用来创建和复制Pod的Replication Controller。

API Server

API Server提供可以用来和集群交互的REST端点,其核心功能为提供了对Kubernetes各类资源对象的增、删、改、查以及Watch等HTTP REST接口,为集群内各个功能模块之间的数据交互和通信的中心枢纽,其还有以下的功能特征

  • 集群管理的API入口
  • 资源配额控制的入口
  • 提供了完备的集群安全机制
Replication Controller

Replication Controller确保任意时间都有指定数量的Pod“副本”在运行。

  • 如果为某个Pod创建了Replication Controller并且指定3个副本,它会创建3个Pod,并且持续监控它们。如果某个Pod不响应,那么Replication Controller会替换它。
  • 如果之前不响应的Pod恢复了,现在就有4个Pod了,那么Replication Controller会将其中一个终止保持总数为3。
  • 如果在运行中将副本总数改为5,Replication Controller会立刻启动2个新Pod,保证总数为5。还可以按照这样的方式缩小Pod,这个特性在执行滚动升级时很有用。

Service

Service是定义一系列Pod以及访问这些Pod的策略的一层抽象服务。Service通过Label找到Pod组。

现在,假定有2个后台Pod,并且定义后台Service的名称为backend-service,该Service会完成如下两件重要的事情:

  • 会为Service创建一个本地集群的DNS入口,因此前端Pod只需要DNS查找主机名为backend-service,就能够解析出前端应用程序可用的IP地址。
  • 现在前端已经得到了后台服务的IP地址,但是它应该访问2个后台Pod的哪一个呢?Service在这2个后台Pod之间提供透明的负载均衡,会将请求分发给其中的任意一个。通过每个Node上运行的代理(kube-proxy)完成。
图2-2 Service

Node

节点是物理或者虚拟机器,作为Kubernetes worker,通常称为Minion。每个节点都运行如下Kubernetes关键组件:

  • Kubelet:是主节点代理。
  • Kube-proxy:Service使用其将链接路由到Pod,如上文所述。
  • Docker或Rocket:Kubernetes使用的容器技术来创建容器。
Pods

Pod为Kubernetes操作的基本单元,把相关的一个或者多个容器构成一个Pod。通常Pod里运行相同的应用。一组共享相同的Volumes以及网络命名空间的IP和Port。

Label

Labels是用于区分Pod、Service、Replication Controller的key/value键值对,Pod、Service、 Replication Controller可以有多个label,但是每个label的key只能对应一个value。

Labels是Service和Replication Controller运行的基础,为了将访问Service的请求转发给后端提供服务的多个容器,正是通过标识容器的labels来选择正确的容器。

Replication Controller也使用labels来管理通过pod 模板创建的一组容器,这样Replication Controller可以更加容易,方便地管理多个容器,无论有多少容器。

kubelet

在Kubernetes集群中,每个节点都会启动一个kubelet服务进程,该进程用于处理Master节点下发到本节点的任务,管理Pod以及Pod中的容器。每个Kubelet进程会在API Server上注册节点自身的信息,定期向Master回报节点资源的使用情况,并通过cAdvisor监控容器和节点资源。

kube-proxy

Service为Kubernetes的抽象概念,kube-proxy为一个反向代理,将客户端访问的请求,负责转发到后方的Pod。

在Kubernetes集群中,每个节点都会运行一个kube-proxy服务,其核心的功能是将某个Service的访问转发到后端的多个Pod实例上。


3. 监控框架调研

Kubernetes监控工具Heapster

简介

Heapster是容器集群监控和性能分析工具,天然的支持Kubernetes和CoreOS。

Kubernetes有个出名的监控agent—cAdvisor。在每个kubernetes Node上都会运行cAdvisor,它会收集本机以及容器的监控数据(cpu,memory,filesystem,network,uptime),每个Node上的cAdvisor进行汇总,然后导到第三方工具(如InfluxDB)。

框架

在较新的版本中,Kubernetes已经将cAdvisor功能集成到kubelet组件中,每个Node节点可以直接进行web访问。

图3-1 Heapster框架
  • Heapster首先从K8S Master获取集群中所有Node的信息
  • 通过这些Node上的kubelet获取有用数据,而kubelet本身的数据则是从cAdvisor得到
  • 所有获取到的数据都被推到Heapster配置的后端存储中,并还支持数据的可视化,后端存储 + 可视化的方法,如InfluxDB + grafana
使用

Heapster可获取的Metrics。

描述 分类
cpu/limit cpu预设值,yaml文件可设置 瞬时值
cpu/node_reservation kube节点的cpu预设值,类似cpu/limit 瞬时值
cpu/node_utilization cpu利用率 瞬时值
cpu/request cpu请求资源,yaml文件可设置 瞬时值
cpu/usage cpu使用 累计值
cpu/usage_rate cpu使用速率 瞬时值
filesystem/limit 文件系统限制 瞬时值
filesystem/usage 文件系统使用 瞬时值
memory/limit 内存限制,yaml文件可设置 瞬时值
memory/major_page_faults 内存主分页错误 累计值
memory/major_page_faults_rate 内存主分页错误速率 瞬时值
memory/node_reservation 节点内存预设值 瞬时值
memory/node_utilization 节点内存使用率 瞬时值
memory/page_faults 内存分页错误 瞬时值
memory/page_faults_rate 内存分页错误速率 瞬时值
memory/request 内存申请,yaml文件可设置 瞬时值
memory/usage 内存使用 瞬时值
memory/working_set 内存工作使用 瞬时值
network/rx 网络接收总流量 累计值
network/rx_errors 网络接收错误数 不确定
network/rx_errors_rate 网络接收错误数速率 瞬时值
network/rx_rate 网络接收速率 瞬时值
network/tx 网络发送总流量 累计值
network/tx_errors 网络发送错误数 不确定
network/tx_errors_rate 网络发送错误数速率 瞬时值
network/tx_rate 网络发送速率 瞬时值
uptime 容器启动时间,毫秒 瞬时值

参考资料:
API文档: https://github.com/kubernetes/ … el.md
Metrics: https://github.com/kubernetes/ … ma.md

总结
  • 对于较大规模的k8s集群,heapster目前的cache方式会吃掉大量内存。
  • 因为要定时获取整个集群的容器信息,信息存储在内存会成为问题,再加上heaspter要支持api获取临时metrics。
  • 如果将heapster以pod方式运行,很容易出现OOM。所以目前建议关掉cache,并以standalone的方式独立出k8s平台, 建议一套K8s,只运行一套heapster容器(heapster1.0版本后内部分为event和metric两个进程)。
  • heapster其抓取的监控数据可以按pod,container,namespace等方式分组

爱奇艺 App Engine 监控框架Dadvisor

简介

爱奇艺 App Engine(iQIYI App Engine,简称 QAE)

dAdvisor,取意 Docker Advisor;dAdvisor 最初有一些监控指标来自于 Docker API,后来完全废弃从 Docker API 读取数据,Docker API 非常脆弱,包括 Docker Daemon,时常卡住。所以 dAdvisor 的监控数据也都直接来自于 cgroups 数据。

框架
图3-2 QAE 监控和预警

Docker 的最佳实践不推荐在容器中运行多个进程,QAE也遵守这个最佳实践,将容器的监控实现在了容器外部,即计算节点上。

  • 每个计算节点上有一个容器的监控 agent 叫 dAdviser
  • dAdviser会负责监控所有 QAE 容器,并且采集包括 CPU、内存、磁盘、网络上/下行速率等基础数据
  • 收集的基础数据通过使用 Graphite 的聚合功能,将属于同一个应用的所有监控数据聚合成应用的数据
  • 应用的监控也非常重要,因为一个业务通常由多个容器组成,所以这里需要监控例如:每个容器的状态,是否健康,所有容器数量,不健康容器占总数的比例;整个业务的流量情况,QPS 是多少等等。有了容器和应用的监控数据后,就可以基于这些数据配置报警了,在报警方面,QAE 对接了一个内部报警平台,支持多个渠道报警
日志框架
图3-2 QAE 日志

与监控类似,QAE日志采用容器外采集方案,在每个节点上,部署运行一个log-agent来负责采集日志。

特点
  • 采集:CPU、内存、磁盘、网络
  • 集成现有 Graphite 服务
  • 统计数据方便(Graphite 内置一些聚合操作符)
  • 呈现方便(Graphite Render URL API)
  • 开发量不大

Zabbix容器监控

简介

Zabbix 作为老牌的基础监控软件,应用非常广泛,但是,对于容器的快速兴起,Zabbix 并没有准备好

问题
  • 在镜像安装 Zabbix 这个 footprint 比较大,因为在一个计算节点上往往需要运行多个容器,而 Zabbix 占用资源也不小,另外也不符合 Docker 最佳实践
  • Zabbix 的数据统计/聚合比较复杂,因为 Zabbix 是为单机设计的,也就是这里的单个容器,而对于容器化的业务来说,整个业务的监控指标实际比单个容器的指标更为重要

修订版本

修订版本 时间 备注
文档创建 2017/6/6 13:26 文件创建