【Kubernetes】controller-manager组件状态Unhealthy解决

最新推荐文章于 2023-03-24 16:43:33 发布
最新推荐文章于 2023-03-24 16:43:33 发布
阅读量3.2k 收藏 1
点赞数 3
CC 4.0 BY-SA版权
分类专栏： Kubernetes 文章标签： kubernetes
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/cnskylee/article/details/117560305
在执行`kubectl get componentstatuses`时，发现controller-manager状态为Unhealthy，错误消息显示HTTP probe失败。解决方案是删除kube-controller-manager配置文件中`--port=xxxxx`选项，仅保留`--secure-port=10257`，然后重启kube-controller-manager服务。完成重启后，controller-manager状态恢复正常。从1.13版本开始，kube-controller-manager的非安全端口已被废弃，建议使用安全端口进行livenessProbe。

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

【异常提示】使用kubectl获取组件的状态时，提示“controller-manager   Unhealthy   HTTP probe failed with statuscode: 400”

$ kubectl get componentstatuses
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME                       STATUS            MESSAGE                                                ERROR
scheduler                  Healthy             ok                             &nb

了解本专栏 订阅专栏 解锁全文 超级会员免费看
解决kubernetes集群controller-manager 和scheduler状态 Unhealthy问题
江晓龙的博客
05-11 1363
解决kubernetes集群controller-manager 和scheduler状态 Unhealthy问题 最近通过kubeadm安装K8s，组件controller-manager 和scheduler状态 Unhealthy [root@k8s-master1 ~]# netstat -lnpt | egrep '10251|10252' 端口也不存在 rancher上显示也比较难看 解决方法如下： 在所有master节点都要操作 vim /etc/kubernetes/manifes
kubeadm安装k8s 组件controller-manager 和scheduler状态 Unhealthy
小啊宇的博客
02-06 942
通过kubeadm安装好kubernetes v1.20.2 查看集群状态，发现组件controller-manager 和scheduler状态 Unhealthy 检查端口未监听 组件运行正常 检查kube-scheduler和kube-controller-manager组件配置是否禁用了非安全端口 vim /etc/kubernetes/manifests/kube-scheduler.yaml vim /etc/kubernetes/manifests/kube-controller-man
kubernetes二进制部署k8s-master集群controller-manager服务unhealthy问题
li123128的博客
12-29 7380
　　一.问题现象 　　 　　我们使用二进制部署k8s的高可用集群时，在部署多master时，kube-controller-manager服务提示Unhealthy 　　 　　[root@ceph-01 system]# kubectl get cs 　　 　　NAME                 STATUS      MESSAGE                             ...
k8s组件状态异常:scheduler Unhealthy controller-manager Unhealthy排除
Q先生
03-24 484
【代码】k8s组件状态异常:scheduler Unhealthy controller-manager Unhealthy排除。
k8s踩坑2——scheduler 、controller-manager Unhealthy
weixin_42104154的博客
05-30 1049
查看master组件状态时出现错误 [root@k8s-master ~]# kubectl get cs Warning: v1 ComponentStatus is deprecated in v1.19+ NAME STATUS MESSAGE ERROR scheduler
Kubeadm部署k8s集群后，scheduler和controller-manager为Unhealthy
weixin_44280843的博客
09-25 888
Get "http://127.0.0.1:10252/healthz": dial tcp 127.0.0.1:10252: connect: connection refused
k8s集群部署之后，controller-manager和scheduler组件状态依然是Unhealthy
每一个不曾起舞的日子，都是对生命的辜负
07-10 1172
这是国外的一个网站的帖子部分内容：意思是从1.13版本开始，kube-controller-manager 和 kube-scheduler 使用使用10257、10259作为暴露的secure-ports（安全端口），而--insecure-ports（非安全端口）常用的10251、10252已经被废弃。 Since 1.13, kube-controller-manager and kube-scheduler exposing 10259, 10257 as a secure ports，In...
Kubernets集群排错之-scheduler&controller-manager组件不健康
云计算新生代农民工
09-07 1517
[root@master1 ~]# kubectl get cs NAME STATUS MESSAGE ERROR scheduler Unhealthy Get http://127.0.0.1:10251/healthz: dial tcp 127.0.0.1:1025
Kubeadm：如何解决kubectl get cs显示scheduler Unhealthy，controller-manager Unhealthy
m0_47219942的博客
03-26 2047
Kubeadm：如何解决kubectl get cs显示scheduler Unhealthy，controller-manager Unhealthy报错显示排障思路1.查看端口2.确认schedule和controller-manager组件配置是否禁用了非安全端口 报错显示 [root@k8s-master ~]# kubectl get cs Warning: v1 ComponentStatus is deprecated in v1.19+ NAME STATUS
kubectl get cs查看组件状态kube-scheduler和kube-controller-manager显示unhealthy
小楼一夜听春雨，深巷明朝卖杏花
12-14 4287
通过kubeadm安装的k8s集群获取kube-scheduler和kube-controller-manager组件状态异常 原因1:这两个pod的非安全端口没有开启，健康检查时报错，但是由于本身服务是正常的，只是健康检查的端口没启，所以不影响正常使用。 $ kubectl get cs NAME STATUS MESSAGE
kubernetes之deployment删除失败定位：controller-manager Unhealthy问题
qq_38695182的博客
01-15 2872
一、环境：Ubuntu  16.04.1                    k8s         1.8.0 二、问题：       删除deployment失败，排查问题发现：       ①.执行 kubectl get componentstatuses，发现controller-manager  Unhealthy       ②.查看k8s  controller-m...
【Rancher相关问题】Rancher 2.5.8 及以下版本，提示Alert: Component controller-manager,scheduler is unhealthy.
拾级而上
06-09 1144
问题描述 如图，Rancher2.5.8版本提示 controller-manager,scheduler 不健康，管理的k8s集群版本1.21.1 解决方法 在Master节点执行如下命令： sed -i 's|- --port=0|#- --port=0|' /etc/kubernetes/manifests/kube-scheduler.yaml sed -i 's|- --port=0|#- --port=0|' /etc/kubernetes/manifests/kube-controller-
K8S报错：controller-manager Unhealthy Get http://127.0.0.1:10252/healthz: dial tcp 127.0.0.1:10252
学亮编程手记
01-05 3630
controller-manager Unhealthy Get “http://127.0.0.1:10252/healthz”: dial tcp 127.0.0.1:10252: connect: connection refused scheduler Unhealthy Get “http://127.0.0.1:10251/healthz”: dial tcp 127.0.0.1:10251: connect: connection refused 解决思路： 注释掉/etc/kubernet
rancher 警告: 组件 controller-manager 不健康
架构+开发+运维
12-14 2719
文章目录【报错】【解决】【结果】 【报错】 警告: 组件 controller-manager 不健康 警告: 组件 scheduler 不健康 【解决】 修改以上两个组件的静态pod的配置文件 /etc/kubernetes/manifests/kube-controller-manager.yaml /etc/kubernetes/manifests/kube-scheduler.yaml 两个文件，删除 --port=0 重启kubelete [root@crust-m01 ~]
kubeadm 搭建 v1.18.6 集群 scheduler, controller-manager Unhealthy 解决方案
wu_weijie的博客
08-08 544
https://www.gjie.cn/2618.html
k8s controller-manager scheduler Unhealthy
qq_15138049的博客
01-18 207
参考：https://blog.youkuaiyun.com/qq_39545674/article/details/110688805 /etc/kubernetes/manifests/kube-controller-manager.yaml /etc/kubernetes/manifests/kube-scheduler.yaml 删除文件中 - --port=0 再次查看 componentstatuses
解决Rancher Dashbroad组件controller-manager、scheduler不健康的问题
gaojie314的专栏
05-16 2465
安装完k8s，在rancher导入完k8s集群之后，显示如下问题： 解决： 1、解决方法，把主节点如下两个文件： /etc/kubernetes/manifests/kube-controller-manager.yaml /etc/kubernetes/manifests/kube-scheduler.yaml 找到中 --port=0 去掉即可； 2、重启kubelet： root@hncs-k8s-1:~# systemctl restart kubelet.service .
使用Kubeadm安装的K8s集群获取kube-scheduler和kube-controller-manager组件状态异常问题
非著名运维的博客
09-07 2364
报错：  使用Kubeadm安装的K8s集群获取kube-scheduler和kube-controller-manager组件状态异常，基本上都会出现这个问题。 [root@k8s-master ~]# kubectl get cs Warning: v1 ComponentStatus is deprecated in v1.19+ NAME STATUS MESSAGE
kube-controller-manager状态为 CreateContainerError，进行重启操作
star的博客
03-10 4666
kube-controller-manager状态为 CreateContainerError，重启kubelet无效 解决方案：停掉所有正在运行的容器 + 删除所有已经停止的容器，之后所有的容器会被k8s集群重新构建运行，原先某些处于非正常状态的pod都可以正常运行。 具体的执行步骤是： 1、先暂停kubelet服务。因为这个服务运行的话会有一些容器停不掉，并且也无法删除。执行命令如下： systemctl stop kubelet 2、停掉或杀死所有正在运行的容器。 docker kill $(do
kubeconfig] Using kubeconfig folder "/etc/kubernetes" [kubeconfig] Writing "admin.conf" kubeconfig file [kubeconfig] Writing "kubelet.conf" kubeconfig file [kubeconfig] Writing "controller-manager.conf" kubeconfig file [kubeconfig] Writing "scheduler.conf" kubeconfig file [control-plane] Using manifest folder "/etc/kubernetes/manifests" [control-plane] Creating static Pod manifest for "kube-apiserver" [control-plane] Creating static Pod manifest for "kube-controller-manager" W0707 16:09:08.109534 1814 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC" [control-plane] Creating static Pod manifest for "kube-scheduler" W0707 16:09:08.110003 1814 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC" [etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests" [wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s [kubelet-check] Initial timeout of 40s passed. 这个是报错嘛
最新发布
07-08
<think>我们分析用户提供的kubeadm init输出片段： 输出内容显示kubeadm已经完成了控制平面组件的静态Pod清单创建，并进入等待控制平面启动的阶段（[wait-control-plane]）。在等待40秒后超时（[kubelet-check] Initial timeout of 40s passed.），但此时并没有出现“ERROR”或“failed”等错误关键词，因此不能直接判断为报错。 详细解读： 1. 输出显示kubeadm正在等待kubelet启动控制平面的静态Pod（包括kube-apiserver, kube-controller-manager, kube-scheduler, etcd）。 2. 等待超时（40秒）是正常现象，因为控制平面组件的启动可能需要更长时间（尤其是etcd和kube-apiserver）。 3. 该阶段最大等待时间为4分钟（输出中提示：This can take up to 4m0s），所以40秒超时后kubeadm会继续等待，直到4分钟超时或控制平面就绪。 因此，当前状态不是报错，而是正常等待过程。但需要关注后续是否在4分钟内成功启动。 常见原因及解决方案： 1. **资源不足**：Master节点CPU/内存不足（特别是etcd需要足够内存）。 2. **网络问题**：节点之间通信问题，或DNS解析问题。 3. **kubelet故障**：检查kubelet服务状态：`systemctl status kubelet` 4. **镜像拉取失败**：使用`crictl images`或`docker images`检查控制平面组件镜像是否完整（如kube-apiserver:v1.18.8等）。 5. **端口冲突**：确保6443、2379-2380等端口未被占用。 诊断步骤： ```bash # 1. 检查kubelet日志（实时查看） journalctl -u kubelet -f # 2. 检查已拉取的镜像 crictl images | grep 'kube-apiserver\|kube-controller-manager\|kube-scheduler\|etcd' # 3. 检查静态Pod是否已生成 ls /etc/kubernetes/manifests/ # 应存在etcd.yaml, kube-apiserver.yaml等 # 4. 检查容器运行状态 crictl ps -a | grep -E 'apiserver|controller|scheduler|etcd' # 5. 查看进程级端口占用 ss -tulnp | grep -E '6443|2379|2380' ``` 如果4分钟后仍超时，kubeadm会输出错误信息，此时需要根据具体错误进行排查。 结论：当前输出不是报错，是等待过程中的正常提示。 §§相关问题§§ 1. 当kubeadm init在[wait-control-plane]阶段超时4分钟失败时，应如何逐步排查故障？ 2. Kubernetes控制平面组件（如etcd）启动失败通常有哪些常见原因？ 3. 如何查看kubelet日志以诊断Kubernetes控制平面启动问题？ 4. 在资源受限的环境中，如何优化Kubernetes控制平面组件的启动参数？ 5. 如何确认Kubernetes静态Pod（Static Pod）的清单是否正确生成？</think>### 分析：这不是报错，而是 Kubernetes 初始化过程中的正常等待阶段 #### 关键状态解读： 1. **正常流程阶段**： - `[kubeconfig] Writing ...`：成功生成集群配置文件 - `[control-plane] Creating static Pod manifest`：控制平面组件配置完成 - `[etcd] Creating static Pod manifest`：etcd 服务配置完成 2. **预期等待提示**： ```bash [wait-control-plane] Waiting for the kubelet to boot up... This can take up to 4m0s [kubelet-check] Initial timeout of 40s passed. ``` - 这是正常等待阶段（最长4分钟） - 40秒提示只是进度通知，**非错误** 3. **警告说明**： ```bash W0707 ... authorization-mode is "Node,RBAC"; using "Node,RBAC" ``` - 这是关于授权模式的**低风险警告** - 表示使用默认安全配置，不影响安装 #### 后续正常输出示例： ```bash [apiclient] All control plane components are healthy after 102 seconds [upload-config] Storing the configuration used in ConfigMap [upload-certs] Skipping phase... [mark-control-plane] Marking the node master as control-plane... ``` #### 需要警惕的真实错误特征： 1. **错误关键词**： - `[ERROR]` - `failed` - `unhealthy` - `crash loop backoff` 2. **异常退出**： - 进程突然终止 - 返回非0退出码 #### 诊断建议： ```bash # 1. 检查kubelet状态（新终端执行） sudo systemctl status kubelet # 2. 查看容器状态 sudo crictl ps -a | grep -E 'apiserver|scheduler|etcd' # 3. 实时监控日志（等待期间） sudo journalctl -u kubelet -f ``` #### 等待策略： 1. **最大等待时间**：4分钟（输出已提示） 2. **网络影响**：首次启动可能需要下载额外镜像 3. **资源需求**：确保节点有足够CPU/内存（etcd至少2核2GB）
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

cnskylee

技术分享我是认真的，期待您打赏

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

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

打赏作者

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

抵扣说明：

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

余额充值