DEV Community

Cover image for Knative serving
Ashok Nagaraj
Ashok Nagaraj

Posted on

Knative serving

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 - 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

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.
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"
Enter fullscreen mode Exit fullscreen mode
> 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
Enter fullscreen mode Exit fullscreen mode
  • 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.
# 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 
Enter fullscreen mode Exit fullscreen mode
  • 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.
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"
Enter fullscreen mode Exit fullscreen mode
  • 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


Reference links

Top comments (0)