Skip to main content

Command Palette

Search for a command to run...

在 Kubernetes(1.6)中配置私有 DNS 区域以及上级域名服务

Updated
1 min read

原文:Configuring Private DNS Zones and Upstream Nameservers in Kubernetes

很多用户都有自己的域名区域,并且希望能够集成到 Kubernetes DNS 的命名空间去。例如混合云用户可能希望能在集群内解析他们内部的 “.corp” 。其他用户用户可能有一个受非 Kubernetes管理的服务发现系统(例如 Consul)。我们在 Kubernetes 1.6 中推出了新功能,kube-dns 添加了可配置的私有 DNS 区域(通常称为存根域)以及外部的上级域名服务,本文将会讲解如何使用这一功能。

Kubernetes 目前在 Pod 定义中支持两个 DNS 策略:DefaultClusterFirstdnsPolicy缺省为ClusterFirst

  • 如果dnsPolicy设置为Default,那么域名解析配置会从 Pod 所在节点继承而来。注意,本文所述功能在dnsPolicy设置为Default时无效。
  • 如果dnsPolicy设置为ClusterFirst,DNS 查询会被发送到 kube-dns 服务。kube-dns 服务负责相应以集群域名为后缀(例如.cluster.local)的查询。其他的域名查询(例如 www.kubernetes.io )会被转发给来自节点定义的上级域名服务器。

在这一功能推出之前,通常需要利用替换上级 DNS 为自定义解析的方式来完成存根域查询。然而这就使得这个自定义域名解析器成为 DNS 解析过程中的一个高风险因素。本功能让用户能够无需对整个 DNS 路径进行改造就完成自定义解析过程。

自定义 DNS 流程

从 Kubernetes 1.6 开始,集群管理员能够利用 ConfigMap 指定自定义的存根域以及上级 NameServer。下文的配置包含一个存根域和两个上级域名服务器。对域名后缀为.aceme.local的查询会被发送到地址为 1.2.3.4 的 DNS 服务。另外会把 Google 公共 DNS 作为上级服务器。注意本节末尾对 ConfigMap 中的数据格式进行的解释。


apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"acme.local": ["1.2.3.4"]}
  upstreamNameservers: |
    ["8.8.8.8", "8.8.4.4"]

下图显示了配置中所指示的 DNS 查询过程。当dnsPolicy设置为ClusterFirst时,DNS 查询首先被发送到 kube-dns 的 DNS 缓存层。从这里开始检查域名后缀,然后发送到指定的 DNS。在本例中,集群后缀的域名(.cluster.local),被发送到 kube-dns,最后不符合上面后缀的其他查询被转发到上级 DNS 去进行解析。

下文表格用来说明域名解析的过程:

域名解析服务
kubernetes.default.svc.cluster.localkube-dns
foo.acme.local自定义 DNS(1.2.3.4)
widget.com上级 DNS(8.8.8.8 和 8.8.4.4)中的一个

ConfigMap 配置说明

  • stubDomains (可选)
    • 格式:一个 JSON 编码的 Map 格式,其 Key 为 DNS 后缀(也就是acme.local),值是一个 JSON 数组,代表一组 DNS IP。
    • 注意:目标域名服务器也可以是 Kuernetes 服务。例如可以用 dnsmasq 把自定义 DNS 导出到 ClusterDNS 的命名空间中。
  • upstreamNameservers
    • 格式:一个 DNS IP 组成的 JSON 数组。
    • 注意:如果指定了这个值,那么从节点的 /etc/resolv.conf 继承过来的值就会被覆盖。
    • 限制:最多可以指定三个。

例 1:添加一个 Consul DNS 存根域

这个例子中,用户希望把 Consul DNS 服务集成到 kube-dns。Consul 服务位于10.150.0.1,所有的 consul 命名后缀都是.consul.local。Kubernetes 管理员简单的创建一个ConfigMap对象就可以完成。注意:本例中管理员不想覆盖节点的上级 DNS 定义,所以不需要指定upstreamNameservers

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"consul.local": "10.150.0.1"}

例 2:替换上级 Nameserver

这个例子中,集群管理员希望所有的集群外 DNS 查询由172.16.0.1的服务来完成,同样的用一个 ConfigMap 完成:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  upstreamNameservers: |
    ["172.16.0.1"]

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts