服务和 Pod 的 DNS

您的工作负载可以使用 DNS 在集群中发现服务；此页面解释了其工作原理。

Kubernetes 为服务和 Pod 创建 DNS 记录。您可以使用一致的 DNS 名称而不是 IP 地址联系服务。

Kubernetes 发布有关 Pod 和服务的信息，这些信息用于编程 DNS。Kubelet 配置 Pod 的 DNS，以便运行的容器可以通过名称而不是 IP 查找服务。

集群中定义的服务将被分配 DNS 名称。默认情况下，客户端 Pod 的 DNS 搜索列表包含 Pod 自己的命名空间和集群的默认域。

服务的命名空间

DNS 查询可能会根据发出请求的 Pod 的命名空间返回不同的结果。没有指定命名空间的 DNS 查询仅限于 Pod 的命名空间。通过在 DNS 查询中指定命名空间来访问其他命名空间中的服务。

例如，考虑一个在 test 命名空间中的 Pod。一个 data 服务位于 prod 命名空间中。

对 data 的查询没有返回结果，因为它使用 Pod 的 test 命名空间。

对 data.prod 的查询返回预期的结果，因为它指定了命名空间。

可以使用 Pod 的 /etc/resolv.conf 扩展 DNS 查询。Kubelet 为每个 Pod 配置此文件。例如，对 data 的查询可能会扩展为 data.test.svc.cluster.local。search 选项的值用于扩展查询。要了解有关 DNS 查询的更多信息，请参阅 resolv.conf 手册页。

nameserver 10.32.0.10
search <namespace>.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

总而言之，test 命名空间中的 Pod 可以成功解析 data.prod 或 data.prod.svc.cluster.local。

DNS 记录

哪些对象会获得 DNS 记录？

服务
Pod

以下部分详细介绍了支持的 DNS 记录类型和布局。任何其他布局或名称或查询（如果偶然有效）都被认为是实现细节，可能会在不经通知的情况下发生更改。有关最新规范，请参阅 Kubernetes 基于 DNS 的服务发现。

服务

A/AAAA 记录

"正常"（非无头）服务将被分配 DNS A 和/或 AAAA 记录（具体取决于服务的 IP 族或族），名称格式为 my-svc.my-namespace.svc.cluster-domain.example。这解析为服务的集群 IP。

无头服务（没有集群 IP）服务也会被分配 DNS A 和/或 AAAA 记录，名称格式为 my-svc.my-namespace.svc.cluster-domain.example。与正常服务不同，这解析为服务选择的所有 Pod 的 IP 集。客户端预计会使用该集合，否则使用该集合中的标准轮询选择。

SRV 记录

为作为正常服务或无头服务一部分的命名端口创建 SRV 记录。对于每个命名端口，SRV 记录的格式为 _port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example。对于常规服务，这解析为端口号和域名：my-svc.my-namespace.svc.cluster-domain.example。对于无头服务，这解析为多个答案，每个答案对应于支持服务的每个 Pod，并包含端口号和 Pod 的域名，格式为 hostname.my-svc.my-namespace.svc.cluster-domain.example。

Pod

A/AAAA 记录

Kube-DNS 版本（在实现 DNS 规范之前）具有以下 DNS 解析

pod-ipv4-address.my-namespace.pod.cluster-domain.example.

例如，如果 default 命名空间中的 Pod 的 IP 地址为 172.17.0.3，并且您的集群的域名是 cluster.local，则该 Pod 具有 DNS 名称

172-17-0-3.default.pod.cluster.local.

通过服务公开的任何 Pod 都可以使用以下 DNS 解析

pod-ipv4-address.service-name.my-namespace.svc.cluster-domain.example.

Pod 的主机名和子域名字段

目前，当创建 Pod 时，其主机名（从 Pod 内部观察）是 Pod 的 metadata.name 值。

Pod 规范有一个可选的 hostname 字段，可用于指定不同的主机名。如果指定了，它将优先于 Pod 的名称作为 Pod 的主机名（再次，从 Pod 内部观察）。例如，给定一个 spec.hostname 设置为 "my-host" 的 Pod，该 Pod 的主机名将设置为 "my-host"。

Pod 规范还有一个可选的 subdomain 字段，可用于指示该 Pod 是命名空间子组的一部分。例如，一个 spec.hostname 设置为 "foo"，spec.subdomain 设置为 "bar"，命名空间为 "my-namespace" 的 Pod，其主机名将设置为 "foo"，其完全限定域名 (FQDN) 将设置为 "foo.bar.my-namespace.svc.cluster.local"（再次，从 Pod 内部观察）。

