Knative: What is it, and why do I care?
Officially…
Knative is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads.
– Source: Google, who “owns” the project
…a reasonable follow-up question is okay, but what does “serverless” mean?
Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform.
– Source: MartinFowler.com’s serverless section
Most of the time, and especially for Knative, “serverless” refers to that second part of the definition – code that runs in containers that are brought to life just to execute that code, and are then killed when the code finishes execution.
Knative is native to Kubernetes (…get it? Native to Kubernetes? lolz), which means that it exists pretty much to take care of Kubernetes things that you most likely won’t want to deal with on your own.
A note on pronunciation…
We joked when we were first looking into Knative that we were definitely going to call it kah-native – assuming it was actually pronounced like “native,” because silent K’s. We were going to run with kah-native instead because…well, probably because we’ve seen Monty Python and the Holy Grail one too many times. It turns out we were both right and wrong – it’s pronounced “kay-native.”
So…what does it do?
There are three main ways that Knative shines with serverless architectures, and also with Kubernetes-run applications as a whole. The three ways are all in the definition we already mentioned – build, deploy, and manage. It does this via custom resource definitions, and some associated API’s (Build, Serving, and Eventing).
The purpose of the API’s, and of Knative as a whole, is to handle some of the fuzzier areas that fall under the semi-gray umbrella of “middleware” for applications intended to run on a Kubernetes (or Kubernetes-based, like OpenShift) cluster. Middleware here refers to the generic definition, “software that runs under the application layer,” not application runtimes. Overloaded IT terms are fun, you guys.
The Knative API’s can also be used independently, so if only the Build portion interests you, that’s all you have to install.
Build
Purpose: build and package application code from within the Kubernetes cluster.
Associate API bundle: Build (…seems legit, Documentation, GitHub source), allows you to…well, build. It also has functionality for the common things people will probably want to do related to a build – like building the source code into a container, or pushing the resulting image to a registry.
Deploy
Purpose: Deploy and serve applications. Also handles spinning the applications up to run as needed and then spinning them back down, which is one of the fundamental pieces of serverless architecture.
Associated API bundle: Serving (Documentation, GitHub source) – among other things, handles custom routing and autoscaling. (note: this uses Istio!)
Manage
Purpose: Event-handling, manages defining event sources and subscriptions.
Associated API Bundle: Eventing (Documentation, GitHub source), handles event sources and event delivery, also Serving applies here too.
Who should care a lot about Knative?
Per Google, there are two main groups of people who are likely to find Knative helpful (most of these words are a summary of what we learned doing the CodeLab on Google, the link is at the bottom of this post).
1. I want to deploy to a Kubernetes cluster easier.
Because of the Build API, which…well, builds, Knative can make it easier to handle that part, starting from a code repository. Routing and autoscaling, part of the Serving API, are also probably things applications on a Kubernetes cluster will want – routing lets the outside world in, and autoscaling (especially spin up and spin down for serverless) is one of the very coolest parts of running on Kubernetes. It also some slick capabilities to make blue/green deployments easier.
2. I want to build my own PaaS/FaaS on Kubernetes.
If you really wanted to write your own internal Paas/FaaS (like Heroku or AWS Lambda) on a Kubernetes cluster, some of the Knative components would help you do that.
Why we like it
Knative provides middleware functionality in modular pieces to help support serverless applications on Kubernetes-based clusters. Several of these modular pieces also can help with getting non-serverless applications on a Kubernetes cluster.
The ecosystem around Kubernetes is growing at a giddy pace, and as one of us is an avid automation nerd (spoiler alert: it’s Laine), Knative is one of the most interesting pieces to pop up recently.
MORE Resources! Learn all the things!
- Google CodeLab – Using Knative to deploy serverless appliations to Kubernetes (this is really good, it’s how we best understood what Knative is good at. It’s free!)
- Knative on GitHub, main page
- Knative Slack