14 ms·

Knative – Kubernetes-based platform to manage modern serverless workloads

423 points by dankohn1 8y ago

jacques_chester 8y ago
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-blocks-for-a-portable-function-platform https://content.pivotal.io/blog/knative-powerful-building-bl... [1] https://thenewstack.io/knative-enables-portable-serverless-platforms-on-kubernetes-for-any-cloud/ https://thenewstack.io/knative-enables-portable-serverless-p...
- caniszczyk 8y ago
  what's happening to riff? https://github.com/projectriff/riff https://github.com/projectriff/riff
  - jacques_chester 8y ago
    Project riff members have been deeply involved for months. Basically, we'll move up the stack to use Knative as the base layer for riff. It's nice because we get to share some of our work with the wider community. The riff team have a more detailed post: https://projectriff.io/blog/announcing-riff-0-1-0-on-Knative/ https://projectriff.io/blog/announcing-riff-0-1-0-on-Knative...
- evankanderson 8y ago
  See also: https://medium.com/@mchmarny/build-deploy-manage-modern-serverless-workloads-using-knative-on-kubernetes-180c1a55e1b5 https://medium.com/@mchmarny/build-deploy-manage-modern-serv... https://www.ibm.com/blogs/cloud-computing/2018/07/24/ibm-cloud-google-knative-serverless/ https://www.ibm.com/blogs/cloud-computing/2018/07/24/ibm-clo... and one by this "Google" thing: https://cloudplatform.googleblog.com/2018/07/bringing-the-best-of-serverless-to-you.html https://cloudplatform.googleblog.com/2018/07/bringing-the-be...
  - jacques_chester 8y ago
    Our colleagues at SAP: https://blogs.sap.com/2018/07/24/sap-cloud-platform-an-open-enterprise-platform-with-a-cloud-native-core/ https://blogs.sap.com/2018/07/24/sap-cloud-platform-an-open-... Edit - and Red Hat: https://blog.openshift.com/state-of-serverless-in-kubernetes-knative-and-openshift-cloud-functions/ https://blog.openshift.com/state-of-serverless-in-kubernetes...
- yebyen 8y ago
  Hey, glad to see you again! It looks like I have some more catch up to play, I see a rails logo on this page... I emailed you a couple of days ago or yesterday about the Ruby support in Riff. There's not a PR yet but we got Ruby into a working state again! It looks like not a lot of people are interested in Ruby on serverless platforms. Can you shed any light on why? And what kind of Ruby support can I expect from knative, given that it's not apparently coming from the Riff project now... as a Rails dev who wants to use this stuff today, how do I get started? (It has a Rails logo on the page linked by the post, so I assume I can use it now, but I haven't gone deeply enough to see if there are limitations... I'm used to Ruby support being neglected in the serverless areas, I don't know if it's because we Ruby devs are slacking, or there's a fundamental flaw I haven't seen yet, or what...) So, what can you tell me about that Rails logo on the landing page?
  - jacques_chester 8y ago
    Yes, I'm sorry I didn't reply to you -- I was caught by the problem that I knew this was imminent but not being able to say so (or even hint so). > It looks like not a lot of people are interested in Ruby on serverless platforms. Can you shed any light on why? I imagine there's some mix of market demand and path dependency. A lot of folks who like experimenting moved onwards to the Node ecosystem and a lot of FaaS work has happened there. Meanwhile enterprises are heavily invested in Java and .NET. The riff team at the moment is pretty small. One thing coming up is to fold buildpacks into the code->running pathway for riff. This should make it easier for the riff team to get out of the business of supporting particular ecosystems and for some of the engineering work for buildpacks to be shared amongst multiple setups. In terms of starting with Rails today, it should be possible to use the buildpacks BuildTemplate to run the existing Ruby buildpack. I don't know if it's working, it's early days for heavy automation of development on Knative itself.
    - yebyen 8y ago
      Awesome! That's totally understandable, your non-response was actually a hint that you were up to something, so it's good to see what it was. So I'm not that surprised to find you here in this discussion. I'll check it out in more detail when I'm back in front of a computer! Glad to see the rails logo somewhere new, too.
markusthoemmes 8y ago
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-cloud-google-knative-serverless/ https://www.ibm.com/blogs/cloud-computing/2018/07/24/ibm-clo...
- otterley 8y ago
  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 8y ago
    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
