Loading [MathJax]/jax/output/CommonHTML/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >腾讯云多Kubernetes的多维度监控实践

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

原创
作者头像
腾讯云开发者社区
修改于 2017-11-16 02:15:39
修改于 2017-11-16 02:15:39
3.5K0
举报

本次内容根据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等网络的问题,这块的监控后期同样会补上。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
史上最全的黑苹果系统「MacOS」安装教程,小白也能秒掌握!
折腾过的人应该不陌生,自从苹果采用 Intel 的处理器,被解锁后可以安装在 Intel CPU 与部分 AMD CPU 的机器上。从而出现了一大批非苹果设备而使用苹果操作系统的机器,被称为黑苹果(Hackintosh)。
全栈程序员站长
2022/07/01
15.9K0
史上最全的黑苹果系统「MacOS」安装教程,小白也能秒掌握!
手把手教您组装一台家用NAS J3455黑群晖6.1.7搭建全过程[通俗易懂]
经过俺几个月的观察和尝试,最终锁定了目标:J3455处理器。将之前的蜗牛星际都换成了J3455,可以说是性能,功耗,都非常适合的一台NAS。
全栈程序员站长
2022/09/20
12.1K0
手把手教您组装一台家用NAS J3455黑群晖6.1.7搭建全过程[通俗易懂]
关于睡眠和休眠
到底用睡眠和休眠,还是直接关机的问题,争论颇多,大家各有各的观点和立场。实际上在很长一段时间内我本人的态度也是变化了不少,在此我想说说我对这个问题的看法,简要分析一下可能涉及到的几个方面。这只是我个人的观点,欢迎大家发表不同意见,但回帖前请先完整的看完本帖的内容。 我首先给出结论,我认为:在大部分情况下使用睡眠和休眠就可以了,重启和关机是在极少数情况下使用的,比如安装了新软件要求重启,或者系统出现了严重故障。下面从几个方面来说这个问题,这里默认了一个前提,就是你的主板支持 s3 待机。究竟哪些主板支持?我家有台老爷机, 2001 年买的,它都支持,我想不必再多说些什么了吧,有的主板需要在 bios 里开启后才支持。还有一种判定方法,就是在设备管理器的系统设备里,看看有没有个叫 "ACPI-Compliant System" 的东西,如果有的话就说明高级电源管理接口已经启动,即支持 s3 待机。
williamwong
2018/07/24
3K0
关于睡眠和休眠
树莓派4b基础入门「建议收藏」
树莓派(Raspberry Pi)是一款基于ARM的微型电脑主板,旨为学生计算机编程教育而设计,其系统基于Linux,由注册于英国的慈善组织“Raspberry Pi基金会”开发,Eben·Upton为项目带头人。别看其外表“娇小”,内“心”却很强大,上网、看视频、听音乐等功能都有,可谓是“麻雀虽小,五脏俱全”。自问世以来,受众多计算机发烧友和创客的追捧。 1.树莓派的家族
全栈程序员站长
2022/07/01
7.7K0
树莓派4b基础入门「建议收藏」
操作系统是什么都没整明白,写什么代码?
现代操作系统由一个或多个处理器、主存、打印机、键盘、鼠标、显示器、网络接口以及各种输入/输出设备构成。计算机操作系统是一个复杂的系统。
淘课之家
2020/04/01
1.4K0
操作系统是什么都没整明白,写什么代码?
手把手教你安装黑苹果之openCore-0.6.3 EFI制作全过程,非常详细
这篇文章主要是记录自己动手安装Big Sur在过程,和心理。略显繁琐,请自行跳跃观看。
全栈程序员站长
2022/09/12
22.9K0
手把手教你安装黑苹果之openCore-0.6.3 EFI制作全过程,非常详细
计算机基础(二)
计算机基础(二) 设计架构     一般消费者常说的电脑通常指的就是x86的个人电脑架构。早期两大主流x86开发商(Intel, AMD)的CPU架构与设计理念都有些许差异。 1、CPU 1.Intel芯片架构     北桥:负责链接速度较快的CPU、内存与显卡接口等元件。     南桥:负责连接速度较慢的设备接口,包括硬盘、USB、网卡等等。     由于北桥最重要的就是CPU 与内存之间的桥接,因此目前的主流架构中,大多将北桥内存控制器整合到CPU封装当中了。     早期芯片组分南北桥,北桥可以连接C
云飞扬
2018/06/19
1.5K0
你越没钱越需要精打细算 (设计师电脑购买指南)
作为一名设计师,有时候真的在想为什么要选择这个行业,经常性的加班已经让人身心俱疲,加班越来越多,电脑配置越来越高, 但是工资却还是不见长!
用户1730674
2020/01/02
5.3K0
教你不花一分钱,用十分钟把旧电脑打造成自己的Windows版NAS系统
一年前我前前后后花了2个多星期的时间才将整套系统部署完成,但这是因为其中有很多的坑,需要找到解决方案。我已经尽可能把过程中遇到的所有问题都写明,大家只要跟着去做,还是非常简单的,不需要太长时间。整套系统至今一直非常稳定。
ICT系统集成阿祥
2024/12/30
11.8K0
教你不花一分钱,用十分钟把旧电脑打造成自己的Windows版NAS系统
OC简要配置说明(旧)已修正
注意事项:OC对于有依赖的SSDT/KEXT加载顺序有严格要求,注意在config配置中的顺序。 主要适用于UEFI启动的电脑。 本文当前写作时OC正式版为0.5.9,0.6.0测试版。以下的配置适用于这两个版本,后续OC的更新可能会有些许改动,到时候应该再参考官方文档进行修改。
GOOPHER
2022/03/31
8.6K0
OC简要配置说明(旧)已修正
常用电脑资料速查
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
全栈程序员站长
2022/11/10
2.5K0
黑群晖安装和使用的常见问题及解决办法【不定期更新中】
答:群晖系统跟Windows不同,Windows有个盘要当成系统盘,而群晖会在每个硬盘上自动安装系统。每个硬盘?对,没错,就是每个硬盘。比如你是6盘位,接了6个硬盘,这6个硬盘初始化以后,每个硬盘都有系统了。所以拿一个SSD来做系统盘的这个做法没必要。当然,也有全部用SSD的土豪,那就不是这个话题了。
cnlixs
2022/11/01
60.5K2
黑群晖安装和使用的常见问题及解决办法【不定期更新中】
廉价的全闪存雷电 NAS 折腾笔记:NUC9 操作系统踩坑
我使用的设备是 NUC9i5QNX,这台设备的硬件基础规格,可以在 Intel ARK 网站中找到。在上一篇文章《廉价的全闪存雷电 NAS 折腾笔记:组网方案的选择》中,我介绍了这台设备的优势,感兴趣可以自行翻阅。
soulteary
2023/09/12
3.3K1
廉价的全闪存雷电 NAS 折腾笔记:NUC9 操作系统踩坑
关于选购笔记本电脑
与电脑打交道十多年来,以及从事程序数年转网络安全三年来,在与985空间安全研究生、电脑经销商,网络安全实验室负责人、讨论及对购买电脑的理解,写下此文。
中龙技术
2022/09/29
4.7K0
关于选购笔记本电脑
Windows操作系统基础
行业介绍 操作系统:Linux系统 Windows系统 Linux系统是80%企业使用的服务器,Windows更适合个人电脑。 为什么企业都用Linux系统:①开源 ②免费 ③安全 ④稳定
张哥编程
2024/12/13
2010
个人计算机硬件设备配置介绍与选型参考
描述:在我们日常使用的计算机中除了需要有硬件支持,还需要要有软件支持,比如我们的操作系统; 在我们自己安装系统或者DIY笔记本电脑的时候需要购买一些PC的一些周边硬件,当然您需要对其有一个大致的了解,所以本篇文章给计算机小白们一个基础入门;
全栈工程师修炼指南
2022/09/28
3.4K0
个人计算机硬件设备配置介绍与选型参考
写给大忙人看的操作系统
现代计算机系统由一个或多个处理器、主存、打印机、键盘、鼠标、显示器、网络接口以及各种输入/输出设备构成。
cxuan
2020/03/04
8360
写给大忙人看的操作系统
Linux系统安全加固指南(万字长文)
本指南旨在说明如何尽可能地加强Linux的安全性和隐私性,并且不限于任何特定的指南。
肉眼品世界
2022/04/19
7K0
硬件资料和软件资料_电脑硬件检测工具哪个好
2. BIOS报警声意义 3. BIOS自检与开机故障相关问题 5. 计算机几个常见指标的意义 6. 显卡GPU参数 7. 显示卡常见故障全面解决 8. 集成声卡常见故障及解决 9. 显示器经典故障以及处理办法 10. AMI主板代码大全(BIOS-ID)
全栈程序员站长
2022/11/01
4.9K0
推荐阅读
相关推荐
史上最全的黑苹果系统「MacOS」安装教程,小白也能秒掌握!
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档