knative configuration on openshift

gistfile1.txt

https://redhat-developer-demos.github.io/knative-tutorial/knative-tutorial-basics/0.7.x/04-scaling.html#scaling-scale-to-zero
https://blog.openshift.com/knative-serving-your-serverless-services/?extIdCarryOver=true&sc_cid=701f2000001OH7TAAW
https://codelabs.developers.google.com/codelabs/knative-intro/index.html?index=..%2F..index#13
https://github.com/nikhilbarthwal/knative
https://learning.oreilly.com/library/view/knative-cookbook/9781492061182/ch07.html


knative deployment 

a) we will deploy our first application on the Knative framework 
b) sample web application written with Node.js
c) gcr.io/knative-samples/helloworld-nodejs
d) create hello-world.yaml , This Knative service object defines values such as the namespace to deploy this service in, the Docker image to use for the container
e) code is getting copied to following git repo https://github.com/satishchennu1/knativeserverlessoc.git
f) kubectl apply -f hello-world.yaml
g) The previous command will create multiple objects, including the Knative service, configuration, revision, route, and Kubernetes Deployment. We can verify the application by listing the newly created objects as in the following commands:
h) run below commands 
  $ oc get ksvc
  $ kubectl get configuration
  $ oc get configuration
  $ oc get rt
  $ oc get deployments
  [root@ip-10-201-26-228 knativepetclinic]# oc get rt
NAME           URL                                                                   READY   REASON
petclinicapp   http://petclinicapp.knativepetclinic.apps.ocppilot.ocpcontainer.com   True

 i) export EXTERNAL_IP=$(kubectl get svc istio-ingressgateway --namespace istio-system --output 'jsonpath={.status.loadBalancer.ingress[0].ip}')
 g) kubectl get route helloworld-nodejs
 h) Now we can invoke our application using the EXTERNAL_IP and URL values that we noted in the earlier steps. Let's make a curl   request with the following command:
 i) there are below  resources get created 
 
 j) There are four resource types in the Knative Serving component:

      Configuration: Defines the desired state of the application
      Revision: Read-only snapshots that track the changes in configurations
      Route: Provides traffic routing to revisions
      Service: Top-level container for routes and configurations
      
     
  k) https://learning.oreilly.com/library/view/serverless-architectures-with/9781838983277/C12607_06_ePub_Final_RK.xhtml
      
 l) The configuration is used to define the desired state of the application. This will define the container image used for the application and any other configuration parameters that are required. A new Revision will be created each time a Configuration is updated. Revision refers to a snapshot of the code and the Configuration. This is used to record the history of Configuration changes. A Route is used to define the traffic routing policy of the application and provides an HTTP endpoint for the application. By default, the Route will send traffic to the latest Revision created by the Configuration. The Route can also be configured for more advanced scenarios, including sending traffic to a specific Revision or splitting traffic to different revisions based on defined percentages. Service objects are used to manage the whole life cycle of the application. While deploying a new application, it is required to create Configuration and Route objects manually, but the Service can be used to simplify this by creating and managing Configuration and Route objects automatically.
 
 CANARY DEPLOYMENT WITH KNATIVE
 
a)  First, we will deploy an initial version (version 1) of an application and route 100% traffic to that version. Next, we will       create version 2 of the application and route 50% of traffic to version 1 and the remaining 50% to version 2. Finally, we will     update the routes to send 100% of traffic to version
b) create file called canary-deployment.yaml
c) kubectl apply -f canary-deployment.yaml
d) kubectl get configurations canary-deployment -o=jsonpath='{.status.latestCreatedRevisionName}'
e) The next step is to create the route object. Let's create a file named canary-deployment-route.yaml with the following content
f) please remember to replace canary-deployment-xgvl8 with the revision name that you noted in the previous step
g) create this file in github canary-deployment-route.yaml
h) kubectl apply -f canary-deployment-route.yaml
g) curl -H "Host: canary-deployment.default.example.com" "http://${EXTERNAL_IP}"
h) we can deploy version 2 of the application. Update canary-deployment.yaml with the following content. In version 2 of the application, we only need to update the value of the TARGET environment variable from This is the first version - v1 to This is the second version - v2:
i) kubectl apply -f canary-deployment.yaml
j) kubectl get revisions
k) kubectl apply -f canary-deployment-route.yaml
l) Now we can invoke the application multiple times to observe how traffic splits between two revisions:
$ curl -H "Host: canary-deployment.default.example.com" "http://${EXTERNAL_IP}"
m) kubectl apply -f canary-deployment-route.yaml
n) curl -H "Host: blue-green-deployment.default.example.com" "http://${EXTERNAL_IP}"


AUTOSCALING WITH KNATIVE

a) kubectl apply -f autoscale-app.yaml
b) curl -Lo hey https://storage.googleapis.com/hey-release/hey_linux_amd64
c) adding it in path . 
    /usr/local/bin/ path:
    $ chmod +x hey
    $ sudo mv hey /usr/local/bin/
d) hey -z 60s -c 50 \
   -host "autoscale-app.default.example.com" \
   "http://${EXTERNAL_IP?}?sleep=1000"
e) kubectl get pods --watch