- TuringNYC 8y ago
  @markusthoemmes could you kindly comment on how OpenWhisk<-->Knative interact or live together or side by side
  - markusthoemmes 8y ago
    This of course needs to be discussed in the broader OpenWhisk community first, but taking dewitt's answer here into perspective (https://news.ycombinator.com/item?id=17604185 https://news.ycombinator.com/item?id=17604185) and also based on what IBM has put out in their statement a possible interaction could be to layer OpenWhisk's higher level abstractions and multi-tenancy features over the knative stack and use the latter as an "execution-engine". In technical terms, OpenWhisk's invoker system could be replaced by knative, keeping the API/Controller bits stable to still support the notion of actions/triggers/rules/sequences/compositions you name it.
dewitt 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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-kubectl.html https://docs.aws.amazon.com/eks/latest/userguide/configure-k...
  - jacques_chester 8y ago
    I think PRs would be gladly accepted. But, in general, it should work fine with any conforming Kubernetes system.
  - dewitt 8y ago
    I'd love to see a PR that documents Knative on EKS!
  - empath75 8y ago
    There seems to be a problem with istio working on EKS, actually -- i'm getting a timeout to the sidecar injector: same issue as this: https://github.com/istio/old_issues_repo/issues/271 https://github.com/istio/old_issues_repo/issues/271
isdal 8y ago
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
gdsdfe 8y ago
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
- jacques_chester 8y ago
  You have source code. You want a simple way to turn it into running functions and apps, with eventing support, with clever routing and rollout capabilities, without lifting a finger. It's an abstraction layer being developed above both of Kubernetes and Istio.
  - gdsdfe 8y ago
    ahh so you just worry about your business logic, which will be a bunch of 'functions', and knative will take care of routing, deployment, load etc. ?
    - jacques_chester 8y ago
      I would say that yes, that is a good statement of the vision that the contributors share.
      - gdsdfe 8y ago
        Got it! thank you! It's actually very interesting ...
    - mattsoldo 8y ago
      It isn't limited to functions. Knative can run containerees, or with a build system take full app code and deploy it as a container.
      - gdsdfe 8y ago
        so it can be anything really ... hmm
gregwebs 8y ago
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?
- jacques_chester 8y ago
  There will probably be stuff pushed down based on things Knative needs. For example, we've discussed the effect of what we call "the warmth hierarchy" on autoscaling (tl;dr, bad). Solving those problems can't be done entirely at the layer in which Knative is developing -- some changes will need to turn up in Kubernetes (node-local caching awareness) and Istio (workload/node-aware routing).
- dewitt 8y ago
  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 8y ago
    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.
- markusthoemmes 8y ago
mchmarny 8y ago
I wrote a little post to explain why Knative is important from the developer perspective https://medium.com/@mchmarny/build-deploy-manage-modern-serverless-workloads-using-knative-on-kubernetes-180c1a55e1b5 https://medium.com/@mchmarny/build-deploy-manage-modern-serv...
- deleted 8y ago
  [deleted]
- cmonfeat 8y ago
  Great post, really cleared up the value proposition of this project for me!
dgllghr 8y ago
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?
- jacques_chester 8y ago
  Eventing provides primitives that can use messaging systems under the hood (Buses). But it's meant to be a higher level abstraction for connecting functions or applications.
- inlined 8y ago
  The eventing repo provides a common pluggable model for managing events. The communication layer is currently HTTP, not NATS. But the broker is pluggable and includes support for Kafka. You can choose to use Kafka throughout your cluster or just for a single feed. You can add other implementations as well. The three pluggable abstractions are your event sources, the bus over which events are stored/sent, and the actions which should be invoked in response to an event.
- evankanderson 8y ago
  "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. :-)
