Chapter 4. Debugging Serverless applications

Procedure

1. List all pods for your deployment by running the following command:

   $ oc get pods

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                                                      READY     STATUS             RESTARTS   AGE
   configuration-example-00001-deployment-659747ff99-9bvr4   2/2       Running            0          3h
   configuration-example-00002-deployment-5f475b7849-gxcht   1/2       CrashLoopBackOff   2          36s

   Copy to Clipboard Toggle word wrap

   In the output, you can see all pods with selected data about their status.

2. View the detailed information on the status of a pod by running the following command:

   Example output

   $ oc get pod <pod_name> --output yaml

   Copy to Clipboard Toggle word wrap

   In the output, the conditions and containerStatuses fields might be particularly useful for debugging.

Procedure

1. If you configure your route with a Configuration object, get the name of the Revision object created for your deployment by running the following command:

   $ oc get configuration <configuration_name> --output jsonpath="{.status.latestCreatedRevisionName}"

   Copy to Clipboard Toggle word wrap

   You can find the configuration name in the Route.yaml file, which specifies routing settings by defining an OpenShift Route resource.

   If you configure your route with revision directly, look up the revision name in the Route.yaml file.

2. Query for the status of the revision by running the following command:

   $ oc get revision <revision-name> --output yaml

   Copy to Clipboard Toggle word wrap

   A ready revision should have the reason: ServiceReady, status: "True", and type: Ready conditions in its status. If these conditions are present, you might want to check pod status or Istio routing. Otherwise, the resource status contains the error message.

Procedure

1. 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'

   Copy to Clipboard Toggle word wrap

   Example output

   NAME            LABELS
   helloworld-go   map[serving.knative.dev/route:helloworld-go serving.knative.dev/routeNamespace:default serving.knative.dev/service:helloworld-go]

   Copy to Clipboard Toggle word wrap

   In this output, labels serving.knative.dev/route and serving.knative.dev/routeNamespace indicate the Route where the Ingress resource resides. Your Route and Ingress should be listed.

   If your Ingress does not exist, the route controller assumes that the Revision objects targeted by your Route or Service object are not ready. Proceed with other debugging procedures to diagnose Revision readiness status.

2. If your Ingress is listed, examine the ClusterIngress object created for your route by running the following command:

   $ oc get ingresses.networking.internal.knative.dev <ingress_name> --output yaml

   Copy to Clipboard Toggle word wrap

   In the status section of the output, if the condition with type=Ready has the status of True, then Ingress is working correctly. Otherwise, the output contains error messages.

3. If Ingress has the status of Ready, then there is a corresponding VirtualService object. Verify the configuration of the VirtualService object by running the following command:

   $ oc get virtualservice -l networking.internal.knative.dev/ingress=<ingress_name> -n <ingress_namespace> --output yaml

   Copy to Clipboard Toggle word wrap

   The network configuration in the VirtualService object must match that of the Ingress and Route objects. Because the VirtualService object does not expose a Status field, you might need to wait for its settings to propagate.