Slide 1

Slide 1 text

Knative: Building serverless experiences on top of Kubernetes Ahmet Alp Balkan follow me at @ahmetb Thanks to Mark Chmarny, Ryan Gregg, DeWitt Clinton, Bret McGowen and Ville Aikas for some of the slides used in this presentation.

Slide 2

Slide 2 text

Talking about servers at a serverless conference

Slide 3

Slide 3 text

Serverless Kubernetes

Slide 4

Slide 4 text

I work on developer tools and experiences for Kubernetes. I'm passionate about microservices, infrastructure-as-code, and RPC frameworks. Past: worked at Microsoft Azure on Linux and Docker. Follow me at @ahmetb.

Slide 5

Slide 5 text

Kubernetes

Slide 6

Slide 6 text

Kubernetes is the de facto platform for running containers.

Slide 7

Slide 7 text

*Sources: COCOMO Model, CNCF Certified Providers , k8s.devstats.cncf.io 400+ Years of effort* 5,000+ Contributors 40k+ GitHub stars The incredible Kubernetes ecosystem

Slide 8

Slide 8 text

How did this happen? Kubernetes encourages cattle; not pets. ● Individual machines don't matter. ○ Container isolates the app from the host. ● Containers are ephemeral: they come and go.

Slide 9

Slide 9 text

How did this happen? Kubernetes has a declarative API. ● Apply the desired configuration to your cluster. ● Kubernetes will drive "current state" to the "desired state" eventually.

Slide 10

Slide 10 text

How did this happen? Kubernetes keeps your applications running while you're asleep. ● Container died? ○ Restart it. ● Container unhealthy? ○ Reschedule to another node. ● Container overloaded? ○ Add more replicas automatically.

Slide 11

Slide 11 text

How did this happen? Kubernetes API is extensible. ● You can create custom API types. ● You can write custom controllers to actuate the custom objects. apiVersion: my.api/v1 kind: MysqlCluster metadata: name: orders-db spec: masters: 3 replicas: 12 storage: innodb: {}

Slide 12

Slide 12 text

Kubernetes is not easy 1. It was never meant to be used by developers directly. 2. Creating and operating Kubernetes clusters in production is pretty much a full time job.

Slide 13

Slide 13 text

Google Kubernetes Engine (GKE) The zero ops cluster experience: ● update your cluster to new versions of Kubernetes ● scale the cluster up/down automatically ● detect and replace broken nodes of the cluster

Slide 14

Slide 14 text

It's not the right abstraction for end-developer experience. (This did not stop developers from using Kubernetes directly!) But it's a great platform for building a PaaS on top of. Kubernetes isn't actually for developers

Slide 15

Slide 15 text

Developers using Kubernetes Have to do Write code Build docker image Upload image to registry Deploy service Expose to the internet Set up monitoring Set up autoscaling Want to do Write code

Slide 16

Slide 16 text

Why do developers still use Kubernetes? ● Some people want control over their infrastructure (VMs, machines, OS images, networking, security, ...) ● Not everyone is on cloud yet, or they want to avoid vendor lock-in. ● Kubernetes lets you effectively manage a large set of {machines, deployments}.

Slide 17

Slide 17 text

Serverless

Slide 18

Slide 18 text

Serverless > Functions

Slide 19

Slide 19 text

Compute Storage Messaging Data processing Database Data warehouse AI Serverless is more than snippets of code

Slide 20

Slide 20 text

Cloud Dataflow Cloud Machine Learning Cloud Storage Cloud PubSub Cloud Functions App Engine BigQuery Cloud Datastore Serverless is more than snippets of code

Slide 21

Slide 21 text

No servers Idiomatic Event-driven Free of lock-in Promise of serverless

Slide 22

Slide 22 text

Developers … just want to run their code. ... want to use their favorite languages and dependencies. … don't want to manage the infrastructure.

Slide 23

Slide 23 text

The case for Serverless on Kubernetes

Slide 24

Slide 24 text

Developers want serverless ... just want to run their code. ... want to use their favorite languages and dependencies. ... don't want to manage the infrastructure. Operators want Kubernetes Kubernetes is great orchestrating microservices They love using GKE and not having to do operations for Kubernetes. Kubernetes is not the right abstraction for their developers.

Slide 25

Slide 25 text

Why would you want serverless on Kubernetes? Ask the developers of >13 open source Kubernetes-based FaaS/serverless projects. :)

Slide 26

Slide 26 text

Why would you want serverless on Kubernetes? 1. Your company doesn't use cloud (or wants vendor lock-in) 2. Need control over the infrastructure, machines, host OS, ... 3. Kubernetes offers good abstractions to build upon.

Slide 27

Slide 27 text

No servers Idiomatic Event-driven Free of lock-in How to get this on Kubernetes?

Slide 28

Slide 28 text

“The majority of people managing infrastructure just want PaaS. There's only one requirement:

Slide 29

Slide 29 text

“The majority of people managing infrastructure just want PaaS. There's only one requirement: It has to be built by them.” -Kelsey Hightower

Slide 30

Slide 30 text

Serverless stack Invokers Event Binding Kubernetes Platform Products Primitives Autoscaling Observability Build Routing ... DX Event Sources Runtimes ... Effort scope

Slide 31

Slide 31 text

