Name	Name	Last commit message	Last commit date
parent directory ..
images	images
README.adoc	README.adoc

Knative Serving Configuration

This lab focuses on the configuration of Knative Serving for OpenLibertyApplication instances. Before proceeding with this lab, it is advisable to complete the AutoscalingLab.

Knative Serving

Knative Serving simplifies the deployment of serverless applications by abstracting away infrastructure complexities. With serverless computing, users can deploy their applications without the burden of managing the underlying servers. The platform dynamically allocates machine resources as per demand, alleviating users from the worries of capacity planning, configuration, maintenance, and container scaling.

One of the key benefits of Knative Serving is its automatic scaling feature, which efficiently adjusts resource allocation based on workload demands. It also provides robust routing and network programming capabilities, enabling intelligent traffic distribution. Additionally, it provides support for point-in-time snapshots, allowing users to capture and manage previous versions of deployed code and configurations. This provides a safety net for seamless rollbacks and helps testing and version control for better application stability.

Getting Started

Using educational cluster? If you need access to the cluster, please contact Lab Administrators to have credentials assigned to you.
Using your own cluster? Please follow Cluster Setup guide before proceeding.

Deployment Options

Choose one of two methods to deploy OpenLibertyApplication instance on your cluster.

Method A: Deployment through oc client

Environment setup: If already setup, you can close this section

Make sure you have oc client and jq installed in your system. oc client is used to communicate with RedHat OpenShift cluster and jq is a JSON processing tool, which helps formatting and extracting data.

Log into a RedHat OpenShift cluster.

oc login --server=https://<cluster-api-ip-address>:6443 --username=<username> --password=<password>

For example:

oc login --server=https://9.123.456.789:6443 --username=testuser --password=PasswordExample123

If you do not have access to a cluster, please contact Lab Administrators to have credentials assigned to you.

To set your current namespace to be the namespace you will be working in, run the following commands:

ℹ️
Replace <your-namespace> with the namespace provided to you for the lab.
```
export NAMESPACE=<your-namespace>
oc project $NAMESPACE
```

Start here after Environment Setup

Ensure Red Hat OpenShift Serverless operator is installed on the cluster and Knative Serving instance is Ready.

oc get subscription serverless-operator -n openshift-serverless
oc get KnativeServing knative-serving -n knative-serving

You will get similar to the following if the operator is installed and the instance is Ready:

NAME                  PACKAGE               SOURCE             CHANNEL
serverless-operator   serverless-operator   redhat-operators   stable
NAME              VERSION   READY   REASON
knative-serving   1.10       True

If you do not see any of the two outputs correctly, contact Lab Administrators.

Create a YAML file called knative-enabled-sample.yaml with the following content:

apiVersion: apps.openliberty.io/v1
kind: OpenLibertyApplication
metadata:
  name: knative-enabled-sample
spec:
  applicationImage: >-
    icr.io/appcafe/open-liberty/samples/getting-started@sha256:e22dd56a05e44618a10d275d3ff07a38eb364c0f04f86ffe9618d83dd5467860
  replicas: 1
  createKnativeService: true
  expose: true
  service:
    port: 9080
    type: ClusterIP

Create the OpenLibertyApplication instance using the command:
```
oc apply -f knative-enabled-sample.yaml
```
The operator will create a Knative Service resource which manages the entire life cycle of a workload.

Check the status of the OpenLibertyApplication instance by running:

oc get OpenLibertyApplication knative-enabled-sample -n $NAMESPACE -ojson | jq '.status.conditions'

It will print output similar to the following:

[
  {
    "lastTransitionTime": "2023-10-25T18:38:23Z",
    "status": "True",
    "type": "Reconciled"
  },
  {
    "lastTransitionTime": "2023-10-25T18:38:23Z",
    "message": "Knative service is ready.",
    "status": "True",
    "type": "ResourcesReady"
  },
  {
    "lastTransitionTime": "2023-10-25T18:38:23Z",
    "message": "Application is reconciled and resources are ready.",
    "status": "True",
    "type": "Ready"
  }
]

As in the example output, status conditions field shows that Knative service is ready instead of reporting the number of application replicas. If any type under status conditions section reports that the Application is not ready even after a considerate amount of time, check the application’s log, by running oc logs deployment/knative-enabled-sample-00001-deployment --container user-container.

Check all managed resources and their statuses. Run the command:

oc get all -l app.kubernetes.io/part-of=knative-enabled-sample -n $NAMESPACE

The output will be similar to the following:

NAME                                                           READY   STATUS    RESTARTS   AGE
pod/knative-enabled-sample-00001-deployment-57b9bd6bf9-5xx7v   2/2     Running   0          60s

NAME                                           TYPE           CLUSTER-IP       EXTERNAL-IP                                                  PORT(S)                                              AGE
service/knative-enabled-sample                 ExternalName   <none>           kourier-internal.knative-serving-ingress.svc.cluster.local   80/TCP                                               14s
service/knative-enabled-sample-00001           ClusterIP      172.30.79.216    <none>                                                       80/TCP,443/TCP                                       61s
service/knative-enabled-sample-00001-private   ClusterIP      172.30.169.227   <none>                                                       80/TCP,443/TCP,9090/TCP,9091/TCP,8022/TCP,8012/TCP   61s

NAME                                                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/knative-enabled-sample-00001-deployment   1/1     1            1           61s

NAME                                                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/knative-enabled-sample-00001-deployment-57b9bd6bf9   1         1         1       61s

NAME                                               URL                                                                                         READY   REASON
route.serving.knative.dev/knative-enabled-sample   https://knative-enabled-sample-user0-namespace.apps.was-education-cluster.cp.fyre.ibm.com   True

NAME                                                        CONFIG NAME              K8S SERVICE NAME   GENERATION   READY   REASON   ACTUAL REPLICAS   DESIRED REPLICAS
revision.serving.knative.dev/knative-enabled-sample-00001   knative-enabled-sample                      1            True             1                 1

NAME                                                 URL                                                                                         LATESTCREATED                  LATESTREADY                    READY   REASON
service.serving.knative.dev/knative-enabled-sample   https://knative-enabled-sample-user0-namespace.apps.was-education-cluster.cp.fyre.ibm.com   knative-enabled-sample-00001   knative-enabled-sample-00001   True

NAME                                                       LATESTCREATED                  LATESTREADY                    READY   REASON
configuration.serving.knative.dev/knative-enabled-sample   knative-enabled-sample-00001   knative-enabled-sample-00001   True

It shows a Deployment and its associated Pods, Services, Route and Knative resources created by the operator. Two containers are running for the Pod: one for Liberty application and one for Queue proxy, which is a sidecar container serving as a reverse proxy in front of the Liberty application.

Knative service autoscales the workload and when the workload is idle, so it may scale the pod to zero. Then the pod will be removed in the output. When traffic is observed (i.e. route is accessed), the pod will be scaled back up.

Get the URL allocated by route.serving.knative.dev/knative-enabled-sample. For example, the route’s URL will be similar to: https://knative-enabled-sample-user0-namespace.apps.was-education-cluster.cp.fyre.ibm.com.
```
oc get route.serving.knative.dev/knative-enabled-sample -n $NAMESPACE
```
```
NAME                     URL                                                                                         READY   REASON
knative-enabled-sample   https://knative-enabled-sample-user0-namespace.apps.was-education-cluster.cp.fyre.ibm.com   True
```
Access the page, and you will see the sample app page on Open Liberty 23.0.0.3. You may experience some delays if Knative scaled the pod to zero to recreate and rerun the service.
Let’s take a closer look at the Knative service instance. Run below to get the revision details:
```
oc get rev -n $NAMESPACE
```
```
NAME                           CONFIG NAME              K8S SERVICE NAME   GENERATION   READY   REASON   ACTUAL REPLICAS   DESIRED REPLICAS
knative-enabled-sample-00001   knative-enabled-sample                      1            True             1                 1
```
There is only 1 revision available. This captures point-in-time snapshot of the Knative service. The actual and desired replicas in the output may be 0’s because of Knative service’s scale-to-zero feature when the pod is idle.

Edit OpenLibertyApplication in knative-enabled-sample.yaml to update application image to newer image. Under spec field, edit applicationImage field:

  applicationImage: >-
    icr.io/appcafe/open-liberty/samples/getting-started@sha256:f7c7da21059eef8734cf0d43a417609aecf68bfe89d0be8e61012fade5877a01

To apply the changes, run:

oc apply -f knative-enabled-sample.yaml

Wait until the application pod is ready. You can check if the pod is ready through running the following:

oc get pods -l app.kubernetes.io/part-of=knative-enabled-sample -n $NAMESPACE

Access the sample app on browser again to see the change. You will see that Open Liberty’s version is updated from 23.0.0.3 to 23.0.0.8. You may have to wait for a few minutes to see the updated version.

Run the following command to see the revisions:

oc get rev -n $NAMESPACE

NAME                           CONFIG NAME              K8S SERVICE NAME   GENERATION   READY   REASON   ACTUAL REPLICAS   DESIRED REPLICAS
knative-enabled-sample-00001   knative-enabled-sample                      1            True             0                 0
knative-enabled-sample-00002   knative-enabled-sample                      2            True             1                 1

Now there are 2 revision outputs. Notice knative-enabled-sample-00002 instance’s generation value is 2 and 1 replica is running under that revision. The updated application image information is held in the second revision. This enables point-in-time snapshot of the Knative service, so that all revisions are stored and accessible when needed.

You can choose to rollback to the previous revision, distribute traffic to both revisions or rollout to the latest revision. Edit Knative service to use both revisions.
```
oc edit ksvc knative-enabled-sample -n $NAMESPACE
```
Replace traffic field under spec field with the following:
```
  traffic:
  - latestRevision: false
    percent: 50
    revisionName: knative-enabled-sample-00001
  - latestRevision: false
    percent: 50
    revisionName: knative-enabled-sample-00002
```
This will route 50% of traffic to the first revision and the other 50% to the latest revision.
Access the sample app on browser again and try refreshing the page several times. It will change the Open Liberty version from time to time. 50% of the traffic is assigned to the first revision (23.0.0.3) and the other to the second revision (23.0.0.8). This feature helps dividing traffic between different revisions as wanted.

Run the following command to check the revisions:

oc get rev -n $NAMESPACE

NAME                           CONFIG NAME              K8S SERVICE NAME   GENERATION   READY   REASON   ACTUAL REPLICAS   DESIRED REPLICAS
knative-enabled-sample-00001   knative-enabled-sample                      1            True             1                 1
knative-enabled-sample-00002   knative-enabled-sample                      2            True             1                 1

There is now a running replica under each revision, compared to when there was only 1 running replica for revision 2.

Edit OpenLibertyApplication in knative-enabled-sample.yaml to disable Knative configuration. Under spec field, locate createKnativeService field and change its value to false:
```
  createKnativeService: false
```
To apply the changes, run:
```
oc apply -f knative-enabled-sample.yaml
```

When you check the managed resources, you will see that Knative managed resources are deleted and new Deployment, Service and Route resources are created.

oc get all -l app.kubernetes.io/part-of=knative-enabled-sample -n $NAMESPACE

Then the output will be similar to the following:

NAME                                          READY   STATUS    RESTARTS   AGE
pod/knative-enabled-sample-74b65ddd9f-4z2rq   1/1     Running   0          10s

NAME                             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/knative-enabled-sample   ClusterIP   172.30.30.22   <none>        9080/TCP   26s

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/knative-enabled-sample   1/1     1            1           10s

NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/knative-enabled-sample-74b65ddd9f   1         1         1       10s

NAME                                              HOST/PORT                                                                      PATH   SERVICES                 PORT       TERMINATION   WILDCARD
route.route.openshift.io/knative-enabled-sample   knative-enabled-sample-test-namespace.apps.liberty-operator.cp.fyre.ibm.com          knative-enabled-sample   9080-tcp   reencrypt     None

Check the status of the OpenLibertyApplication instance by running:

oc get OpenLibertyApplication knative-enabled-sample -ojson -n $NAMESPACE | jq '.status.conditions'

Then the output will be similar to the following:

[
  {
    "lastTransitionTime": "2023-10-25T19:00:58Z",
    "status": "True",
    "type": "Reconciled"
  },
  {
    "lastTransitionTime": "2023-10-25T19:01:00Z",
    "message": "Deployment replicas ready: 1/1",
    "reason": "MinimumReplicasAvailable",
    "status": "True",
    "type": "ResourcesReady"
  },
  {
    "lastTransitionTime": "2023-10-25T19:01:00Z",
    "message": "Application is reconciled and resources are ready.",
    "status": "True",
    "type": "Ready"
  }
]

Now the OpenLibertyApplication instance is reporting that the application is hosted as a Deployment with static replica of 1.

Please delete the OpenLibertyApplication instance to clean up the resources.
```
oc delete OpenLibertyApplication/knative-enabled-sample
```

Method B: Deployment through OpenShift Web Console

Access your OpenShift web console. Web console’s URL starts with https://console-openshift-console.apps. If you do not have access to a cluster, please contact Lab Administrators to have credentials assigned to you.
Switch to the Developer perspective, if it is set to the Administrator perspective. Ensure you are on a project/namespace that you were assigned with for the lab.
Click +Add. Under Developer Catalog, click Operator Backed. This page shows the operator catalog on the cluster and enables you to deploy operator managed services.

