Lab x: Knative Routes

[Starefossen]

Example of routes and builds

The example-module contains an example of a Node.js module with a dependency. It also, instead of a Service, has individual build yaml files and routes that you can edit.

List configurations and their age:

kubectl get configuration.serving.knative.dev

Optionally use kubectl describe configuration.serving.knative.dev/[name from list] to see status.

List the builds that have been generated:

kubectl get build.build.knative.dev

Builds sometimes fail, so let's hope your Knative vendor provides easy access to logs indexed for your build. In the meantime let's use kubectl and the step names from the build template (assuming the generated steps "creds-initializer" and "git-source" succeed).

SELECTOR="build-name=nodejs-runtime-example-module-00001"
kubectl logs -l $SELECTOR -c build-step-dockerfile
kubectl logs -l $SELECTOR -c build-step-export

Now Knative should look up the image digest and produce an exact revision spec:

kubectl get revision.serving.knative.dev

... and the generated deployment should have the image digest (which Serving looks up) set:

kubectl get deploy/nodejs-runtime-example-module-00001-deployment -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

... and it will bing up a pod. Logs for that are found using:

kubectl logs -l serving.knative.dev/configuration=nodejs-runtime-example-module -c user-container

If no pod is brought up you might want to look for error messages in kubectl get configuration.serving.knative.dev/nodejs-runtime-example-module -o yaml. You might also want to look for pull errors etc in the generated deployment kubectl describe deploy/nodejs-runtime-example-module-00001-deployment.

If a pod is running, create a route and use describe to see your public and local URL.

kubectl apply -f route-r00001.yaml
kubectl describe route.serving.knative.dev/nodejs-runtime-example-module

To test the route through the cluster's internal name.

kubectl run -i -t knative-test-client --image=gcr.io/cloud-builders/curl --restart=Never --rm -- \
  -H 'Host: nodejs-runtime-example-module.default.example.com' \
  -H 'Content-Type: text/plain' \
  -d 'Aguid this!' \
  --connect-timeout 3 --retry 10 -vSL -w '\n' \
  http://knative-ingressgateway.istio-system.svc.cluster.local/

If the function call worked your response from curl is the deterministic UUID.

Build your next revision and route traffic

The function source is fixed in this example, but its output can be altered using the SALT env. To Knative a new image digest and a new env value are both valid causes for generating a new Revison. Hence we trigger an almost identical build.

kubectl apply -f build-r00002.yaml

There's an example route which directs 50% of the traffic to each of the two revisions.

kubectl apply -f route-r00002.yaml

Now we can test repeated calls:

kubectl run -i -t knative-test-client --image=gcr.io/cloud-builders/curl --restart=Never --rm -- \
  -H 'Host: nodejs-runtime-example-module.default.example.com' \
  -H 'Content-Type: text/plain' \
  -d 'Aguid this!' \
  -s -w '\n' \
  http://knative-ingressgateway.istio-system.svc.cluster.local/?test=[1-20]

Source: https://github.com/triggermesh/nodejs-runtime