如果在与 Pod 相同的命名空间中存在一个无头服务，并且名称与子域名相同，则集群的 DNS 服务器还会返回 Pod 的完全限定主机名的 A 和/或 AAAA 记录。

示例

apiVersion: v1
kind: Service
metadata:
  name: busybox-subdomain
spec:
  selector:
    name: busybox
  clusterIP: None
  ports:
  - name: foo # name is not required for single-port Services
    port: 1234
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox1
  labels:
    name: busybox
spec:
  hostname: busybox-1
  subdomain: busybox-subdomain
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    name: busybox
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox2
  labels:
    name: busybox
spec:
  hostname: busybox-2
  subdomain: busybox-subdomain
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    name: busybox

给定上面的服务 "busybox-subdomain" 和将 spec.subdomain 设置为 "busybox-subdomain" 的 Pod，第一个 Pod 将看到它自己的 FQDN 为 "busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example"。DNS 在该名称处提供 A 和/或 AAAA 记录，指向 Pod 的 IP。两个 Pod "busybox1" 和 "busybox2" 将拥有自己的地址记录。

一个 EndpointSlice 可以为任何端点地址指定 DNS 主机名及其 IP。

注意

由于不会为 Pod 名称创建 A 和 AAAA 记录，因此需要 hostname 才能创建 Pod 的 A 或 AAAA 记录。没有 hostname 但有 subdomain 的 Pod 仅会为无头服务 (busybox-subdomain.my-namespace.svc.cluster-domain.example) 创建 A 或 AAAA 记录，指向 Pod 的 IP 地址。此外，Pod 需要处于就绪状态才能拥有记录，除非在服务上设置了 publishNotReadyAddresses=True。

Pod 的 setHostnameAsFQDN 字段

功能状态： Kubernetes v1.22 [稳定]

当 Pod 配置为具有完全限定域名 (FQDN) 时，其主机名是短主机名。例如，如果您有一个具有完全限定域名 busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example 的 Pod，那么默认情况下，该 Pod 内部的 hostname 命令将返回 busybox-1，而 hostname --fqdn 命令将返回 FQDN。

当您在 Pod 规范中设置 setHostnameAsFQDN: true 时，kubelet 会将 Pod 的 FQDN 写入该 Pod 命名空间的主机名。在这种情况下，hostname 和 hostname --fqdn 都将返回 Pod 的 FQDN。

注意

在 Linux 中，内核的主机名字段（struct utsname 的 nodename 字段）限制为 64 个字符。

如果 Pod 启用了此功能并且其 FQDN 长度超过 64 个字符，它将无法启动。Pod 将保持在 Pending 状态（如 kubectl 所示为 ContainerCreating），并生成错误事件，例如无法从 Pod 主机名和集群域构建 FQDN，FQDN long-FQDN 太长（最大为 64 个字符，请求 70 个字符）。解决此问题的一种方法是创建一个准入 Webhook 控制器来控制用户创建顶级对象时（例如，部署）的 FQDN 大小。

Pod 的 DNS 策略

可以在每个 Pod 基础上设置 DNS 策略。目前，Kubernetes 支持以下 Pod 特定的 DNS 策略。这些策略在 Pod 规范的 dnsPolicy 字段中指定。

"Default"：Pod 从运行 Pod 的节点继承名称解析配置。有关更多详细信息，请参阅相关讨论。
"ClusterFirst"：任何与配置的集群域后缀不匹配的 DNS 查询（例如，"www.kubernetes.io"）都会由 DNS 服务器转发到上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。有关在这些情况下如何处理 DNS 查询的详细信息，请参阅相关讨论。
"ClusterFirstWithHostNet"：对于使用 hostNetwork 运行的 Pod，您应该明确将其 DNS 策略设置为 "ClusterFirstWithHostNet"。否则，使用 hostNetwork 和 "ClusterFirst" 运行的 Pod 将回退到 "Default" 策略的行为。
- 注意：这在 Windows 上不受支持。有关详细信息，请参阅下文
"None"：它允许 Pod 忽略来自 Kubernetes 环境的 DNS 设置。所有 DNS 设置都应该使用 Pod 规范中的 dnsConfig 字段提供。请参阅以下的 Pod 的 DNS 配置小节。

注意

"Default" 不是默认的 DNS 策略。如果未明确指定 dnsPolicy，则使用 "ClusterFirst"。

以下示例显示了一个 DNS 策略设置为 "ClusterFirstWithHostNet" 的 Pod，因为它将 hostNetwork 设置为 true。

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
    name: busybox
  restartPolicy: Always
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet

