Skip to main content

Command Palette

Search for a command to run...

介绍一个小工具:KubeNurse——集群网络监控

Updated
1 min read

地址

Kubenurse:https://github.com/postfinance/kubenurse

简介

在 Kubernetes 集群运行中,一个常见故障就是集群内网络故障,经常会因为临时策略变更或者网络抖动导致一些古怪问题,而实际场景里的虚拟机和网络的监控经常是由其它部门管理的,如果从业务和 Kubernetes 这样的上层设施着手,可能需要一些时间才能解决问题。kubenurse 项目使用 HTTP 检测的方式提供了常用的几个监控指标。

这个工具的实现也很直接,用 Daemonset 的形式部署在每个集群节点上,每个 Pod 都会通过 HTTP 检测的方式对上述几种目标分别进行访问,最后用 Prometheus Summary 指标的形式暴露出来用于监控。检测机制如图所示:

每个 Pod 都开放了 8080 的 http 端口,包含以下端点:

  • / 或者 /alive:返回本节点信息

  • /alwayshappy:返回 HTTP 200 用于心跳

  • /metrics:暴露 Prometheus 指标数据

/alive 返回的节点信息如下:

{
  "api_server_direct": "ok",
  "api_server_dns": "ok",
  "me_ingress": "ok",
  "me_service": "ok",
  "hostname": "kubenurse-1234-x2bwx",
  "neighbourhood_state": "ok",
  "neighbourhood": [
   {
    "PodName": "kubenurse-1234-8fh2x",
    "PodIP": "10.10.10.67",
    "HostIP": "10.12.12.66",
    "NodeName": "k8s-66.example.com",
    "Phase": "Running"
   },
   {
    "PodName": "kubenurse-1234-ffjbs",
    "PodIP": "10.10.10.138",
    "HostIP": "10.12.12.89",
    "NodeName": "k8s-89.example.com",
    "Phase": "Running"
   }
  ],
  "headers": {
   "Accept": [
    "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8"
   ],
   "Accept-Encoding": [
    "gzip, deflate, br"
   ],
   ...
  }
}

可以看到,其中包含了上述所说的几个检测结果。

部署

源码中包含了一个 example 目录,简单地 kubectl apply 就可以完成部署,这里有两个可能需要修改的地方:

  1. 缺省命名空间是 kube-system,建议查找替换,并要注意调整 RBAC 授权。

  2. 涉及 Ingress 检测,因此要注意提供正确的域名。

监控

部署成功之后,Prometheus 会根据 Daemonset 中的注解采集数据:

...
      annotations:
        prometheus.io/path: "/metrics"
        prometheus.io/port: "8080"
        prometheus.io/scheme: "http"
        prometheus.io/scrape: "true"
...

访问任意 Pod 的 :8080/metrics 端点,会看到如下指标:

  • kubenurse_errors:如果检测过程中出现错误,这个计数器会进行累加。

  • kubenurse_request:一个 Summary 类型的指标,正常检测结果的时间消耗分布。

这两个指标使用 type 标签对结果进行标识,对应几种不同的检测目标:

  • api_server_direct:从节点直接检测 API Server

  • api_server_dns:从节点通过 DNS 检测 API Server

  • me_ingress:通过 Ingress 检测本服务 Service

  • me_service:使用 Service 检测本服务 Service

  • path_$KUBELET_HOSTNAME:节点之间的互相检测

如此一来,我们就可以根据各种延迟时间的分布情况,以及返回错误的数量来确认集群网络状况了。

注意

节点较多时,每次采集可能会产生 n*(n-1) 次访问,会造成较重负载,可以给 Pod 打标签,并使用标签过滤的方式来减少请求,但是这样一来,就会导致检测结果不够全面的问题,因此还需对实际应用进行权衡。

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts