本次内容根据2017年11月4日 K8S Geek Gathering 沙龙深圳站腾讯云高级工程师王天夫的演讲内容整理而成。
本次分享的主要内容涉及腾讯云容器的顶层整体设计，包括产品功能，及提供的附加能力。同时会介绍我们现在Master集群化部署的整体方案。通过这些内容的提前了解，可以更好理解后面和大家分享的关于容器监控的内容，所有监控的设计都是依赖于Master集群化部署的。最后会和大家分享腾讯云容器服务监控的Future Work。
大家可以看一下这个图，这是腾讯云容器服务PaaS平台顶层的设计，最上面是云Portal，意义是用户在使用我们容器服务的时候能够从这几个维度去掌控他们的集群、创建他们的容器。第一个是MC，可以理解为是控制管理台，大家都知道Kubernetes本身的概念是比较复杂的，对一个刚刚接手Kubernetes的人来说理解成本是特别大的，我们在Kubernetes之上包装了它的概念，对于刚刚接手的人来说是非常好的理解。同时可视化出来提供页面给大家用。第二点是支持原生的K8S API，因为整个容器服务是基于K8S开发的，为了保证用户使用不同的Kubernetes，所以我们在Kubernetes主干上并不会去做很大的改动，因为一开始我们是做过这方面的东西，但是我们发现如果我们在K8S上做了特别大的改动，在第二次提供给用户或者升级的时候，是一个非常困难的事情，因为大家知道K8S的迭代是非常快的，大概是半年到一年时间就会升级一个大版本，所以我们基本上都是原生基于K8S开发。最后我们还把我们自己包装的概念通过一个云API提供给用户使用，因为现在很多的用户都是有自己的运营系统的，他们会使用云API去封装一些自己的运营平台，所以我们这里也支持了一下。
中间这块是整个容器服务三个大部分，第一块是整个CCS，这块提供了如下的功能，像集群管理、模板应用管理，应用管理这里指的是我们会把所有的服务包装成一个大的应用，方便用户去一键部署自己的应用。第三个是服务管理，我们把K8S里面提到的概念，像deployment,service,pod封装成服务的概念提供给用户，后面还有日志、券和配额，这些都是我们这边开发的。最底层，因为我们要支持原生的Kubernetes，所以不可避免的需要有些开发，比如和IaaS层、PaaS层的打通，就需要有日志、网络、券、负载均衡的驱动开发。第二块是CCR，是我刚才提到的镜像服务。镜像服务支持有多个hub源的镜像，还有自建的Cloud的镜像，还有第三方的也支持。同时我们做了一些比较重要的优化，我们在海外搭建了很多节点，帮助用户能够快速的拉取镜像，并且做成mirror，同时我们的镜像仓库是分地域部署。同时我们还会定时拉去Docker Hub上的镜像做缓存，进一步提升效率。最后一块是CI/CD，CI/CD是去定义自动部署、自动构建的策略，例如提交代码时自动触发。
下面是我现在负责的CCS-Monitor Server，包括监控上面整套容器服务的体系。最底下是对我们自己腾讯云的IaaS和PaaS层的集合，譬如说CVM、黑石，大家可以理解为公有云和私有云，同时我们集成块存储、对象存储、CFS，我们还有日志中心，后面我会讲一下。最后还有弹性伸缩和负载均衡，弹性伸缩主要可以理解为HPA和HNA，这是腾讯服务顶层的计。
接下来第二点，给大家讲一下腾讯云Master集群化部署。下图是现在腾讯容器服务Master集群化部署的概览，我给大家说一下大概的背景。当初腾讯云的容器服务刚开始上线的时候，这个地方并不是这样子的。
刚开始我们会为用户的每个集群创建一个Master，这个Master当初是一个虚拟机，为了做高可用，我们会为用户再部署一个stand by的Master，当Master出现故障的时候，我们可以方便的切换。
最后就造成很多多的问题，一是成本的问题，如果每个集群都部署一个Master，部署一台虚拟机，成本很大。二是运维成本，每台Master都是一台虚拟机，每个master的组件，是一个二进制文件部署在Master上面。这种情况下，如果对某个Master进行升级，不可避免的就会出现很多问题。
基于这个考虑，我们重新优化了整个我们的Master部署，我们采用的方案是调研了社区里面一些热门的方案，这个方案就是kubernetes in kubernetes，不知道大家有没有了解过这个东西。我们单独部署一套K8S集群，所有Master的组件，大家知道的三大组件都会以pod的形式运行在K8S集群中。我们为Pod绑定双网卡，一个网卡是弹性网卡，它会单独与用户的VPC做网络通信，另外一个网卡是原生的，这个网卡会是Master集群中使用的网卡。
每个API的组件都是一个Pod，好处是，一是Master集群的部署，主要是以K8S管理，这样HA、SLA都有很大的保证，包括后面运维的提升，可以使用K8S原生的rolling update去操作。其次是成本，有些用户可能Master不需要那么大的CPU Memory，我们可以共同调整CPU Memory的request，同时对于大型的客户，譬如说在集群中运行了上千个Pod情况下，通过动态调整扩展Master的配置，增大更多的Api server做一个负载调优。
这里大概讲了现在集群化部署的方案，后面我监控的方案都会依赖于这个，给大家稍微先讲一下这块。
第三，基础的指标监控。我们的基础指标监控主要还是以IaaS层为主，就是大家所说的Cpu,Memory、DiSK和Network方面。这里一共有四块，Node、Deployment，Deployment，Pod，container，所有IaaS层的监控指标都会依照这四个模块来做聚合。
上面的四块是我讲的IaaS层基础指标，这里我选取了几个重要的指标，如果大家以后有自建容器监控，希望对大家有所帮助。CPU Memory有些指标是非常重要的，例如CPU Usage和Memory Usage，这里的Cpu Usage和Memory Usage是占整个pod request或者 limit的整个比例，如果这两个指标比较高，就必须警觉起来，可能会造成pod不可用的问题发生，另外我提一下，大家知道，在K8S中，有一个request 和limit的概念，如果request limit不配置，在一些测试环境，不知道大家有没有试过，当一个Pod跑到很高的情况下，会出现雪崩的效应，比如跑挂一台机器，这时候挂了之后，节点异常，K8S会自动的把这台机器上所有的Pod踢走，Pod会自动创建到另外的机器上，继续拖垮另外一台机器，这种可以称之为“雪崩效应”。最后造成的结果是K8S集群不可用。其次，CPU node和Memory node。当前你的K8S集群中还有剩余的CPU和Memory可分配的比例，当一个K8S pod配置的request limit不能满足当前集群中所剩余的量，就会造成，新的Pod无法调度。Network比较基本，一个是进出带宽、进出流量，还有进出包量。Disk有几个比较重要的，traffic、iops，这些自己自建的时候也需要关注。
最后单独提一下Inode，有一次用户使用过程发现Pod创建不成功，经过多方面调查，发现Inode满了，为什么出现这种情况？我们看了K8S代码，它对镜像和日志都有回收机制，但是对Inode的回收和清理是没有的，社区也有讨论，但是一直没有解决。所以说Inode这块是必须要监控起来的，它会造成你整个集群中某个节点无法创建服务，所以说我单独把它拎出来和大家提一下，我不知道现在的1.8版本有没有解决这个问题。
最后是LB的监控，大家可以知道，servers有几种提供的访问方式，腾讯云容器服务的servers与腾讯云的LB做了绑定，用户创建servers的时候，如果指定的方式是LB，我们通过插件的方式帮他申请一个LB挂在上面，不管是内网还是外网。用户对自己服务的监控，我们可以通过LB的Httpcode和当前的连接数、回包的时间等指标去做，就能准确的判断出当前业务的健康状态。
这是基础监控指标大概的架构（见下图）。我们主要使用开源的方式，大家在网上关注监控就知道，容器的监控大概有这么几种方案，当时我们做方案评估的时候也考虑过其他几种，最后还是选择了heapster的方式，还是业务驱动，因为调研的时候发现cadvisor对K8S中的聚合没有做得特别好，它的数据都是原始的数据，如果我们在以Kubernetes的方式聚合，这是很复杂的。普罗米修斯，我们考虑它比较重，一个是集收集，告警和存储一体的，我们需要的仅仅是收集这块，所以说普罗米修斯并不适合我们这里的业务，最后我们就选择使用heapster。我们这里的heapster也是以容器的方式部署在Master集群化部署的集群里面，对用户是无感知的，也不消耗用户的资源。其次heapster我们帮它绑定两张网卡，一张是去用户的集群中拉取监控数据，因为大家知道heapster需要与Kubernetes通信，拉取一些监控数据，所以我们这里必须绑定两张网卡。其次我们会构建一个CCS Monitorserver，定时拉取一些集群的监控数据，做一些汇总或计算。最后，我们会把这些收集到的数据Push到Barad server，这可以理解为腾讯云整个监控的组件，这是平台级的组件。Barad server做了几件事，一是聚合，会把我们所有上报的指标聚合成，比如我们加一些时间粒度的汇总，1分钟、5分钟、10分钟这种，包括我们以Node的形式展示出整个Node下所有pod平均的监控指标。做这种聚合。最后我们会提供云API的方式给接入层使用，接入层主要是用户调取需要的监控指标，还有HPA和HNA，就是Pod和Node水平扩展，这个是我们直接拉取Barad API的数据做扩展工作。
第四，事件指标。其实在问题发生的时候，如果仅仅只看基础的监控指标是远远不够的，因为你只能发现你的服务出现了问题，但是你不能很好的去知道到底是哪个服务出现了问题，事件指标主要如下几个问题：1、汇聚当前K8S所有资源事件的汇总，我们会根据这些事件做自己的提炼，同时push到事件中心。2、事件中心指标弥补指标监控信息部直接的短板，我刚才说到过。3、提高问题的定位效率。4、事件指标支持告警。事件指标主要分两大块：1、异常事件；2、状态事件。异常事件大家可以理解为Pod创建失败、重启、节点异常、内存不足、调度失败的事件。状态事件是一些正常事件，比如Pod启动、销毁、更新中、HPA触发、HNA触发。它对对于定位问题也有很大的帮助。
事件指标的整体方案，我们当前是从API server中拉取K8S所有的事件，会存储在ES集群中，我们会有内部的Cluster做数据的查询和展示。ES中汇聚的都是每条基础数据，也就是大家俗称的源数据。其次CCS Monitor会把它合并成用户能够理解的汇总的数据，然后推到腾讯云事件中心去。最后用户可以在控制台上看到这个事件发生的原因、属于哪个资源，最后还会告诉它如何解决这个问题，会有一个帮助文档。
第五，整个监控中对腾讯最重要的是集群稳定性的监控。这里的图会有点问题，集群稳定性的监控分为四大块，Kube-System和ETCD、Master相关组件监控，比如API server等，最重要的是运行时问题监控。
集群稳定性监控采用三个开源的方案，一是Node Detector，主要是做运行时。Fluentd主要是采集每个Master集群上每个容器的node，后面也用了普罗米修斯的方案，没有再使用heapster，因为普罗米修斯，我们需要它做一些存储，不需要做对外展示，这是内部使用，所以我们需要采用普罗米修斯去定制一些东西去采集更多的指标。大家可以看到整个Master集群上，每个Master集群上每个node部署的各个pod，Fluentd会拉取lod。普罗米修斯我们自己定制了一些插件，在每个pod上拉取一些我们基本的指标。同时Node Detector部署在每个用户节点上，这是用户可以自己选择的。它主要采集一些Kernel和runtime的问题。Node Detector是K8S官方的项目，如果大家感兴趣可以了解一下。
第六，最后一个监控组件，业务日志监控。大家知道业务日志对于一个问题定位帮助是非常大的，如果一个监控仅仅只有事件和指标，其实很多问题都无法定位，因为容器在使用的时候，更多的会动态的增加和减少。所以我们这里会采集容器日志，并且保存在日志服务中，供用户在后期能更方便的去追溯到原来的一些业务问题。业务日志分四个板块，容器日志的收集和节点日志的收集，还有日志存储和日志处理，现在容器日志也是前面提到的stdout和stderr日志，并且附加相关的Kubernetes Metadata，主机特定目录的日志并附加指定的label去收集用户容器达到主机上固定的日志。存储方面，我们支持把日志发送到用户自己搭建的Kafka或者ES或者腾讯云的日志服务中存储起来做消费。最后一块是日志处理，日志处理主要是方便用户能够去方便定位问题，同时我们支持能够根据一定关键字配置一些关键字的告警，最后我们后续可能还会支持做一些大数据的处理工作。
整个业务日志的监控整体的方案（见PPT），我们让用户定义一个个不同的规则，不同的规则可以叫collector，所有的collector会并成一个Config Map，在启动Fluentd的时候会收集Cluster指定的收集策略，最后发送到不同的后端源，当时做这套设计的时候我们考虑其他组件的方案，主要采集的agent，我们考虑了filebeat和fluentd,最后我们采用的还是fluentd，一是基于性能的考虑，fluentd是c和ruby写的，消耗只有在40M左右，filebeat会更大一些。最重要的一点是fluentd支持数据源推的路由，也就是说它能够通过不同的规则、不同的lable去推到不同的终端上。例如我有一条规则A和规则B，它分别推到ES或者Ckafka，所以我们最后就选择了fluentd的方案做业务日志的收集。
最后讲一下我们后期调研的工作和待开发的工作：1、自定义监控。自定义希望让用户能够自己去定义一些监控指标，自己Push一些监控指标到我们的监控平台。2、调用链追踪和Real-time Monitor的部署，当一个应用起来之后，会有成千上百的容器在里面传输，调用链就是非常直观的监控方向,同时配合realtimemonitor，能够很好的发现服务的健康状态，其次我们还会提供一个应用市场，因为现在普遍上开源也有很多的监控方案，我们会把它打包成一个个应用提供给用户使用，最后两点就是告警的预测和集群网络的监控，告警预测我们希望通过我们收集的数据去分析可能发生的问题，例如说当一个时间点内某项指标与前段时间周期性比较的指标的发生很大差异的时候，我们需要能够及时的通知用户，这里可能会出现了问题。集群网络的监控方面，我们发现用户在部署的集群的时候，经常有些iptables，ACL，或者timeout等网络的问题，这块的监控后期同样会补上。