mikevm 8y ago
Why would you use something like this over, say, Google App Engine Flex?
- jacques_chester 8y ago
  I can't give a definitive answer as I'm not very familiar with Flex. But a lot of Google folks with App Engine backgrounds are working on Knative.
  - dewitt 8y ago
    Indeed. Much of what we open sourced in Knative came from what we learned from running GAE and GCF. Which is important: this isn't a side project for us, this is based on real-world experience doing it at scale for huge customers. You don't run a serverless stack for 10+ years without taking away a few lessons. : )
    - geggam 8y ago
      When do you run into rate limiting for scaling up ? We all call it serverless but somewhere there are servers you are using and they dont magically appear from nowhere.
      - isdal 8y ago
        Yep, no free lunch. Scaling up has a few different "cliffs". To outline a few: 1. Existing pod scheduled and ready (fastest) 2. Room on existing node (so no docker pull needed) 3. Room on existing cluster (so no VM creation needed) 4. No room, need to increase cluster size. Optimizing 1-3 is very much in scope for the Knative project. Optimizing (4) is a provider problem and will vary by provider. The Knative Scaling working group is discussing this every week on Wednesdays and that meeting is open to the public. We also keep good notes linked from our community page: https://github.com/knative/docs/blob/master/community/WORKING-GROUPS.md#scaling https://github.com/knative/docs/blob/master/community/WORKIN...
- snug 8y ago
minimaxir 8y ago
The Google Next keynote is happening now: they announced Istio 1.0, but not this. Interesting.
- dewitt 8y ago
  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. : )
shaohua 8y ago
What is the limitation on this? AWS lambda has 250M code size limit, 3G memory limit, 512M temp storage limit, how about this?
- evankanderson 8y ago
  How big is your Kubernetes cluster?
- deleted 8y ago
  [deleted]
pwaai 8y ago
Cold startup time and mitigation strategies like those on AWS?
- markusthoemmes 8y ago
  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 8y ago
    That tells me not much....is it pinging to keep instances warm?
    - jacques_chester 8y ago
      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 8y ago
        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.
perfunctory 8y ago
So Kunernetes by itself is not high-level enough, we need a layer on top of it? Turtles all the way up.
- bigdubs 8y ago
  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 8y ago
    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 8y ago
      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.
- rifung 8y ago
  Isn't that computer science/software industry in general? Everyone builds upon other people's work.
bbayer 8y ago
Digital Ocean is about to ship similar product. https://www.digitalocean.com/products/kubernetes/ https://www.digitalocean.com/products/kubernetes/
- evankanderson 8y ago
  That looks more like GKE or AKS.
- meddlepal 8y ago
  No, Digital Ocean's Kubernetes product will be similar to the existing Google Kubernetes Engine... this is much more high-level.
  - bbayer 8y ago
    Yeah, you are right. My bad.
lima 8y ago
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 8y ago
  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.
- smarterclayton 8y ago
  We definitely want to support knative, integrated well with existing concepts (like triggering deployments and builds when images change), to stitch in the new build resource so it works well with existing tools like s2i (as Jacques mentioned), and generally make sure these are good building blocks for applications. There’s a lot of good ideas in knative that will benefit anyone who uses Kubernetes.
omegaworks 8y ago
Whats the difference between this and KOPS? https://github.com/kubernetes/kops https://github.com/kubernetes/kops
- jacques_chester 8y ago
  Knative is on top of Kubernetes and Istio. Kops addresses the bits below Kubernetes.
mfer 8y ago
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 8y ago
  > 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.
  - dewitt 8y ago
    Just to amplify jacques_chester's reply, yes, we do see products being built on Knative components. Google is doing that (serverless container support in GCF, serverless add-on in GKE), and you can see similar announcements being made from partners in this thread. These are early days of course, but given that the goal is to codify the commonalities (the 80% we all do roughly the same anyway) and to improve customer workload portability overall, I hope to see new products built using Knative, and existing products re-base on Knative as well. Good questions, btw!
falcolas 8y ago
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.
reilly3000 8y ago
How is this different than Kubeless on Kubernetes?
- pas 8y ago
  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.
polskibus 8y ago
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 8y ago
  > 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/5b8542fb58044834d50f71a40d36b936e372a9ec/docs/runtime-contract.md https://github.com/knative/serving/blob/5b8542fb58044834d50f...
  - smarterclayton 8y ago
    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.
djhworld 8y ago
How do you pronounce it? Native with a silent K? (like "knave" or "knee") Kay-Native? Kuh-Native?
- praseodym 8y ago
  From https://github.com/knative/docs https://github.com/knative/docs: “Knative (pronounced kay-nay-tiv)”
