[zh] Sync concepts section (6)
parent
2ac91aaa59
commit
6f498cfeb9
|
@ -3,12 +3,23 @@ title: Pod 与 Service 的 DNS
|
|||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- davidopp
|
||||
- thockin
|
||||
title: DNS for Services and Pods
|
||||
content_type: concept
|
||||
weight: 20
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page provides an overview of DNS support by Kubernetes.
|
||||
Kubernetes creates DNS records for services and pods. You can contact
|
||||
services with consistent DNS names instead of IP addresses.
|
||||
-->
|
||||
本页面提供 Kubernetes 对 DNS 的支持的概述。
|
||||
Kubernetes 为服务和 Pods 创建 DNS 记录。
|
||||
你可以使用一致的 DNS 名称而非 IP 地址来访问服务。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
@ -21,40 +32,93 @@ resolve DNS names.
|
|||
-->
|
||||
## 介绍
|
||||
|
||||
Kubernetes DNS 在群集上调度 DNS Pod 和服务,并配置 kubelet 以告知各个容器使用 DNS 服务的 IP 来解析 DNS 名称。
|
||||
Kubernetes DNS 在集群上调度 DNS Pod 和服务,并配置 kubelet 以告知各个容器
|
||||
使用 DNS 服务的 IP 来解析 DNS 名称。
|
||||
|
||||
<!--
|
||||
### What things get DNS names?
|
||||
|
||||
Every Service defined in the cluster (including the DNS server itself) is
|
||||
assigned a DNS name. By default, a client Pod's DNS search list will
|
||||
include the Pod's own namespace and the cluster's default domain. This is best
|
||||
illustrated by example:
|
||||
assigned a DNS name. By default, a client Pod's DNS search list includes the
|
||||
Pod's own namespace and the cluster's default domain.
|
||||
-->
|
||||
集群中定义的每个 Service (包括 DNS 服务器自身)都被赋予一个 DNS 名称。
|
||||
默认情况下,客户端 Pod 的 DNS 搜索列表会包含 Pod 自身的名字空间和集群
|
||||
的默认域。
|
||||
|
||||
Assume a Service named `foo` in the Kubernetes namespace `bar`. A Pod running
|
||||
in namespace `bar` can look up this service by simply doing a DNS query for
|
||||
`foo`. A Pod running in namespace `quux` can look up this service by doing a
|
||||
DNS query for `foo.bar`.
|
||||
<!--
|
||||
### Namespaces of Services
|
||||
|
||||
The following sections detail the supported record types and layout that is
|
||||
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 的名字空间
|
||||
|
||||
DNS 查询可能因为执行查询的 Pod 所在的名字空间而返回不同的结果。
|
||||
不指定名字空间的 DNS 查询会被限制在 Pod 所在的名字空间内。
|
||||
要访问其他名字空间中的服务,需要在 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
|
||||
sets this file for each pod. For example, a query for just `data` may be
|
||||
expanded to `data.test.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.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.cluster.local`.
|
||||
-->
|
||||
概括起来,名字空间 `test` 中的 Pod 可以成功地解析 `data.prod` 或者
|
||||
`data.prod.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 名字? {#what-things-get-dns-names}
|
||||
|
||||
在集群中定义的每个 Service(包括 DNS 服务器自身)都会被指派一个 DNS 名称。
|
||||
默认,一个客户端 Pod 的 DNS 搜索列表将包含该 Pod 自己的名字空间和集群默认域。
|
||||
如下示例是一个很好的说明:
|
||||
|
||||
假设在 Kubernetes 集群的名字空间 `bar` 中,定义了一个服务 `foo`。
|
||||
运行在名字空间 `bar` 中的 Pod 可以简单地通过 DNS 查询 `foo` 来找到该服务。
|
||||
运行在名字空间 `quux` 中的 Pod 可以通过 DNS 查询 `foo.bar` 找到该服务。
|
||||
|
||||
以下各节详细介绍了受支持的记录类型和支持的布局。
|
||||
以下各节详细介绍了被支持的 DNS 记录类型和被支持的布局。
|
||||
其它布局、名称或者查询即使碰巧可以工作,也应视为实现细节,
|
||||
将来很可能被更改而且不会因此出现警告。
|
||||
将来很可能被更改而且不会因此发出警告。
|
||||
有关最新规范请查看
|
||||
[Kubernetes 基于 DNS 的服务发现](https://github.com/kubernetes/dns/blob/master/docs/specification.md)。
|
||||
|
||||
|
@ -301,7 +365,7 @@ If a Pod enables this feature and its FQDN is longer than 64 character, it will
|
|||
|
||||
如果 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 主机名和集群域名构造 FQDN,FQDN `long-FQDN` 过长,至多 64
|
||||
|
|
|
@ -24,7 +24,8 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
|
|||
-->
|
||||
为了让 Ingress 资源工作,集群必须有一个正在运行的 Ingress 控制器。
|
||||
|
||||
与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同,Ingress 控制器不是随集群自动启动的。
|
||||
与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同,
|
||||
Ingress 控制器不是随集群自动启动的。
|
||||
基于此页面,你可选择最适合你的集群的 ingress 控制器实现。
|
||||
|
||||
Kubernetes 作为一个项目,目前支持和维护
|
||||
|
@ -54,15 +55,18 @@ Kubernetes 作为一个项目,目前支持和维护
|
|||
* [AKS 应用程序网关 Ingress 控制器](https://azure.github.io/application-gateway-kubernetes-ingress/)
|
||||
是一个配置 [Azure 应用程序网关](https://docs.microsoft.com/azure/application-gateway/overview)
|
||||
的 Ingress 控制器。
|
||||
* [Ambassador](https://www.getambassador.io/) API 网关是一个基于 [Envoy](https://www.envoyproxy.io) 的 Ingress
|
||||
* [Ambassador](https://www.getambassador.io/) API 网关是一个基于
|
||||
[Envoy](https://www.envoyproxy.io) 的 Ingress
|
||||
控制器。
|
||||
* [Apache APISIX Ingress 控制器](https://github.com/apache/apisix-ingress-controller) 是一个基于 [Apache APISIX 网关](https://github.com/apache/apisix) 的 Ingress 控制器。
|
||||
* [Apache APISIX Ingress 控制器](https://github.com/apache/apisix-ingress-controller)
|
||||
是一个基于 [Apache APISIX 网关](https://github.com/apache/apisix) 的 Ingress 控制器。
|
||||
* [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)
|
||||
使用 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)
|
||||
提供第 4 到第 7 层的负载均衡。
|
||||
* [Citrix Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller#readme)
|
||||
可以用来与 Citrix Application Delivery Controller 一起使用。
|
||||
* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 Ingress 控制器。
|
||||
* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/)
|
||||
的 Ingress 控制器。
|
||||
* [EnRoute](https://getenroute.io/) 是一个基于 [Envoy](https://www.envoyproxy.io) API 网关,
|
||||
可以作为 Ingress 控制器来执行。
|
||||
<!--
|
||||
|
@ -82,7 +86,8 @@ Kubernetes 作为一个项目,目前支持和维护
|
|||
让你能够使用 Ingress 来配置 F5 BIG-IP 虚拟服务器。
|
||||
* [Gloo](https://gloo.solo.io) 是一个开源的、基于 [Envoy](https://www.envoyproxy.io) 的
|
||||
Ingress 控制器,能够提供 API 网关功能,
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io/) 针对 [HAProxy](https://www.haproxy.org/#desc)
|
||||
* [HAProxy Ingress](https://haproxy-ingress.github.io/) 针对
|
||||
[HAProxy](https://www.haproxy.org/#desc)
|
||||
的 Ingress 控制器。
|
||||
* [用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress#readme)
|
||||
也是一个针对 [HAProxy](https://www.haproxy.org/#desc) 的 Ingress 控制器。
|
||||
|
@ -96,6 +101,7 @@ Kubernetes 作为一个项目,目前支持和维护
|
|||
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy.
|
||||
* The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an
|
||||
ingress controller for the [Traefik](https://traefik.io/traefik/) proxy.
|
||||
* [Tyk Operator](https://github.com/TykTechnologies/tyk-operator) extends Ingress with Custom Resources to bring API Management capabilities to Ingress. Tyk Operator works with the Open Source Tyk Gateway & Tyk Cloud control plane.
|
||||
* [Voyager](https://appscode.com/products/voyager) is an ingress controller for
|
||||
[HAProxy](https://www.haproxy.org/#desc).
|
||||
-->
|
||||
|
@ -109,8 +115,11 @@ Kubernetes 作为一个项目,目前支持和维护
|
|||
设计用来作为构造你自己的定制代理的库。
|
||||
* [Traefik Kubernetes Ingress 提供程序](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)
|
||||
是一个用于 [Traefik](https://traefik.io/traefik/) 代理的 Ingress 控制器。
|
||||
* [Voyager](https://appscode.com/products/voyager) 是一个针对 [HAProxy](https://www.haproxy.org/#desc)
|
||||
的 Ingress 控制器。
|
||||
* [Tyk Operator](https://github.com/TykTechnologies/tyk-operator)
|
||||
使用自定义资源扩展 Ingress,为之带来 API 管理能力。Tyk Operator
|
||||
使用开源的 Tyk Gateway & Tyk Cloud 控制面。
|
||||
* [Voyager](https://appscode.com/products/voyager) 是一个针对
|
||||
[HAProxy](https://www.haproxy.org/#desc) 的 Ingress 控制器。
|
||||
|
||||
<!--
|
||||
## Using multiple Ingress controllers
|
||||
|
|
|
@ -411,9 +411,32 @@ IngressClass 资源包含额外的配置,其中包括应当实现该类的控
|
|||
|
||||
<!--
|
||||
IngressClass resources contain an optional parameters field. This can be used to
|
||||
reference additional configuration for this class.
|
||||
reference additional implementation-specific configuration for this class.
|
||||
-->
|
||||
IngressClass 资源包含一个可选的 `parameters` 字段,可用于为该类引用额外配置。
|
||||
IngressClass 资源包含一个可选的 `parameters` 字段,可用于为该类引用额外的、
|
||||
特定于具体实现的配置。
|
||||
|
||||
<!--
|
||||
#### Namespace-scoped parameters
|
||||
-->
|
||||
#### 名字空间域的参数
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
|
||||
<!--
|
||||
`Parameters` field has a `scope` and `namespace` field that can be used to
|
||||
reference a namespace-specific resource for configuration of an Ingress class.
|
||||
`Scope` field defaults to `Cluster`, meaning, the default is cluster-scoped
|
||||
resource. Setting `Scope` to `Namespace` and setting the `Namespace` field
|
||||
will reference a parameters resource in a specific namespace:
|
||||
-->
|
||||
`parameters` 字段有一个 `scope` 和 `namespace` 字段,可用来引用特定
|
||||
于名字空间的资源,对 Ingress 类进行配置。
|
||||
`scope` 字段默认为 `Cluster`,表示默认是集群作用域的资源。
|
||||
将 `scope` 设置为 `Namespace` 并设置 `namespace` 字段就可以引用某特定
|
||||
名字空间中的参数资源。
|
||||
|
||||
{{< codenew file="service/networking/namespaced-params.yaml" >}}
|
||||
|
||||
<!--
|
||||
### Deprecated Annotation
|
||||
|
@ -488,7 +511,7 @@ There are existing Kubernetes concepts that allow you to expose a single Service
|
|||
|
||||
<!--
|
||||
If you create it using `kubectl apply -f` you should be able to view the state
|
||||
of the Ingress you just added:
|
||||
of the Ingress you added:
|
||||
-->
|
||||
如果使用 `kubectl apply -f` 创建此 Ingress,则应该能够查看刚刚添加的 Ingress 的状态:
|
||||
|
||||
|
|
|
@ -0,0 +1,12 @@
|
|||
apiVersion: networking.k8s.io/v1
|
||||
kind: IngressClass
|
||||
metadata:
|
||||
name: external-lb
|
||||
spec:
|
||||
controller: example.com/ingress-controller
|
||||
parameters:
|
||||
apiGroup: k8s.example.com
|
||||
kind: IngressParameters
|
||||
name: external-lb
|
||||
namespace: external-configuration
|
||||
scope: Namespace
|
Loading…
Reference in New Issue