Make sure you see Knative Serving in the list. If not, please contact Lab Administrator to have it installed.

Click OpenLibertyApplication and create an instance.

Select YAML view and replace the default configurations with the following content:

apiVersion: apps.openliberty.io/v1
kind: OpenLibertyApplication
metadata:
  name: knative-enabled-sample
spec:
  applicationImage: >-
    icr.io/appcafe/open-liberty/samples/getting-started@sha256:e22dd56a05e44618a10d275d3ff07a38eb364c0f04f86ffe9618d83dd5467860
  replicas: 1
  createKnativeService: true
  expose: true
  service:
    port: 9080
    type: ClusterIP

The operator will create a Knative Service resource which manages the entire life cycle of a workload.

You will see that an instance is created in Topology tab. If you would like to see the instance’s status at once, click 3 dots beside OLA knative-enabled-sample, then Edit OpenLibertyApplication.
Scroll to the botton of the YAML file. As in the example, status conditions field shows that Knative service is ready instead of reporting the number of application replicas.

If any type under status conditions section reports that the Application is not ready even after a considerate amount of time, check the application’s log through Topology page.
Go back to Topology page. Select KSVC knative-enabled-sample below the icon. You can select a resource that you would like to investigate.

It shows Knative service’s Pod, Revision and Route created by the operator. Two containers are running for the Pod: one for Liberty application and one for Queue proxy, which is a sidecar container serving as a reverse proxy in front of the Liberty application.

Knative service autoscales the workload and when the workload is idle, so it may scale the pod to zero. Then the pod will be removed in the list. When traffic is observed (i.e. route is accessed), the pod will be scaled back up.
You will see that there is only 1 revision available under Revisions section. This captures point-in-time snapshot of the Knative service. The actual and desired replicas in the output may be 0’s because of Knative service’s scale-to-zero feature when the pod is idle.
Get the URL allocated by Routes resource. You can locate it under Routes section on the right. For example: https://knative-enabled-sample-user0-namespace.apps.was-education-cluster.cp.fyre.ibm.com.

Access the page, and you will see the sample app page on Open Liberty 23.0.0.3. You may experience some delays if Knative scaled the pod to zero to recreate and rerun the service.
Go back to topology page. Update OpenLibertyApplication instance to use newer sample image. Click 3 dots beside OLA knative-enabled-sample, then Edit OpenLibertyApplication.

Under spec, edit applicationImage field:
```
  applicationImage: >-
    icr.io/appcafe/open-liberty/samples/getting-started@sha256:f7c7da21059eef8734cf0d43a417609aecf68bfe89d0be8e61012fade5877a01
```
When you go back to Topology page, you will now see 2 revisions in the list. Notice that the latest revision knative-enabled-sample-00002 has 100% written on the right side. This indicates 100% of the traffic is routed to knative-enabled-sample-00002. This enables point-in-time snapshot of the Knative service, so that all revisions are stored and accessible when needed.
Access the sample app on browser again to see the change. You will see that Open Liberty’s version is updated from 23.0.0.3 to 23.0.0.8. You may have to wait for a few minutes to see the updated version.
You can choose to rollback to the previous revision, distribute traffic to both revisions or rollout to the latest revision. Edit the traffic distribution to use both revisions. Click Set traffic distribution on the right side of Revisions and distribute traffic to both revisions by 50%.

Click Add Revision and select knative-enabled-sample-00001. Then assign 50 for both under Split section.
Access the sample app on browser again and try refreshing the page several times. It will change the Open Liberty version from time to time. 50% of the traffic is assigned to the first revision (23.0.0.3) and the other to the second revision (23.0.0.8). This feature helps dividing traffic between different revisions as wanted.

There is now a running replica under each revision, compared to when there was only 1 running replica for revision 2. You can also see 50% on the right side of each revision.
Edit the OpenLibertyApplication instance to disable Knative configuration. Under spec field, locate createKnativeService field and change its value to false:
```
  createKnativeService: false
```
The operator will delete Knative related resources and create new resources for the application.
Select Details tab and scroll down to see the status conditions.

Now the OpenLibertyApplication instance is reporting that the application is hosted as a Deployment with static replica of 1. When you check the managed resources in Topology section, you will no longer see Knative related resources. You will see that new Deployment, Service and Route resources are created.
Please delete the OpenLibertyApplication instance to clean up the resources.