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.
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 with yamls, ingress and other optional configurations
Generated kubernetes resources
service.serving.knative.devresource 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)  (39s) Image: gcr.io/knative-samples/helloworld-go (pinned to 946b7c) Conditions: OK TYPE AGE REASON ++ Ready 25s ++ ConfigurationsReady 26s ++ RoutesReady 25s
route.serving.knative.devresource 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
configuration.serving.knative.devresource 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"
revision.serving.knative.devresource 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.
Top comments (0)