sahrizv 8y ago
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 8y ago
  Rather than linking to your own tweet, perhaps you could post the comment here and save us all a click?
  - sahrizv 8y ago
    Fair point, but the medium changes the message sometimes. :-) The tweet resonated with a sizeable part of the developer community hence linked here.
alexnewman 8y ago
Why would I choose this over kubeless?
mkj 8y ago
Are serverless applications used internally at Google, or this is just for their cloud hosting platform?
sequoia 8y ago
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 8y ago
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.

423 points by dankohn1 8y ago

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-blocks-for-a-portable-function-platform https://content.pivotal.io/blog/knative-powerful-building-bl... [1] https://thenewstack.io/knative-enables-portable-serverless-platforms-on-kubernetes-for-any-cloud/ https://thenewstack.io/knative-enables-portable-serverless-p...

caniszczyk 8y ago
what's happening to riff? https://github.com/projectriff/riff https://github.com/projectriff/riff
- jacques_chester 8y ago
  Project riff members have been deeply involved for months. Basically, we'll move up the stack to use Knative as the base layer for riff. It's nice because we get to share some of our work with the wider community. The riff team have a more detailed post: https://projectriff.io/blog/announcing-riff-0-1-0-on-Knative/ https://projectriff.io/blog/announcing-riff-0-1-0-on-Knative...
evankanderson 8y ago
See also: https://medium.com/@mchmarny/build-deploy-manage-modern-serverless-workloads-using-knative-on-kubernetes-180c1a55e1b5 https://medium.com/@mchmarny/build-deploy-manage-modern-serv... https://www.ibm.com/blogs/cloud-computing/2018/07/24/ibm-cloud-google-knative-serverless/ https://www.ibm.com/blogs/cloud-computing/2018/07/24/ibm-clo... and one by this "Google" thing: https://cloudplatform.googleblog.com/2018/07/bringing-the-best-of-serverless-to-you.html https://cloudplatform.googleblog.com/2018/07/bringing-the-be...
- jacques_chester 8y ago
  Our colleagues at SAP: https://blogs.sap.com/2018/07/24/sap-cloud-platform-an-open-enterprise-platform-with-a-cloud-native-core/ https://blogs.sap.com/2018/07/24/sap-cloud-platform-an-open-... Edit - and Red Hat: https://blog.openshift.com/state-of-serverless-in-kubernetes-knative-and-openshift-cloud-functions/ https://blog.openshift.com/state-of-serverless-in-kubernetes...
yebyen 8y ago
Hey, glad to see you again! It looks like I have some more catch up to play, I see a rails logo on this page... I emailed you a couple of days ago or yesterday about the Ruby support in Riff. There's not a PR yet but we got Ruby into a working state again! It looks like not a lot of people are interested in Ruby on serverless platforms. Can you shed any light on why? And what kind of Ruby support can I expect from knative, given that it's not apparently coming from the Riff project now... as a Rails dev who wants to use this stuff today, how do I get started? (It has a Rails logo on the page linked by the post, so I assume I can use it now, but I haven't gone deeply enough to see if there are limitations... I'm used to Ruby support being neglected in the serverless areas, I don't know if it's because we Ruby devs are slacking, or there's a fundamental flaw I haven't seen yet, or what...) So, what can you tell me about that Rails logo on the landing page?
- jacques_chester 8y ago
  Yes, I'm sorry I didn't reply to you -- I was caught by the problem that I knew this was imminent but not being able to say so (or even hint so). > It looks like not a lot of people are interested in Ruby on serverless platforms. Can you shed any light on why? I imagine there's some mix of market demand and path dependency. A lot of folks who like experimenting moved onwards to the Node ecosystem and a lot of FaaS work has happened there. Meanwhile enterprises are heavily invested in Java and .NET. The riff team at the moment is pretty small. One thing coming up is to fold buildpacks into the code->running pathway for riff. This should make it easier for the riff team to get out of the business of supporting particular ecosystems and for some of the engineering work for buildpacks to be shared amongst multiple setups. In terms of starting with Rails today, it should be possible to use the buildpacks BuildTemplate to run the existing Ruby buildpack. I don't know if it's working, it's early days for heavy automation of development on Knative itself.
  - yebyen 8y ago
    Awesome! That's totally understandable, your non-response was actually a hint that you were up to something, so it's good to see what it was. So I'm not that surprised to find you here in this discussion. I'll check it out in more detail when I'm back in front of a computer! Glad to see the rails logo somewhere new, too.

