Chapter 3. Updating OpenShift Service Mesh in ambient mode

Procedure

1. After the new Istio control plane revision is ready, verify waypoint proxy pods are running by entering the following command:

   $ oc get pods -n bookinfo -l gateway.networking.k8s.io/gateway-name=waypoint

   You should see an output similar to the following example:

   NAME                       READY   STATUS    RESTARTS   AGE
   waypoint-5d9c8b7f9-abc12   1/1     Running   0          5m

2. Confirm that you updated the waypoint proxy to the latest version by running the following command:

   $ istioctl proxy-status | grep waypoint

   You should see an output similar to the following example:

   waypoint-5d9c8b7f9-abc12.bookinfo     SYNCED     SYNCED     SYNCED     SYNCED     istiod-1-27-3-7b9f8c5d6-xyz78.istio-system     1.28.5

   You can run the command to query the Istio control plane and verify that the waypoint proxy connects to the new revision. The output lists the revision-specific istiod pod (for example, istiod-1-27-3) and shows that the waypoint proxy is running the updated version, 1.28.5. The revision-specific name in the ISTIOD column confirms that the waypoint proxy has successfully migrated to the new control plane revision.

Procedure

1. Optional: Create the HTTPRoute resource if it does not already exist by running the following command:

   $ oc apply -f - <<EOF
   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: 90
       - name: reviews-v2
         port: 9080
         weight: 10
   EOF

2. Verify that the HTTPRoute rules distribute traffic correctly by running the following command:

   for i in {1..10}; do
     kubectl exec "$(
       kubectl get pod \
         -l app=productpage \
         -n bookinfo \
         -o jsonpath='{.items[0].metadata.name}'
     )" \
     -c istio-proxy \
     -n bookinfo -- \
     curl -s http://reviews:9080/reviews/0 | grep -o "reviews-v[0-9]"
   done

   The output should reflect the traffic distribution defined in your HTTPRoute. For example, with a 90/10 weight split between reviews-v1 and reviews-v2, you should observe about nine requests routed to reviews-v1 and one request routed to reviews-v2. The exact ratio can vary slightly due to load balancing behavior, but should closely match the configured weights over many test runs.

Procedure

1. Optional: Create the AuthorizationPolicy resource if it does not already exist by running the following command:

   $ oc apply -f - <<EOF
   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/default/sa/curl
       to:
       - operation:
           methods: ["GET"]
   EOF

2. Verify that services not included in the allow list, such as the ratings service, are denied access by running the following command:

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

   The request will be denied because the ratings service is not included in the authorization policy’s allow list. Only the curl pod by using the default/curl service account can access productpage service.

3. Verify that the curl service can access the productpage service with GET requests by running the following command:

   oc exec "$(
     kubectl get pod \
       -l app=curl \
       -n default \
       -o jsonpath='{.items[0].metadata.name}'
   )" \
   -c curl \
   -n default -- \
   curl -sS http://productpage.bookinfo:9080/productpage | grep -o "<title>.*</title>"

   The request will succeed because the curl service meets the authorization policy rules. It uses the cluster.local/ns/default/sa/curl principal and performs a GET operation, both allowed by the policy. The successful response containing the page title confirms that the waypoint proxy correctly enforces L7 authorization rules and allows valid traffic.

Procedure

1. Verify the namespace with any of the waypoint labels by running the following command:

   $ oc get ns bookinfo --show-labels | grep waypoint

2. If there is no namespace with the label or if the label is wrong, re-apply the labels:

   1. Apply the istio.io/use-waypoint-namespace by running the following command:

      $ oc label ns bookinfo istio.io/use-waypoint-namespace=foo --overwrite

   2. Apply the istio.io/use-waypoint by running the following command:

      $ oc label ns bookinfo istio.io/use-waypoint=waypoint-foo --overwrite