#更新 waypoint 代理

Waypoint 代理通过 Kubernetes Gateway API 部署，并由 Istio 控制平面管理。当你使用 InPlace 策略更新控制平面时，istiod 会自行将 waypoint 部署滚动更新到匹配的代理版本 — 你无需单独更新 waypoint，其服务的应用工作负载在整个过程中都会持续运行。

由于 waypoint 始终跟随活动控制平面，因此请确保其版本与控制平面相差不超过一个次要版本（相同版本或 n-1）。这与 Istio 支持策略一致，该策略要求数据平面组件不得领先于控制平面；同样的规则也适用于 Istio CNI plugin 和 ZTunnel。RevisionBased 策略在 ambient 模式下不可用 — 有关原因，请参阅在 ambient 模式下更新 Alauda Service Mesh。

前提条件

• 你已按照更新 ambient 模式组件中的说明更新 Istio 控制平面。
• Bookinfo 应用已部署在 ambient 模式下；请参阅在 ambient 模式下部署 Bookinfo 应用。
• waypoint 命名的 waypoint 代理存在于 bookinfo 命名空间中；请参阅Waypoint 代理。

#验证 waypoint 代理版本

确认 waypoint 代理已重新连接到更新后的控制平面，并运行新的代理版本：

istioctl proxy-status | grep waypoint

示例输出

waypoint-7b6bcffd55-lj54j.bookinfo     Kubernetes     istiod-85c76b5b66-qgbrv     1.30.4-asm-r3     4 (CDS,LDS,EDS,WDS)

输出列出了 waypoint pod、其连接到的 istiod pod、正在运行的代理版本，以及代理订阅的 xDS 配置类型。填充的订阅列表确认 waypoint 正在从控制平面接收配置，并且 VERSION 列现在应显示更新后的版本。

#验证 L7 流量路由

更新 waypoint 代理后，确认第 7 层 (L7) 流量管理仍按配置运行。如果使用 HTTPRoute 资源路由流量，请检查配置的权重是否仍然生效。

前提条件

• 已创建 bookinfo-versions 服务（属于 ambient 模式下 Bookinfo 部署的一部分）。
• HTTPRoute 资源会拆分 reviews 流量。

操作步骤

1. 可选：如果尚不存在，请创建 HTTPRoute 资源，以 80/20 的比例在 reviews-v1 和 reviews-v2 之间分配 reviews 流量：

   cat <<EOF | kubectl apply -f -
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: reviews
     namespace: bookinfo
   spec:
     parentRefs:
       - group: ""
         kind: Service
         name: reviews
         port: 9080
     rules:
       - backendRefs:
           - name: reviews-v1
             port: 9080
             weight: 80
           - name: reviews-v2
             port: 9080
             weight: 20
   EOF

2. 通过 mesh 重复发送请求，并观察由哪个 reviews 版本响应：

   kubectl exec "$(kubectl get pod -l app=ratings -n bookinfo -o jsonpath='{.items[0].metadata.name}')" \
     -c ratings -n bookinfo \
     -- bash -lc '\
        for i in {0..19}; do \
          curl -sS productpage:9080/productpage | grep -om1 "reviews-v[12]"; \
        done'

   响应结果应大致符合配置的流量分配比例。采用 80/20 权重时，二十个请求中大约有十六个会到达 reviews-v1，其余请求会到达 reviews-v2。负载均衡会导致每次运行的结果存在一定差异，但经过多次尝试后，该比例会趋近于配置的权重。

#验证 L7 授权策略

确认更新后 L7 授权决策仍然有效。以下示例使用名为 productpage-waypoint 的 AuthorizationPolicy，该策略仅允许 curl 命名空间中 curl 服务账户发出的 GET 请求访问 productpage 服务。

前提条件

• curl 客户端运行在 curl 命名空间中，并且该命名空间带有 istio-discovery=enabled 和 istio.io/dataplane-mode=ambient 标签。有关部署步骤，请参阅 ambient 模式下的第 7 层功能。

操作步骤

1. 可选：如果尚不存在，请创建 AuthorizationPolicy 资源：

   cat <<EOF | kubectl apply -f -
   apiVersion: security.istio.io/v1
   kind: AuthorizationPolicy
   metadata:
     name: productpage-waypoint
     namespace: bookinfo
   spec:
     targetRefs:
       - kind: Service
         group: ""
         name: productpage
     action: ALLOW
     rules:
       - from:
           - source:
               principals:
                 - cluster.local/ns/curl/sa/curl
         to:
           - operation:
               methods: ["GET"]
   EOF
   1. principal 必须与客户端工作负载的命名空间和服务账户匹配。此示例使用 curl 命名空间中的 curl 服务账户。

2. 确认允许的客户端发出的 GET 请求成功，并收到 HTTP 200 响应：

   kubectl -n curl exec deploy/curl -- sh -c '\
     curl -s -o /dev/null -w "HTTP %{http_code}\n" \
       -X GET \
       http://productpage.bookinfo.svc.cluster.local:9080/productpage'

   预期输出

   HTTP 200

3. 确认允许列表之外的工作负载（例如 ratings pod）仍被拒绝：

   kubectl exec "$(kubectl get pod -l app=ratings -n bookinfo \
     -o jsonpath='{.items[0].metadata.name}')" \
     -c ratings -n bookinfo \
     -- curl -X GET -sS productpage:9080/productpage

   预期输出

   RBAC: access denied

   拒绝结果确认更新后的 waypoint 代理会继续强制执行 L7 授权规则：ratings 服务账户未列在策略中，而 curl 客户端同时匹配 principal 和 GET 操作。

清理验证资源

如果你创建路由和授权资源只是为了执行此验证，请在完成后将其删除：

kubectl delete -n bookinfo httproute reviews --ignore-not-found
kubectl delete -n bookinfo authorizationpolicy productpage-waypoint --ignore-not-found