Demo of Application Routing of Knative Serving

This paper describes a sample application and how to visually demonstrate the Knative serving routing features with it.

Sample Application

The sample app consists of backend and frontend service.

Backend service

The backend service is a simple Golang HTTP handler program that returns a JSON response with color and version information upon request, as shown below,

curl demo-backend.knative-demo.apps.ocp.io.cpak/getcolor
{"Color":"blue","Version":"v1.0"}

Frontend service

The frontend is a single page application developed with Vuejs and Vuetify. It has an express server to serve the REST API request from the web browser and therefore avoid any CORS issue. It calls the Backend service in turn to get the color and version. Vuejs then display them with some of the Vuetify widgets. A sample screen capture is shown below.

There are 10 boxes. For each box, a REST API call is triggered to get the color and version then they are displayed on the webpage.

The applications are built as a Docker image and pushed into the target docker registry. In my case, it is the integrated Docker registry in the OpenShift 3.11.

Environment

I have the IBM cloud pak for the application installed on top of OCP 3.11 where the Kabanero is included.

Deploy Backend as a Knative Service

Let’s deploy the backend service first with the good old friend kubectl apply -f The yaml file content is shown below,

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: demo-backend
  namespace: knative-demo
spec:
  template:
    metadata:
      name: demo-backend-v1
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
      - image: docker-registry.default.svc:5000/knative-demo/knative-demo-backend
        env:
        - name: APP_PORT
          value: "8080"
        - name: APP_COLOR
          value: blue
        - name: APP_VERSION
          value: "v1.0"

Though we are using Knative API v1alpha1, the syntax is stable for the v1 version. The deprecated syntax is not used. Notice we give a name of demo-backend-v1 which will be used for this revision’s name.

For the container image, we use the internal OCP registry. We have to be always cautious when using pure numbers in the YAML. Here the port number 8080 has to be quoted otherwise Knative just failed to create all the required objects, silently.

Check the Knative route,

kubectl get rt
NAME            URL                                                 READY     REASON
demo-backend    http://demo-backend.knative-demo.apps.ocp.io.cpak    True

The URL is the endpoint to access the backend, test it out.

curl http://demo-backend.knative-demo.apps.ocp.io.cpak/getcolor
{"Color":"blue","Version":"v1.0"}

Deploy Frontend as a Knative Service

Similarly, create the following frontend service.

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: demo-frontend
  namespace: knative-demo
spec:
  template:
    spec:
      containers:
      - image: docker-registry.default.svc:5000/knative-demo/knative-demo-frontend
        env:
        - name: APP_PORT
          value: "8080"
        - name: APP_REST_SERVER
          value: http://demo-backend.knative-demo.apps.ocp.io.cpak

We refer to the backend server with the Knative route’s name created in the above step.

Demo Case 1. Canary Deployment

Now let's have some new “feature”, green color and version 1.1. We use the same Knative service as what we have just defined, but with a different revision name, demo-backend-v2.

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: demo-backend
  namespace: knative-demo
spec:
  template:
    metadata:
      name: demo-backend-v2
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
      - image: docker-registry.default.svc:5000/knative-demo/knative-demo-backend
        env:
        - name: APP_PORT
          value: "8080"
        - name: APP_COLOR
          value: green
        - name: APP_VERSION
          value: "v1.1"
  traffic:
  - tag: current
    revisionName: demo-backend-v1
    percent: 90
  - tag: candidate
    revisionName: demo-backend-v2
    percent: 10

Though the docker image is the same, the environment variable as the pod’s configuration is changed. Therefore a new Knative revision will be created and it is named as demo-backend-v2 as what we have defined,

kubectl get rev
NAME                  SERVICE NAME          GENERATION   READY     REASON
demo-backend-v1       demo-backend-v1       1            True
demo-backend-v2       demo-backend-v2       2            True
demo-frontend-9kknc   demo-frontend-9kknc   1            True

In the traffic block, we define a canary deployment to let the new version has 10% of the traffic. Test it out from the browser by going to the URL of the frontend Knative route http://demo-frontend.knative-demo.apps.ocp.io.cpak

Demo Case 2. Blue and Green Deployment

Now let's update the service of revision 2, specifying all the traffic 100% goes to this new feature.

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: demo-backend
  namespace: knative-demo
spec:
  template:
    metadata:
      name: demo-backend-v2
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
      - image: docker-registry.default.svc:5000/knative-demo/knative-demo-backend
        env:
        - name: APP_PORT
          value: "8080"
        - name: APP_COLOR
          value: green
        - name: APP_VERSION
          value: "v1.1"
  traffic:
  - tag: current
    revisionName: demo-backend-v1
    percent: 0
  - tag: candidate
    revisionName: demo-backend-v2
    percent: 100

Now test it from UI

The source code and the Dockerfile is published in https://github.com/zhiminwen/kabanero-demo