更新 waypoint proxies

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

由于 waypoint 始终跟随当前活动的控制平面，请将其保持在控制平面一个次版本范围内（相同版本或 n-1）。这与 Istio 支持策略一致，该策略要求数据平面组件绝不能领先于控制平面；同样的规则也适用于 Istio CNI plugin 和 ZTunnel。RevisionBased 策略在 ambient mode 中不可用——有关原因，请参见在 ambient mode 下更新 Alauda Service Mesh。

前提条件

你已按照更新 ambient mode 组件的说明更新了 Istio 控制平面。
Bookinfo 应用已在 ambient mode 下部署；请参见在 ambient mode 下部署 Bookinfo 应用。
在 bookinfo namespace 中存在一个名为 waypoint 的 waypoint proxy；请参见 Waypoint proxies。

验证 waypoint proxy 版本

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

istioctl proxy-status | grep waypoint

示例输出

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

输出会列出 waypoint pod、它所连接的 istiod pod、其运行的 proxy 版本，以及 proxy 订阅的 xDS 配置类型。订阅列表有内容表示 waypoint 正在从控制平面接收配置，并且 VERSION 列现在应显示更新后的发行版本。

验证 L7 流量路由

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

前提条件

已创建 bookinfo-versions 服务（它们是 ambient mode 下 Bookinfo 部署的一部分）。
一个 HTTPRoute 资源将 reviews 流量进行拆分。

操作步骤

可选：如果尚未创建，请创建将 reviews 流量以 80/20 分配给 reviews-v1 和 reviews-v2 的 HTTPRoute 资源：

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

通过 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 权重下，20 次请求中大约有 16 次会到达 reviews-v1，其余请求到达 reviews-v2。负载均衡会在每次运行时引入一定波动，但随着重复尝试，比例会收敛到配置的权重。

验证 L7 授权策略

确认 L7 授权决策在更新后仍然有效。以下示例使用名为 productpage-waypoint 的 AuthorizationPolicy，它仅允许来自 curl namespace 中 curl service account 的 GET 请求到达 productpage 服务。

前提条件

在 curl namespace 中运行着一个 curl 客户端，并且该 namespace 已打上 istio-discovery=enabled 和 istio.io/dataplane-mode=ambient 标签。部署步骤请参见 ambient mode 下的 Layer 7 功能。

操作步骤

可选：如果尚未创建，请创建 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

principal 必须与客户端工作负载的 namespace 和 service account 匹配。此示例使用 curl namespace 中的 curl service account。

确认来自允许客户端的 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

确认允许列表之外的工作负载，例如 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 proxy 仍在强制执行 L7 授权规则：ratings service account 未列入策略，而 curl 客户端同时匹配 principal 和 GET 操作。

清理验证资源

如果你仅为本次验证创建了路由和授权资源，请在完成后将其删除：

kubectl delete -n bookinfo httproute reviews
kubectl delete -n bookinfo authorizationpolicy productpage-waypoint

#更新 waypoint proxies

#目录

#验证 waypoint proxy 版本

#验证 L7 流量路由

#验证 L7 授权策略

更新 waypoint proxies

目录

验证 waypoint proxy 版本

验证 L7 流量路由

验证 L7 授权策略