
Knative – Kubernetes-based platform to manage modern serverless workloads - dankohn1
https://cloud.google.com/knative/
======
markusthoemmes
Joining in, Markus from IBM and OpenWhisk. Been involved with knative for
quite some time now as well.

Happy to answer any questions that might arise as well. Answers might be
biased and opinions are my own.

See IBM's statement: [https://www.ibm.com/blogs/cloud-
computing/2018/07/24/ibm-clo...](https://www.ibm.com/blogs/cloud-
computing/2018/07/24/ibm-cloud-google-knative-serverless/)

~~~
otterley
Can we see a design document/theory of operations, please? It’s difficult to
evaluate this effort without understanding exactly what it _is_ \- namely, the
constituent components, their respective functions, how they work and relate
to one another, etc.

~~~
labadav
The docs repo gives a high level overview and a deeper dive into each of the
components with samples:

[https://github.com/knative/docs/blob/master/README.md](https://github.com/knative/docs/blob/master/README.md)

------
mfer
I have a few questions.

> Knative provides a set of middleware components that are essential to build
> modern, source-centric, and container-based applications that can run
> anywhere

Are these middleware components that someone else is supposed to package
together into something useful like a platform? The other bits lead me to
think it's a platform of sorts in itself. So, why the talk of middleware?

> Knative offers a set of reusable components that focus on solving many
> mundane but difficult tasks such as orchestrating source-to-container
> workflows, routing and managing traffic during deployment, auto-scaling your
> workloads,

PaaS systems already do this. Other serverless things, like kubeless, do this
too. Are these reusable components supposed to be packaged in a higher level
system? It sounds like that but other parts of the page suggest it's a
platform to use now.

> Kubernetes-native APIs

This is found in the docs repo. The examples are long form k8s style objects.
Have developers (those being targeted) been interested in these? In my
experience they like shorter form ones (there are numerous tools making that
possible).

I'm curious of the meat and usefulness behind the hype.

~~~
jacques_chester
> _Are these middleware components that someone else is supposed to package
> together into something useful like a platform? The other bits lead me to
> think it 's a platform of sorts in itself. So, why the talk of middleware?_

It's intended to be usable as a single installation with the option to install
individual parts. The textbook case is Build -- you can get things done with
or without it.

> _Are these reusable components supposed to be packaged in a higher level
> system? It sounds like that but other parts of the page suggest it 's a
> platform to use now._

I think a bit of both. The joke I've made is that if Kubernetes is IaaS++,
Knative is PaaS--. It's usable as-is, it aims to provide a common set of
primitives for shared concerns, but it can also serve as a base for higher-
level systems. The Project riff team, for example, have pushed some of their
efforts down into Knative.

> _In my experience they like shorter form ones (there are numerous tools
> making that possible)._

Mine too. My personal view is that Build (and before long Pipelines) will be
the main entryway to Knative.

~~~
mfer
> Knative is PaaS--

Except it bills itself as serverless. In a PaaS your apps need to have a
server (e.g., http server). Serverless (e.g., FaaS or Brigade) elsewhere
doesn't need this. Stuff isn't long running.

How is long running software servers like this serverless?

> My personal view is that Build (and before long Pipelines) will be the main
> entryway to Knative.

Pipelines? That doesn't appear to be in the docs. What is Pipelines?

~~~
jacques_chester
> _Except it bills itself as serverless. In a PaaS your apps need to have a
> server (e.g., http server). Serverless (e.g., FaaS or Brigade) elsewhere
> doesn 't need this. Stuff isn't long running._

I think this comes down to the difficulties of terminology. I think of FaaS as
a PaaS with some extra features (scale-to-zero being the most-noticeable).
"Serverless" is a catch-all term for a variety of workloads, of which FaaS is
the most visible.

> _Pipelines? That doesn 't appear to be in the docs. What is Pipelines?_

It's a proposal[0] to evolve Concourse into being a Knative component, picking
up from Build for complex workflows. I've been working on parts of this with
various folks over the past few months.

I should emphasise that it is a proposal. For what you do with Knative today,
use Build. It's a simple abstraction and it works right now.

[0]
[https://docs.google.com/document/d/1PicF7UhvSBpZLwichuY5hdhT...](https://docs.google.com/document/d/1PicF7UhvSBpZLwichuY5hdhTX7Sl6aak2OzwDK8G78s/edit)
(to view, join the knative-dev group:
[https://groups.google.com/forum/#!forum/knative-
dev](https://groups.google.com/forum/#!forum/knative-dev))

------
gdsdfe
I kinda have a hard time understanding what it is ... is it kinda a 'glue'
layer between Kubernetes and istio ? Can somebody give us a 2 sentences
explanation? please and thank you

~~~
evankanderson
This is a way to deploy and manage a stateless web application ("function")
without needing to get into a bunch of low-level details, and get closer to
pay-for-what-you-use.

~~~
djhworld
> get closer to pay-for-what-you-use.

How though, won't you need a Kubernetes cluster running?

~~~
ryangregg
On the small scale, no, it's not pay-for-what-you-use. Imagine though you're
an enterprise, running a large K8S cluster with lots of workloads inside. By
using Knative and scale-to-zero, now you can pack more lightweight workloads
into the same cluster resources, because the pods scale down when they're not
actively being used. It gives you (as the cluster operator in your company)
the ability to run your cluster the same way serverless works in the cloud.

------
jacques_chester
I've been around Knative for a few months on behalf of Pivotal (our blogpost
here[0] and TheNewStack here[1]). Other leading contributors are IBM, SAP and
Red Hat.

Subject to my biases, what would people like to know?

[0] [https://content.pivotal.io/blog/knative-powerful-building-
bl...](https://content.pivotal.io/blog/knative-powerful-building-blocks-for-a-
portable-function-platform)

[1] [https://thenewstack.io/knative-enables-portable-
serverless-p...](https://thenewstack.io/knative-enables-portable-serverless-
platforms-on-kubernetes-for-any-cloud/)

~~~
evankanderson
See also:

[https://medium.com/@mchmarny/build-deploy-manage-modern-
serv...](https://medium.com/@mchmarny/build-deploy-manage-modern-serverless-
workloads-using-knative-on-kubernetes-180c1a55e1b5)

[https://www.ibm.com/blogs/cloud-computing/2018/07/24/ibm-
clo...](https://www.ibm.com/blogs/cloud-computing/2018/07/24/ibm-cloud-google-
knative-serverless/)

and one by this "Google" thing:

[https://cloudplatform.googleblog.com/2018/07/bringing-the-
be...](https://cloudplatform.googleblog.com/2018/07/bringing-the-best-of-
serverless-to-you.html)

~~~
jacques_chester
Our colleagues at SAP: [https://blogs.sap.com/2018/07/24/sap-cloud-platform-
an-open-...](https://blogs.sap.com/2018/07/24/sap-cloud-platform-an-open-
enterprise-platform-with-a-cloud-native-core/)

Edit - and Red Hat: [https://blog.openshift.com/state-of-serverless-in-
kubernetes...](https://blog.openshift.com/state-of-serverless-in-kubernetes-
knative-and-openshift-cloud-functions/)

------
dewitt
Thanks to everyone who played a part of this! The Google team is also watching
this thread. Happy to answer any questions people have.

~~~
dcosson
This looks really cool, I'll definitely be looking into it more closely when I
get a chance.

Obviously this is a conflict of interest for Google, but just curious if you
know of any plans in the works for being able to run this on AWS EKS? It's the
obvious omission from the list of supported clouds on the installation
page[0].

[0]
[https://github.com/knative/docs/tree/master/install](https://github.com/knative/docs/tree/master/install)

~~~
markusthoemmes
If AWS EKS gives you access to kubectl or similar, it is probably trivial to
setup. There shouldn't be any obvious roadblocks. Will be a great contribution
to add to the guides!

~~~
csears
AWS EKS definitely does support kubectl, but requires the aws-iam-
authenticator (formerly Heptio) to integrate with AWS IAM. Docs here:
[https://docs.aws.amazon.com/eks/latest/userguide/configure-k...](https://docs.aws.amazon.com/eks/latest/userguide/configure-
kubectl.html)

------
mchmarny
I wrote a little post to explain why Knative is important from the developer
perspective [https://medium.com/@mchmarny/build-deploy-manage-modern-
serv...](https://medium.com/@mchmarny/build-deploy-manage-modern-serverless-
workloads-using-knative-on-kubernetes-180c1a55e1b5)

~~~
cmonfeat
Great post, really cleared up the value proposition of this project for me!

------
falcolas
Just a quick reminder from the installation documents (emphasis mine):

"If you already have a Kubernetes cluster you're comfortable installing _alpha
software_ on, use the following instructions"

This looks cool, and will likely be useful in the future, but this is still
alpha quality software. Don't bet your business on it by installing it to your
production clusters. Don't let your development cycle by driven by the latest
shiny thing, no matter whose logo is on it.

------
lima
They say Red Hat is involved.

How does this relate to OpenShift?

I really hope that, for instance, Knative's builder will be merged with Red
Hat's source-to-image (S2I) builder.

~~~
jacques_chester
The current Build design allows for a relatively straightforward extension to
use S2I as a BuildTemplate. You can see other examples here:
[https://github.com/knative/build-templates](https://github.com/knative/build-
templates)

As and when Builds becomes Pipelines, I anticipate that it will remain
relatively trivial to integrate existing build infrastructure without too much
fuss.

------
isdal
The github page is now public. If you want to see the actual code you can find
it at [https://github.com/knative](https://github.com/knative)

------
dgllghr
I'm a bit confused about the "eventing" application. Is it a message bus like
NATS? a persistent event log like Kafka? or is it an adapter that allows
applications to interact with both?

~~~
evankanderson
"eventing" is building an ecosystem to make it easy to connect events to event
consumers (whether they are Knative Services, k8s services, VMs, or even a
SaaS).

In order to do this, we've broken the problem down into 3 parts:

Buses provide a k8s-native abstraction over message buses like NATS or Kafka.
At this level, the abstraction is basically publish-subscribe; events are
published to a Channel, and Subscriptions route that Channel to interested
parties.

Sources provide a similar abstraction layer for _provisioning_ data sources
from outside Kubernetes and routing them to the cluster, expressed as a Feed
(typically, to a Channel on a Bus, but could also be directly to another
endpoint). Right now, we only have a few generic Sources, but we plan to add
more interesting and specific Sources over time.

Lastly, we have a higher-level abstraction called a Flow which bundles up the
specification from the Source to the endpoint, optionally allowing you to
choose the Channel and Bus which the event is routed over. (Otherwise, there
is a default Bus used to provision a Channel.)

All of this is also very much work-in-progress. You're seeing the workshop as
we put down our tools yesterday, not as cleaned up for a tour. :-)

~~~
otterley
Can you point us to the design document so we can further study it?

~~~
jacques_chester
This one is harder to point to, eventing is still under fairly active
discussion. The Eventing Glossary doc[0] and the working group notes are
probably the best references right now.

[0]
[https://docs.google.com/document/d/1JSPgieg0DiP4uIfo_zDoojo6...](https://docs.google.com/document/d/1JSPgieg0DiP4uIfo_zDoojo65U5G64zbTgXwgQoeaWg/edit#heading=h.4bitbo4ik33t)

[1]
[https://docs.google.com/document/d/1uGDehQu493N_XCAT5H4XEw5T...](https://docs.google.com/document/d/1uGDehQu493N_XCAT5H4XEw5T9IWlPN1o19ULOWKuPnY/edit#)

------
perfunctory
So Kunernetes by itself is not high-level enough, we need a layer on top of
it? Turtles all the way up.

~~~
bigdubs
Have you ever used Kubernetes? The abstraction it focuses on is running
container images; building them and getting them to a registry is a whole
separate abstraction.

~~~
yebyen
This is a great answer. Kubernetes is missing (or said another way, OpenShift
has...) buildconfig and imagestream primitives to make building containers a
natural extension of your Kubernetes deployments/daemonsets/whatever.

OpenShift has done a really good job of being there, wherever Kubernetes is
lagging behind. They may not provide the new canonical implementation of the
solution to the forseen problem, but they are expert at predicting where the
gaps will need to be filled (and preemptively making an effort to fill them.)

I see Helm project has a specific advice for multi-tenant usage now, too, in
their best-practices advice! That was one of the criticisms of helm from
OpenShift, and now it's evidently solved(-ish) with the advancements in modern
k8s rbac and some documentation.

~~~
smarterclayton
Thanks for that - we definitely think there are many great ideas floating
around in the Kube ecosystem, and projects like knative bring together a
critical mass of perspectives and people to take “good ideas” and make them
“things we all can depend on”.

knative is a mashup of good ideas and patterns from app engine, openshift,
cloud foundry, FaaS, and public cloud providers. I think it will fill the
missing space between containerized apps and true FaaS on top of Kube, while
still making it easy to break the abstraction glass as necessary.

------
mkj
Are serverless applications used internally at Google, or this is just for
their cloud hosting platform?

------
gregwebs
I am glad to see attempts at making a high-level platform. However, I feel
like it will be too opinionated for many to pick Istio and solve build and
FaaS all at once. Will there be some push-down of some of the functionality
into Kubernetes? Will any of this turn into specification with alternative
implementations?

~~~
dewitt
One of the goals is to make the components loosely coupled at the top (so a
product can choose among them as needed), and also pluggable at the bottom (so
you can swap out implementations as needed, for example logging and
monitoring).

I expect that some of this will end up upstreamed into Kubernetes proper if
it's broadly useful (autoscaler work, to pick an example), but this is still
super early so let's see what people want.

And yes, we're documenting the control plane APIs, the data plane
requirements, and the contract for serverless container environments, with the
hope that they can be reimplemented consistently wherever needed.

One of the explicit goals is workload portability, so separating spec from
implementation is critical.

~~~
smarterclayton
Re: upstreaming - Kubernetes has tried really hard to make it easy to be
extended, and knative also tries to use those mechanisms and be nice, clean,
reusable APIs that can be used on any Kubernetes cluster. I think it's
increasingly likely that "upstreaming" an API pattern means "everyone installs
it to their cluster", but we'll need to see how that plays out.

------
minimaxir
The Google Next keynote is happening now: they announced Istio 1.0, but not
this. Interesting.

~~~
dewitt
We have several days of keynotes at GCP Next and way more to share throughout
the week. But for the curious, there's a serverless spotlight session at 1:55
today that will cover this, as well as a Knative-specific talk at 4:35.

We decided to announce this first thing with the blog posts just to get the
word out as soon as possible and give our amazing partners (Pivotal, SAP,
RedHat, IBM, and more) a chance to share their news as well.

And frankly, it's just more fun to run an open source project out in the open,
so we were pretty keen to flip the git repo bits to public as early as we
could. : )

------
reilly3000
How is this different than Kubeless on Kubernetes?

~~~
pas
knative has "distributed tracing" and supports scaling to zero, and aims to be
loosely coupled. that said I have no idea how kubeless works, but I like that
they have a CLI for quickly deploying functions.

------
sequoia
It strikes me as highly significant that a large portion of the questions here
are along the lines of "what the heck is this thing?" I'm certainly in that
boat: as far as I can tell Knative is some kubernetes based cloud something
something that maybe let's you host your own FaaS? Like Openwhisk? Or maybe it
helps you deploy or something (isn't that already what k8s does?)?

This is hopefully received by Knative devs (or marketers) that the homepage
needs a major overhaul, as it's not at all clear what the product is to the
average visitor.

------
hemapani
1) It is mentioned that KNative "deliver a serverless experience to developers
on any cloud". How does it work with any cloud? Are you referring to fact that
all clouds has k8s? Is it already supported in any cloud or will be supported?

2) If any cloud is supported, does it virtualize services such as storage,
queues, API management and Identity

3) Does Knative can seamlessly switch monitoring to what is provided by each
cloud.

------
shaohua
What is the limitation on this? AWS lambda has 250M code size limit, 3G memory
limit, 512M temp storage limit, how about this?

~~~
evankanderson
How big is your Kubernetes cluster?

------
polskibus
Can I run functions written on any platform on Knative? Java? .net core? Js?

What about startup times? How do they compare to other solutions?

~~~
jacques_chester
> _Can I run functions written on any platform on Knative? Java? .net core?
> Js?_

Anything that meets the Container Runtime Contract[0] should work.

> _What about startup times? How do they compare to other solutions?_

Startup times need a lot more work. Knative has a number of moving pieces
which are contributing delay to startup time and they're being discussed or
attacked by various groups. Some of this work will probably require changes to
be contributed upstream to Kubernetes and Istio.

[0]
[https://github.com/knative/serving/blob/5b8542fb58044834d50f...](https://github.com/knative/serving/blob/5b8542fb58044834d50f71a40d36b936e372a9ec/docs/runtime-
contract.md)

~~~
smarterclayton
Startup time is the hardest (and most valuable) piece for everyone to work
together on. By improving startup time of Kube containers, we can benefit (and
draw from) a lot of people who are using Kube today, not just knative. This is
a great example of trying to find an “everyone wins” scenario in open source
and succeeding.

------
mikevm
Why would you use something like this over, say, Google App Engine Flex?

~~~
isdal
I'm the engineering manager at Google responsible for both Knative and App
Engine Flex. What we heard from a lot of customers is that they want a
serverless / App Engine Flex-like experience but one that works multi-cloud or
in hybrid/on-prem setups. The goal for Knative is to fill that need,
especially for people that already use kubernetes. That being said, App Engine
Flex is a solid GA service that provides a fully managed experience and runs
huge services today. Knative is not there yet but is getting better by the
day.

~~~
wikibob
I want to love AppEngine Flex, but it consistently takes 10+ minutes to
deploy. Is this something that we can ever expect a fix for?

~~~
isdal
Network/Load-balancer programming is embarrassingly slow on Flex. We have long
term projects in place that will improve it but I can't give any dates here.

Short term we have a few tactical features in the pipeline. In the next few
weeks we are rolling our "parallel build and deploy" which moved the docker
build to run parallel with LB programming. Depending on your build that saves
a few minutes.

When doing development I usually just replace an existing version by deploying
with:

gcloud app deploy --version <my-dev-version>

This keeps the same LB and VMs as before and does a gradual container swap. It
is not safe for production but definitely helps when iterating.

------
djhworld
How do you pronounce it?

Native with a silent K? (like "knave" or "knee")

Kay-Native?

Kuh-Native?

~~~
praseodym
From [https://github.com/knative/docs](https://github.com/knative/docs):
“Knative (pronounced kay-nay-tiv)”

------
omegaworks
Whats the difference between this and KOPS?

[https://github.com/kubernetes/kops](https://github.com/kubernetes/kops)

~~~
jacques_chester
Knative is on top of Kubernetes and Istio.

Kops addresses the bits below Kubernetes.

------
alexnewman
Why would I choose this over kubeless?

------
pwaai
Cold startup time and mitigation strategies like those on AWS?

~~~
markusthoemmes
Even better! Knative will allow you to even scale your containers out-of-band
if you know that something BIG will happen. See
[https://github.com/knative/serving/issues/1656](https://github.com/knative/serving/issues/1656)
for the discussion.

~~~
pwaai
That tells me not much....is it pinging to keep instances warm?

~~~
jacques_chester
No. The intention is that the autoscaler will support both floor and ceiling
values for its work. So while scale-to-zero is the default, you can make an
economic decision that you want scale-to-1, scale-to-10, whatever makes sense
for your case. Pinging won't be necessary to artificially create this
behaviour.

This is an example of nesting reactive control (the autoscaler) with
predictive control (the min/max values).

~~~
pwaai
interesting...by floor and ceiling is that like the minimum and maximum
threshold for latency?

here's my pain point. I built a serverless REST API with token authentication
on Lambda. However, if many people aren't using it _all the time_ it will
sleep and then the next sucker who calls the endpoint is stuck with waiting
for the serverless instance to wake up.

In some cases even getting a token from a simple POST request would take an
awful long time. This was a few years ago and I stopped using serverless since
then.

But now I'm interested in serverless because I've been hearing that the cold
startup problem is being reduced.

I wonder if in the future developers will be just taking core logics from
serverless repository and wiring up the components, sort of like how wordpress
does it without the crazy layers of PHP and bloat.

~~~
jacques_chester
There are two aspects here: engineering and economic.

Our engineering view is that we want startup to be as fast as possible, which
is a surprisingly nuanced problem with lots of moving parts that need to
collectively do something smart, even before you get to the startup time of
your own code. This will show a lot of improvement as we go, but right now
it's early days.

The economic question is about trading off the risk of hitting a slow start vs
the cost of maintaining idle instances. It is _impossible_ for Knative's
contributors to solve that problem with a black box solution. What we _can_ do
is to provide you with some knobs and dials to express your preferences.

Edit: I didn't answer this question --

> _interesting...by floor and ceiling is that like the minimum and maximum
> threshold for latency?_

Not for now, this would be bounds on what scale the autoscaler can choose.
Latency is an example of an output setpoint that an autoscaler could attempt
to control, as opposed to a process input. We have in mind to make autoscaling
somewhat pluggable because different people want to target different signals.

------
sahrizv
I recently tweeted about these abstractions over abstractions here:
[https://twitter.com/sahrizv/status/1018184792611827712](https://twitter.com/sahrizv/status/1018184792611827712)

Not downplaying the team's effort and the immense utility of this to many
companies.

~~~
vosper
Rather than linking to your own tweet, perhaps you could post the comment here
and save us all a click?

~~~
sahrizv
Fair point, but the medium changes the message sometimes. :-)

The tweet resonated with a sizeable part of the developer community hence
linked here.

------
bbayer
Digital Ocean is about to ship similar product.

[https://www.digitalocean.com/products/kubernetes/](https://www.digitalocean.com/products/kubernetes/)

~~~
meddlepal
No, Digital Ocean's Kubernetes product will be similar to the existing Google
Kubernetes Engine... this is much more high-level.

~~~
bbayer
Yeah, you are right. My bad.

