Istio Ambient Waypoint Proxy 簡化版
推出新的以目標為導向的 waypoint proxy，以實現簡化和可擴展性。
Ambient 將 Istio 的功能分為兩個不同的層級：一個安全的覆蓋層和一個第 7 層處理層。Waypoint proxy 是一個可選組件，它基於 Envoy，並處理其管理的 workload 的 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 配置轉移到目標 proxy
在現有的 sidecar 架構中，大多數流量塑形（例如 請求路由 或 流量轉移 或 故障注入）策略由來源（客戶端）proxy 實作，而大多數安全策略由目標（伺服器）proxy 實作。這導致了一些問題
- 擴展性 - 每個來源 sidecar 都需要了解網格中每個其他目標的資訊。這是一個多項式擴展問題。更糟糕的是，如果任何目標配置發生變更，我們需要立即通知所有 sidecar。
- 除錯 - 由於策略執行是在客戶端和伺服器端 sidecar 之間分開進行的，因此在疑難排解時很難了解系統的行為。
- 混合環境 - 如果我們有並非所有客戶端都是網格一部分的系統，我們會得到不一致的行為。例如，非網格客戶端將不遵守 canary rollout 策略，導致意外的流量分配。
- 所有權和歸屬 - 理想情況下，在一個命名空間中編寫的策略應僅影響在同一命名空間中執行的 proxy 所做的工作。但是，在此模型中，它是由每個 sidecar 分散和執行。雖然 Istio 設計了繞過此限制的方法以使其安全，但它仍然不是最佳的。
在 ambient 中，所有策略都由目標 waypoint 執行。在許多方面，waypoint 充當進入命名空間（預設範圍）或服務帳戶的閘道。Istio 強制所有進入命名空間的流量都通過 waypoint，然後為該命名空間執行所有策略。因此，每個 waypoint 只需要知道其自身命名空間的配置即可。
特別是，擴展性問題對於在大型叢集中執行的使用者來說是一個麻煩。如果我們將其視覺化，我們可以了解新架構的改進幅度有多大。
考慮一個簡單的部署，其中我們有 2 個命名空間，每個命名空間有 2 個（顏色編碼的）部署。程式化 sidecar 所需的 Envoy (XDS) 配置顯示為圓圈
在 sidecar 模型中，我們有 4 個 workload，每個 workload 有 4 組配置。如果其中任何一個配置發生變更，則需要更新所有配置。總共分發了 16 個配置。
但是，在 waypoint 架構中，配置得到了極大的簡化
在這裡，我們看到了截然不同的情況。我們只有 2 個 waypoint proxy，因為每個 proxy 都能夠服務整個命名空間，並且每個 proxy 只需要其自身命名空間的配置。即使對於一個簡單的範例，我們也僅發送了 25% 的配置量。
如果我們將每個命名空間擴展到 25 個部署，每個部署有 10 個 pod，並且每個 waypoint 部署有 2 個 pod 以實現高可用性，則數字甚至更加令人印象深刻 - waypoint 配置分發僅需要 sidecar 配置分發的 0.8%，如下表所示！
| 配置分發 | 命名空間 1 | 命名空間 2 | 總計 |
|---|---|---|---|
| Sidecar | 25 個配置 * 250 個 sidecar | 25 個配置 * 250 個 sidecar | 12500 |
| Waypoint | 25 個配置 * 2 個 waypoint | 25 個配置 * 2 個 waypoint | 100 |
| Waypoint / Sidecar | 0.8% | 0.8% | 0.8% |
雖然我們使用命名空間範圍的 waypoint proxy 來舉例說明上述簡化，但當您將其應用於服務帳戶 waypoint proxy 時，簡化是類似的。
這種減少的配置意味著控制平面和資料平面的資源使用率（CPU、RAM 和網路頻寬）更低。雖然使用者今天可以透過仔細使用其 Istio 網路資源中的 exportTo 或 Sidecar API 看到類似的改進，但在 ambient 模式下，不再需要這樣做，使擴展變得輕而易舉。
如果我的目標沒有 waypoint proxy 怎麼辦？
ambient 模式的設計圍繞一個假設，即大多數配置最好由服務生產者而不是服務消費者實作。但是，情況並非總是如此 - 有時我們需要為我們不控制的目標配置流量管理。一個常見的範例是連線到具有更高彈性的外部服務，以處理偶爾的連線問題（例如，為對 example.com 的呼叫新增逾時）。
這是社群中正在積極開發的領域，我們在這裡設計流量如何路由到您的出口閘道，以及如何使用您所需的策略配置出口閘道。請密切注意此領域的未來部落格文章！
Waypoint 配置的深入探討
假設您已遵循ambient 入門指南，直至並包括控制流量部分，您已為 bookinfo-reviews 服務帳戶部署了 waypoint proxy，以將 90% 的流量導向 reviews v1，並將 10% 的流量導向 reviews 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 的 inbound HBONE 連接埠，waypoint proxy 將終止 HBONE 連線，並將請求轉發到 main_internal 接聽程式，以執行任何 workload 策略，例如 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 終止的 inbound 流量，它將在服務 VIP 和連接埠 9080 上針對 reviews 或按 pod IP 位址和應用程式協定（ANY、h2c 或 http/1.1）進行匹配。
檢視 reviews waypoint proxy 的叢集，您會得到 main_internal 叢集以及一些 inbound 叢集。除了基礎設施的叢集之外，建立的唯一 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 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 路由，以配置一個入口閘道以路由到 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
請注意，您沒有獲得與 reviews 以外的任何服務相關的任何端點，即使您在 default 和 istio-system 命名空間中還有其他幾個服務。
總結
我們對專注於以目標為導向的 waypoint proxy 的 waypoint 簡化感到非常興奮。這是朝簡化 Istio 的可用性、可擴展性和可除錯性邁出的又一重要一步，這些都是 Istio 路線圖上的首要任務。請遵循我們的入門指南，立即試用 ambient alpha 版本，體驗簡化的 waypoint proxy！
