Calico-node进程导致机器CPU资源占满问题

本文描述了一个由于Calico-node进程导致的服务器CPU资源完全被占满的问题。在排查过程中,发现kubelet和docker进程也参与其中,存在创建容器失败的情况。通过检查系统日志,发现在9099端口存在冲突。经过一系列尝试,包括停用kubelet、重启docker、删除相关容器,甚至重启主机,最终解决了问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Calico-node进程导致机器CPU资源占满问题

1、问题现象
在这里插入图片描述

截图上可以看出CPU的资源已经被占满,这个截图CPU的数值还算好看的,基本上是0空闲。
#看了一下进程,想知道到底跑的什么进程吧CPU跑满的。
#看上图可以看出来,导致跑满CPU的原因是跑calico-node的pod导致,但按理说跑一个calico-node不至于吧机器的CPU全部跑满。

2、问题处理
带着疑问,我首先先将占资源高的calico-node进程杀死
在这里插入图片描述

杀死后看了下,仍然没有解决问题
然后分别看了下,kubelet状态、docker状态
在这里插入图片描述

查看后感觉就是kubelet一直在给docker请求,要求docker创建相关容器,但是docker也在做并且一直在做,但是就是无法创建成功。

然后又在master上看了下这个node下calico-node的pod状态,在建立的过程中报存活探针和就绪探针错误。

针对以上问题,我先停掉kubelet,停止创建pod,发现进程中runc和dockerd仍然占用大量的CPU资源,占到50以上,但是机器已经不卡了,可以正常操作命令了。

然后在将docker进行重启,然后在启动kubelet,发现很快资源就被占满了。

针对这个问题,看了下系统日志,发现9099端口被占用,找到了问题所在。

首先先将占用9099的进程杀死,但是杀死后马

