在 Kubernetes 集群中使用 NodeLocal DNSCache

本页概述了 Kubernetes 中的 NodeLocal DNSCache 特性。

开始之前

你需要有一个 Kubernetes 集群，并且 kubectl 命令行工具必须配置为与你的集群通信。建议在至少有两个非控制平面主机的节点组成的集群上运行本教程。如果你还没有集群，可以使用 minikube 创建一个，或者使用这些 Kubernetes 在线环境之一：

• Killercoda
• KodeKloud
• Play with Kubernetes

要检查版本，请输入 kubectl version。

简介

NodeLocal DNSCache 通过在集群节点上以 DaemonSet 的形式运行 DNS 缓存代理来提升集群 DNS 性能。在当前的架构中，处于 'ClusterFirst' DNS 模式下的 Pod 会通过 kube-dns serviceIP 发起 DNS 查询。这个查询通过 kube-proxy 添加的 iptables 规则被转换到 kube-dns/CoreDNS 端点。使用新的架构，Pod 将会访问在同一节点上运行的 DNS 缓存代理，从而避免 iptables DNAT 规则和连接跟踪。对于集群主机名（默认为 "cluster.local" 后缀）的缓存未命中，本地缓存代理将会向 kube-dns 服务发起查询。

动机

• 在当前的 DNS 架构下，如果本地没有 kube-dns/CoreDNS 实例，DNS QPS 最高的 Pod 可能必须访问不同的节点。拥有本地缓存将有助于在此类场景中改善延迟。

• 跳过 iptables DNAT 和连接跟踪有助于减少conntrack 竞争并避免 UDP DNS 条目填满 conntrack 表。

• 从本地缓存代理到 kube-dns 服务的连接可以升级到 TCP。TCP conntrack 条目会在连接关闭时移除，而 UDP 条目必须超时后才能移除（默认的 nf_conntrack_udp_timeout 为 30 秒）。

• 将 DNS 查询从 UDP 升级到 TCP 可以减少由丢弃的 UDP 数据包和通常长达 30 秒的 DNS 超时（3 次重试 + 10 秒超时）引起的尾部延迟。由于本地节点缓存监听 UDP DNS 查询，因此应用程序无需更改。

• 节点级别的 DNS 请求指标和可见性。

• 可以重新启用否定缓存，从而减少对 kube-dns 服务的查询次数。

架构图

NodeLocal DNSCache 启用后 DNS 查询遵循的路径

配置

可以通过以下步骤启用此特性

• 准备一个类似于示例 nodelocaldns.yaml 的清单文件，并将其保存为 nodelocaldns.yaml。

• 如果使用 IPv6，在采用“IP:端口”格式时，CoreDNS 配置文件需要将所有 IPv6 地址用方括号括起来。如果你使用上一点中的示例清单，则需要修改配置的第 70 行，像这样："health [__PILLAR__LOCAL__DNS__]:8080"。

• 用正确的值替换清单中的变量

  kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
  domain=<cluster-domain>
  localdns=<node-local-address>
  

  <cluster-domain> 默认为 "cluster.local"。<node-local-address> 是为 NodeLocal DNSCache 选择的本地监听 IP 地址。

  • 如果 kube-proxy 在 IPTABLES 模式下运行

    sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml
    

    __PILLAR__CLUSTER__DNS__ 和 __PILLAR__UPSTREAM__SERVERS__ 将由 node-local-dns Pod 填充。在此模式下，node-local-dns Pod 会同时监听 kube-dns 服务 IP 和 <node-local-address>，因此 Pod 可以使用任一 IP 地址来查找 DNS 记录。

  • 如果 kube-proxy 在 IPVS 模式下运行

    sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/,__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
    

    在此模式下，node-local-dns Pod 仅监听 <node-local-address>。node-local-dns 接口无法绑定 kube-dns 集群 IP，因为用于 IPVS 负载均衡的接口已经使用了该地址。__PILLAR__UPSTREAM__SERVERS__ 将由 node-local-dns Pod 填充。

• 运行 kubectl create -f nodelocaldns.yaml

• 如果在 IPVS 模式下使用 kube-proxy，则需要修改 kubelet 的 --cluster-dns 参数以使用 NodeLocal DNSCache 监听的 <node-local-address>。否则，无需修改 --cluster-dns 参数的值，因为 NodeLocal DNSCache 会同时监听 kube-dns 服务 IP 和 <node-local-address>。

启用后，node-local-dns Pod 将在每个集群节点的 kube-system 命名空间中运行。此 Pod 在缓存模式下运行 CoreDNS，因此各种插件公开的所有 CoreDNS 指标将在每个节点上可用。

你可以通过使用 kubectl delete -f <manifest> 移除 DaemonSet 来禁用此特性。你也应该还原对 kubelet 配置所做的任何更改。

StubDomain 和上游服务器配置

kube-system 命名空间中的 kube-dns ConfigMap 中指定的 StubDomain 和上游服务器将由 node-local-dns Pod 自动获取。ConfigMap 内容需要遵循示例中所示的格式。node-local-dns ConfigMap 也可以直接使用 Corefile 格式的 stubDomain 配置进行修改。有些云厂商可能不允许直接修改 node-local-dns ConfigMap。在这种情况下，可以更新 kube-dns ConfigMap。

设置内存限制

node-local-dns Pod 使用内存存储缓存条目和处理查询。由于它们不监视 Kubernetes 对象，因此集群大小或 Service/EndpointSlice 的数量不会直接影响内存使用量。内存使用量受 DNS 查询模式影响。根据CoreDNS 文档：

默认缓存大小为 10000 条目，完全填满时约使用 30 MB 内存。

这将是每个服务器块的内存使用量（如果缓存完全填满）。通过指定较小的缓存大小可以减少内存使用量。

并发查询的数量与内存需求相关，因为用于处理查询的每个额外 goroutine 都需要一定量的内存。你可以在 forward 插件中使用 max_concurrent 选项设置上限。

如果 node-local-dns Pod 尝试使用的内存超过可用内存（由于系统总资源，或者由于配置的资源限制），操作系统可能会终止该 Pod 的容器。如果发生这种情况，被终止的容器（“OOMKilled”）不会清理它之前在启动期间添加的自定义包过滤规则。node-local-dns 容器应该会重启（因为它作为 DaemonSet 的一部分进行管理），但这会导致每次容器失败时都会出现短暂的 DNS 中断：包过滤规则将 DNS 查询导向到不健康的本地 Pod。

你可以通过在没有限制的情况下运行 node-local-dns Pod 并测量峰值使用量来确定合适的内存限制。你也可以在推荐模式下设置并使用 VerticalPodAutoscaler，然后检查其推荐值。