From 0cb0d7fa7e40e2dc7882f5ddae60ed9d77d1ca8f Mon Sep 17 00:00:00 2001 From: Wilson Wu Date: Sun, 17 Nov 2024 19:33:03 +0800 Subject: [PATCH] [zh] Sync #15931 DNS Auto Allocation Version 2 into Chinese (#15941) * Sync #15931 DNS Auto Allocation Version 2 into Chinese * improve --- .../traffic-management/dns-proxy/index.md | 127 ++++++++++++++---- 1 file changed, 103 insertions(+), 24 deletions(-) diff --git a/content/zh/docs/ops/configuration/traffic-management/dns-proxy/index.md b/content/zh/docs/ops/configuration/traffic-management/dns-proxy/index.md index af5828ffe0..cc2c1de87e 100644 --- a/content/zh/docs/ops/configuration/traffic-management/dns-proxy/index.md +++ b/content/zh/docs/ops/configuration/traffic-management/dns-proxy/index.md @@ -7,19 +7,21 @@ owner: istio/wg-networking-maintainers test: yes --- -除了捕获应用流量，Istio 还可以捕获 DNS 请求，以提高网格的性能和可用性。 -当 Istio 代理 DNS 时，所有来自应用程序的 DNS 请求将会被重定向到 Sidecar， +除了捕获应用流量，Istio 还可以捕获 DNS 请求， +以提高网格的性能和可用性。当 Istio 代理 DNS 时， +所有来自应用程序的 DNS 请求将会被重定向到 Sidecar， 因为 Sidecar 存储了域名到 IP 地址的映射。如果请求被 Sidecar 处理， 它将直接给应用返回响应，避免了对上游DNS服务器的往返。 反之，请求将按照标准的 `/etc/resolv.conf` DNS 配置向上游转发。 -虽然 Kubernetes 为 Kubernetes `Service` 提供了一个开箱即用的 DNS 解析， -但任何自定义的 `ServiceEntry` 都不会被识别。有了这个功能，`ServiceEntry` -地址可以被解析，而不需要自定义 DNS 服务配置。对于 Kubernetes `Service` 来说， +虽然 Kubernetes 为 Kubernetes `Service` +提供了一个开箱即用的 DNS 解析，但任何自定义的 `ServiceEntry` +都不会被识别。有了这个功能，`ServiceEntry` 地址可以被解析， +而不需要自定义 DNS 服务配置。对于 Kubernetes `Service` 来说， 一样的 DNS 响应，但减少了 `kube-dns` 的负载，并且提高了性能。 -该功能也适用于在 Kubernetes 外部运行的服务。这意味着所有的内部服务都可以被解析， -而不需要再使用笨重的运行方法来暴露集群外的 Kubernetes DNS 条目。 +该功能也适用于在 Kubernetes 外部运行的服务。 +这意味着所有的内部服务都可以被解析，而不需要再使用笨重的运行方法来暴露集群外的 Kubernetes DNS 条目。 ## 开始 {#getting-started} @@ -92,8 +94,8 @@ $ kubectl label namespace default istio-injection=enabled --overwrite $ kubectl apply -f @samples/curl/curl.yaml@ {{< /text >}} -如果不开启 DNS 代理功能，请求 `address.internal` 时可能解析失败。 -一旦启用，您将收到一个基于 `address` 配置的响应： +如果不开启 DNS 代理功能，请求 `address.internal` +时可能解析失败。一旦启用，您将收到一个基于 `address` 配置的响应： {{< text bash >}} $ kubectl exec deploy/curl -- curl -sS -v address.internal @@ -102,23 +104,33 @@ $ kubectl exec deploy/curl -- curl -sS -v address.internal ## 自动分配地址 {#address-auto-allocation} -在上面的示例中，对于发送请求的服务，您有一个预定义的 IP 地址。但是常规情况下， -服务访问外部服务时一般没有一个相对固定的地址，因此需要通过 DNS 代理去访问外部服务。 -如果 DNS 代理没有足够的信息去返回一个响应的情况下，将需要向上游转发 DNS 请求。 +在上面的示例中，对于发送请求的服务，您有一个预定义的 IP 地址。 +但是常规情况下，服务访问外部服务时一般没有一个相对固定的地址， +因此需要通过 DNS 代理去访问外部服务。如果 DNS 代理没有足够的信息去返回一个响应的情况下， +将需要向上游转发 DNS 请求。 这在 TCP 通讯中是一个很严重的问题。它不像 HTTP 请求，基于 `Host` 头部去路由。 -TCP 携带的信息更少，只能在目标 IP 和端口号上路由。由于后端没有稳定的 IP， -所以也不能基于其他信息进行路由，只剩下端口号，但是这会导致多个 `ServiceEntry` -使用 TCP 服务会共享同一端口而产生冲突。更多细节参阅[以下章节](#external-tcp-services-without-vips)。 +TCP 携带的信息更少，只能在目标 IP 和端口号上路由。 +由于后端没有稳定的 IP，所以也不能基于其他信息进行路由， +只剩下端口号，但是这会导致多个 `ServiceEntry` 使用 TCP +服务会共享同一端口而产生冲突。更多细节参阅[以下章节](#external-tcp-services-without-vips)。 为了解决这些问题，DNS 代理还支持为没有明确定义的 `ServiceEntry` 自动分配地址。 这是通过 `ISTIO_META_DNS_AUTO_ALLOCATE` 选项配置的。 +{{< tip >}} +请参阅 [DNS 自动分配 V2](/zh/docs/ops/configuration/traffic-management/dns-proxy/#dns-auto-allocation-v2)， +了解 Istio 从 1.23 开始支持的新的自动分配增强实现。 +DNS 自动分配 V2 是 Sidecar 模式的推荐配置，也是 Ambient 模式的必需配置。 +{{< /tip >}} + 启用此特性后，DNS 响应将为每个 `ServiceEntry` 自动分配一个不同的独立地址。 然后代理能匹配请求与 IP 地址，并将请求转发到相应的 `ServiceEntry`。 -当使用 `ISTIO_META_DNS_AUTO_ALLOCATE` 时，Istio 会自动为不可路由的 VIP（从 Class E 子网中） -分配给这些服务，只要它们不使用通配符主机。Sidecar 上的 Istio 代理将使用 VIP 作为应用程序中 DNS -查找查询的响应。Envoy 现在可以清楚地区分每个外部 TCP 服务的流量，并将其转发到正确的目标。有关更多信息， +当使用 `ISTIO_META_DNS_AUTO_ALLOCATE` 时， +Istio 会自动为不可路由的 VIP（从 Class E 子网中）分配给这些服务， +只要它们不使用通配符主机。Sidecar 上的 Istio 代理将使用 VIP +作为应用程序中 DNS 查找查询的响应。Envoy 现在可以清楚地区分每个外部 +TCP 服务的流量，并将其转发到正确的目标。有关更多信息， 请查阅相应的[关于智能 DNS 代理的 Istio 博客](/zh/blog/2020/dns-proxy/#automatic-vip-allocation-where-possible)。 {{< warning >}} @@ -152,13 +164,15 @@ $ kubectl exec deploy/curl -- curl -sS -v auto.internal {{< /text >}} 您可以看到，请求被发送到一个自动分配的地址 `240.240.0.1` 上。 -这些地址将从 `240.240.0.0/16` 预留的 IP 地址池中挑选出来，以避免与真实的服务发生冲突。 +这些地址将从 `240.240.0.0/16` 预留的 IP 地址池中挑选出来， +以避免与真实的服务发生冲突。 ## 不带 VIP 的外部 TCP 服务 {#external-tcp-services-without-vips} 默认情况下，Istio 在路由外部 TCP 流量时存在限制，因为它无法区分相同端口上的多个 TCP 服务。 当使用第三方数据库（如 AWS 关系型数据库服务）或任何具有地理冗余设置的数据库时，这种限制尤为明显。 -默认情况下，类似但不同的外部 TCP 服务不能被分别处理。为了让 Sidecar 区分网格之外的两个不同的 TCP 服务的流量， +默认情况下，类似但不同的外部 TCP 服务不能被分别处理。 +为了让 Sidecar 区分网格之外的两个不同的 TCP 服务的流量， 这些服务必须位于不同的端口上，或者它们需要具有全局唯一的 VIP 地址。 例如，如果您有两个外部数据库服务（`mysql-instance1` 和 `mysql-instance2`）， @@ -167,11 +181,12 @@ $ kubectl exec deploy/curl -- curl -sS -v auto.internal 并将流量转发到它。它无法将流量路由到 `mysql-instance2`，因为它无法区分抵达 `0.0.0.0:{port}` 的流量是针对 `mysql-instance1` 还是 `mysql-instance2` 的。 -以下示例显示了如何使用 DNS 代理解决此问题。虚拟 IP 地址将被分配到每个服务条目， -以便客户端 Sidecar 可以清楚地区分每个外部 TCP 服务的流量。 +以下示例显示了如何使用 DNS 代理解决此问题。 +虚拟 IP 地址将被分配到每个服务条目，以便客户端 Sidecar 可以清楚地区分每个外部 TCP 服务的流量。 -1. 更新[开始](#getting-started)一节中指定的 Istio 配置，以配置 `discoverySelectors`， - 从而限制网格仅对启用了 `istio-injection` 的命名空间进行筛选。 +1. 更新[开始](#getting-started)一节中指定的 Istio 配置， + 以配置 `discoverySelectors`，从而限制网格仅对启用了 + `istio-injection` 的命名空间进行筛选。 这将使我们可以在集群中使用任何其他命名空间来运行网格之外的 TCP 服务。 {{< text bash >}} @@ -248,6 +263,70 @@ $ kubectl exec deploy/curl -- curl -sS -v auto.internal ADDRESS=240.240.69.138, DESTINATION=Cluster: outbound|9000||tcp-echo.external-1.svc.cluster.local {{< /text >}} +## DNS 自动分配 V2 {#dns-auto-allocation-v2} + +Istio 现在提供了 DNS 自动分配的增强实现。要使用新功能， +请在安装 Istio 时将上一个示例中使用的 `MeshConfig` 标志 +`ISTIO_META_DNS_AUTO_ALLOCATE` 替换为 pilot 环境变量 +`PILOT_ENABLE_IP_AUTOALLOCATE`。到目前为止给出的所有示例均可按原样运行。 + +{{< text bash >}} +$ cat <}} + +用户还可以通过向其 `ServiceEntry` 添加标签 +`networking.istio.io/enable-autoallocate-ip="true/false"` +来灵活地进行更细粒度的配置。此标签配置未设置任何 `spec.addresses` +的 `ServiceEntry` 是否应自动为其分配 IP 地址。 + +要尝试此功能，请使用退出标签更新现有的 `ServiceEntry`： + +{{< text bash >}} +$ kubectl apply -f - <}} + +现在，发送请求并验证自动分配不再发生： + +{{< text bash >}} +$ kubectl exec deploy/curl -- curl -sS -v auto.internal +* Could not resolve host: auto.internal +* shutting down connection #0 +{{< /text >}} + ## 清理 {#cleanup} {{< text bash >}}