diff --git a/docs/serving/debugging-application-issues.md b/docs/serving/debugging-application-issues.md index df8c53616e..0faf3cfa98 100644 --- a/docs/serving/debugging-application-issues.md +++ b/docs/serving/debugging-application-issues.md @@ -43,22 +43,21 @@ kubectl get route --output yaml The `conditions` in `status` provide the reason if there is any failure. For details, see Knative -[Error Conditions and Reporting](https://github.com/knative/serving/blob/master/docs/spec/errors.md)(currently -some of them are not implemented yet). +[Error Conditions and Reporting](https://github.com/knative/docs/blob/master/docs/serving/spec/knative-api-specification-1.0.md#error-signalling). -### Check ClusterIngress/Istio routing +### Check Ingress/Istio routing -Run the following command to list all the cluster ingress, with their labels +To list all Ingress resources and their corresponding labels, run the following command: ```shell -kubectl get clusteringress -o=custom-columns='NAME:.metadata.name,LABELS:.metadata.labels' -NAME LABELS -helloworld-go-h5kd4 map[serving.knative.dev/route:helloworld-go serving.knative.dev/routeNamespace:default] +kubectl get ingresses.networking.internal.knative.dev -o=custom-columns='NAME:.metadata.name,LABELS:.metadata.labels' +NAME LABELS +helloworld-go map[serving.knative.dev/route:helloworld-go serving.knative.dev/routeNamespace:default serving.knative.dev/service:helloworld-go] ``` The labels `serving.knative.dev/route` and `serving.knative.dev/routeNamespace` -will tell exactly which Route a ClusterIngress is a child resource of. Find the -one corresponding to your Route. If a ClusterIngress does not exist, the route +indicate the Route in which the Ingress resource resides. Your Route and +Ingress should be listed. If your Ingress does not exist, the route controller believes that the Revisions targeted by your Route/Service isn't ready. Please proceed to later sections to diagnose Revision readiness status. @@ -66,23 +65,23 @@ Otherwise, run the following command to look at the ClusterIngress created for your Route ``` -kubectl get clusteringress --output yaml +kubectl get ingresses.networking.internal.knative.dev --output yaml ``` -particularly, look at the `status:` section. If the ClusterIngress is working +particularly, look at the `status:` section. If the Ingress is working correctly, we should see the condition with `type=Ready` to have `status=True`. Otherwise, there will be error messages. -Now, if ClusterIngress shows status Ready, there must be a corresponding +Now, if Ingress shows status `Ready`, there must be a corresponding VirtualService. Run the following command: ```shell -kubectl get virtualservice -n knative-serving --output yaml +kubectl get virtualservice -n --output yaml ``` -the network configuration in VirtualService must match that of ClusterIngress +the network configuration in VirtualService must match that of Ingress and Route. VirtualService currently doesn't expose a Status field, so if one -exists and have matching configurations with ClusterIngress and Route, you may +exists and have matching configurations with Ingress and Route, you may want to wait a little bit for those settings to propagate. If you are familar with Istio and `istioctl`, you may try using `istioctl` to diff --git a/docs/serving/samples/knative-routing-go/README.md b/docs/serving/samples/knative-routing-go/README.md index 4091261408..4152ebbf60 100644 --- a/docs/serving/samples/knative-routing-go/README.md +++ b/docs/serving/samples/knative-routing-go/README.md @@ -210,7 +210,7 @@ kubectl get VirtualService entry-route --output yaml 3. Send a request to the `Search` service and the `Login` service by using corresponding URIs. You should get the same results as directly accessing - these services. \_ Get the ingress IP: + these services. Get the ingress IP: ```shell INGRESSGATEWAY=istio-ingressgateway