markusthoemmes 8y ago

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-cloud-google-knative-serverless/ https://www.ibm.com/blogs/cloud-computing/2018/07/24/ibm-clo...

otterley 8y ago
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 8y ago
  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
TuringNYC 8y ago
@markusthoemmes could you kindly comment on how OpenWhisk<-->Knative interact or live together or side by side
- markusthoemmes 8y ago
  This of course needs to be discussed in the broader OpenWhisk community first, but taking dewitt's answer here into perspective (https://news.ycombinator.com/item?id=17604185 https://news.ycombinator.com/item?id=17604185) and also based on what IBM has put out in their statement a possible interaction could be to layer OpenWhisk's higher level abstractions and multi-tenancy features over the knative stack and use the latter as an "execution-engine". In technical terms, OpenWhisk's invoker system could be replaced by knative, keeping the API/Controller bits stable to still support the notion of actions/triggers/rules/sequences/compositions you name it.

dewitt 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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-kubectl.html https://docs.aws.amazon.com/eks/latest/userguide/configure-k...
- jacques_chester 8y ago
  I think PRs would be gladly accepted. But, in general, it should work fine with any conforming Kubernetes system.
- dewitt 8y ago
  I'd love to see a PR that documents Knative on EKS!
- empath75 8y ago
  There seems to be a problem with istio working on EKS, actually -- i'm getting a timeout to the sidecar injector: same issue as this: https://github.com/istio/old_issues_repo/issues/271 https://github.com/istio/old_issues_repo/issues/271

isdal 8y ago

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

gdsdfe 8y ago

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

jacques_chester 8y ago
You have source code. You want a simple way to turn it into running functions and apps, with eventing support, with clever routing and rollout capabilities, without lifting a finger. It's an abstraction layer being developed above both of Kubernetes and Istio.
- gdsdfe 8y ago
  ahh so you just worry about your business logic, which will be a bunch of 'functions', and knative will take care of routing, deployment, load etc. ?
  - jacques_chester 8y ago
    I would say that yes, that is a good statement of the vision that the contributors share.
    - gdsdfe 8y ago
      Got it! thank you! It's actually very interesting ...
  - mattsoldo 8y ago
    It isn't limited to functions. Knative can run containerees, or with a build system take full app code and deploy it as a container.
    - gdsdfe 8y ago
      so it can be anything really ... hmm

gregwebs 8y ago

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?

jacques_chester 8y ago
There will probably be stuff pushed down based on things Knative needs. For example, we've discussed the effect of what we call "the warmth hierarchy" on autoscaling (tl;dr, bad). Solving those problems can't be done entirely at the layer in which Knative is developing -- some changes will need to turn up in Kubernetes (node-local caching awareness) and Istio (workload/node-aware routing).
dewitt 8y ago
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 8y ago
  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.
markusthoemmes 8y ago

mchmarny 8y ago

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

deleted 8y ago
[deleted]
cmonfeat 8y ago
Great post, really cleared up the value proposition of this project for me!

dgllghr 8y ago

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?

jacques_chester 8y ago
Eventing provides primitives that can use messaging systems under the hood (Buses). But it's meant to be a higher level abstraction for connecting functions or applications.
inlined 8y ago
The eventing repo provides a common pluggable model for managing events. The communication layer is currently HTTP, not NATS. But the broker is pluggable and includes support for Kafka. You can choose to use Kafka throughout your cluster or just for a single feed. You can add other implementations as well. The three pluggable abstractions are your event sources, the bus over which events are stored/sent, and the actions which should be invoked in response to an event.
evankanderson 8y ago
"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. :-)

mikevm 8y ago

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

