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

最新推荐文章于 2025-05-26 18:12:29 发布
最新推荐文章于 2025-05-26 18:12:29 发布
阅读量2.8k 收藏 1
点赞数 1
CC 4.0 BY-SA版权
分类专栏： K8S、calico-node 文章标签： kubernetes 运维
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/hclhcl12/article/details/118977979
本文描述了一个由于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的进程杀死，但是杀死后马

最低0.47元/天 解锁文章

200万优质内容无限畅学
K8S集群calico报错Calico node ‘binary-k8s-master1‘ is already using the IPv4 address 172.18.0.1
江晓龙的博客
11-26 2215
k8s calico报错Calico node ‘binary-k8s-master1’ is already using the IPv4 address 172.18.0.1 1.问题描述 将pinpoint微服务链路监控以docker方式部署在了k8s集群中的node节点上，刚开始没有问题，过了一天后，发现calico组件全部启动失败，并且集群中的所有微服务无法提供服务 calico报错如下 # kubectl logs -f calico-node-p6hsk -n kube-system 2021
性能分析-Kubernetes-cpu篇
魔都虫师的博客
02-27 788
CPU时间 正如我在第一篇文章中指出，限制CPU时间要比限制内存限制更加复杂，好消息是限制CPU也是根据我们前面所了解到的cgroups机制控制的，与限制内存的原理是通用的，我们只需要关注一些细节即可。我们从向前文的例子里添加CPU时间限制开始： resources: requests: memory: 50Mi cpu: 50m limits: memory: 100Mi cpu: 100...
calico网络故障排查(calico/node is not ready: BIRD is not ready)
热门推荐
JH200811的博客
04-19 1万+
一、问题发现 1.执行kubectl get pod -o wide -n calico-system，发现有一个节点的calico-node没有出入READY状态，如下： 2.执行kubectl describe pod calico-node-5xskb -n calico-system，发现有如下报错： 3.执行kubectl exec -ti calico-node-5xskb -n calico-system -- bash，进入calico-node，打开bird配置文件，发现rout
calico-node-3.10.2（用docker load -i加载）.rar
07-14
calico-node-3.10.2（用docker load -i加载）.rar
Calico-node报错Back-off restarting failed container，定位install-cni容器报错【解决】
最新发布
Harry_mumu的博客
05-26 537
本文描述了calico-node节点重启后无法启动的问题排查过程。通过日志分析发现install-cni容器无法连接172.17.0.1:443端口，但节点间网络正常。进一步排查发现是node2缺少默认路由导致服务访问异常。解决方案是在node2上手动添加默认路由（192.168.10.150）并删除问题pod后，问题得到解决。整个排查过程涉及容器日志分析、网络连通性测试、kube-proxy检查和路由表比对。
calico-node组件分析内存、cpu使用量（开启pprof功能）
weixin_49497353的博客
03-28 596
为了更好地了解calico-node组件的cpu、内存使用情况，可以尝试开启pprof debug来分析。
「NodeJs」nodejs 定时任务
拥抱AI Design
02-27 1513
nodejs 定时访问网页。
k8s 使用 calico 作为 CNI ，calico-node 启动失败
月光游侠
10-29 1万+
1 问题描述 k8s 集群，使用 calico 作为 CNI，calico 的安装配置参考 https://docs.projectcalico.org/getting-started/kubernetes/hardway/overview。 calico 需要 k8s 运行 calico-node 的 daemonset 在每个node 上运行一个 calico-node，calico-node 里面包括了Felix，BIRD，confd组件。calico-node 是 node 上网络能够正常使用的必要
k8s集群cpu冲高问题
weixin_49471976的博客
08-24 1796
k8s集群 kube-apisever服务cpu使用率高问题
云计算实训49——k8s环镜搭建（续2）
m0_73907608的博客
09-12 1704
Metrics 部署；Dashboard部署；部署Kube-proxy；机器可用性验证；注意事项；
kubeadm 以 containerd & cri-docker 作为容器运行时，部署1.26.9版本的kubernetes集群
刘某的博客
04-12 845
本文采用 kubeadm，以 containerd & cri-docker 作为容器运行时，部署 calico 网络模式的k8s集群
【kubernetes/k8s源码分析】calico node源码分析
zhonglinzhang
07-28 5664
calico node 工作内容 镜像命令 start_runit #!/bin/sh # From https://github.com/faisyl/alpine-runit env > /etc/envvars /etc/rc.local retval=$? if [ $retval -ne 0 ]; then echo >&2 "Calico node ...
calico
weixin_34392906的博客
08-27 408
为什么80%的码农都做不了架构师？>>> ...
Readiness probe failed: caliconode is not ready: BIRD is not ready: BGP not established w
weixin_43999753的博客
09-23 2480
Calico 问题 :Readiness probe failed: caliconode is not ready: BIRD is not ready: BGP not established with 10.1.126.32 解决方法： 调整calicao 网络插件的网卡发现机制，修改IP_AUTODETECTION_METHOD对应的value值。官方提供的yaml文件中，ip识别策略（IPDETECTMETHOD）没有配置，即默认为first-found，这会导致一个网络异常的ip作为nod
【水文】calico-node 启动失败 Init:CrashLoopBackOff
大健的日常的博客
12-02 1万+
Defaulted container "calico-node" out of: calico-node, upgrade-ipam (init), install-cni (init), mount-bpffs (init) Error from server (BadRequest): container "calico-node" in pod "calico-node-4j7td" is waiting to start: PodInitializing
K8s集群node节点异常处理(Calico)
漠效的博客
03-19 8093
前言 近期在测试环境k8s集群发现Calico的节点出现了异常，状态一直处于连接中，而且node节点的ip也出现了变化。 于是对此次处理过程进行记录。这个异常不具备普遍性，因此文档仅供参考。 发现在Calico 异常的node节点上，出现了大量的br开头的以及一些其他的虚拟网卡和虚拟ip. 应该是这些ip导致的。由于具体排查和处理需要大量的时间，为了不影响服务，先把异常节点下线。 备注: 可查看异常pod日志，再处理问题 kubectl logs calico-node-f846j -
k8s网络插件之Calico
梵修
12-01 1万+
Calico是一套开源的网络和网络安全解决方案，用于容器、虚拟机、宿主机之前的网络连接，它是一个纯三层的虚拟化网络解决方案，它把每个节点都作为一个虚拟路由器，并把每个节点上的Pod当作是节点路由器后的一个终端设备并为其分配一个IP地址。各节点路由器通过BGP协议生成路由规则，从而实现不通节点上Pod间的通信。如下图：与Flannel相比，Calico的一个显著优势是对网络策略的支持，它允许用户定义访问控制规则以管控进出Pod的数据报文，从而为Pod间的通信施加安全策略。
k8s中calico网络组件部署时一个节点一直处于Pending状态
weixin_45294285的博客
03-12 4611
default-scheduler 0/3 nodes are available: 1 Insufficient cpu, 2 node(s) didn't match Pod's node affinity/selector
calico启动NodeName获取的顺序
weixin_42323738的博客
06-07 243
2、如果1为false，则判断NODENAMEFromFile，默认文件路径为/var/lib/calico/nodename，如果不为空，则只用NODENAMEFromFile的内容作为NODENAME。3、如果2为false，则或者环境变量HOSTNAME，如果为true，则HOSTNAME作为NODENAME。2、如果2为false，则或者环境变量HOSTNAME，如果为true，则HOSTNAME作为NODENAME。3、如果3为false，则自动获取主机名称，作为NODENAME。
kube_daemonset_status_number_misscheduled{job!~"k8s-(.*)-prometheus|node-exporter"} > 0
02-26
<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、付费专栏及课程。

余额充值