#Updating waypoint proxies

Waypoint proxies are deployed through the Kubernetes Gateway API and are managed by the Istio control plane. When you update the control plane with the InPlace strategy, istiod rolls the waypoint deployments to the matching proxy version on its own — you do not update waypoints separately, and the application workloads they serve keep running throughout.

Because a waypoint always follows the active control plane, keep it within one minor version of the control plane (the same version or n-1). This matches the Istio support policy, which requires that data plane components never run ahead of the control plane; the same rule applies to the Istio CNI plugin and ZTunnel. The RevisionBased strategy is not available in ambient mode — see Updating Alauda Service Mesh in ambient mode for the reasoning.

Prerequisites

• You have updated the Istio control plane as described in Updating ambient mode components.
• The Bookinfo application is deployed in ambient mode; see Deploying the Bookinfo application in ambient mode.
• A waypoint proxy named waypoint exists in the bookinfo namespace; see Waypoint proxies.

#Verifying the waypoint proxy version

Confirm that the waypoint proxy reconnected to the updated control plane and runs the new proxy version:

istioctl proxy-status | grep waypoint

Example output

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

The output lists the waypoint pod, the istiod pod it is connected to, the proxy version it runs, and the xDS configuration types the proxy subscribes to. A populated subscription list confirms that the waypoint receives configuration from the control plane, and the VERSION column should now show the updated release.

#Verifying L7 traffic routing

After the waypoint proxies are updated, confirm that Layer 7 (L7) traffic management still behaves as configured. If you route traffic with HTTPRoute resources, check that the configured weights are still enforced.

Prerequisites

• The bookinfo-versions services are created (part of the Bookinfo deployment in ambient mode).
• An HTTPRoute resource splits the reviews traffic.

Procedure

1. Optional: If it does not exist yet, create the HTTPRoute resource that distributes reviews traffic 80/20 between reviews-v1 and reviews-v2:

   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. Send repeated requests through the mesh and observe which reviews version answers:

   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'

   The responses should approximate the configured split — with an 80/20 weighting, roughly sixteen of twenty requests reach reviews-v1 and the rest reach reviews-v2. Load balancing introduces some variance per run, but the ratio converges on the configured weights over repeated attempts.

#Verifying L7 authorization policies

Confirm that L7 authorization decisions survive the update. The following example uses an AuthorizationPolicy named productpage-waypoint that permits only GET requests issued by the curl service account in the curl namespace to reach the productpage service.

Prerequisites

• A curl client runs in the curl namespace, and the namespace carries the istio-discovery=enabled and istio.io/dataplane-mode=ambient labels. For the deployment steps, see Layer 7 features in ambient mode.

Procedure

1. Optional: If it does not exist yet, create the AuthorizationPolicy resource:

   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. The principal must match the namespace and service account of your client workload. This example uses the curl service account in the curl namespace.

2. Confirm that a GET request from the allowed client succeeds with an HTTP 200 response:

   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'

   Expected output

   HTTP 200

3. Confirm that a workload outside the allow list, such as the ratings pod, is still rejected:

   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

   Expected output

   RBAC: access denied

   The denial confirms that the updated waypoint proxy keeps enforcing the L7 authorization rules: the ratings service account is not listed in the policy, while the curl client matches both the principal and the GET operation.

Clean up the verification resources

If you created the routing and authorization resources only for this verification, remove them afterwards:

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