Istio 环境感知路标代理简化
推出新的面向目标的路标代理，以实现简单性和可扩展性。
Ambient 将 Istio 的功能划分为两个不同的层，一个安全的覆盖层和一个第 7 层处理层。路标代理是一个可选组件，它基于 Envoy 并处理其管理的工作负载的第 7 层处理。自从 2022 年首次推出 Ambient 以来，我们已经做出了重大改变，以简化路标配置、可调试性和可扩展性。
路标代理的架构
与 sidecar 类似，路标代理也基于 Envoy，并由 Istio 动态配置以服务于您的应用程序配置。路标代理的独特之处在于，它可以按命名空间（默认）或按服务帐户运行。通过在应用程序 Pod 之外运行，路标代理可以独立于应用程序进行安装、升级和扩展，以及降低运营成本。
路标代理使用 Kubernetes 网关资源或有用的 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 将监视这些资源，并自动为用户部署和管理相应的路标部署。
将源代理配置转移到目标代理
在现有的 sidecar 架构中，大多数流量整形（例如 请求路由 或 流量切换 或 故障注入）策略由源（客户端）代理实施，而大多数安全策略由目标（服务器）代理实施。这导致了一些问题。
- 扩展性 - 每个源 sidecar 需要知道网格中每个其他目标的信息。这是一个多项式扩展问题。更糟糕的是，如果任何目标配置发生更改，我们需要立即通知所有 sidecar。
- 调试 - 由于策略执行在客户端和服务器 sidecar 之间拆分，因此在进行故障排除时可能难以理解系统的行为。
- 混合环境 - 如果我们的系统中并非所有客户端都是网格的一部分，我们会得到不一致的行为。例如，非网格客户端不会遵守金丝雀发布策略，从而导致意外的流量分配。
- 所有权和归属 - 理想情况下，在一个命名空间中编写的策略应该只影响在同一命名空间中运行的代理执行的工作。但是，在此模型中，它由每个 sidecar 分布式执行。虽然 Istio 围绕此约束进行了设计以使其安全，但它仍然不是最佳的。
在 Ambient 中，所有策略都由目标路标强制执行。在许多方面，路标充当命名空间（默认范围）或服务帐户的网关。Istio 强制执行进入命名空间的所有流量都必须通过路标，然后路标会强制执行该命名空间的所有策略。因此，每个路标只需要知道其自身命名空间的配置。
特别是可扩展性问题对于在大型集群中运行的用户来说是一个麻烦。如果我们将其可视化，我们可以看到新架构的改进程度有多大。
考虑一个简单的部署，其中我们有两个命名空间，每个命名空间都有两个（颜色编码）部署。用于对 sidecar 进行编程的 Envoy（XDS）配置显示为圆圈。
在 sidecar 模型中，我们有 4 个工作负载，每个工作负载都有 4 组配置。如果这些配置中的任何一个发生更改，则所有配置都需要更新。总共有 16 个配置被分发。
然而，在路标架构中，配置得到了极大的简化。
在这里，我们看到了一个截然不同的故事。我们只有 2 个路标代理，因为每个代理都能够服务整个命名空间，并且每个代理只需要其自身命名空间的配置。即使对于一个简单的示例，我们也只发送了 25% 的配置量。
如果我们将每个命名空间扩展到 25 个部署，每个部署有 10 个 Pod，并且每个路标部署有 2 个 Pod 用于高可用性，那么数字将更加令人印象深刻 - 路标配置分发只需要 sidecar 配置分发的 0.8%，如下表所示！
| 配置分发 | 命名空间 1 | 命名空间 2 | 总计 |
|---|---|---|---|
| Sidecar | 25 个配置 * 250 个 sidecar | 25 个配置 * 250 个 sidecar | 12500 |
| 路标 | 25 个配置 * 2 个路标 | 25 个配置 * 2 个路标 | 100 |
| 路标 / Sidecar | 0.8% | 0.8% | 0.8% |
虽然我们使用命名空间范围的路标代理来说明上述简化，但当您将其应用于服务帐户路标代理时，简化过程也是类似的。
这种减少的配置意味着控制平面和数据平面都降低了资源使用率（CPU、RAM 和网络带宽）。虽然用户今天可以通过仔细使用 Istio 网络资源中的 exportTo 或 Sidecar API 获得类似的改进，但在 Ambient 模式下，这不再需要，从而使扩展变得轻而易举。
如果我的目标没有路标代理会怎样？
Ambient 模式的设计围绕着一个假设：大多数配置最好由服务生产者而不是服务消费者来实现。但是，情况并非总是如此 - 有时我们需要为我们无法控制的目标配置流量管理。一个常见的例子是连接到外部服务，并提高弹性以处理偶尔的连接问题（例如，为对 example.com 的调用添加超时）。
这是社区正在积极开发的一个领域，我们将在其中设计如何将流量路由到您的出口网关，以及如何使用您所需的策略配置出口网关。敬请关注此领域的未来博文！
路标配置的深入探讨
假设您已按照 Ambient 入门指南 操作，直到包含 控制流量部分，您已为 bookinfo-reviews 服务帐户部署了一个路标代理，以将 90% 的流量定向到 reviews v1，并将 10% 的流量定向到 reviews v2。
使用 istioctl 检索 reviews 路标代理的侦听器。
$ 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 端口，路标代理会终止 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 命令查看集群的这些 IP。对于纯文本或 HBONE 终止的入站流量，它将匹配服务 VIP 和端口 9080（用于 reviews）或 Pod IP 地址和应用程序协议（ANY、h2c 或 http/1.1）。
查看 reviews 路标代理的集群，您将获得 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 服务（例如 productpage 或 ratings 服务）上配置 exportTo。换句话说，reviews 路标不会感知任何不必要的集群，而无需您进行任何额外的手动配置。
显示 reviews 路标代理的路由列表。
$ 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 路由以配置一个入口网关以路由到 productpage，但 reviews 路标没有意识到任何此类无关的路由。
显示 inbound-vip|9080|http|reviews.default.svc.cluster.local 路由的详细信息，您将看到基于权重的路由配置，将 90% 的流量定向到 reviews v1，并将 10% 的流量定向到 reviews v2，以及一些 Istio 的默认重试和超时配置。这确认了流量和弹性策略已从源转移到前面讨论的面向目标的路标。
$ 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 路标代理的端点。
$ 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命名空间中还有其他一些服务，您也不会获得与任何其他服务（除了评论服务）相关的任何端点。
总结
我们对专注于目标导向的Waypoint代理的Waypoint简化感到非常兴奋。这是简化Istio的可用性、可扩展性和可调试性的又一个重要步骤，这些是Istio路线图中的重中之重。请遵循我们的入门指南，立即尝试Ambient Alpha版本，体验简化的Waypoint代理！
