Istio Ambient Waypoint Proxy 让一切变得简单

Ambient 将 Istio 的功能分为两个不同层级，一个是具备安全机制的 Overlay 层，另一个是 L7 处理层。 Waypoint Proxy 是一个基于 Envoy 的可选组件，为其管理的工作负载进行 L7 处理。 自 2022 年首次发布 Ambient 以来， 我们在简化 Waypoint 配置、可调试性和可扩展性方面做了许多重大变更。

Waypoint Proxy 的架构

与 Sidecar 类似，Waypoint Proxy 也是基于 Envoy 的，由 Istio 动态配置以服务于您的应用程序配置。 Waypoint Proxy 的独特之处在于它按照每个命名空间（默认）或每个服务账户来运行。 通过在应用程序 Pod 之外运行，Waypoint Proxy 可以独立于应用程序安装、升级和扩展，并降低运营成本。

Waypoint Proxy 是使用 Kubernetes Gateway 资源以声明方式部署的，也可以使用以下 istioctl 命令来部署：

$ istioctl experimental waypoint generate
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: namespace
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

Istiod 将监控这些资源并自动为用户部署和管理相应的 Waypoint Proxy。

将源代理配置转移到目的地代理

在现有的 Sidecar 架构中，大多数流量形态（例如请求路由 或流量转移或 故障注入）策略由源（客户端）代理实现， 而大多数安全策略由目标（服务器）代理实现。这导致了一些担忧：

• 扩缩：每个源 Sidecar 都需要知道关于网格中每个其他目的地的信息。这是一个多项式扩缩问题。 更糟糕的是，如果任何目标配置发生变化，我们需要立即通知所有 Sidecar。
• 调试：因为策略执行在客户端和服务器 Sidecar 之间分开，所以在故障排除时很难理解系统的行为。
• 混合环境：如果有这样一个系统，不是所有客户端都属于网格，那可能就会得到不一致的行为。 例如，非网格客户端不会遵守金丝雀部署策略，从而导致意外的流量分配。
• 所有权和归属：理想情况下，在一个命名空间中编写的策略应该只影响在同一命名空间中运行的代理所做的工作。 然而，在这个模型中，它是由每个 Sidecar 分发和执行的。 尽管 Istio 已围绕此约束进行设计以确保其安全，但它仍然不是最佳选择。

在 Ambient 中，所有策略都由目的地 Waypoint 强制执行。 在许多方面，Waypoint 充当进入命名空间（默认范围）或服务账户的网关。 Istio 强制所有进入命名空间的流量都经过 Waypoint，然后该 Waypoint 执行该命名空间的所有策略。 因此，每个 Waypoint 只需要了解其自己命名空间的配置。

特别是可扩展性问题，对于在大型集群中运行的用户来说是一个困扰。 如果我们把它形象化，我们就可以看到新架构有多大的改进。

考虑一个简单的部署，我们有 2 个命名空间，每个命名空间有 2 个（彩色编码的）部署。 为 Sidecar 编程所需的 Envoy (XDS) 配置显示为圆圈：

在 Sidecar 模型中，我们有 4 个工作负载，每个工作负载有 4 组配置。 如果这些配置中的任何一个发生更改，则所有这些配置都需要更新。总共分发了 16 个配置。

然而，在 Waypoint 架构中，配置得到了极大的简化：

在这里，我们看到一个非常不同的情况。我们只有 2 个 Waypoint Proxy， 因为每个 Waypoint Proxy 都能为整个命名空间提供服务，而且每个 Waypoint Proxy 只需要为自己的命名空间配置。 总的来说，即使对于一个简单的例子，我们发送的配置量也只有总量的 25%。

如果我们将每个命名空间扩容到 25 个 Deployment，每个 Deployment 有 10 个 Pod， 每个 Waypoint Deployment 有 2 个 Pod 以实现高可用性，那么数值就更加惊人了。 如下表所示，Waypoint 配置分发只需要 Sidecar 配置分发的 0.8%！

虽然我们使用命名空间范围的 Waypoint Proxy 来说明上面的简化， 但当您将其应用于服务账户 Waypoint Proxy 时，简化是相似的。

这样减少配置意味着控制平面和数据平面更低的资源使用率（CPU、RAM 和网络带宽）。 虽然如今的用户可以通过在 Istio 网络资源或 Sidecar API 中谨慎使用 exportTo 来看到类似的改进，但在 Ambient 模式下不再需要这样做，这就使得扩缩容轻而易举。

