k8s集群的calico-node的守护容器探测异常Liveness probe failed: Get http://localhost:9099/liveness

文章讲述了K8s集群中calico-node节点偶发的livenessprobe探测异常问题,原因在于calico-node容器尝试通过ipv6访问localhost失败。解决方法是将livenessprobe的localhost地址改为ipv4的127.0.0.1并重启容器。

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

背景:

k8s集群正常运行过程中偶发的出现calico-node节点容器探测异常的问题,出现之后会导致宿主机所在的容器也会相应的出现网络波动,但是都是过一会儿就自动就好了,。

​
Liveness probe failed: Get http://localhost:9099/liveness: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

​

故障分析:

分析的时候发现对应的calico-node节点容器是正常的:

[root@master-01 ~]# kubectl describe pods calico-node-mlekb -n kube-system
Name:                 calico-node-mlekb
Namespace:            kube-system
Priority:             2000001000
Priority Class Name:  system-node-critical
Node:                 pro-slave-12/192.20.66.22
Start Time:           Wed, 21 Dec 2022 14:57:38 +0800
Labels:               component=calico
                      controller-revision-hash=74c5ff99d4
                      k8s-app=calico
                      pod-template-generation=1
Annotations:          kubernetes.io/psp: system
Status:               Running
.........

同时describe查看的内容只有探测告警的内容:

然后登入倒calico-node容器上去执行curl时也是正常的

但是让专家分析的时候说在calico-node节点容器里访问localhost的时候会走ipv6的网络,并且是失败的情况。经过提醒确实是这样的:

然后去检查calico的ippools的配置:

发现k8s集群的calico只有启用了ipv4的地址池,同时查看calico.yaml文件的configmap有开启ipv6配置:

 

问题处理:

既然localhost的解析会解析到ipv6的地址上去,那就可以将livenss探针的配置localhost修改为127.0.0.1的地址,然后重启一下calico-node容器就可以了。

<think>嗯,用户遇到了Milvus的etcd启动报错,显示健康检查失败,连接被拒绝。首先,我需要回忆一下Milvus和etcd的关系。Milvus依赖etcd作为元数据存储,如果etcd出问题,整个系统可能无法正常运行。 接下来,看错误信息里的关键点:Liveness probe failed,还有连接被拒绝。可能的原因有很多,比如etcd服务没有正确启动,网络问题导致无法访问,资源不足,或者配置错误。 先考虑etcd本身的状态。用户可能没有检查etcd的Pod状态,需要确认Pod是否处于Running状态,是否有频繁重启的情况。如果Pod没有运行,可能是资源不足,比如内存或CPU不够,或者存储卷的问题。 然后是网络问题。错误中提到无法建立TCP连接到2379端口,可能etcd的Service没有正确暴露端口,或者网络策略阻止了连接。需要检查Service和Endpoints是否正确,以及网络策略是否允许流量通过。 另外,etcd的日志也很重要。用户应该用kubectl logs命令查看etcd Pod的日志,看看有没有启动时的错误,比如证书问题、节点间通信失败等。如果是集群部署,节点间的网络连通性也需要检查。 资源限制也是一个常见问题。etcd对资源比较敏感,如果内存不足,可能会导致进程被OOMKilled。需要确认Pod的资源请求和限制是否合理,适当调整。 还有健康检查的配置。有时候liveness probe的超时时间设置太短,导致在etcd启动较慢时误判为失败。可以适当增加initialDelaySeconds或timeoutSeconds,看看是否有改善。 安全配置方面,etcd可能启用了TLS,而客户端没有正确配置证书,导致连接失败。需要检查etcd的证书配置和Milvus的连接参数是否匹配。 最后,建议用户按照步骤逐一排查:检查Pod状态和日志,确认网络连通性,调整资源限制和健康检查参数,验证安全配置。如果问题依然存在,可能需要更深入的集群诊断,比如检查kube-proxy或CNI插件的问题。</think>以下是针对该问题的逐步分析及解决方案: ============================ ### 关键错误信息解析 ``` Liveness probe failed: {"level":"warn","ts":"2025-03-24T09:05:46.222578Z","logger":"client",...,"error":"rpc error: code = DeadlineExceeded desc = ... connection refused\""} ``` 核心错误为 **etcd 2379端口连接被拒绝**,表明健康检查探测失败。 ============================ ### 第一步:检查etcd基础状态 ```bash kubectl get pods -l app=etcd -o wide # 确认Pod状态是否为Running kubectl describe pod my-release-etcd-0 # 查看Events中是否有异常事件 kubectl logs my-release-etcd-0 # 直接查看etcd容器的日志 ``` *常见现象*:OOMKilled(内存不足)、CrashLoopBackOff(持续崩溃)、Pending(资源不足) ============================ ### 第二步:排查网络连通性问题 ```bash kubectl get svc my-release-etcd # 检查Service类型和端口映射 kubectl get endpoints my-release-etcd # 验证Endpoint是否包含正确IP kubectl exec -it busybox -- nc -zv 10.244.70.177 2379 # 测试跨节点网络连通性 ``` *常见问题*:Service未正确暴露端口、节点防火墙规则限制、CNI插件异常 ============================ ### 第三步:检查资源限制配置 ```yaml # 检查Helm values.yaml中etcd资源配置示例 etcd: resources: requests: memory: "4Gi" cpu: "1000m" limits: memory: "8Gi" cpu: "2000m" ``` *注意*:etcd对内存敏感,建议至少分配4GB内存,生产环境需更高配额 ============================ ### 第四步:调整健康检查参数(临时方案) ```yaml # 在Helm values.yaml中添加探针调优 etcd: livenessProbe: initialDelaySeconds: 60 # 延长初始化等待时间 timeoutSeconds: 10 # 适当增加超时阈值 readinessProbe: initialDelaySeconds: 60 timeoutSeconds: 10 ``` *注意*:此调整仅用于缓解健康检查误判,需同步解决根本问题 ============================ ### 第五步:检查证书配置(TLS场景) ```bash kubectl exec -it my-release-etcd-0 -- ls /etc/etcd/tls # 验证证书文件存在性 kubectl describe secret etcd-certs # 检查证书Secret是否有效 ``` *典型错误*:证书过期、SAN列表不包含服务域名、证书链不完整 ============================ ### 高级排查建议 1. 检查etcd数据持久化状态: ```bash kubectl exec -it my-release-etcd-0 -- etcdctl --endpoints=localhost:2379 endpoint status ``` 2. 验证集群节点时钟同步: ```bash kubectl exec -it my-release-etcd-0 -- date && date -u # 检查时区与时钟偏差 ``` 3. 检查内核参数: ```bash sysctl fs.file-max # 建议值 >100000 sysctl fs.inotify.max_user_watches # 建议值 >524288 ``` ============================ ### 典型解决方案汇总 | 问题类型 | 解决方案 | |---------|----------| | 资源不足 | 增加CPU/Memory配额,添加NodeSelector调度到高配节点 | | 网络故障 | 检查Calico/Flannel日志,验证kube-proxy是否正常 | | 数据损坏 | 清理持久化卷并重建StatefulSet(会丢失数据!) | | 配置错误 | 检查Helm values.yaml中的endpoints配置是否包含完整FQDN | 建议按照上述步骤依次排查,重点关注**Pod事件日志**和**etcd容器日志**中的时序关联信息。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

jiang0615csdn

你对鼓励是我最大的动力来源

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值