<think>好的,我现在需要分析用户提供的PromQL查询:kube_daemonset_status_number_misscheduled{job!~"k8s-(.*)-prometheus|node-exporter"} > 0。首先,我要理解这个查询的各个部分,包括涉及的指标、过滤条件以及比较操作符的作用。 首先,指标kube_daemonset_status_number_misscheduled应该来自Kubernetes的kube-state-metrics组件,用来监控DaemonSet的状态。这个指标表示被错误调度的Pod数量,即那些不应该在某个节点上运行但实际被调度的Pod数目。如果这个值大于0,说明存在配置或调度问题。 接下来看过滤条件{job!~"k8s-(.*)-prometheus|node-exporter"}。这里使用正则表达式排除了名称匹配k8s--prometheus或node-exporter结尾的job。用户可能希望排除监控相关的DaemonSet,只关注业务相关的DaemonSet。例如,Prometheus和Node Exporter通常作为监控组件部署,可能由DaemonSet管理,但用户更关心自己的业务应用是否有调度问题。 然后是比较操作符> 0,这意味着只要存在任何被错误调度的Pod,就会触发条件。用户可能希望当有DaemonSet的Pod被错误调度时立即收到警报,以便及时处理,避免影响服务稳定性。 接下来需要考虑这个查询的应用场景。DaemonSet通常用于在每个节点或特定节点上运行守护进程,如日志收集、网络插件等。如果这些Pod被错误调度,可能导致某些节点缺少必要的服务,或者在不应该运行的节点上消耗资源。例如,如果网络插件的Pod被错误调度到未打标签的节点,该节点的网络功能可能受到影响。 用户可能是在设置监控告警规则,当有DaemonSet出现调度问题时及时通知运维人员。需要确认是否应该排除监控组件,因为它们的调度问题可能由不同的团队处理,或者用户只负责业务部分。 此外,还要考虑指标的获取方式。kube-state-metrics需要正确配置和运行,才能导出这些指标。如果用户的集群中没有部署kube-state-metrics,或者版本不支持该指标,查询将无法得到数据。同时,标签的正确性也很重要,确保job标签与实际部署的job名称匹配,避免过滤条件错误地排除或包含某些指标。 可能还需要分析为什么会出现misscheduled的情况。常见原因包括节点选择器(nodeSelector)或亲和性(affinity)配置错误、节点标签不匹配、污点(taint)和容忍(toleration)设置不当等。例如,DaemonSet可能被配置为只在带有特定标签的节点上运行,但某些节点可能缺少该标签,导致Pod无法调度,但被错误地调度到其他节点。 此外,用户可能需要结合其他指标来全面了解DaemonSet的状态,例如kube_daemonset_status_desired_number_scheduled(期望调度的Pod数量)和kube_daemonset_status_current_number_scheduled(当前实际调度的数量),以比较期望和实际的差异,进一步诊断问题。 在告警规则的设计上,除了简单的存在性检查(>0),可能还需要设置持续时间,例如持续5分钟以上才触发告警,以避免短暂的调度波动导致误报。同时,告警信息应包含具体的DaemonSet名称、命名空间、错误调度的Pod数量等信息,便于快速定位问题。 最后,需要考虑如何处理这些告警。可能的应对措施包括检查DaemonSet的配置、节点标签、污点和容忍设置,查看事件日志以了解调度失败的具体原因,或者重启DaemonSet控制器等。用户可能还需要文档或自动化脚本来快速修复常见问题。 总结来说,这个查询帮助用户监控业务相关的DaemonSet是否存在调度问题,及时发出警报,确保集群中的关键守护进程正确运行。排除监控组件可以避免干扰,专注于核心业务应用的稳定性。需要结合其他指标和日志,全面分析问题原因,并制定相应的处理流程。</think>以下是对该 PromQL 查询的详细解析,涵盖指标含义、过滤逻辑及典型应用场景: --- ### 查询结构 ```promql kube_daemonset_status_number_misscheduled{job!~"k8s-(.*)-prometheus|node-exporter"} > 0 ``` --- #### 1. **核心指标解析** - **`kube_daemonset_status_number_misscheduled`** - **来源**:由 `kube-state-metrics` 组件提供,用于监控 Kubernetes 资源状态。 - **含义**:表示 DaemonSet 当前被错误调度的 Pod 数量。 - **典型场景**:当 Pod 被调度到不满足节点选择器(`nodeSelector`)、亲和性规则(`affinity`)或污点容忍(`tolerations`)的节点时,此值会大于 0。 --- #### 2. **过滤规则解析** - **`{job!~"k8s-(.*)-prometheus|node-exporter"}`** - 使用正则表达式 `!~` 排除以下两类 Job: 1. **`k8s-*-prometheus`**:Kubernetes 集群中 Prometheus 相关的组件(如 Prometheus Operator 部署的资源)。 2. **`node-exporter`**:Node Exporter 相关的监控指标。 - **意图**:聚焦业务相关的 DaemonSet,避免监控基础设施自身组件的误报(如 Prometheus 的 DaemonSet 异常可能由监控团队单独处理)。 --- #### 3. **阈值条件 `> 0`** - 当被错误调度的 Pod 数量大于 0 时触发条件。 - **设计目标**: - 快速发现 DaemonSet 的调度异常,防止因配置错误导致关键守护进程(如日志采集、网络插件)未按预期运行。 --- ### 典型应用场景 #### 1. **关键守护进程监控** - **示例**: - 日志采集 DaemonSet(如 Fluentd)未在指定节点运行 → 导致日志丢失。 - 网络插件 DaemonSet(如 Calico)调度异常 → 节点网络功能故障。 - **告警触发**:`kube_daemonset_status_number_misscheduled > 0` 表示需立即检查 DaemonSet 配置。 #### 2. **配置验证** - **场景**:修改 DaemonSet 的节点选择规则后,验证是否所有 Pod 均按预期调度。 - **监控方式**:观察该指标是否归零。 #### 3. **资源冲突排查** - **根因分析**: - 节点标签不匹配(如 `nodeSelector` 指定的标签未正确添加到目标节点)。 - 污点(Taint)未配置容忍(如 DaemonSet 未声明容忍 `node.kubernetes.io/disk-pressure`)。 - 资源不足(如节点 CPU/内存不足导致调度失败,但需结合其他指标如 `kube_pod_status_unschedulable` 进一步分析)。 --- ### 告警规则示例(YAML) ```yaml - alert: DaemonSetMisscheduledPods expr: | kube_daemonset_status_number_misscheduled{job!~"k8s-(.*)-prometheus|node-exporter"} > 0 for: 5m # 持续 5 分钟触发以避免瞬时抖动 labels: severity: critical annotations: summary: "DaemonSet 存在异常调度的 Pod ({{ $labels.namespace }}/{{ $labels.daemonset }})" description: | DaemonSet {{ $labels.daemonset }} 在命名空间 {{ $labels.namespace }} 中有 {{ $value }} 个 Pod 被错误调度。 可能原因:节点选择器、亲和性规则或污点容忍配置错误。 ``` --- ### 根因分析与处理建议 #### 1. **检查 DaemonSet 配置** - 验证 `nodeSelector`、`affinity`、`tolerations` 是否与目标节点匹配: ```bash kubectl get daemonset <daemonset-name> -n <namespace> -o yaml ``` #### 2. **检查节点标签与污点** - 查看目标节点标签: ```bash kubectl describe node <node-name> | grep Labels: -A 10 ``` - 查看节点污点: ```bash kubectl describe node <node-name> | grep Taints: ``` #### 3. **查看事件日志** - 获取 DaemonSet 相关事件: ```bash kubectl describe daemonset <daemonset-name> -n <namespace> | grep -A 10 Events ``` --- ### 优化建议 1. **关联指标扩展** - 结合 `kube_daemonset_status_desired_number_scheduled` 和 `kube_daemonset_status_current_number_scheduled`,计算调度成功率: ```promql (kube_daemonset_status_current_number_scheduled / kube_daemonset_status_desired_number_scheduled) * 100 < 100 ``` 2. **自动化修复** - 对已知配置问题(如缺失节点标签),通过 CI/CD 流水线自动修补。 3. **分级告警** - 根据 DaemonSet 的重要性设置不同阈值(如核心组件 `>0` 即告警,非核心组件 `>1` 告警)。 --- ### 示例输出解读 假设查询返回: ```text kube_daemonset_status_number_misscheduled{ daemonset="fluentd-logging", namespace="logging", job="k8s-app-metrics" } 2 ``` 表示: - `logging` 命名空间中的 `fluentd-logging` DaemonSet 有 2 个 Pod 被错误调度。 - 需检查该 DaemonSet 的调度策略与目标节点状态是否匹配。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值