腾讯云多Kubernetes的多维度监控实践

欢迎你们前往腾讯云社区，获取更多腾讯海量技术实践干货哦~

本次内容根据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的数据作扩展工做。

第四，事件指标。其实在问题发生的时候，若是仅仅只看基础的监控指标是远远不够的，由于你只能发现你的服务出现了问题，可是你不能很好的去知道究竟是哪一个服务出现了问题，事件指标主要以下几个问题：一、汇聚当前K8S全部资源事件的汇总，咱们会根据这些事件作本身的提炼，同时push到事件中心。二、事件中心指标弥补指标监控信息部直接的短板，我刚才说到过。三、提升问题的定位效率。四、事件指标支持告警。事件指标主要分两大块：一、异常事件；二、状态事件。异常事件你们能够理解为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的方案作业务日志的收集。

最后讲一下咱们后期调研的工做和待开发的工做：一、自定义监控。自定义但愿让用户可以本身去定义一些监控指标，本身Push一些监控指标到咱们的监控平台。二、调用链追踪和Real-time Monitor的部署，当一个应用起来以后，会有成千上百的容器在里面传输，调用链就是很是直观的监控方向,同时配合realtimemonitor，可以很好的发现服务的健康状态，其次咱们还会提供一个应用市场，由于如今广泛上开源也有不少的监控方案，咱们会把它打包成一个个应用提供给用户使用，最后两点就是告警的预测和集群网络的监控，告警预测咱们但愿经过咱们收集的数据去分析可能发生的问题，例如说当一个时间点内某项指标与前段时间周期性比较的指标的发生很大差别的时候，咱们须要可以及时的通知用户，这里可能会出现了问题。集群网络的监控方面，咱们发现用户在部署的集群的时候，常常有些iptables，ACL，或者timeout等网络的问题，这块的监控后期一样会补上。

 

推荐阅读

腾讯云批量计算：用搭积木的方式构建高性能计算系统

EB级别云存储是如何涨成的？

腾讯云首发智能网关流控，公有云进入网络精细管控时代

 

此文已由做者受权腾讯云技术社区发布，转载请注明文章出处 

原文连接：https://cloud.tencent.com/community/article/581671