website/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md

636 lines
27 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

---
title: Service 与 Pod 的 DNS
content_type: concept
weight: 80
description: >-
你的工作负载可以使用 DNS 发现集群内的 Service本页说明具体工作原理。
---
<!--
reviewers:
- jbelamaric
- bowei
- thockin
title: DNS for Services and Pods
content_type: concept
weight: 80
description: >-
Your workload can discover Services within your cluster using DNS;
this page explains how that works.
-->
<!-- overview -->
<!--
Kubernetes creates DNS records for Services and Pods. You can contact
Services with consistent DNS names instead of IP addresses.
-->
Kubernetes 为 Service 和 Pod 创建 DNS 记录。
你可以使用一致的 DNS 名称而非 IP 地址访问 Service。
<!-- body -->
<!--
Kubernetes publishes information about Pods and Services which is used
to program DNS. Kubelet configures Pods' DNS so that running containers
can lookup Services by name rather than IP.
-->
Kubernetes 发布有关 Pod 和 Service 的信息,这些信息被用来对 DNS 进行编程。
Kubelet 配置 Pod 的 DNS以便运行中的容器可以通过名称而不是 IP 来查找服务。
<!--
Services defined in the cluster are assigned DNS names. By default, a
client Pod's DNS search list includes the Pod's own namespace and the
cluster's default domain.
-->
集群中定义的 Service 被赋予 DNS 名称。
默认情况下,客户端 Pod 的 DNS 搜索列表会包含 Pod 自身的名字空间和集群的默认域。
<!--
### Namespaces of Services
A DNS query may return different results based on the namespace of the Pod making
it. DNS queries that don't specify a namespace are limited to the Pod's
namespace. Access Services in other namespaces by specifying it in the DNS query.
For example, consider a Pod in a `test` namespace. A `data` Service is in
the `prod` namespace.
A query for `data` returns no results, because it uses the Pod's `test` namespace.
A query for `data.prod` returns the intended result, because it specifies the
namespace.
-->
### Service 的名字空间 {#namespaces-of-services}
DNS 查询可能因为执行查询的 Pod 所在的名字空间而返回不同的结果。
不指定名字空间的 DNS 查询会被限制在 Pod 所在的名字空间内。
要访问其他名字空间中的 Service需要在 DNS 查询中指定名字空间。
例如,假定名字空间 `test` 中存在一个 Pod`prod` 名字空间中存在一个服务
`data`
Pod 查询 `data` 时没有返回结果,因为使用的是 Pod 的名字空间 `test`
Pod 查询 `data.prod` 时则会返回预期的结果,因为查询中指定了名字空间。
<!--
DNS queries may be expanded using the Pod's `/etc/resolv.conf`. Kubelet
configures this file for each Pod. For example, a query for just `data` may be
expanded to `data.test.svc.cluster.local`. The values of the `search` option
are used to expand queries. To learn more about DNS queries, see
[the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)
-->
DNS 查询可以使用 Pod 中的 `/etc/resolv.conf` 展开。
Kubelet 为每个 Pod 配置此文件。
例如,对 `data` 的查询可能被展开为 `data.test.svc.cluster.local`
`search` 选项的取值会被用来展开查询。要进一步了解 DNS 查询,可参阅
[`resolv.conf` 手册页面](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)。
```
nameserver 10.32.0.10
search <namespace>.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
```
<!--
In summary, a Pod in the _test_ namespace can successfully resolve either
`data.prod` or `data.prod.svc.cluster.local`.
-->
概括起来,名字空间 _test_ 中的 Pod 可以成功地解析 `data.prod` 或者
`data.prod.svc.cluster.local`
<!--
### DNS Records
What objects get DNS records?
-->
### DNS 记录 {#dns-records}
哪些对象会获得 DNS 记录呢?
1. Services
2. Pods
<!--
The following sections detail the supported DNS record types and layout that is
supported. Any other layout or names or queries that happen to work are
considered implementation details and are subject to change without warning.
For more up-to-date specification, see
[Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
-->
以下各节详细介绍已支持的 DNS 记录类型和布局。
其它布局、名称或者查询即使碰巧可以工作,也应视为实现细节,
将来很可能被更改而且不会因此发出警告。
有关最新规范请查看
[Kubernetes 基于 DNS 的服务发现](https://github.com/kubernetes/dns/blob/master/docs/specification.md)。
<!--
## Services
### A/AAAA records
"Normal" (not headless) Services are assigned DNS A and/or AAAA records,
depending on the IP family or families of the Service, with a name of the form
`my-svc.my-namespace.svc.cluster-domain.example`. This resolves to the cluster IP
of the Service.
[Headless Services](/docs/concepts/services-networking/service/#headless-services)
(without a cluster IP) Services are also assigned DNS A and/or AAAA records,
with a name of the form `my-svc.my-namespace.svc.cluster-domain.example`. Unlike normal
Services, this resolves to the set of IPs of all of the Pods selected by the Service.
Clients are expected to consume the set or else use standard round-robin
selection from the set.
-->
### Service
#### A/AAAA 记录 {#a-aaaa-records}
除了无头 Service 之外的 “普通” Service 会被赋予一个形如 `my-svc.my-namespace.svc.cluster-domain.example`
的 DNS A 和/或 AAAA 记录,取决于 Service 的 IP 协议族(可能有多个)设置。
该名称会解析成对应 Service 的集群 IP。
没有集群 IP 的[无头 Service](/zh-cn/docs/concepts/services-networking/service/#headless-services)
也会被赋予一个形如 `my-svc.my-namespace.svc.cluster-domain.example` 的 DNS A 和/或 AAAA 记录。
与普通 Service 不同,这一记录会被解析成对应 Service 所选择的 Pod IP 的集合。
客户端要能够使用这组 IP或者使用标准的轮转策略从这组 IP 中进行选择。
<!--
### SRV records
SRV Records are created for named ports that are part of normal or headless
services. For each named port, the SRV record has the form
`_port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
For a regular Service, this resolves to the port number and the domain name:
`my-svc.my-namespace.svc.cluster-domain.example`.
For a headless Service, this resolves to multiple answers, one for each Pod
that is backing the Service, and contains the port number and the domain name of the Pod
of the form `hostname.my-svc.my-namespace.svc.cluster-domain.example`.
-->
#### SRV 记录 {#srv-records}
Kubernetes 根据普通 Service 或无头 Service
中的命名端口创建 SRV 记录。每个命名端口,
SRV 记录格式为 `_port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example`
普通 Service该记录会被解析成端口号和域名`my-svc.my-namespace.svc.cluster-domain.example`。
无头 Service该记录会被解析成多个结果及该服务的每个后端 Pod 各一个 SRV 记录,
其中包含 Pod 端口号和格式为 `hostname.my-svc.my-namespace.svc.cluster-domain.example`
的域名。
<!--
## Pods-->
## Pod
<!--
### A/AAAA records
In general a Pod has the following DNS resolution:
`pod-ip-address.my-namespace.pod.cluster-domain.example`.
For example, if a Pod in the `default` namespace has the IP address 172.17.0.3,
and the domain name for your cluster is `cluster.local`, then the Pod has a DNS name:
`172-17-0-3.default.pod.cluster.local`.
Any Pods exposed by a Service have the following DNS resolution available:
`pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`.
-->
### A/AAAA 记录 {#a-aaaa-records}
一般而言Pod 会对应如下 DNS 名字解析:
`pod-ip-address.my-namespace.pod.cluster-domain.example`
例如,对于一个位于 `default` 名字空间IP 地址为 172.17.0.3 的 Pod
如果集群的域名为 `cluster.local`,则 Pod 会对应 DNS 名称:
`172-17-0-3.default.pod.cluster.local`
通过 Service 暴露出来的所有 Pod 都会有如下 DNS 解析名称可用:
`pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`
<!--
### Pod's hostname and subdomain fields
Currently when a Pod is created, its hostname (as observed from within the Pod)
is the Pod's `metadata.name` value.
-->
### Pod 的 hostname 和 subdomain 字段 {#pod-s-hostname-and-subdomain-fields}
当前,创建 Pod 时其主机名(从 Pod 内部观察)取自 Pod 的 `metadata.name` 值。
<!--
The Pod spec has an optional `hostname` field, which can be used to specify a
different hostname. When specified, it takes precedence over the Pod's name to be
the hostname of the Pod (again, as observed from within the Pod). For example,
given a Pod with `spec.hostname` set to `"my-host"`, the Pod will have its
hostname set to `"my-host"`.
-->
Pod 规约中包含一个可选的 `hostname` 字段,可以用来指定一个不同的主机名。
当这个字段被设置时,它将优先于 Pod 的名字成为该 Pod 的主机名(同样是从 Pod 内部观察)。
举个例子,给定一个 `spec.hostname` 设置为 `“my-host”` 的 Pod
该 Pod 的主机名将被设置为 `“my-host”`
<!--
The Pod spec also has an optional `subdomain` field which can be used to indicate
that the pod is part of sub-group of the namespace. For example, a Pod with `spec.hostname`
set to `"foo"`, and `spec.subdomain` set to `"bar"`, in namespace `"my-namespace"`, will
have its hostname set to `"foo"` and its fully qualified domain name (FQDN) set to
`"foo.bar.my-namespace.svc.cluster.local"` (once more, as observed from within
the Pod).
-->
Pod 规约还有一个可选的 `subdomain` 字段,可以用来表明该 Pod 是名字空间的子组的一部分。
举个例子,某 Pod 的 `spec.hostname` 设置为 `“foo”``spec.subdomain` 设置为 `“bar”`
在名字空间 `“my-namespace”` 中,主机名称被设置成 `“foo”` 并且对应的完全限定域名FQDN
“`foo.bar.my-namespace.svc.cluster-domain.example`”(还是从 Pod 内部观察)。
<!--
If there exists a headless Service in the same namespace as the Pod, with
the same name as the subdomain, the cluster's DNS Server also returns A and/or AAAA
records for the Pod's fully qualified hostname.
Example:
-->
如果 Pod 所在的名字空间中存在一个无头服务,其名称与子域相同,
则集群的 DNS 服务器还会为 Pod 的完全限定主机名返回 A 和/或 AAAA 记录。
示例:
```yaml
apiVersion: v1
kind: Service
metadata:
name: busybox-subdomain
spec:
selector:
name: busybox
clusterIP: None
ports:
- name: foo # 实际上不需要指定端口号
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
```
<!--
Given the above Service `"busybox-subdomain"` and the Pods which set `spec.subdomain`
to `"busybox-subdomain"`, the first Pod will see its own FQDN as
`"busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example"`. DNS serves
A and/or AAAA records at that name, pointing to the Pod's IP. Both Pods "`busybox1`" and
"`busybox2`" will have their own address records.
-->
鉴于上述服务 `“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`” 都将有自己的地址记录。
<!--
An {{<glossary_tooltip term_id="endpoint-slice" text="EndpointSlice">}} can specify
the DNS hostname for any endpoint addresses, along with its IP.
-->
{{<glossary_tooltip term_id="endpoint-slice" text="EndpointSlice">}}
对象可以为任何端点地址及其 IP 指定 `hostname`
<!--
Because A and AAAA records are not created for Pod names, `hostname` is required for the Pod's A or AAAA
record to be created. A Pod with no `hostname` but with `subdomain` will only create the
A or AAAA record for the headless Service (`busybox-subdomain.my-namespace.svc.cluster-domain.example`),
pointing to the Pods' IP addresses. Also, the Pod needs to be ready in order to have a
record unless `publishNotReadyAddresses=True` is set on the Service.
-->
{{< note >}}
由于 A 和 AAAA 记录不是基于 Pod 名称创建,因此需要设置了 `hostname` 才会生成 Pod 的 A 或 AAAA 记录。
没有设置 `hostname` 但设置了 `subdomain` 的 Pod 只会为
无头 Service 创建 A 或 AAAA 记录(`busybox-subdomain.my-namespace.svc.cluster-domain.example`
指向 Pod 的 IP 地址。
另外,除非在服务上设置了 `publishNotReadyAddresses=True`,否则只有 Pod 准备就绪
才会有与之对应的记录。
{{< /note >}}
<!--
### Pod's setHostnameAsFQDN field {#pod-sethostnameasfqdn-field}
-->
### Pod 的 setHostnameAsFQDN 字段 {#pod-sethostnameasfqdn-field}
{{< feature-state for_k8s_version="v1.22" state="stable" >}}
<!--
When a Pod is configured to have fully qualified domain name (FQDN), its
hostname is the short hostname. For example, if you have a Pod with the fully
qualified domain name `busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example`,
then by default the `hostname` command inside that Pod returns `busybox-1` and the
`hostname --fqdn` command returns the FQDN.
When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the Pod's FQDN into the hostname for that Pod's namespace. In this case, both `hostname` and `hostname --fqdn` return the Pod's FQDN.
-->
当 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 的主机名记录到 Pod 所在名字空间。
在这种情况下,`hostname` 和 `hostname --fqdn` 都会返回 Pod 的全限定域名。
{{< note >}}
<!--
In Linux, the hostname field of the kernel (the `nodename` field of `struct utsname`) is limited to 64 characters.
If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from Pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
-->
在 Linux 中,内核的主机名字段(`struct utsname` 的 `nodename` 字段)限定最多 64 个字符。
如果 Pod 启用这一特性,而其 FQDN 超出 64 字符Pod 的启动会失败。
Pod 会一直出于 `Pending` 状态(通过 `kubectl` 所看到的 `ContainerCreating`
并产生错误事件,例如
"Failed to construct FQDN from Pod hostname and cluster domain, FQDN
`long-FQDN` is too long (64 characters is the max, 70 characters requested)."
(无法基于 Pod 主机名和集群域名构造 FQDNFQDN `long-FQDN` 过长,至多 64 个字符,请求字符数为 70
对于这种场景而言,改善用户体验的一种方式是创建一个
[准入 Webhook 控制器](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
在用户创建顶层对象(如 Deployment的时候控制 FQDN 的长度。
{{< /note >}}
<!--
### Pod's DNS Policy
DNS policies can be set on a per-Pod basis. Currently Kubernetes supports the
following Pod-specific DNS policies. These policies are specified in the
`dnsPolicy` field of a Pod Spec.
- "`Default`": The Pod inherits the name resolution configuration from the node
that the Pods run on.
See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers)
for more details.
- "`ClusterFirst`": Any DNS query that does not match the configured cluster
domain suffix, such as "`www.kubernetes.io`", is forwarded to an upstream
nameserver by the DNS server. Cluster administrators may have extra
stub-domain and upstream DNS servers configured.
See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers)
for details on how DNS queries are handled in those cases.
- "`ClusterFirstWithHostNet`": For Pods running with hostNetwork, you should
explicitly set its DNS policy to "`ClusterFirstWithHostNet`". Otherwise, Pods
running with hostNetwork and `"ClusterFirst"` will fallback to the behavior
of the `"Default"` policy.
- Note: This is not supported on Windows. See [below](#dns-windows) for details
- "`None`": It allows a Pod to ignore DNS settings from the Kubernetes
environment. All DNS settings are supposed to be provided using the
`dnsConfig` field in the Pod Spec.
See [Pod's DNS config](#pod-dns-config) subsection below.
-->
### Pod 的 DNS 策略 {#pod-s-dns-policy}
DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod 的 DNS 策略。
这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置:
- "`Default`": Pod 从运行所在的节点继承名称解析配置。
参考[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers)获取更多信息。
- "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询(例如 "www.kubernetes.io"
都会由 DNS 服务器转发到上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。
参阅[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers)
了解在这些场景中如何处理 DNS 查询的信息。
- "`ClusterFirstWithHostNet`": 对于以 hostNetwork 方式运行的 Pod应将其 DNS 策略显式设置为
"`ClusterFirstWithHostNet`"。否则,以 hostNetwork 方式和 `"ClusterFirst"` 策略运行的
Pod 将会做出回退至 `"Default"` 策略的行为。
- 注意:这在 Windows 上不支持。 有关详细信息,请参见[下文](#dns-windows)。
- "`None`": 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置。Pod 会使用其 `dnsConfig`
字段所提供的 DNS 设置。
参见 [Pod 的 DNS 配置](#pod-dns-config)节。
{{< note >}}
<!--
"Default" is not the default DNS policy. If `dnsPolicy` is not
explicitly specified, then "ClusterFirst" is used.
-->
"Default" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`,则使用 "ClusterFirst"。
{{< /note >}}
<!--
The example below shows a Pod with its DNS policy set to
"`ClusterFirstWithHostNet`" because it has `hostNetwork` set to `true`.
-->
下面的示例显示了一个 Pod其 DNS 策略设置为 "`ClusterFirstWithHostNet`"
因为它已将 `hostNetwork` 设置为 `true`
```yaml
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's DNS Config {#pod-dns-config}
-->
### Pod 的 DNS 配置 {#pod-dns-config}
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
<!--
Pod's DNS Config allows users more control on the DNS settings for a Pod.
The `dnsConfig` field is optional and it can work with any `dnsPolicy` settings.
However, when a Pod's `dnsPolicy` is set to "`None`", the `dnsConfig` field has
to be specified.
Below are the properties a user can specify in the `dnsConfig` field:
-->
Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。
`dnsConfig` 字段是可选的,它可以与任何 `dnsPolicy` 设置一起使用。
但是,当 Pod 的 `dnsPolicy` 设置为 "`None`" 时,必须指定 `dnsConfig` 字段。
用户可以在 `dnsConfig` 字段中指定以下属性:
<!--
- `nameservers`: a list of IP addresses that will be used as DNS servers for the
Pod. There can be at most 3 IP addresses specified. When the Pod's `dnsPolicy`
is set to "`None`", the list must contain at least one IP address, otherwise
this property is optional.
The servers listed will be combined to the base nameservers generated from the
specified DNS policy with duplicate addresses removed.
- `searches`: a list of DNS search domains for hostname lookup in the Pod.
This property is optional. When specified, the provided list will be merged
into the base search domain names generated from the chosen DNS policy.
Duplicate domain names are removed.
Kubernetes allows up to 32 search domains.
- `options`: an optional list of objects where each object may have a `name`
property (required) and a `value` property (optional). The contents in this
property will be merged to the options generated from the specified DNS policy.
Duplicate entries are removed.
-->
- `nameservers`:将用作于 Pod 的 DNS 服务器的 IP 地址列表。
最多可以指定 3 个 IP 地址。当 Pod 的 `dnsPolicy` 设置为 "`None`" 时,
列表必须至少包含一个 IP 地址,否则此属性是可选的。
所列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器,并删除重复的地址。
- `searches`:用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。
指定此属性时,所提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。
重复的域名将被删除。Kubernetes 最多允许 32 个搜索域。
- `options`:可选的对象列表,其中每个对象可能具有 `name` 属性(必需)和 `value` 属性(可选)。
此属性中的内容将合并到从指定的 DNS 策略生成的选项。
重复的条目将被删除。
<!--
The following is an example Pod with custom DNS settings:
-->
以下是具有自定义 DNS 设置的 Pod 示例:
{{% code_sample file="service/networking/custom-dns.yaml" %}}
<!--
When the Pod above is created, the container `test` gets the following contents
in its `/etc/resolv.conf` file:
-->
创建上面的 Pod 后,容器 `test` 会在其 `/etc/resolv.conf` 文件中获取以下内容:
```
nameserver 192.0.2.1
search ns1.svc.cluster-domain.example my.dns.search.suffix
options ndots:2 edns0
```
<!--
For IPv6 setup, search path and name server should be set up like this:
-->
对于 IPv6 设置,搜索路径和名称服务器应按以下方式设置:
```shell
kubectl exec -it dns-example -- cat /etc/resolv.conf
```
<!--
The output is similar to this:
-->
输出类似于:
```
nameserver 2001:db8:30::a
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
options ndots:5
```
<!--
## DNS search domain list limits
-->
## DNS 搜索域列表限制 {#dns-search-domain-list-limits}
{{< feature-state for_k8s_version="1.28" state="stable" >}}
<!--
Kubernetes itself does not limit the DNS Config until the length of the search
domain list exceeds 32 or the total length of all search domains exceeds 2048.
This limit applies to the node's resolver configuration file, the Pod's DNS
Config, and the merged DNS Config respectively.
-->
Kubernetes 本身不限制 DNS 配置,最多可支持 32 个搜索域列表,所有搜索域的总长度不超过 2048。
此限制分别适用于节点的解析器配置文件、Pod 的 DNS 配置和合并的 DNS 配置。
{{< note >}}
<!--
Some container runtimes of earlier versions may have their own restrictions on
the number of DNS search domains. Depending on the container runtime
environment, the pods with a large number of DNS search domains may get stuck in
the pending state.
It is known that containerd v1.5.5 or earlier and CRI-O v1.21 or earlier have
this problem.
-->
早期版本的某些容器运行时可能对 DNS 搜索域的数量有自己的限制。
根据容器运行环境,那些具有大量 DNS 搜索域的 Pod 可能会卡在 Pending 状态。
众所周知 containerd v1.5.5 或更早版本和 CRI-O v1.21 或更早版本都有这个问题。
{{< /note >}}
<!--
## DNS resolution on Windows nodes {#dns-windows}
- ClusterFirstWithHostNet is not supported for Pods that run on Windows nodes.
Windows treats all names with a `.` as a FQDN and skips FQDN resolution.
- On Windows, there are multiple DNS resolvers that can be used. As these come with
slightly different behaviors, using the
[`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
powershell cmdlet for name query resolutions is recommended.
- On Linux, you have a DNS suffix list, which is used after resolution of a name as fully
qualified has failed.
On Windows, you can only have 1 DNS suffix, which is the DNS suffix associated with that
Pod's namespace (example: `mydns.svc.cluster.local`). Windows can resolve FQDNs, Services,
or network name which can be resolved with this single suffix. For example, a Pod spawned
in the `default` namespace, will have the DNS suffix `default.svc.cluster.local`.
Inside a Windows Pod, you can resolve both `kubernetes.default.svc.cluster.local`
and `kubernetes`, but not the partially qualified names (`kubernetes.default` or
`kubernetes.default.svc`).
-->
## Windows 节点上的 DNS 解析 {#dns-windows}
- 在 Windows 节点上运行的 Pod 不支持 ClusterFirstWithHostNet。
Windows 将所有带有 `.` 的名称视为全限定域名FQDN并跳过全限定域名FQDN解析。
- 在 Windows 上,可以使用的 DNS 解析器有很多。
由于这些解析器彼此之间会有轻微的行为差别,建议使用
[`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
powershell cmdlet 进行名称查询解析。
- 在 Linux 上,有一个 DNS 后缀列表,当解析全名失败时可以使用。
在 Windows 上,你只能有一个 DNS 后缀,
即与该 Pod 的命名空间相关联的 DNS 后缀(例如:`mydns.svc.cluster.local`)。
Windows 可以解析全限定域名FQDN和使用了该 DNS 后缀的 Services 或者网络名称。
例如,在 `default` 命名空间中生成一个 Pod该 Pod 会获得的 DNS 后缀为 `default.svc.cluster.local`
在 Windows 的 Pod 中,你可以解析 `kubernetes.default.svc.cluster.local``kubernetes`
但是不能解析部分限定名称(`kubernetes.default` 和 `kubernetes.default.svc`)。
## {{% heading "whatsnext" %}}
<!--
For guidance on administering DNS configurations, check
[Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
-->
有关管理 DNS 配置的指导,
请查看[配置 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/)