2 ms·
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 c
by 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 agoRe: 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.