3 ms·

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 a

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
Some of the attributes of serverless workloads will require changes deeper down in the stack (read Kubernetes). For instance constantly getting containers up or throwing them away at high rates stresses parts of Kubernetes more than its used to. I fully expect lots of requirements to make their way into Kubernetes itself.

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

Some of the attributes of serverless workloads will require changes deeper down in the stack (read Kubernetes). For instance constantly getting containers up or throwing them away at high rates stresses parts of Kubernetes more than its used to. I fully expect lots of requirements to make their way into Kubernetes itself.