Knative serving
Tags: kubernetes, knative, serverless
Published: 2023-02-21 01:26:17

Knative Serving is a project that builds on Kubernetes to support deploying and serving serverless applications and functions. It defines a set of objects as Kubernetes Custom Resource Definitions (CRDs) that control how your serverless workload behaves on the cluster. Some of the features of Knative Serving are rapid deployment, autoscaling, routing and network programming.

##### Components
To install Knative Serving, you need to have a Kubernetes cluster with ingress installed (or you can use [Kourier](https://developers.redhat.com/blog/2020/06/30/kourier-a-lightweight-knative-serving-ingress) - a lightweight ingress). You can use different methods to install Knative Serving, such as using YAML files, using an operator, or using a web console (in-case of 3rd party provider). 

Knative Serving has six main components: controller, webhook, autoscaler, autoscaler-hpa, activator, and queue-proxy. 
- The controller is responsible for creating other resources based on user requests. 
- The webhook validates and mutates CRDs. 
- The autoscaler scales pods up and down based on traffic. 
- The autoscaler-hpa scales pods horizontally based on CPU utilization. 
- The activator buffers requests for cold pods and reports metrics to the autoscaler. 
- The queue-proxy runs as a sidecar in each pod and handles requests routing, health checking, and metrics reporting.

##### Installation
[Installation with yamls, ingress and other optional configurations](https://knative.dev/docs/install/yaml-install/serving/install-serving-with-yaml/)

##### Generated kubernetes resources
- **Services** The `service.serving.knative.dev` resource automatically manages the whole lifecycle of your workload. It controls the creation of other objects to ensure that your app has a route, a configuration, and a new revision for each update of the service. Service can be defined to always route traffic to the latest revision or to a pinned revision.
```yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hw-go
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          env:
            - name: TARGET
              value: "Go Sample v1"
```

```shell
> kn service describe hw-go
Name        hw-go
Namespace   default
Age         4m
URL         http://hw-go.default.cluster.local

Revisions:
  100%  @latest (hw-go-mnqr1-1) [1] (39s)
        Image:  gcr.io/knative-samples/helloworld-go (pinned to 946b7c)

Conditions:
  OK TYPE                   AGE REASON
  ++ Ready                  25s
  ++ ConfigurationsReady    26s
  ++ RoutesReady            25s
```
- **Routes** The `route.serving.knative.dev` resource maps a network endpoint to one or more revisions. You can use routes to split traffic between different revisions based on percentage or header-based routing. Routes are created automatically when you create a service, but you can also create them manually.
```yaml
# This YAML is to implement a 80-20 traffic split
apiVersion: serving.knative.dev/v1
kind: Route
metadata:
  name: hw-go-route
spec:
  traffic:
    - revisionName: hw-go-v1 # Revision name created by Configuration resource.
      percent: 20 
    - revisionName: hw-go-v2 # Revision name created by Configuration resource.
      percent: 80 
```


- **Configurations** The `configuration.serving.knative.dev` resource maintains the desired state for your deployment. It specifies how your app should be deployed using parameters such as container image, environment variables, resources requests and limits, etc. Configurations are also created automatically when you create a service, but you can also create them manually.
```yaml
apiVersion: serving.knative.dev/v1
kind: Configuration
metadata:
  name: hw-go-config
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          env:
            - name: TARGET
              value: "Go Sample v1"
```
- **Revisions** The `revision.serving.knative.dev` resource represents an immutable snapshot of your code and configuration at a given point in time. Each time you update your configuration, a new revision is created with a unique name and URL. Revisions are scaled up and down by Knative Serving based on traffic demand.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/skaop8t536mcfdr45t18.png)

---
**Reference links**
- https://knative.dev/docs/serving/
- https://www.sobyte.net/post/2022-07/knative-serving/
- https://mycloudjourney.medium.com/knative-serving-and-eventing-f6bcc165493f