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
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.
Sorry, I'm still pretty new to Kubernetes. I am exploring using Serverless Framework + AWS Lambda/GCP Functions to build out a full CRUD-like REST API backend. If I used Knative, would I achieve a similar functionality? Would each "function" (i.e. endpoint) be deployed in a separate container? If it's all in one single (autoscaling) container you still don't acheive full pay-for-what-you-use, right?
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.
The exact economics depend on where the billing boundary falls. For on-prem the economics will probably follow one of central IT budget, showback or chargeback and I expect the case for hugging the curve as tightly as possible is weaker.
For cloud providers the boundary is likely to become execution-seconds. As Kubernetes worker nodes become abstracted away this will be the remaining way to track utilisation.
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.
You basically have a git repo that contains your business logic implemented as 'functions' and some configuration : knative will build, containerize, deploy, and glue/route those functions for you to make it a full fledged app. it will also take care of load balancing/scaling etc.
So all you need really is focus on you business logic code and write some config for knative ... well this is at least the vision
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 the pedals ...
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.
One of the items that's not present at the moment (and dewitt can probably provide additional color) is the top-level developer shell which puts the pieces together with a minimal amount of client-side work. If you can see Oren's GCP Next talk (https://cloud.withgoogle.com/next18/sf/sessions/session/2204... -- which doesn't show build or events yet), you can see a deployment using `gcloud serverless` to both containers on GCF and a Knative cluster, which differ only in a single flag to gcloud to tell it which endpoint to use.
The short summary if you had a nice client shell would be:
1) Run a command to deploy. That command:
a) determines what build templates are available on your cluster and what language/tools you're using, and finds a match between the two.
b) Creates a YAML definition of your application on the Knative cluster(and stages your source if needed).
2) On the server side:
a) The build component will (optionally) trigger to take staged source and convert it to a container.
b) The serving component will create Istio routes and various pieces to schedule your app into a k8s Deployment.
i) This Deployment will scale to zero if there's no activity, and scale back up if needed.
ii) Scale-to-zero is accomplished via a (shared) "actuator" which stalls the incoming HTTP request until a Pod is live.
c) Additionally, the serving components loads various observability tools like Prometheus and ELK (by default, the no-mon or lite installs skip this) so that you can see what's happening even as your pods appear and disappear.
Sorry I was just trying to help.
You're obviously perfectly capable of clicking on links, reading and figuring out things for yourself... My intent was to help figure out if this was worth investigating as you were wondering to which I clearly failed.
You car analogy is still falling short but it doesn't matter.
Best of luck ;)
The car analogy is just right, IMO. It's a functional description of how a car works at a high level, so that we can understand how it's put together; and if we're reasonably expert in mechanics, we can fill in a lot of missing details. Whereas "a box that you sit in that lets you get to where you want to go quickly" leaves out far too much detail.
Too many descriptions of tools for devs sell benefits instead of functions. This is normally good sales practice, but devs are experts in the mechanisms behind the tools they use, and they generally prefer more functional descriptions so that they can more quickly evaluate whether any given tool is a good fit for them, and what its strengths and weaknesses will be.
Yeah, on the other hand I'm looking closely at this one just because of the people that showed up in this thread. I know some of these guys and their past work is exceptional, so if they're claiming to be involved in this, I am sure I'll be sorry if I don't check it out.
> ...But a car is based on general principles which most of us understand... (etc)
This is bar none the best explanation I have ever read of how a car works, without hand waving, to clarify for non-believers in car technology. I want to reward you, but I am kind of an outsider who honestly just strives to use Kubernetes, unsuccessfully, and I haven't got it off the ground at my organization yet (and I may never...)
So let me do my best, as an outsider who you must understand is absolutely hand-waving based on a quick read-over of the high-level documentation, and an understanding of how these systems go wrong; but I have no honest understanding of this particular stack (but then again, I've seen a lot of what some of the contributors are doing, so perhaps your grain of salt need not be too big... but I digress, in under 20 sentences...)
Serving Scale to zero, request-driven compute model:
You're aiming to build out your environment inside of a small footprint. If all of your customers go away, and stay gone for a day, you'd really like for your stack to approximately stop the cash bonfire altogether. This is a goal of the stack, too.
Build Cloud-native source to container orchestration
So your footprint is a program, and you programmed it in a language... great, an event... to be treated like other events, like a new customer that visits your website, or a new commit from one of your devs... whatever build is necessary for your stack to come into being, it's handled inside of this stack. Not to spoil it, but: events like this are the key driver for the entire system, which the system architecture actually reflects in a way...
Events Universal subscription, delivery and management of events
A minimal gateway serves as router that intercepts customers, and serves as infrastructure stander-upper, standing up the infrastructure on-demand while the greater parts of your stack are basically disposable and automatically self-destructive, so that every time a new customer comes along, the request actually starts the whole response stack anew. Then, upon finding no further traffic to answer, the newly provisioned stack rapidly disposes of itself to save on the cost.
The response stack tears itself down entirely on the way after the response is served. Unless there's another customer, if the capacity remains un-utilized for long enough to leave a mark... it's gone. But obviously this goes both ways. We don't want anyone to keep waiting in periods of increased load, if ever there's no capacity available, we want to increase the capacity as demand is spiking, in response to the demand to keep it satisfied. Again, this is baked into the platform.
Serverless add-on on GKE
* the fine print, you must at least have GKE or another Kubernetes cluster or provider at equivalent service levels to enjoy the benefits described above. This runs on GKE, or to be more precise, Kubernetes. That infrastructure stander-upper actually lives in the footprint of a GKE cluster. If you've paid for a cluster before GKE, don't worry, what I just said is still potentially much smaller and cheaper than you think. (GKE can scale to about $5/mo baseline footprint if you are small-time like me.) If you know how resource scheduling on Kubernetes works and you know how Autoscaling of Kubernetes cluster nodes works, you're about 90% of the way there toward knowing how this scaling situation works too.
There is a function gateway, that minimal gateway that I spoke of under "Events", and it is a persistent process that can't be stowed away for cheaper when it is not answering requests. But it drives the whole cluster. It spins up extra demand when events result in requests on topics that spawn Pods to respond, and Kubernetes will react to Pending pods with new Nodes to allow extra capacity to schedule those pods. tl;dr You need not keep extra capacity around when it's not actually needed. Don't even worry about it. The cluster will autoscale in response to rising and falling demand, and the bill will definitely come at the end of the month.
---
I've been trying to wrap my head around the whole Serverless Function thing for a couple of weeks now, as a Rails dev who hasn't had very much exposure to it and a Kubernetes enthusiast, well I think I get it now. (No one serverless stack is going to win, but obviously there will be a winner. Scaling to zero is the big win here. It's not the first platform to purport to scale in response to events, and even scaling down to zero, but not many have done this from what I can tell.)
Riff is one that advertised this "scale to zero" capability in their project before, and they are apparently involved with this project too, so that's neat. But if it's a car, back to where you started... and the commits from your developers are the feet on the pedals, ...oh hell we don't really need another car analogy do we? I seriously can't write anymore of this kind of garbage now, at least until I get my keyboard on the terminal for a while and try the thing out.
Supported on Minikube. I can tell you I tried Riff out this weekend (Riff team is represented here in this thread, they are apparently deeply involved in Knative), and I went through the experience of adding support for a new language runtime for Riff, and it was a lot like "not really having to do anything" other than put my feet on the pedals and keep control of the wheel, in terms of how the stack let me do what I know about, and getting out of my way for the most part.
I think I'll learn how to use gRPC now. I think I get the idea of what a "sidecar" container is really meant to be used for, now. I think I should stop writing though, and try compiling the source and see how this new runtime environment on Kubernetes behaves. I hope it's better than Riff (because Riff was impressive from the demo to the trial, but I don't think the Riff devs will be working and focused on this instead, unless it's actually going to be even better than that. They have no lack of vision in this space, in my humble opinion.)
The serverless.com framework is built around existing serverless/faas platforms and allows you to write vendor-agnostic functions and deploy them exchangeably. It does not provide the resources to run your code. it abstracts away different API of different vendors to make them seem as one.
Knative on the other hand provides building blocks to eventually build a serverless platform. It provides the resources necessary to run and scale your application.
In short: You could use the serverless.com framework to deploy applications/functions on knative. But you still need some layer actually running your workload, like knative.
not sure they seem quite similar (I am not familiar with neither to be honest) but the main difference in my opinion is this is built on open source and backed by the big boys : google, IBM, SAP ..etc
serverless is a config/deploy thing that deploys "functions" (to lambda etc.), ties them to HTTP routes or other events, provisions resources (storage etc.), ties them to your applicatoins etc.. The main thing it does not do is scaling etc. because you're deploying to a platform that handles that.
Thank you for the link to the samples, they are much more informative. But it still doesn't quite explain it.
The samples show that you can make an app, make a container, and make a service config file, and deploy your app to K8s. Yes, we've been able to do that for some time now.
This thing is supposed to provide a bunch of advanced features for devs to not have to think about. However, the build repo says this:
"While Knative builds are optimized for building, testing, and deploying source code, you are still responsible for developing the corresponding components that: + Retrieve source code from repositories. + Run multiple sequential jobs against a shared filesystem (for example, Install dependencies, Run unit and integration tests). + Build container images. + Push container images to an image registry, or deploy them to a cluster."
"While today, a Knative build does not provide a complete standalone CI/CD solution, it does however, provide a lower-level building block that was purposefully designed to enable integration and utilization in larger systems."
So as a developer you still have to have all the things you had before, but with extra layers of abstraction now, apparently just to support hybrid cloud installations.
The marketing lingo appeals to developers as if it makes all this simple, when in fact it may be more complicated.
I don't get it either. It seems like a big clapping for hot air. Yeah, it's great that there's a proper build, serve and events responsibility group, and now what? What's the "killer app" here, "the use case"?
It seems to me that the weakest part of this is build currently. Mostly because that's what's pretty linear and one-off, and well explored by other projects (GitLab CI/CD can easily run on and deploy to k8s), and knative is mostly about serving and eventing, meaning all the interaction between the lifecycles of stuff on k8s.
It'll be interesting to see the differences from other systems in this space (OpenShift, Deis Workflow). From the samples it appears to be more of a "pull code from github and push to Dockerhub" model than a "push code to the platform and push to an internal registry" that other PaaSes target.
Oh, I miss Deis, but congrats on the MS acquisition.
I think looking at build is not interesting, because it seems that knative currently focuses on the serving and events part (some thoughts on this you might find interesting: https://news.ycombinator.com/item?id=17607401 )
The repository is just an example. Using an internal repo seems just as easy.
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.
It's a bit funny that knative serving is so complicated I have still no idea what they use under the many layers of abstraction (probably something hacked together in go), and I don't understand why don't they use a generic configurable ingress component.
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.
I think Knative (and the scale to zero in particular) are best suited for request/response or event-delivery workloads. So you wouldn't want to run (for example) memcache or mysql under knative. FaaS and (HTTP application) PaaS are both good matches.
I think it's an open question whether a PaaS like Google Dataflow is a good match or not. It will certainly require more planning, but I think it's doable.
Yeah but don't forget this is a higher abstraction on top of microservices. I think the big take away here is that if your app falls into the patten of 80% of modern apps (can't remember where is saw that number, don't quote me :) and is split properly you can have all your 'ops' part as configuration.
This is what I am trying to figure out too. Is Knative standalone, or is it running inside your K8 cluster, or do you build a K8 cluster and run this in it exclusively?
Knative installs into a Kubernetes cluster. Knative as it stands is not multi-tenant, so if you need to isolate workloads, you will need distinct Kubernetes clusters.
It has software, yes, that of course runs in pods, but ..
It's a whole lot of infrastructure to support a PaaS / FaaS workflow. From building and routing/serving/tracing to complex event driven stuff.
It's fully k8s native (hence the name, I reckon), and it uses CRDs. Which is basically k8s's DSL for describing anything. Basically a k8s-standard for k8s plugins with schema, validation, schema change management, kubectl support, etc.
Based on the linked GitHub readme, it seems that this allows you to deploy autoscaling apps ready for public consumption without having to worry about defining load balancers, ingress routes, etc. There's a lot of documentation and it's difficult (for me) to completely grok.
Serverless means that you as a developer don't have to manage servers. There's still real computers behind the "serverless".
Knative calls the role of the person providing the servers are "operator". Kubernetes is great for operators because it has a lot of common low-level primitives, and lots of choice if you want to pay someone else to be your operator.
Knative aims to give a similar great experience to developers if you can convince your operator to install it on top of the kubernetes they already have. In particular, if an operator charges you for container runtime minutes on knative, you're getting close to the pay-per use model of lambda or app engine. Also, as you noted, developers should have fewer concepts they need to grok in order to deploy a knative app compared with kubernetes.
