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"
> 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.
# 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.
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.
Reference links
Top comments (0)