From 6f498cfeb921959db7e4a6203cfd79598e55f262 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 28 Apr 2021 10:55:54 +0800 Subject: [PATCH] [zh] Sync concepts section (6) --- .../services-networking/dns-pod-service.md | 116 ++++++++++++++---- .../ingress-controllers.md | 23 ++-- .../concepts/services-networking/ingress.md | 29 ++++- .../service/networking/namespaced-params.yaml | 12 ++ 4 files changed, 144 insertions(+), 36 deletions(-) create mode 100644 content/zh/examples/service/networking/namespaced-params.yaml diff --git a/content/zh/docs/concepts/services-networking/dns-pod-service.md b/content/zh/docs/concepts/services-networking/dns-pod-service.md index 2672d4e7d0..50a6c47d86 100644 --- a/content/zh/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh/docs/concepts/services-networking/dns-pod-service.md @@ -3,12 +3,23 @@ title: Pod 与 Service 的 DNS content_type: concept weight: 20 --- + + -本页面提供 Kubernetes 对 DNS 的支持的概述。 +Kubernetes 为服务和 Pods 创建 DNS 记录。 +你可以使用一致的 DNS 名称而非 IP 地址来访问服务。 @@ -21,40 +32,93 @@ resolve DNS names. --> ## 介绍 -Kubernetes DNS 在群集上调度 DNS Pod 和服务，并配置 kubelet 以告知各个容器使用 DNS 服务的 IP 来解析 DNS 名称。 +Kubernetes DNS 在集群上调度 DNS Pod 和服务，并配置 kubelet 以告知各个容器 +使用 DNS 服务的 IP 来解析 DNS 名称。 +集群中定义的每个 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`. + +### Service 的名字空间 + +DNS 查询可能因为执行查询的 Pod 所在的名字空间而返回不同的结果。 +不指定名字空间的 DNS 查询会被限制在 Pod 所在的名字空间内。 +要访问其他名字空间中的服务，需要在 DNS 查询中给出名字空间。 + +例如，假定名字空间 `test` 中存在一个 Pod，`prod` 名字空间中存在一个服务 +`data`。 + +Pod 查询 `data` 时没有返回结果，因为使用的是 Pod 的名字空间 `test`。 + +Pod 查询 `data.prod` 时则会返回预期的结果，因为查询中指定了名字空间。 + + +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 .svc.cluster.local svc.cluster.local cluster.local +options ndots:5 +``` + + +概括起来，名字空间 `test` 中的 Pod 可以成功地解析 `data.prod` 或者 +`data.prod.cluster.local`。 + + +### DNS 记录 {#dns-records} + +哪些对象会获得 DNS 记录呢？ + +1. Services +2. Pods + + -## 哪些对象会有 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 diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md index a50312b63d..a2c9eaaae3 100644 --- a/content/zh/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md @@ -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 控制器来执行。 @@ -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 控制器。 -IngressClass 资源包含一个可选的 `parameters` 字段，可用于为该类引用额外配置。 +IngressClass 资源包含一个可选的 `parameters` 字段，可用于为该类引用额外的、 +特定于具体实现的配置。 + + +#### 名字空间域的参数 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + + +`parameters` 字段有一个 `scope` 和 `namespace` 字段，可用来引用特定 +于名字空间的资源，对 Ingress 类进行配置。 +`scope` 字段默认为 `Cluster`，表示默认是集群作用域的资源。 +将 `scope` 设置为 `Namespace` 并设置 `namespace` 字段就可以引用某特定 +名字空间中的参数资源。 + +{{< codenew file="service/networking/namespaced-params.yaml" >}} 如果使用 `kubectl apply -f` 创建此 Ingress，则应该能够查看刚刚添加的 Ingress 的状态： diff --git a/content/zh/examples/service/networking/namespaced-params.yaml b/content/zh/examples/service/networking/namespaced-params.yaml new file mode 100644 index 0000000000..dd56724787 --- /dev/null +++ b/content/zh/examples/service/networking/namespaced-params.yaml @@ -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