深入剖析 Kubernetes
张磊
Kubernetes 社区资深成员与项目维护者
112983 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 57 讲
再谈开源与社区 (1讲)
结束语 (1讲)
深入剖析 Kubernetes
15
15
1.0x
00:00/00:00
登录|注册

48 | Prometheus、Metrics Server与Kubernetes监控体系

你好,我是张磊。今天我和你分享的主题是:Prometheus、Metrics Server 与 Kubernetes 监控体系。
通过前面的文章,我已经和你分享过了 Kubernetes 的核心架构,编排概念,以及具体的设计与实现。接下来,我会用 3 篇文章,为你介绍 Kubernetes 监控相关的一些核心技术。
首先需要明确指出的是,Kubernetes 项目的监控体系曾经非常繁杂,在社区中也有很多方案。但这套体系发展到今天,已经完全演变成了以 Prometheus 项目为核心的一套统一的方案。
在这里,可能有一些同学对 Prometheus 项目还太不熟悉。所以,我先来简单为你介绍一下这个项目。
实际上,Prometheus 项目是当年 CNCF 基金会起家时的“第二把交椅”。而这个项目发展到今天,已经全面接管了 Kubernetes 项目的整套监控体系。
比较有意思的是,Prometheus 项目与 Kubernetes 项目一样,也来自于 Google 的 Borg 体系,它的原型系统,叫作 BorgMon,是一个几乎与 Borg 同时诞生的内部监控系统。而 Prometheus 项目的发起原因也跟 Kubernetes 很类似,都是希望通过对用户更友好的方式,将 Google 内部系统的设计理念,传递给用户和开发者。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入剖析 Kubernetes》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(29)

  • 最新
  • 精选
  • Acter
    1.老师能讲下prometheus的部署方式吗?比如helm部署,operator部署,过程中具体发生了什么? 2.能否解析下prometheus server配置文件中,jobs的写法,alert rule的写法?还有alertmanager的配置。感谢

    作者回复: 篇幅所限,prometheus 项目具体的玩法不进行详细展开了

    25
  • --
    核心监控数据是Prometheus通过Metric Server拉取的还是直接从kubelet拉取?

    作者回复: metric server

    5
  • leisland
    老师您好,我想请教你一个k8s问题。我们使用liveness probe探针检查容器健康状态,这个探针执行的是容器里一个脚本。当容器内存和CPU过载时这个脚本会一直执行卡死然后超时。现在看k8s好像不认为执行超时是失败,在不停的去执行脚本。从而检查不到容器异常了,容器一直不重拉起。我们设置失败上限是3次,应该没起作用。请问有没有办法可以解决呢?业界都是怎么使用探针的呢?

    作者回复: 最常用的是暴露healthcheck 端口,脚本也常用,但得处理好各种异常情况

  • 孙健波
    Pull和Push两种模式的区别非常有意思,Prometheus非常大胆的采用了pull的模式,但是仔细思考后就会觉得非常适合监控的场景。 Pull模式的特点 1. 被监控方提供一个server,并负责维护 2. 监控方控制采集频率 第一点其实对用户来说要求过高了,但是好处很多,比如pull 不到数据本身就说明了节点存在故障;又比如监控指标自然而言由用户自己维护,使得标准化很简单。 第二点其实更为重要,那就是监控系统对metric采集的统一和稳定有了可靠的保证,对于数据量大的情况下很重要。 缺点也很明显,用户不知道你什么时候来pull一下,数据维护多久更新也不好控制,容易造成一些信息的丢失和不准确。 当把这些优缺点权衡过后就会发现,纯监控的场景确实是适合pull的
    4
    54
  • Goswing
    Push模式的优点是在正常情况下数据的延迟可以做到更低,也就是能更快的获取metrics并发现问题,而pull模式一般不会设定很短的轮询时间,所以延迟更高一些。 Push模式的缺点我能想到以下几个: 1 增加了服务的实现复杂度(比如推送错误处理等); 2 不利于平行扩展; 3 不支持自定义metrics采集策略,比如高峰期减少采集频率。
    14
  • 拉欧
    pull是拉动作,监听者主动调用被监听者的接口 push是推动作,被监听者主动上报,监听者被动采集 拉动作有助于监听者自己控制频率和采样量,缺点是需要掌握所有被监听者的地址和端口,也就是要有注册中心; 推动作有利于被监听者自己控制上报数量和频率,但有可能对监听者构成额外的压力,同时有信息丢失的风险
    13
  • CalvinXiao
    push 方式针对没有 http 接口应用,例如 worker,可以设定每 5 秒上报处理了多少个 job,平均每个 job 耗时多少,有多少个错误等数据,需要配合 push gateway 使用。 当然,也可以自己写一个 exporter 通过查询日志来得到这些数据,然后用 pull 方式来获取。push 方式可以联想到 APM。
    9
  • 狮锅艺
    文中缺少的链接:https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh
    5
  • 我要收购腾讯
    prometheus 的pull模式搭配自己的kubernetes SD, 加上prometheus-operator的service monitor的抽象,可以很大程度的简化配置的复杂程度
    5
  • 我在睡觉
    我认为拉取的最大好处是解耦,metric server对外提供标准接口,第三方实现自己的监控逻辑。还有部署的时候更方便,如果使用push的方式,那么部署一个监控组件之后需要用某种方式配置metric server,让他知道一个监控服务的存在以便通知上报数据,这样对于监控数据描述的配置文件都要配置到metric server(metric server也需要实现逻辑来处理这些配置),这显然增加了使用的复杂度,也不不够灵活。
    1
    3
收起评论
显示
设置
留言
29
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部