如果我的目的地没有 Waypoint Proxy 怎么办？

Ambient 模式的设计围绕这样一个假设，即大多数配置最好由服务生产者而不是服务消费者实施。 然而，情况并非总是如此，有时我们需要为无法控制的目的地配置流量管理。 一个常见的例子是连接到具有改进弹性的外部服务，以处理偶尔的连接问题（例如为调用添加超时 example.com）。

这是社区中正在积极开发的一个领域，我们在其中设计如何将流量路由到您的出口网关， 以及您如何使用所需的策略配置出口网关。留意这方面的未来博客文章！

对 Waypoint 配置的深入研究

假设您已遵循 Ambient 入门指南 以及控制流量章节的说明， 您已经为 bookinfo-reviews 服务账户部署了一个 Waypoint Proxy， 将 90% 的流量引导至 review v1，将 10% 的流量引导至 review v2。

使用 istioctl 检索 reviews Waypoint Proxy 的监听器：

$ istioctl proxy-config listener deploy/bookinfo-reviews-istio-waypoint --waypoint
LISTENER              CHAIN                                                 MATCH                                         DESTINATION
envoy://connect_originate                                                       ALL                                           Cluster: connect_originate
envoy://main_internal inbound-vip|9080||reviews.default.svc.cluster.local-http  ip=10.96.104.108 -> port=9080                 Inline Route: /*
envoy://main_internal direct-tcp                                            ip=10.244.2.14 -> ANY                         Cluster: encap
envoy://main_internal direct-tcp                                            ip=10.244.1.6 -> ANY                          Cluster: encap
envoy://main_internal direct-tcp                                            ip=10.244.2.11 -> ANY                         Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.2.11 -> application-protocol='h2c'  Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.2.11 -> application-protocol='http/1.1' Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.2.14 -> application-protocol='http/1.1' Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.2.14 -> application-protocol='h2c'  Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.1.6 -> application-protocol='h2c'   Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.1.6 -> application-protocol='http/1.1'  Cluster: encap
envoy://connect_terminate default                                               ALL                                           Inline Route:

对于到达端口的请求 15008，默认情况下是 Istio 的入站 HBONE 端口， Waypoint Proxy 终止 HBONE 连接并将请求转发给 main_internal 监听器以执行任何工作负载策略，例如 AuthorizationPolicy。 如果您不熟悉内部监听器， 它们是 Envoy 监听器，无需使用系统网络 API 即可接受用户空间连接。 上述添加到 istioctl proxy-config 命令的 --waypoint 参数指示它显示 main_internal 监听器、过滤链、链匹配和目的地详情。

注意 10.96.104.108 是 reviews 的服务 VIP，10.244.x.x 是 reviews 服务的 v1/v2/v3 Pod IP， 您可以使用 kubectl get svc,pod -o wide 命令查看集群信息。 对于明文或 HBONE 终止的入站流量，它将在服务 VIP 和端口 9080 上进行匹配以供审查或通过 Pod IP 地址和应用协议（ANY、h2c、http/1.1）进行匹配。

检查集群的 reviews Waypoint Proxy，您将获得 main_internal 集群以及一些入站集群。 除了用于基础设施的集群之外，唯一创建的 Envoy 集群是为在同一服务账户中运行的服务和 Pod 创建的。 没有为在别处运行的服务或 Pod 创建集群。

$ istioctl proxy-config clusters deploy/bookinfo-reviews-istio-waypoint
SERVICE FQDN                         PORT SUBSET  DIRECTION   TYPE         DESTINATION RULE
agent                                -    -       -           STATIC
connect_originate                    -    -       -           ORIGINAL_DST
encap                                -    -       -           STATIC
kubernetes.default.svc.cluster.local 443  tcp     inbound-vip EDS
main_internal                        -    -       -           STATIC
prometheus_stats                     -    -       -           STATIC
reviews.default.svc.cluster.local    9080 http    inbound-vip EDS
reviews.default.svc.cluster.local    9080 http/v1 inbound-vip EDS
reviews.default.svc.cluster.local    9080 http/v2 inbound-vip EDS
reviews.default.svc.cluster.local    9080 http/v3 inbound-vip EDS
sds-grpc                             -    -       -           STATIC
xds-grpc                             -    -       -           STATIC
zipkin                               -    -       -           STRICT_DNS

