理解 DNS

    本文档描述了底层实施细节。要了解更高层次的概述,请查看流量管理概念或页面。

    下面我们将以一个应用程序运行 为例来看一个请求的全过程。这里的 curl 请求过程适用于几乎所有客户端。

    当您向一个域名发送请求时,客户端会进行 DNS 解析,将其解析为一个 IP 地址。不管 Istio 如何设置,这都会发生,因为 Istio 只是拦截网络流量;它不能改变应用程序的行为或决定是否发送 DNS 请求。在下面的例子中,example.com 被解析为 192.0.2.0

    如果客户端无法解析 DNS 请求,在 Istio 收到请求之前就会终止。这意味着,即使一个请求发送到一个 Istio 已知的主机名(例如,通过 VirtualService 配置),但是无法通过 DNS 解析,该请求也会失败。不过 Istio 的 可以改变这种行为。

    一旦 Istio 确定了预期的目的地,它必须选择要发送到的地址。由于 Istio 的高级负载均衡能力,这往往不是客户端发送的原始 IP 地址。根据服务配置的不同,Istio 有几种不同的方式来实现:

    • 使用客户端的原始 IP 地址(上例中为 192.0.2.0)。这种情况适用于 resolution: NONE 类型的 和。
    • 在一组静态 IP 地址上进行负载均衡。这种情况适用于 resolution: STATIC 类型的 ServiceEntry,将使用其中所有的 spec.endpoints,或者对于标准 Service 将使用所有 Endpoint

    请注意,在任何情况下,Istio 代理内部的 DNS 解析与用户应用程序中的 DNS 解析是正交(orthogonal )的。即使客户端进行了 DNS 解析,代理也可能忽略已解析的 IP 地址,而使用自己的地址,这些地址可能来自静态的 IP 列表或通过代理的 DNS 解析(可能是同一主机名或不同的主机名)。

    对于具有许多代理或许多 resolution: DNS 类型 ServiceEntry 的网格而言,尤其是在使用较低 TTL 时,可能会导致 DNS 服务器的负载很高。在这些情况下,以下行为有助于减轻负载:

    • 切换为 resolution: NONE 以完全避免代理 DNS 查找。这适用于许多使用场景。
    • 如果您可以控制正在解析的域,请适当增加它们的 TTL。

    Istio 提供了代理 DNS 请求的功能。这允许 Istio 捕获客户端发送的 DNS 请求并直接返回响应。这可以改善 DNS 延迟,减少负载,并解决了 ServiceEntry 无法通过 kube-dns 解析的问题。

    请注意,此代理仅适用于用户应用程序发送的 DNS 请求;当使用 类型的 ServiceEntry 时,DNS 代理对 Istio 代理的 DNS 解析没有影响。