k8s-coredns-CrashLoopBackOff 工作不正常

img

本文作者: slience_me


问题描述

# 问题描述
# root@k8s-node1:/home/slienceme# kubectl get pods --all-namespaces
# NAMESPACE      NAME                                READY   STATUS             RESTARTS   AGE
# kube-flannel   kube-flannel-ds-66bcs               1/1     Running            0          12h
# kube-flannel   kube-flannel-ds-ntwwx               1/1     Running            0          12h
# kube-flannel   kube-flannel-ds-vb6n9               1/1     Running            5          12h
# kube-system    coredns-7f9c544f75-67njd            0/1     CrashLoopBackOff   17         12h   // [!code focus:8]
# kube-system    coredns-7f9c544f75-z82nl            0/1     CrashLoopBackOff   17         12h
# kube-system    etcd-k8s-node1                      1/1     Running            4          12h
# kube-system    kube-apiserver-k8s-node1            1/1     Running            4          12h
# kube-system    kube-controller-manager-k8s-node1   1/1     Running            3          12h
# kube-system    kube-proxy-fs2p6                    1/1     Running            0          12h
# kube-system    kube-proxy-x7rkp                    1/1     Running            0          12h
# kube-system    kube-proxy-xpbvt                    1/1     Running            3          12h
# kube-system    kube-scheduler-k8s-node1            1/1     Running            3          12h
# kube-system    tiller-deploy-6ffcfbc8df-mzwd7      1/1     Running            0          39m

原因分析:

在 CoreDNS 的配置文件 (Corefile) 中,forward 插件不应该指向 CoreDNS 本身,否则会导致 DNS 请求循环。如果 forward 指向 CoreDNS,它会不断地将请求转发回自己,造成无限循环。

通过对问题的追踪,在github issue找到 CoreDNS pod goes to CrashLoopBackOff State

解决方案:

你需要修改 Kubernetes 中的 CoreDNS 配置,具体操作步骤如下:

步骤 1: 修改 CoreDNS 配置ConfigMap

kubectl edit configmap coredns -n kube-system

步骤 2: 修改 Corefile 配置

修改 Corefile 中的 forward 配置,当前配置为:

forward . /etc/resolv.conf

你需要将其修改为指向外部 DNS 服务器,比如 Google 的公共 DNS 服务器 8.8.8.81.1.1.1(Cloudflare DNS)。例如,你可以修改为:

forward . 8.8.8.8

或者如果你希望使用多个 DNS 服务器,可以配置多个地址:

forward . 8.8.8.8 8.8.4.4

步骤 3: 保存并退出

步骤 4: 验证配置生效

验证 CoreDNS 配置是否生效,可以查看 CoreDNS Pod 是否正常运行,并且配置是否正确生效。

kubectl get pods -n kube-system -l k8s-app=kube-dns

如果需要,也可以重启 CoreDNS Pods,以确保新的配置生效:

kubectl rollout restart deployment coredns -n kube-system

通过这些步骤,你就能避免 CoreDNS 发生循环请求,确保 DNS 请求被转发到外部的 DNS 服务器,而不是 CoreDNS 本身。

### 解决 Kubernetes 中 Tigera Operator Pod 状态稳定的问题 当遇到 `CrashLoopBackOff` 错误时,通常意味着容器启动失败并断重启。对于 `tigera-operator` 这样的组件来说,可能的原因有很多。 #### 日志分析 查看日志可以帮助理解为什么 `tigera-operator` 容器无法正常工作。可以使用如下命令获取更多细节: ```bash kubectl logs -<pod-name> -n kube-system ``` 这一步骤有助于识别具体的错误消息或异常情况[^1]。 #### 配置文件验证 由于安装过程中指定了自定义配置文件 (`values.yaml`),建议仔细检查该文件的内容是否存在任何可能导致问题的设置。特别是网络插件相关的参数,因为 Calico 是作为 CNI 实现被部署的。 #### 基础设施健康状况评估 考虑到 CoreDNS 出现过循环查询的问题[^2],这也可能是整个集群内部通信存在问题的表现之一。因此有必要确认其他核心服务的状态是否良好,比如通过下面这条指令来获得所有命名空间下的 Pods 列表及其状态概览: ```bash kubectl get pods --all-namespaces ``` 如果发现有多个关键组件都处于健康的条件下,则更有可能是一个影响范围较广的基础架构层面的问题而是单独针对某个特定应用的服务故障[^3]。 #### ARP 测试 为了进一步诊断潜在的网络连接障碍,在 Master 和 Worker 节点之间执行简单的连通性测试也是有益处的。例如利用 BusyBox 工具来进行 ICMP Echo Request (ping): ```bash kubectl exec busybox-deployment-8c7dc8548-x6ljh -- ping 192.168.196.131 -c 1 ``` 以及随后检查相应的 ARP 缓存记录以确保 IP 地址解析成正确的 MAC 地址[^4]: ```bash kubectl exec busybox-deployment-8c7dc8548-x6ljh -- arp ``` 以上方法能够帮助定位引起 `tigera-operator` 稳定的具体原因,并采取相应措施加以修复。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

slience_me

你的鼓励将是我创作的最大动力

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

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

打赏作者

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

抵扣说明:

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

余额充值