「Kubernetes」- 使用DaemonSet时,主节点没有运行Pod实例 @20210130

本文档详细介绍了如何解决使用DaemonSet时Pod未在Master节点上创建的问题。通常,从Kubernetes 1.6开始,由于node-role.kubernetes.io/master污点,DaemonSet不会调度到Master节点。解决方案是在DaemonSet的Pod定义中添加容忍该污点的配置。然而,作者在特定情况下错误地为Master节点添加了额外的Taint,导致即使删除node-role.kubernetes.io/master污点,Pod也无法调度。正确做法是移除之前添加的Taint,或者恢复Master节点的默认设置并应用常规解决办法。

内容简介

处理「当使用DaemonSet时,没有在主节点创建Pod实例」问题。

问题描述

在以DaemonSet方式部署Traefik Ingress Controller之后,没有在Master节点上创建Pod实例。因此不能通过Master节点来访问服务,但是我们希望Master节点中也运行Pod实例。

经过一番Google查找,学习「Taints and Tolerations」文档。

问题原因(正常情况)

因为从1.6开始,不会再将DaemonSet调度到主节点上。由于主节点上有node-role.kubernetes.io/masterNoSchedule污点,而Pod没有容忍该污点,所以不会调度到主节点上。

!!!既然官方已经不建议这么做了,如果没有必要就不要向主机调度Pod了,除非是出于监控或者指标收集等原因。

解决办法(正常情况)

我参考了「Kubernetes ds won't run pod on master node」与「Scheduler is not scheduling Pod for DaemonSet in Master node」这两个问题。

正确的解决办法其实是在DaemonSets的Pod定义中添加如下配置:

tolerations:
- key: node-role.kubernetes.io/master
  effect: NoSchedule

问题原因(我的情况)

我的情况有点特殊:症状是常见的症状,但是成因却稍微有所不同。

因为在第一次遇到这个问题之后,由于不懂,我一顿搜索搜索之后,执行了kubectl taint nodes k8s-master key=value:NoSchedulekubectl taint nodes --all node-role.kubernetes.io/master-命令。当执行第一条命令之后,将不会有Pod调度到主节点上。之后,执行第二条命令,虽然删除了node-role.kubernetes.io/master污点,但是依旧不能调度,因为Pod不能容忍第一个污点。

解决办法(我的情况)

不是常规成因,所以也不是常规的解决办法。

最后我也发现:由于之前的测试,在Master节点上添加了Taint的NoSchedule标记,从而导致后面创建的Pod示例无法调度到该节点上。因此去掉该Taint即可。(而最好的解决办法是把Master的node-role.kubernetes.io/master污点还给人家,然后运行正常的解决办法。)

注意事项

由于主节点具有一定的特殊性,出于安全及角色的原因,其实不建议在Master节点上运行Pod实例。

参考文献

WikiNotes/使用DaemonSet时,主节点没有运行Pod实例
Kubernetes ds won't run pod on master node
Scheduler is not scheduling Pod for DaemonSet in Master node
kubernetes/Concepts/DaemonSet#Taints and Tolerations

### Kubernetes DaemonSet 部署 Master 节点缺少 Pod 的解决方案 #### 一、检查节点状态 确保所有节点,包括Master节点处于正常工作状态。可以通过`kubectl get nodes`命令查看各个节点的状态。如果发现某些节点不可用或存在异常,则需要进一步排查这些节点上的问题。 #### 二、验证Flannel网络配置 由于提到所有节点需上传flannel镜像至/opt目录并由master节点应用kube-flannel.yml文件[^2],因此要确认此操作已在集群内全部完成,并且Flannel CNI插件已成功启动运行。这一步骤对于跨主机容器间通信至关重要,任何错误都可能导致Pod无法被正确分配给目标节点。 #### 三、调整调度策略排除控制平面组件所在节点 默认情况下,Kubernetes不会将普通的工作负载安排到标记为“control-plane”的节点上(即通常所说的master节点)。这是因为通过taints/tolerations机制设置了排斥规则来保护关键系统的稳定性。然而,在特定场景下比如小型开发测试环境中可能希望改变这种行为以便充分利用资源。此可考虑移除相关污点或者增加容忍度设置让DaemonSets能够覆盖整个集群中的每一个成员: ```bash # 移除master节点上的NoSchedule taint kubectl taint nodes <your-master-node-name> node-role.kubernetes.io/control-plane- ``` 上述命令将会使得master节点不再具有阻止其他pods调度上去的特性,从而允许DaemonSet管理下的Pod实例也能在此类特殊位置创建出来。 #### 四、重启API Server和服务代理进程 有简单的服务重启就能解决问题。尝试停止再重新开启apiserver以及kube-proxy等相关后台程序可能会刷新内部缓存数据结构进而恢复正常的服务发现流程。具体做法取决于所使用的操作系统版本及其初始化方式;例如systemd环境下可以使用如下指令: ```bash sudo systemctl restart kubelet.service sudo systemctl restart kube-apiserver.service sudo systemctl restart kube-controller-manager.service sudo systemctl restart kube-scheduler.service sudo systemctl restart kube-proxy.service ``` 以上措施有助于清除潜在的数据不一致情况,特别是当遇到因同步过程发生部分Node信息丢失而导致DaemonSet的部分Pod实例无法调度的情况尤为有效[^1]。 #### 五、核对资源配置请求与实际可用容量之间的匹配程度 最后还需仔细对比期望部署的应用所需CPU/内存等硬件参数同当前环境所能提供的最大限额之间是否存在冲突。即使是在看似充足的条件下也有可能因为预留不足或其他因素造成个别实例得不到满足而一直处于Pending阶段。针对这一点可通过编辑YAML描述文档适当降低单个单元消耗量或是扩大整体供给规模加以改善。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值