5.6. Checking Ingress and Istio routing
Sometimes, when Istio is used as an Ingress layer, the Ingress and Istio routing have issues. You can see the details on them by using the OpenShift CLI (oc).
Procedure
List all Ingress resources and their corresponding labels by running the following command:
$ oc get ingresses.networking.internal.knative.dev -o=custom-columns='NAME:.metadata.name,LABELS:.metadata.labels'Example output
NAME LABELS helloworld-go map[serving.knative.dev/route:helloworld-go serving.knative.dev/routeNamespace:default serving.knative.dev/service:helloworld-go]In this output, labels
serving.knative.dev/routeandserving.knative.dev/routeNamespaceindicate theRoutewhere the Ingress resource resides. YourRouteand Ingress should be listed.If your Ingress does not exist, the route controller assumes that the
Revisionobjects targeted by yourRouteorServiceobject are not ready. Proceed with other debugging procedures to diagnoseRevisionreadiness status.If your Ingress is listed, examine the
ClusterIngressobject created for your route by running the following command:$ oc get ingresses.networking.internal.knative.dev <ingress_name> --output yamlIn the status section of the output, if the condition with
type=Readyhas the status ofTrue, then Ingress is working correctly. Otherwise, the output contains error messages.If Ingress has the status of
Ready, then there is a correspondingVirtualServiceobject. Verify the configuration of theVirtualServiceobject by running the following command:$ oc get virtualservice -l networking.internal.knative.dev/ingress=<ingress_name> -n <ingress_namespace> --output yamlThe network configuration in the
VirtualServiceobject must match that of theIngressandRouteobjects. Because theVirtualServiceobject does not expose aStatusfield, you might need to wait for its settings to propagate.