Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Knative – Kubernetes-based platform to manage modern serverless workloads

cloud.google.com

Post reply on HN
Print view View original

121–130 of 168 posts

Re: Knative – Kubernetes-based platform to manage modern serverless workloads

#121

Post by isdal »

happythought wrote: post #111
isdal wrote: post #45

Earlier quoted context omitted.

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 full…

I’ve read through this whole thread and everyone is struggling to understand the primary use case for knative. Your comment is the most clear. Please please please at the forefront of all docs, presentations, and blogs put something like this: Knative’s primary use case is for you to provide your own cloud-neutral, on-prem, or hybrid-cloud serverless platform built on top of kubernetes.

Thanks! In my mind a key goal for Knative is to: "Free customers from serverless lock-in through industry-wide portability" I think I like your version better so maybe I should start using that :-)

We are still very early in the process so code (and comms) are a bit rough. Really appreciate your feedback and we will work to clarify things over the next few days.

Re: Knative – Kubernetes-based platform to manage modern serverless workloads

#122

Post by hrktb »

pas wrote: post #62
peterwwillis wrote: post #52

Earlier quoted context omitted.

Can someone also give us a 20 sentences explanation on how it works, or an example installation? "It does magic" still leaves me wondering if this is worth investigating.

it's a PaaS .. heroku for k8s https://github.com/knative/docs/tree/master/serving/samples/...

Interesting.

I had to learn Kubernetes very recently and this seems to simplify a lot of the boilerplate needed to have an app running.

One the most grating part for me was having the ingress run with a proper SSL certificate with the right handshakes though (had to install a nginx controller just for that).

That’s the kind of things that everyone will go through, and is solved in one click on heroku. Yet it seems to be left out of all the samples, if it’s out of the scope that diminishes a lot the appeal.

Re: Knative – Kubernetes-based platform to manage modern serverless workloads

#123

Post by yebyen »

bigdubs wrote: post #48
perfunctory wrote: post #46

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

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.

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.

Re: Knative – Kubernetes-based platform to manage modern serverless workloads

#124

Post by yebyen »

jacques_chester wrote: post #119
yebyen wrote: post #113

Earlier quoted context omitted.

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 kn…

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 wo…

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.

Re: Knative – Kubernetes-based platform to manage modern serverless workloads

#125

Post by peterwwillis »

gdsdfe wrote: post #109
peterwwillis wrote: post #105

Earlier quoted context omitted.

This is just a summary of what it is. A car is a machine that moves you around the roads. But how does the car work ? Are you using it? Because the docs seem to show that what you describe is not the case. The devs seem to have to write integrations for everything, so almost nothing is done for them. Saying Knative will "do it for you" is like saying your car will "drive itself". You only have to steer it and work th…

I am giving you the higher level view on what I think it does ... read the docs! or even better the source code it is open. Explaining to you how the car works can be as far as explaining how physics work, because you need understand combustion, gravity etc. EDIT: and that will exceed 20 sentences by a few very heavy books.

According to the docs, the high level overview is misleading.

You don't have to explain physics to explain how a car works. You only have to explain it in terms of something your audience is familiar with. Magnetization would be hard to explain to someone without physics, because there's no other parallel to quantum mechanics for the average person.

But a car is based on general principles which most of us understand at a simplistic level. We understand "stickiness", so "stickiness" can stand in for "coefficient of friction". We understand "weight", so we don't have to explain how gravity works. We understand that fuel, oxygen and a spark creates a fire (or explosion), so we don't have to explain chemical reactions. We also understand that explosions exert a force on things around them.

So when I say that an explosion in your car's engine exerts a force pushing against a piston, and that piston is connected to a rod, and that rod pushes on and turns a crank, which (skipping the transmission for brevity) turns an axle, which is connected to a wheel whose tire is stuck to the road, and that the weight of the car on the wheel forces either the road or the tire to move, we understand that even though the car is heavy and the turning force on the tire is pretty strong, the road is probably stronger and isn't going to move, so instead the tire moves, and the car is attached to the tire. So you can understand at a basic level how a car works without having to know physics.

What I was asking for was what combination of components in what order are required to make the thing run, and how these things are accomplished without the developer seeming to have to do anything. If they've built a car for developers, that's great, but it seems more like they've created nuts and bolts.

Re: Knative – Kubernetes-based platform to manage modern serverless workloads

#126

Post by jacques_chester »

happythought wrote: post #111
isdal wrote: post #45

Earlier quoted context omitted.

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 full…

I’ve read through this whole thread and everyone is struggling to understand the primary use case for knative. Your comment is the most clear. Please please please at the forefront of all docs, presentations, and blogs put something like this: Knative’s primary use case is for you to provide your own cloud-neutral, on-prem, or hybrid-cloud serverless platform built on top of kubernetes.

It's probably harder for us to dig ourselves out of the various deep dives and rabbit holes we've been over the past few months.

I think there are two parts to the story here. One is what Knative is for, what it can do. That's some version of "source code to event-driven system on any Kubernetes system without the tears". As with previous Big Changes there will be a cottage industry of explanations, and that is fine.

The second part of the story is: who is working on it. And that's the underrated part for me so far. You see Pivotal and Red Hat -- we are fierce competitors -- working on the same project with Googlers, IBMers and SAPers. You find folks who work on riff and OpenWhisk sitting in calls with engineers who've worked on Google Cloud Functions comparing notes on problems and solutions.

I have sat in working groups where experiences have been shared from Cloud Foundry, OpenWhisk and Google App Engine in the space of 5 minutes. I've sat in other calls with teams comparing notes on Buildpacks and S2I, Concourse and OpenShift ImageStreams ... it goes on and on.

The big story here is that Google were able to catalyse a conversation that would be very difficult to start any other way. People from contributing organisations are busily sorting out common ground that will let everyone to move past this level of abstraction much quicker than would otherwise be the case.

Re: Knative – Kubernetes-based platform to manage modern serverless workloads

#127

Post by isdal »

geggam wrote: post #61
dewitt wrote: post #36

Earlier quoted context omitted.

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. : )

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.

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/WORKIN...

Re: Knative – Kubernetes-based platform to manage modern serverless workloads

#128

Post by jacques_chester »

otterley wrote: post #66
evankanderson wrote: post #38

Earlier quoted context omitted.

"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…

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

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...

[1] https://docs.google.com/document/d/1uGDehQu493N_XCAT5H4XEw5T...

Re: Knative – Kubernetes-based platform to manage modern serverless workloads

#129

Post by joshlambert »

mfer wrote: post #101
sytse wrote: post #85

Earlier quoted context omitted.

I just had a call with Josh, a GitLab product manager, that maybe helps with some of your questions https://www.youtube.com/watch?v=k1jK4F4NoBw

Thanks for sharing. Noticed you talked a bit about kaniko. It has some security issues that have been talked about but last I checked not addressed by the kaniko team. How are you dealing with those?

Thanks for watching mfer! Kaniko certainly doesn't address all of the challenges with building containers securely, but I think it's the best solution available _today_ that supports the common Dockerfile workflow.

There are a number of other promising tools like img, but aren't readily usable yet because of a dependency on some upstream PR's.

At GitLab, we're trying to think of ways to help developers understand the challenges, as well as provide easy to adopt solutions as these tools become available. Would love your thoughts and feedback: https://gitlab.com/gitlab-org/gitlab-ce/issues/48913

Re: Knative – Kubernetes-based platform to manage modern serverless workloads

#130

Post by smarterclayton »

lima wrote: post #56

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.

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.
Post reply on HN