在 Kubernetes 集群中使用 NodeLocal DNSCache

本页面概述了 Kubernetes 中的 NodeLocal DNSCache 功能。

开始之前

您需要拥有一个 Kubernetes 集群，并且 kubectl 命令行工具必须配置为与您的集群通信。建议在至少有两个节点（不充当控制平面主机）的集群上运行本教程。如果您还没有集群，可以使用 minikube 创建一个，或者可以使用以下 Kubernetes 游乐场之一

• Killercoda
• 与 Kubernetes 玩耍

介绍

NodeLocal DNSCache 通过在集群节点上作为 DaemonSet 运行 DNS 缓存代理来提高集群 DNS 性能。在当今的架构中，处于“ClusterFirst”DNS 模式下的 Pod 会联系 kube-dns serviceIP 以进行 DNS 查询。这会通过 kube-proxy 添加的 iptables 规则转换为 kube-dns/CoreDNS 端点。使用这种新架构，Pod 将联系运行在同一节点上的 DNS 缓存代理，从而避免 iptables DNAT 规则和连接跟踪。本地缓存代理将查询 kube-dns 服务以查找集群主机名（默认情况下为“cluster.local”后缀）的缓存未命中。

动机

• 使用当前的 DNS 架构，如果不存在本地 kube-dns/CoreDNS 实例，具有最高 DNS QPS 的 Pod 可能需要联系不同的节点。拥有本地缓存将有助于提高此类情况下的延迟。

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

• 从本地缓存代理到 kube-dns 服务的连接可以升级到 TCP。与必须超时的 UDP 条目（默认 nf_conntrack_udp_timeout 为 30 秒）相比，TCP conntrack 条目将在连接关闭时被删除。

• 将 DNS 查询从 UDP 升级到 TCP 将减少由于 UDP 数据包丢失和 DNS 超时（通常最多 30 秒（3 次重试 + 10 秒超时））造成的尾部延迟。由于 nodelocal 缓存侦听 UDP DNS 查询，因此应用程序不需要更改。

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

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

架构图

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

配置

可以使用以下步骤启用此功能

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

• 如果使用 IPv6，则 CoreDNS 配置文件需要将所有 IPv6 地址括在方括号中（如果在“IP:Port”格式中使用）。如果您使用的是上一点中的示例清单，则需要修改 配置行 L70，如下所示：“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 指标都将在每个节点的基础上可用。

您可以通过删除 DaemonSet 来禁用此功能，使用 kubectl delete -f <manifest>。您还应该恢复对 kubelet 配置所做的任何更改。

StubDomains 和上游服务器配置

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

设置内存限制

node-local-dns Pod 使用内存来存储缓存条目和处理查询。由于它们不监视 Kubernetes 对象，因此集群大小或服务/EndpointSlices 的数量不会直接影响内存使用情况。内存使用情况受 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（处于推荐模式），然后检查其推荐内容。