k8s主节点部署pod状态一直是pending原因排除,并彻底删除pod技巧

前言

一般来说,master节点是会产生一个污点,不允许部署pod的。

命令检测pod处于pending原因

如果其他原因也可以使用这个命令检查状态原因

# 查看节点状态原因
kubectl -n <namespace> describe pod <pod-name>

# 也可以查看日记
kubectl logs <pod-name> -n <namespace> --previous
这个命令打印前一个容器的错误消息

当出现类似这样问题
问题描述:
Warning FailedScheduling 40s (x28 over 28m) default-scheduler 0/1 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/master: }, that the pod didn’t tolerate.
这是master节点上部署pod会出现的报错:说明当前pod不被mester污点所容忍

也可以查看当前节点的污点:

# 查看名为node-name节点所纯在污点
kubectl describe node <node-name> | grep Taints

# 或者查看所有节点,包括master、node节点
kubectl get no -o yaml | grep taint -A 5

在这里插入图片描述
key:node-role.kubernetes.io/master就是kubeadm集群时污点,出于安全考虑Pod不会被调度到Master Node上,默认情况下,master打了污点,不参与工作负载

关于污点和容忍度推荐看下官方解读《污点和容忍度》

解决办法

  • 最直接可以删除这个污点:
kubectl taint nodes --all node-role.kubernetes.io/master-

之后你就发现之前部署的pod就会处于running

  • 当然再次开启master节点污点,可以执行:
kubectl taint nodes k8s node-role.kubernetes.io/master=true:NoSchedule

正确删除pod

在日常的k8s运维过程中,避免不了会对某些pod进行剔除,那么如何才能正确的剔除不需要的pod呢

  • 首先,需要查出想要删除的pod
kubectl get pods -A |grep <podname>
kubectl get pods -n <namespace>
kubectl get pods --all-namespaces |grep <podname> 
  • kubectl 删除pod命令
kubectl delete pod <podname> -n <namespace>

例如:kubectl delete pod nginx-web-460776586-f6nf0 -n yundoc 

可是这里你会发现,在进行删除delete pod后,并不会直接删除。该pod会自动重新构建(可以理解为重启、重构),原因是k8s误认为我们要删除的pod异常挂了,会启用容灾机制,导致重新再拉起一个新的pod。

我们想要正常且彻底的删除一个pod,必须要先破坏掉他的容灾机制,即删除deployment机制。

  • 查看deployment信息
#可理解是调度管理pod的
kubectl get deployment --all-namespaces
kubectl get deployment -n kube-system
  • 删除deployment配置
kubectl delete deployment <deployment名> -n <namespace>

例如:kubectl delete deployment nginx-web -n yundoc

删除deployment,pod会随之删除。

可通过再次查看pod状态,然后进行删除pod命令即可,通常情况下删除deployment后,再次查询pod发现,pod已经开始自行删除了(这步可酌情处理)。

  • 强制删除pod(对于node部分节点无法删除的)
# 删除POD
kubectl delete pod PODNAME --force --grace-period=0

# 删除NAMESPACE不一定有用
kubectl delete ns NAMESPACENAME --force --grace-period=0

### Kubernetes 1.21 版本新加入节点域名解析失败解决方案 Kubernetes 集群中的 DNS 是通过 CoreDNS 提供服务的,默认情况下,CoreDNS 负责处理集群内部的服务发现和域名解析。如果在 Kubernetes 1.21 中新增加的节点无法解析域名,则可能是由于以下几个原因引起的。 #### 可能的原因分析 1. **CoreDNS 未正常运行** 如果 CoreDNS 的 Pod 出现异常状态(如 CrashLoopBackOff 或者 Pending),则可能导致整个集群内的域名解析功能失效[^1]。 2. **网络插件配置错误** Kubernetes 使用 CNI 插件来管理容器网络。如果新的节点上未正确安装或配置网络插件(例如 Calico、Flannel 等),可能会导致 DNS 请求在网络层面上被阻断[^2]。 3. **kubelet 服务未启动成功** 新增节点上的 `kubelet` 服务如果没有正确启动注册到 API Server 上,也可能影响该节点与其他组件之间的通信,从而间接导致 DNS 解析问题[^3]。 4. **resolv.conf 文件设置不当** 容器内的 `/etc/resolv.conf` 应指向 CoreDNS 所监听的地址(通常是 `cluster-ip`)。如果此文件的内容不正确,比如包含了外部 DNS 地址或其他无效条目,则会干扰正常的名称解析过程[^4]。 --- #### 排查步骤与修复方法 ##### 1. 检查 CoreDNS 运行状况 确认当前部署环境中是否存在健康的核心 DNS 组件实例: ```bash kubectl get pods -n kube-system -l k8s-app=kube-dns ``` 上述命令应返回至少一个处于 Running 状态下的 CoreDNS Pod 实例;否则需进一步排查日志信息找出具体故障所在位置,采取相应措施恢复其运作能力。 ##### 2. 核实网络连通性 测试目标主机能否访问到指定的 ClusterIP 对应于 CoreDNS 服务端口 (默认为53/tcp),可执行如下操作验证连接情况: ```bash nc -zv <coredns-clusterip> 53 ping <coredns-clusterip> ``` ##### 3. 查看 Kubelet 日志记录 登录至出现问题的新服务器终端界面下输入以下指令获取更多关于本地代理进程的工作详情以便定位潜在隐患源头: ```bash journalctl -u kubelet.service --no-pager | tail -n 50 ``` ##### 4. 修改 resolv.conf 设置 进入任意有问题的应用容器内部环境编辑路径名为 /etc/resolv.conf 文档内容替换原有数据仅保留一行server字段值设为核心 dns ip 即可完成调整工作流程图解说明如下所示: 假设已知 core dns service cluster ip address is : 10.x.y.z; 那么最终修改后的效果应该是这样的样子 : ```plaintext nameserver 10.x.y.z search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5 ``` --- ### 总结 通过对以上几个方面的逐一核查可以有效解决大部分因各种因素引发出来的此类现象的发生概率大大降低同时提高了整体系统的稳定性表现水平.
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值