Knative Enables Portable Serverless Platforms on Kubernetes, for Any Cloud
Kubernetes (K8s) has gotten a lot of attention recently. The project has emerged as the predominant abstraction for containers. And for good reason! Kubernetes excels at container scheduling, and offers useful primitives for automating infrastructure.
But we’ve noticed that development teams often struggle when they use vanilla Kubernetes for application deployments. By all means, use Kubernetes to push containers all day long. But if you want to push application code — or a function — Kubernetes on its own isn’t enough.
That’s why a slew of vendors are rallying around K8s as a foundational tech for higher-level abstractions. And that’s where Knative fits in.
Kubernetes is a platform for building platforms. It's a better place to start; not the endgame.
— Kelsey Hightower (@kelseyhightower) November 27, 2017
Functions are the Next Abstraction You Need to Care About
You may have noticed a recent addition to the world of distributed systems: Function as a Service (“functions” or “serverless”). Functions have emerged as a new abstraction that allows developers to easily run and deploy snippets of code that instantly scale up and down in response to events.
This is a really attractive proposition for developers. Why? Abstracting away all the infrastructure and event processing (up until the point they trigger the function) means developers can focus entirely on their function code to process an event. No toil, no undifferentiated heavy lifting!
Of course, there’s no such thing as a free lunch, so where is the complexity with functions?
There are dozens of Function as a Service options on the market. Each offering is unique as far as how functions are triggered, the format of events they can process, scaling capabilities and the amount of complexity they abstract away from the developer.
When there’s a useful abstraction, you can count on the public cloud vendors to package it up and run it as a service for you. These are Azure Functions (Microsoft), Lambda (AWS), and Google Cloud Functions. Each service runs function code in response to events, and scales based on current demand. The products have utility-style billing; you pay each time the function is invoked.
Open source developers have joined the serverless party with projects like OpenFaaS, Fission, Kubeless and Project riff. All are examples of Function as a Service, built on top of Kubernetes. But this shared foundation is where the similarities end.
Each project has a slightly different implementation in three core areas:
- Each has a build service, or a means to build and then deploy containers with the function code.
- Each has an implementation of scale up (and scale down) to react to demand for function invocation.
- Each provides a way to invoke the function based on an event, such as http or pub/sub with event brokers.
These oh-so-subtle differences are actually large obstacles to adoption. Enterprise developers see fragmentation and lots of new entrants into the market. So they sit on the sidelines, waiting for a de facto standard to emerge.
This Brings Us to the News of the Day — Knative
Google saw this fragmentation and recognized the need for common tooling to help developers build functions atop Kubernetes. That’s Knative (pronounced kay-nay-tiv).
Knative is an open source software layer that helps cloud service providers and enterprise platform operators deliver a serverless experience to developers on any cloud.
For our part at Pivotal, we have contributed our eventing model from Project riff to Knative. Additionally, we have worked with Google in several other areas of the Knative project, committing both developers and code. We are so excited about the future of this project that we are combining Project riff and Knative to form the foundation of our upcoming product Pivotal Function Service.
So what else should you know about Knative? The project uses Kubernetes for the container orchestration layer. It builds functionality atop of the familiar Kubernetes primitives (pods, replica sets, deployments). What about Istio? Yup, Knative uses Istio for network routing within the cluster, and for ingress connections into the cluster.
But Kubernetes and Istio aren’t enough. That’s why Knative adds three loosely-coupled components to provide a complete serverless platform: Build, Eventing, and Serving.
- Build provides a pluggable model for building containers from source code.
- Eventing allows apps/functions to publish to, and subscribe to, event streams such as Google Cloud Pub/Sub and Apache Kafka.
- Serving provides the ability to easily run applications/functions and scale them up or scale them down to zero.
Those are the ingredients of Knative. What is the result? A simpler way to deploy and run functions, including these patterns:
- Build an application/function from source code
- Enable multiple build methods (Cloud Foundry Buildpacks, Bazel, Kaniko, Dockerfiles and others via extensibility)
- Allow developer to easily deploy new (routable) applications/functions
- Allow zero-downtime upgrades to applications
- Automate the scaling of application instances.
- Bind events to functions, apps or containers.
- Trigger functions when called via HTTP requests.
Let’s take a closer look at Build, Eventing, and Serving.
Build: Flexible and Extensible Source Code to Container Automation
Developers write source code. Kubernetes deals with containers. How do you reconcile this mismatch? By building containers from developer source code. (Sound familiar? Cloud Foundry uses buildpacks for this scenario.) Knative provides a pluggable model specifically for building containers from source code. This model is implemented via custom resource definitions, a collection of Kubernetes API objects. This approach provides the building blocks that facilitate source code builds as part of a larger system, like a CI/CD pipeline.
There are 4 main elements of a build with Knative:
- Describes where to find the source code for the build. This location is stored in /workspace volume, which is then used in the subsequent steps. As you’d expect, source code is stored in a source code control system (i.e. GIT, GCS, or a custom container that can be used to access the source code).
- Steps or Templates. This is the actual work of building the container. The process is a series of steps that adhere to the builder specification. Alternatively, it is a build template made up of pluggable builders designed specifically for building containers from source code. Currently, the model supports five build templates that are shareable build processes: the aforementioned Cloud Foundry Buildpacks, Google Container Builder, Bazel, Kaniko, and Jib.
- Service Account. The account that will be used to run the build.
- Volumes. Provides the ability to define multiple volumes that are available during the build steps. These volumes can have a variety of uses such as sharing secrets or providing a cache for multiple steps.
Serving: Demand-based Scaling and Revision Control Enable Advanced Operations
Automation improves developer workflows. Serving automates the flow from container to running function. It also enables rapid deployment of containers and performs the scaling to N, and down to zero based on incoming requests. Istio routes traffic among revisions (versions of functions), which enables activities like zero-downtime updates, blue-green deployments, partial-load testing, and code rollback.
Serving has four custom resource definitions:
- The resource that manages the lifecycle of the application/function and provides single point of control. It handles the creation of objects to ensure applications/functions have a network route, a configuration, and revisions for any update of the service.
- An immutable snapshot of code and its configuration. A revision will reference a container image and the build that creates it. Multiple revisions can exist in a history which allows more advance operations like blue-green deployments or rollbacks.
- The mapping of network endpoints to one or more revisions of a function.
- Defines the the desired latest state of a deployment, as well as the status of revisions as that state is updated.
Eventing: Abstract the Details of Publish/Subscribe Away from the Developer
Functions exist to respond to events. The difference between the implementations across FaaS projects and managed services is how those events are acquired and consumed. The Knative Eventing component is designed to abstract the backend details of working with events away from the developer. So, developers don’t need to worry about what messaging platform is used, how data is replicated, and so on.
Knative provides the developer Kubernetes custom resources that are used in the production and consumption of events. There are two categories of custom resource definitions that are part of Eventing:
- Channels
- These are publish/subscribe destinations (topics) to which publishers send messages. Basically, channels are a catalog of places to get or put events.
- Bus. The backing provider for channels. This is the messaging platform for the events in the platform and can be Google Cloud PubSub, Apache Kafka, RabbitMQ, etc.
- This specifies the Knative service for an application/function to which messages will be dispatched from a channel. This is the ingress address into the application/function.
- Feeds. The attachment of an individual event from an event source to an action.
Use the Highest Abstraction You Can
Knative is brand new, but there are a lot of resources available to learn more about what it is, and how to use it: Enterprises are writing more software than ever these days. That means a typical company is going to have application platforms, container orchestrators and functions. Pivotal wants to drive innovation in open source for all these different abstractions. Cloud Foundry, Kubernetes and now Knative will all have a major role to play as big companies modernize how they build and run software.
- The Knative Docs are a great source of project information. Each component has a section in the repo that can get you up to date on the latest functionality.
- You can take a look at the Pivotal Blog for information about Pivotal’s contributions to Knative from Ryan Morgan. He talks about unlocking more use cases for serverless in the enterprise.
- Read more from our friends at Google Cloud:
- Knative overview page.
- Knative blog.
- If you would like to know more about Project riff, the projectriff.io website is the best place to start. It has all the documentation and pointers to the Project riff repo.
- Want to learn more about Knative? SpringOne Platform has a whole serverless track. Register before 7/31 you get a cool Pivotal ping-pong paddle!