Serverless stack Invokers Event Binding Kubernetes Platform Products Primitives Autoscaling Observability Build Routing ... DX Event Sources Runtimes ... Duplication of efforts Decreased portability Opportunity lost

Slide 32

Slide 32 text

What if I told you, we can still fulfill the serverless promises on servers (but you don't have to manage them)?

Slide 33

Slide 33 text

Knative

Slide 34

Slide 34 text

Building blocks for creating serverless experiences on top of Kubernetes. github.com/knative Hello Knative

Slide 35

Slide 35 text

Knative collaborators

Slide 36

Slide 36 text

The Knative Stack Kubernetes Platform

Slide 37

Slide 37 text

The Knative Stack Knative Build Serving Events Kubernetes Platform Primitives

Slide 38

Slide 38 text

Knative Build Serving Events Kubernetes Platform Products Serverless Containers on GCF GKE Serverless Add-on SAP Kyma Pivotal Function Service IBM Cloud Functions Red Hat Cloud Functions Primitives riff OpenFaaS Jazz

Slide 39

Slide 39 text

Knative Build Serving Events Kubernetes Infrastructure Developer Product Primitives riff OpenFaaS fn your private PaaS ...

Slide 40

Slide 40 text

What Knative is ● An open source project ● Set of building blocks to construct your own FaaS/PaaS ○ abstracts common tasks through custom Kubernetes API objects ● An abstraction on top of Kubernetes. ○ It's still Kubernetes: Runs containers at the end of the day.

Slide 41

Slide 41 text

What Knative is not ● It's not a Google product. ● It's not a FaaS.

Slide 42

Slide 42 text

What can you do with Knative? ● [Developers] Use it directly to deploy stuff (not easy, but works fine) ● [Operators] Put a level of abstraction between your devs and Kubernetes. ● [Platform Architects] Use it to build your own serverless platform. ○ e.g. DIY Heroku or GCF/Lambda.

Slide 43

Slide 43 text

Infrastructure Primitives Knative Kubernetes Off-the-shelf FaaS (riff, OpenFaaS, Apache Whisk…) Developer Experience Your in-house FaaS platform Developers

Slide 44

Slide 44 text

DIY FaaS on Kubernetes (oversimplified) ● Something to wake up your workload (activation) on request. ● Something to scale up, and back to zero. ● Something to turn your app/function into a container ● Something to collect metrics and export telemetry from the app. ● Handling of revisions of the code+config (+ability to rollback) ● A way to offer traffic splitting (gradual rollout) ● An eventing system with configurable sources/flows/subscribers

Slide 45

Slide 45 text

Knative building blocks Build Serving Events

Slide 46

Slide 46 text

Knative components ● Serving: Revisions, Traffic Splitting, Autoscaling ● Build: On-cluster builds and transformations ● Eventing: Declarative way to bind event sources to services

Slide 47

Slide 47 text

Knative Serving Benefits ● Seamlessly scale up and down ● Built-in traffic splitting between revisions ● Integrates networking and service mesh automatically ● Easy to reason about object model Pluggable ● Connect to your own logging and monitoring platform, or use the built-in system ● Auto-scaler can be tuned or swapped out for custom code

Slide 48

Slide 48 text

Knative Serving Primitives with clear separation of concerns: Configuration Current/desired state of an application Code & configuration separated (a la 12-factor) Revision Point in time snapshots for your code and configuration Route Maps traffic to a revisions Supports fractional, named routing

Slide 49

Slide 49 text

Knative Build Lets you go from source code to container images. ● Build pipelines can consist of multiple steps ● Each build step is a container image. ● Builds run inside the containers on the cluster. Makes it possible to do GitOps and go from "git push" to a running URL.

Slide 50

Slide 50 text

source: git: url: git://github.com/example/foo.git steps: - name: compile image: gcc args: ["gcc", "-o", "a.out"] - name: build image: docker-cli args: ["docker", "build", "--tag", "my-image", "."] - [...] Knative Build: Source-to-container image

Slide 51

Slide 51 text

Knative Build: Function-to-container Step 1: function to app (add an invoker for your function) Step 2: app to a container (add a buildpack environment) Step 3: push container to a registry

Slide 52

Slide 52 text

Knative Build: Benefits ● Flexible: Control over how your source is turned into artifact (container image). ● Builds happen on the cluster. ○ No need for Docker locally ○ Cached Docker builds ○ Faster image pushes ○ No cross-compiling toil

Slide 53

Slide 53 text

Knative Eventing Benefits ● Declaratively bind between event produces and your services ● Custom event pipelines to connect with your own existing systems Event type Flow Event source Event type Event type Event consumer(s)

Slide 54

Slide 54 text

Knative Eventing (Work in progress, subject to change.) Eventing constructs : ● Event Sources (producer) ● Event Types (different events) ● Event Actions (any route) ● Event Feeds (configuration) Event type Flow Event source Event type Event type Event consumer(s)

Slide 55

Slide 55 text

Knative development principles Organic 03 Extensible 02 Idiomatic 01 ● Feel native on Kubernetes ● Meet the developer ● Loose coupling at the top ● Pluggable at the bottom ● Codify the commonalities ● Build a stable platform

Slide 56

Slide 56 text

Demo

Slide 57

Slide 57 text

Thanks! github.com/knative cloud.google.com/knative g.co/serverlessaddon (alpha sign-up)