Pod 的 DNS 配置

功能状态： Kubernetes v1.14 [稳定]

Pod 的 DNS 配置允许用户更好地控制 Pod 的 DNS 设置。

dnsConfig 字段是可选的，它可以与任何 dnsPolicy 设置一起使用。但是，当 Pod 的 dnsPolicy 设置为 "None" 时，必须指定 dnsConfig 字段。

以下是用户可以在 dnsConfig 字段中指定的属性

nameservers: 一个包含将用作 Pod 的 DNS 服务器的 IP 地址列表。最多可以指定 3 个 IP 地址。当 Pod 的 dnsPolicy 设置为 "None" 时，该列表必须包含至少一个 IP 地址，否则此属性是可选的。列出的服务器将与从指定 DNS 策略生成的基准名称服务器合并，重复的地址将被删除。
searches: 一个包含用于 Pod 中主机名查找的 DNS 搜索域列表。此属性是可选的。如果指定，提供的列表将合并到从所选 DNS 策略生成的基准搜索域名中。重复的域名将被删除。Kubernetes 允许最多 32 个搜索域。
options: 一个可选的对象列表，其中每个对象可能具有一个 name 属性（必需）和一个 value 属性（可选）。此属性中的内容将合并到从指定 DNS 策略生成的选项中。重复的条目将被删除。

以下是具有自定义 DNS 设置的 Pod 示例

service/networking/custom-dns.yaml

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 192.0.2.1 # this is an example
    searches:
      - ns1.svc.cluster-domain.example
      - my.dns.search.suffix
    options:
      - name: ndots
        value: "2"
      - name: edns0

当上面的 Pod 被创建时，容器 test 在其 /etc/resolv.conf 文件中获得以下内容

nameserver 192.0.2.1
search ns1.svc.cluster-domain.example my.dns.search.suffix
options ndots:2 edns0

对于 IPv6 设置，搜索路径和名称服务器应按如下方式设置

kubectl exec -it dns-example -- cat /etc/resolv.conf

输出类似于此

nameserver 2001:db8:30::a
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
options ndots:5

DNS 搜索域名列表限制

功能状态: Kubernetes 1.28 [稳定]

Kubernetes 本身不会限制 DNS 配置，直到搜索域名列表的长度超过 32 或所有搜索域的总长度超过 2048。此限制分别适用于节点的解析器配置文件、Pod 的 DNS 配置和合并的 DNS 配置。

注意

早期版本的某些容器运行时可能对其 DNS 搜索域的数量有自己的限制。根据容器运行时环境，具有大量 DNS 搜索域的 Pod 可能会卡在 pending 状态。

众所周知，containerd v1.5.5 或更早版本和 CRI-O v1.21 或更早版本存在此问题。

Windows 节点上的 DNS 解析

ClusterFirstWithHostNet 不支持在 Windows 节点上运行的 Pod。Windows 将所有带有 . 的名称视为 FQDN 并跳过 FQDN 解析。
在 Windows 上，可以使用多种 DNS 解析器。由于这些解析器具有略微不同的行为，因此建议使用 Resolve-DNSName powershell cmdlet 进行名称查询解析。
在 Linux 上，您有一个 DNS 后缀列表，该列表在以完全限定的方式解析名称失败后使用。在 Windows 上，您只能有一个 DNS 后缀，即与该 Pod 的命名空间关联的 DNS 后缀（例如：mydns.svc.cluster.local）。Windows 可以解析 FQDN、服务或可以使用此单个后缀解析的网络名称。例如，在 default 命名空间中生成的 Pod 将具有 DNS 后缀 default.svc.cluster.local。在 Windows Pod 中，您可以解析 kubernetes.default.svc.cluster.local 和 kubernetes，但不能解析部分限定的名称（kubernetes.default 或 kubernetes.default.svc）。

下一步

有关管理 DNS 配置的指南，请查看配置 DNS 服务

最后修改时间：2024 年 1 月 29 日上午 12:52 PST：更新了准入 Webhook 控制器链接 (a3b714cbfc)

服务和 Pod 的 DNS

服务的命名空间

DNS 记录

服务

A/AAAA 记录

SRV 记录

Pod

A/AAAA 记录

Pod 的主机名和子域名字段

注意

Pod 的 setHostnameAsFQDN 字段

注意

Pod 的 DNS 策略

注意

Pod 的 DNS 配置

DNS 搜索域名列表限制

注意

Windows 节点上的 DNS 解析

下一步

反馈