☰

GKE 上的抢占式节点池出现 DNS 问题：kube-dns 服务的端点保留失败的 Pod

tag-icon • tag-icon kubernetes google-kubernetes-engine dnsmasq
GKE 上的抢占式节点池出现 DNS 问题：kube-dns 服务的端点保留失败的 Pod

我确实有一个由可抢占节点组成的 GKE k8s 集群（k8s 1.22）仅有的，其中包括 kube-dns 等关键服务。这是一台可以容忍每天出现几分钟故障的开发机器。每次关闭托管 kube-dns pod 的节点时，我都会遇到 DNS 解析问题，这些问题会一直存在，直到我删除失败的 pod（在 1.21 中，pod 保持“状态：失败”/“原因：关闭”，直到手动删除）。

虽然我确实预计在回收可抢占节点时会出现一些问题，但我希望几分钟后它能够自行修复。持续存在问题的根本原因似乎是故障的 pod 未从 k8s Service/中删除Endpoint。这是我在系统中看到的内容：

通过以下方式查看 Pod 的状态kubectl -n kube-system get po -l k8s-app=kube-dns

NAME                        READY   STATUS       RESTARTS   AGE
kube-dns-697dc8fc8b-47rxd   4/4     Terminated   0          43h
kube-dns-697dc8fc8b-mkfrp   4/4     Running      0          78m
kube-dns-697dc8fc8b-zfvn8   4/4     Running      0          19h

故障 pod 的 IP 是 192.168.144.2 - 它仍然被列为该服务的端点之一：

kubectl -n kube-system describe ep kube-dns带来这个：

Name:         kube-dns
Namespace:    kube-system
Labels:       addonmanager.kubernetes.io/mode=Reconcile
              k8s-app=kube-dns
              kubernetes.io/cluster-service=true
              kubernetes.io/name=KubeDNS
Annotations:  endpoints.kubernetes.io/last-change-trigger-time: 2022-02-21T10:15:54Z
Subsets:
  Addresses:          192.168.144.2,192.168.144.7,192.168.146.29
  NotReadyAddresses:  <none>
  Ports:
    Name     Port  Protocol
    ----     ----  --------
    dns-tcp  53    TCP
    dns      53    UDP

Events:  <none>

我知道其他人通过以下方式解决了这些问题将 kube-dns 调度到其他 pod，但我宁愿让它具有自我修复功能，因为节点故障仍然可能发生在非可抢占节点上，只是可能性较小。

我的问题：

  • 为什么即使在初始节点发生故障数小时后，发生故障的 pod 仍然被列为服务的端点之一？
  • 我可以做些什么来缓解这个问题（除了添加一些非短暂节点）？

似乎 GKE 中默认部署中的 kube-dns 没有连接到 dnsmasq（端口 53）的就绪探测，而该探测是 kube-dns 服务的目标，拥有该探测可以解决问题 - 但我怀疑它不存在，原因我还不明白。

编辑：显然是这样不是1.21.6-gke.1500（常规通道）上会发生这种情况，但 1.22.6-gke.1500（快速通道）上也会发生这种情况。我没有很好的解释，但尽管今天有几个失败的 pod，但 kube-dns 服务只包含正常工作的 pod。

答案1

不建议使用抢占式节点来运行关键工作负载，例如 kube-dns（1)，因此出现这种情况是可以预料的。

您可以尝试通过将 pod 标记为关键来缓解此问题（2), 使用节点自动配置 (3）或 PodDisruptionBudget（4）。
此文档 (5）。

此外，已经向 Google 提出了一些建议（6）。

如果以上方法都不能解决您的问题，您可以通过以下方式报告 公共问题追踪。

答案2

它也开始发生在我的环境（gke 上的可抢占节点）上，并且发生在所有部署中，但 kube-dns 是最关键的一个。我认为这可能与revisionHistoryLimit参数有关。默认值为 10，因此最多 10 个旧副本将存在一段时间。我已将其设置为 0 并期望节点被替换，让我们看看 :)

相关内容