请注意，列表中没有 outbound 集群，您可以使用 istioctl proxy-config cluster deploy/bookinfo-reviews-istio-waypoint --direction outbound 来确认! 最棒的是，您不需要在任何其他 bookinfo 服务上配置 exportTo （例如 productpage 或 ratings 服务）。换句话说，reviews Waypoint 不会感知到任何不必要的集群，不需要您进行任何额外的手动配置。

显示 reviews Waypoint Proxy 的路由列表：

$ istioctl proxy-config routes deploy/bookinfo-reviews-istio-waypoint
NAME                                                    DOMAINS MATCH              VIRTUAL SERVICE
encap                                                   *       /*
inbound-vip|9080|http|reviews.default.svc.cluster.local *       /*                 reviews.default
default

回想一下，您没有在 Istio 网络资源上配置任何 Sidecar 资源，也未执行 exportTo 配置。 然而，您部署了 bookinfo-productpage 路由来配置 Ingress 网关以路由到 productpage， 但 reviews Waypoint 还未感知到此类不相关的路由。

在显示 inbound-vip|9080|http|reviews.default.svc.cluster.local 路由的详情时， 您会看到基于权重的路由配置将 90% 的流量引导到 reviews v1，将 10% 的流量引导到 reviews v2， 还能看到 Istio 的一些默认重试和超时配置。如前所述，这证实了流量和弹性策略已从来源转移到面向目的地的 Waypoint。

$ istioctl proxy-config routes deploy/bookinfo-reviews-istio-waypoint --name "inbound-vip|9080|http|reviews.default.svc.cluster.local" -o yaml
- name: inbound-vip|9080|http|reviews.default.svc.cluster.local
 validateClusters: false
 virtualHosts:
 - domains:
   - '*'
   name: inbound|http|9080
   routes:
   - decorator:
       operation: reviews:9080/*
     match:
       prefix: /
     metadata:
       filterMetadata:
         istio:
           config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/reviews
     route:
       maxGrpcTimeout: 0s
       retryPolicy:
         hostSelectionRetryMaxAttempts: "5"
         numRetries: 2
         retriableStatusCodes:
         - 503
         retryHostPredicate:
         - name: envoy.retry_host_predicates.previous_hosts
           typedConfig:
             '@type': type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate
         retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes
       timeout: 0s
       weightedClusters:
         clusters:
         - name: inbound-vip|9080|http/v1|reviews.default.svc.cluster.local
           weight: 90
         - name: inbound-vip|9080|http/v2|reviews.default.svc.cluster.local
           weight: 10

查看 reviews Waypoint Proxy 的端点：

$ istioctl proxy-config endpoints deploy/bookinfo-reviews-istio-waypoint
ENDPOINT                                            STATUS  OUTLIER CHECK CLUSTER
127.0.0.1:15000                                     HEALTHY OK            prometheus_stats
127.0.0.1:15020                                     HEALTHY OK            agent
envoy://connect_originate/                          HEALTHY OK            encap
envoy://connect_originate/10.244.1.6:9080           HEALTHY OK            inbound-vip|9080|http/v2|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.1.6:9080           HEALTHY OK            inbound-vip|9080|http|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.11:9080          HEALTHY OK            inbound-vip|9080|http/v1|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.11:9080          HEALTHY OK            inbound-vip|9080|http|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.14:9080          HEALTHY OK            inbound-vip|9080|http/v3|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.14:9080          HEALTHY OK            inbound-vip|9080|http|reviews.default.svc.cluster.local
envoy://main_internal/                              HEALTHY OK            main_internal
unix://./etc/istio/proxy/XDS                        HEALTHY OK            xds-grpc
unix://./var/run/secrets/workload-spiffe-uds/socket HEALTHY OK            sds-grpc

请注意，即使您在 default 和 istio-system 命名空间中还有一些其他服务， 您也不会获得除 reviews 之外与任何服务相关的任何端点。

结束语

我们对专注于面向目的地的 Waypoint Proxy 的 Waypoint 简化感到非常兴奋。 这是朝着简化 Istio 的可用性、可扩展性和可调试性迈出的重要一步， 这些是 Istio Roadmap 的重中之重。请跟随入门指南试用 Ambient Alpha 构建并体验简化的 Waypoint Proxy！