Photo by Maximilian Weisbecker on Unsplash
An Introduction to Knative
Kubernetes(K8s) has slowly emerged as the standard way of deploying applications but is still only running a minority of enterprise workloads. While it is a fantastic platform to abstract away infrastructure concerns from developers and enables Site Reliability Engineer’s (SRE’s) to perform their jobs with a much higher degree of standardization across deployments, environment config, network, storage, provisioning, orchestration and troubleshooting, the point is well made that K8s is still not an application server. In short kubernetes by itself is not a developer-focused platform.
The Knative project aims to make the development of applications on Kubernetes a breeze by abstracting away common concerns – complexities of CI/CD pipelines, image builds and other ancillary concerns such as logging & tracing. Knative aims to provide the basic guardrails that make all of the above parts of building cloud-native services a breeze.
Key highlights –
-
Focused API for common use cases
-
Support for rapidly developing stateless services irrespective of vendor locking
-
Pluggable components for Loosely coupled features let you use the pieces you need.
-
Logging, monitoring & tracing support by supporting configurable 3rd party services – whether open source or proprietary
-
Developer experience and workflow
Knative Architecture
Knative is one of the most exciting projects in the CNCF (Cloud Native Computing Foundation) umbrella and aims to simplify end to end development of business services that run on containers and are orchestrated by Kubernetes. It is important to note that business services can include both microservices and serverless functions. Knative frees developers completely from CI/CD concerns such as docker image management, registry integration, deploying their services, configuring load balancing, monitoring, logging, and scaling.
I have covered the topic of Serverless functions heavily in previous posts. Below is a link to Fission which is a FaaS framework on K8s. Most of the use cases and architectures are applicable to Knative as well.
As shown in the below illustration, Knative can be installed on any environment – on-prem or cloud – that can run kubernetes. It is installed as a set of CRDs (Custom Resource Definitions) as a collection of YAML files.
At its core, Knative is comprised of three different parts namely Build, Serving and Events. Let consider each of these as illustrated in the below diagram –
Knative Components
Knative provides three fundamental components that help make the development of cloud-native applications on k8s a breeze.
The current components that are available today are
-
Build – the ability to build images from source
-
Serving – Deploying applications on underlying k8s cluster while handling snapshotting & scaling
-
Eventing – Supporting an event-driven model to ingest messages
Knative Build
The Build component of Knative is concerned with how developers build their application i.e take it from source code to a fully built container. It is a build system which can thus be incorporated into any existing CI/CD pipeline where the source is mounted as a k8s volume such as Git or any cloud storage system. It includes support for various build systems such as Google Kaniko etc. The Build portion enables the developer to define a consistent way to compile and package their code before sending it over to a registry.
Builds include support for Build Templates which ensures a set of repeatable steps that need to be performed and an ability to parameterize builds. All of these features are created using k8s CRDs. The images created out of the build process are designed to be efficient in terms of both size and performance. The most straightforward way to use the Build system is to define the sequence of ‘steps’ needed to build from source to container image. These steps which are designed to run as a pipeline use a Builder which itself is a container. Security tokens such as SSH keys, tokens and other credentials can be passed using a ServiceAccount object.
Knative Serving
The Serving component enables the deploy of an application as a container image onto an underlying k8s cluster. It also maintains snapshots of deployable, handles routing and any networking interaction. It finally provides scaling – scale up and scale down – for application deployments. Knative enables developers to define policies around development, deployment, and management using primitive objects as shown below (Service, Configuration, Route and Revision) in the form of Custom Resource Definitions (CRDs) which extend the kubernetes object model.
Remember that the key design principle of k8s is for the deployment administrator to declare the desired state using the API that the system always drives towards eventually. In that light, the purpose of the Configuration primitive is to define the desired state for your services, both in terms of the actual code as well as configuration. Reference to a container image as well as a name can be provided and these can be maintained as versions or revisions.
Revision represents an immutable snapshot of both code (in the shape of a container image) and configuration (arguments, environment variables, etc) at a given point in time. Revisions are created and maintained by the runtime when the deployer creates a new configuration or modifies an existing configuration. At runtime, the deployer can see ReplicaSets, Pods, etc that correspond to the Configuration object.
Knative Route
Finally, Route assigns traffic to a revision(s) of your service. The Service object (don’t confuse with the k8s Service object) combines Configurations and Routes manage the lifecycle of the workload. Every revision of the Service object ensures that the application has a Route and Configuration.
A key tenet of serverless platforms is their ability to react to events or be event-driven. Thus, Knative includes an events module. The Events module enables support for production and consumption of events leveraging the event source of choice. E.g. Git, messaging platform of choice. E.g. Kafka, RabbitMQ, etc. Knative aims to decouple both producers and consumers by following the CNCF CloudEvents model.
Similar to the Build and Serving modules, the framework defines foundational objects for eventing – In addition to these objects, Knative also defines objects for eventing as shown below.
The Knative eventing constructs include Event Sources which denote the represents the producer of events (e.g. GCP PubSub, Kubernetes Events, GitHub). The Event Consumers object represents the consumer of the event. Event Types — describes the kinds of events that are supported by the corresponding Event Source (e.g. a pull or push request from a GitHub source). Eventing also includes support for Channels which denote events can be sent to the Service. These Channels include Kafka, NATS, RabbitMQ, etc. Event Feeds is denotes the glue configuration that connects Events to actions.
The functional implementation of the Knative object model means that Knative is both easy to start with, but capable enough to address more advanced use cases as the complexity of your solutions increases.
Conclusion
The Knative project aims to provide key building blocks and semantics to enable the development of applications on k8s. My intention in the following months is to dive into the kinds of application architectures that can be created using Knative as well as deployment patterns in conjunction with projects such as Istio.
References
[1] The Knative website www.knative.com