jacques_chester 8y ago
I can't give a definitive answer as I'm not very familiar with Flex. But a lot of Google folks with App Engine backgrounds are working on Knative.
- dewitt 8y ago
  Indeed. Much of what we open sourced in Knative came from what we learned from running GAE and GCF. Which is important: this isn't a side project for us, this is based on real-world experience doing it at scale for huge customers. You don't run a serverless stack for 10+ years without taking away a few lessons. : )
  - geggam 8y ago
    When do you run into rate limiting for scaling up ? We all call it serverless but somewhere there are servers you are using and they dont magically appear from nowhere.
    - isdal 8y ago
      Yep, no free lunch. Scaling up has a few different "cliffs". To outline a few: 1. Existing pod scheduled and ready (fastest) 2. Room on existing node (so no docker pull needed) 3. Room on existing cluster (so no VM creation needed) 4. No room, need to increase cluster size. Optimizing 1-3 is very much in scope for the Knative project. Optimizing (4) is a provider problem and will vary by provider. The Knative Scaling working group is discussing this every week on Wednesdays and that meeting is open to the public. We also keep good notes linked from our community page: https://github.com/knative/docs/blob/master/community/WORKING-GROUPS.md#scaling https://github.com/knative/docs/blob/master/community/WORKIN...
snug 8y ago

minimaxir 8y ago

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

dewitt 8y ago
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. : )

shaohua 8y ago

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

evankanderson 8y ago
How big is your Kubernetes cluster?
deleted 8y ago
[deleted]

pwaai 8y ago

Cold startup time and mitigation strategies like those on AWS?

markusthoemmes 8y ago
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 8y ago
  That tells me not much....is it pinging to keep instances warm?
  - jacques_chester 8y ago
    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 8y ago
      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.

perfunctory 8y ago

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

bigdubs 8y ago
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 8y ago
  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 8y ago
    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.
rifung 8y ago
Isn't that computer science/software industry in general? Everyone builds upon other people's work.

bbayer 8y ago

Digital Ocean is about to ship similar product. https://www.digitalocean.com/products/kubernetes/ https://www.digitalocean.com/products/kubernetes/

evankanderson 8y ago
That looks more like GKE or AKS.
meddlepal 8y ago
No, Digital Ocean's Kubernetes product will be similar to the existing Google Kubernetes Engine... this is much more high-level.
- bbayer 8y ago
  Yeah, you are right. My bad.

lima 8y ago

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 8y ago
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.
smarterclayton 8y ago
We definitely want to support knative, integrated well with existing concepts (like triggering deployments and builds when images change), to stitch in the new build resource so it works well with existing tools like s2i (as Jacques mentioned), and generally make sure these are good building blocks for applications. There’s a lot of good ideas in knative that will benefit anyone who uses Kubernetes.

omegaworks 8y ago

Whats the difference between this and KOPS? https://github.com/kubernetes/kops https://github.com/kubernetes/kops

jacques_chester 8y ago
Knative is on top of Kubernetes and Istio. Kops addresses the bits below Kubernetes.

mfer 8y ago

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 8y ago
> 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.
- dewitt 8y ago
  Just to amplify jacques_chester's reply, yes, we do see products being built on Knative components. Google is doing that (serverless container support in GCF, serverless add-on in GKE), and you can see similar announcements being made from partners in this thread. These are early days of course, but given that the goal is to codify the commonalities (the 80% we all do roughly the same anyway) and to improve customer workload portability overall, I hope to see new products built using Knative, and existing products re-base on Knative as well. Good questions, btw!

falcolas 8y ago

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.

reilly3000 8y ago

How is this different than Kubeless on Kubernetes?

pas 8y ago
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.

polskibus 8y ago

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 8y ago
> 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/5b8542fb58044834d50f71a40d36b936e372a9ec/docs/runtime-contract.md https://github.com/knative/serving/blob/5b8542fb58044834d50f...
- smarterclayton 8y ago
  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.

djhworld 8y ago

How do you pronounce it? Native with a silent K? (like "knave" or "knee") Kay-Native? Kuh-Native?

praseodym 8y ago
From https://github.com/knative/docs https://github.com/knative/docs: “Knative (pronounced kay-nay-tiv)”

sahrizv 8y ago

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 8y ago
Rather than linking to your own tweet, perhaps you could post the comment here and save us all a click?
- sahrizv 8y ago
  Fair point, but the medium changes the message sometimes. :-) The tweet resonated with a sizeable part of the developer community hence linked here.

alexnewman 8y ago

Why would I choose this over kubeless?

mkj 8y ago

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

sequoia 8y ago

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 8y ago

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.