树叶云kubernetes教程:Kubernetes 在Kubernetes集群中使用NodeLocal DNSCache

在 Kubernetes 集群中使用 NodeLocal DNSCache

FEATURE STATE: Kubernetes v1.18 [stable]

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

在开始之前

你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程,且这些节点不作为控制平面主机。 如果你还没有集群,你可以通过 Minikube 构建一个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:

  • Katacoda
  • 玩转 Kubernetes

要检查版本,请输入 ​kubectl version​。

引言

NodeLocal DNSCache 通过在集群节点上作为 DaemonSet 运行 DNS 缓存代理来提高集群 DNS 性能。 在当今的体系结构中,运行在 ‘ClusterFirst’ DNS 模式下的 Pod 可以连接到 kube-dns ​serviceIP​ 进行 DNS 查询。 通过 kube-proxy 添加的 iptables 规则将其转换为 kube-dns/CoreDNS 端点。 借助这种新架构,Pods 将可以访问在同一节点上运行的 DNS 缓存代理,从而避免 iptables DNAT 规则和连接跟踪。 本地缓存代理将查询 kube-dns 服务以获取集群主机名的缓存缺失(默认为 “​cluster.local​” 后缀)。

动机

  • 使用当前的 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 包和 DNS 超时而带来的尾部等待时间; 这类延时通常长达 30 秒(3 次重试 + 10 秒超时)。 由于 nodelocal 缓存监听 UDP DNS 查询,应用不需要变更。
  • 在节点级别对 DNS 请求的度量和可见性。
  • 可以重新启用负缓存,从而减少对 kube-dns 服务的查询数量。

架构图

启用 NodeLocal DNSCache 之后,DNS 查询所遵循的路径如下:

配置

Note: NodeLocal DNSCache 的本地侦听 IP 地址可以是任何地址,只要该地址不和你的集群里现有的 IP 地址发生冲突。 推荐使用本地范围内的地址,例如,IPv4 链路本地区段 ‘169.254.0.0/16’ 内的地址, 或者 IPv6 唯一本地地址区段 ‘fd00::/8’ 内的地址。

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

  • 根据示例 nodelocaldns.yaml 准备一个清单,把它保存为 ​nodelocaldns.yaml​。
  • 如果使用 IPv6,在使用 ‘IP:Port’ 格式的时候需要把 CoreDNS 配置文件里的所有 IPv6 地址用方括号包起来。 如果你使用上述的示例清单,需要把 配置行 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
    

    node-local-dns Pods 会设置 ​__PILLAR__CLUSTER__DNS__​ 和 ​__PILLAR__UPSTREAM__SERVERS__​。 在此模式下, node-local-dns Pods 会同时侦听 kube-dns 服务的 IP 地址和 ​<node-local-address>​ 的地址,以便 Pods 可以使用其中任何一个 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 Pods 只会侦听 ​<node-local-address>​ 的地址。 node-local-dns 接口不能绑定 kube-dns 的集群 IP 地址,因为 IPVS 负载均衡 使用的接口已经占用了该地址。 node-local-dns Pods 会设置 ​__PILLAR__UPSTREAM__SERVERS__​。

  • 运行 ​kubectl create -f nodelocaldns.yaml
  • 如果 kube-proxy 运行在 IPVS 模式,需要修改 kubelet 的 ​--cluster-dns​ 参数 NodeLocal DNSCache 正在侦听的 ​<node-local-address>​ 地址。 否则,不需要修改 ​--cluster-dns​ 参数,因为 NodeLocal DNSCache 会同时侦听 kube-dns 服务的 IP 地址和 ​<node-local-address>​ 的地址。

启用后,​node-local-dns​ Pods 将在每个集群节点上的 ​kube-system​ 名字空间中运行。 此 Pod 在缓存模式下运行 CoreDNS, 因此每个节点都可以使用不同插件公开的所有 CoreDNS 指标。

如果要禁用该功能,你可以使用 ​kubectl delete -f <manifest>​ 来删除 DaemonSet。 你还应该回滚你对 kubelet 配置所做的所有改动。

StubDomains 和上游服务器配置

node-local-dns​ Pod 能够自动读取 ​kube-system​ 名字空间中 ​kube-dns​ ConfigMap 中保存的 StubDomains 和上游服务器信息。ConfigMap 中的内容需要遵从 此示例 中所给的格式。 ​node-local-dns​ ConfigMap 也可被直接修改,使用 Corefile 格式设置 stubDomain 配置。 某些云厂商可能不允许直接修改 ​node-local-dns​ ConfigMap 的内容。 在这种情况下,可以更新 ​kube-dns​ ConfigMap。

设置内存限制

node-local-dns Pod 使用内存来保存缓存项并处理查询。 由于它们并不监视 Kubernetes 对象变化,集群规模或者 Service/Endpoints 的数量都不会直接影响内存用量。内存用量会受到 DNS 查询模式的影响。 根据 CoreDNS 文档。

The default cache size is 10000 entries, which uses about 30 MB when completely filled. (默认的缓存大小是 10000 个表项,当完全填充时会使用约 30 MB 内存)

这一数值是(缓存完全被填充时)每个服务器块的内存用量。 通过设置小一点的缓存大小可以降低内存用量。

并发查询的数量会影响内存需求,因为用来处理查询请求而创建的 Go 协程都需要一定量的内存。 你可以在 forward 插件中使用 ​max_concurrent ​选项设置并发查询数量上限。

如果一个 ​node-local-dns​ Pod 尝试使用的内存超出可提供的内存量 (因为系统资源总量的,或者所配置的资源约束)的原因, 操作系统可能会关闭这一 Pod 的容器。 发生这种情况时,被终止的(”OOMKilled”)容器不会清理其启动期间所添加的定制包过滤规则。 该 ​node-local-dns​ 容器应该会被重启(因其作为 DaemonSet 的一部分被管理), 但因上述原因可能每次容器失败时都会导致 DNS 有一小段时间不可用: the packet filtering rules direct DNS queries to a local Pod that is unhealthy (包过滤器规则将 DNS 查询转发到本地某个不健康的 Pod)。

通过不带限制地运行 ​node-local-dns​ Pod 并度量其内存用量峰值,你可以为其确定一个合适的内存限制值。 你也可以安装并使用一个运行在 “Recommender Mode(建议者模式)” 的 VerticalPodAutoscaler, 并查看该组件输出的建议信息。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/163423.html<

(0)
管理的头像管理
上一篇2025-03-19 03:43
下一篇 2025-03-19 03:45

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注