5 ms·

Kubernetes is getting a number of extensibility features in this release. The net new one is "API Aggregation" which enables the addition/registration of API se

Kubernetes is getting a number of extensibility features in this release. The net new one is "API Aggregation" which enables the addition/registration of API servers behind the primary API server. And there is sort of a toolkit for building these new API servers emerging[1]. The second major one is "third-party resources" which has now been renamed to custom resource definitions. These power a number of software systems[2] today and the changes are explained in this blog post[3]. [1]: https://github.com/kubernetes-incubator/apiserver-builder https://github.com/kubernetes-incubator/apiserver-builder [2]: https://github.com/coreos/awesome-kubernetes-extensions https://github.com/coreos/awesome-kubernetes-extensions [3]: https://coreos.com/blog/custom-resource-kubernetes-v17 https://coreos.com/blog/custom-resource-kubernetes-v17

hosh 9y ago
"API Aggregation" along with CRDs are going to be huge. It essentially lets people create plugins and Operators more easily, without having to go through the development and release cycle for the core project. That's going to accelerate a lot of innovation. Combined with Helm charts and some discovery mechanism, and it is going to crank things up for Kubernetes even more so than what we've seen in the past year and a half. I was looking at service-catalog, and I got thinking, wow, K8S rapidly catching up to CloudFoundry. It may not be long before it starts overtaking it. I still wonder how the pre-container generation of DevOps tools will work with this -- Puppet, Chef, Ansible, etc. It seems to me that all the older-generation devops "infrastructure as code" tooling are one move behind Kubernetes.
- lobster_johnson 9y ago
  I wonder if the plan is to eventually split out core controllers into separate modules. For example, the replica set controller could easily be its own thing that ran as a pod; what it does, fundamentally, is ensure that the correct number of pods exists for a specific template. Kubernetes is, conceptually, MVC. There's a data store of objects that describe what the world should look like, then a bunch of controllers that use this store to continually "converge" and "repair" the world so it looks like the description, plus APIs to perform specific actions such as perform a rollout or undo. With this new addition, you get closer to erasing the conceptual distinction between "core" Kubernetes and everything else, which is great.
  - hosh 9y ago
    I don't know if the core is going to get split. There might not be a reason (overhead with memory, more to supervise). It's kinda like MVC but I think it follows more closely to the control/convergence loop you are talking about (and from there, Promise Theory), whereas MVC don't really have that control loop. On the other hand, Operators are essentially non-core controllers. They can be highly specialized to a specific system (etcd, kafka, postgresql, etc.) Same with service catalogs.
    - smarterclayton 9y ago
      It's likely things will continue to subdivide gracefully, but I don't know how likely we are in the near term to split out the existing apis and controllers. The line will be drawn more strongly for net new things - do it as an extension, not in core.
  - puzzle 9y ago
    In 1.7 cloud controllers are already on their way to run externally.
    - lobster_johnson 9y ago
      That's great. Kubernetes is already huge, and a pain to develop against because it takes a long time to compile and test, never mind check out the code; moving stuff out should help here. (They've fortunately taken some steps to pull out the client into separate repos, so you no longer have to link your project against the entire Kubernetes codebase.)

hosh 9y ago

"API Aggregation" along with CRDs are going to be huge. It essentially lets people create plugins and Operators more easily, without having to go through the development and release cycle for the core project. That's going to accelerate a lot of innovation. Combined with Helm charts and some discovery mechanism, and it is going to crank things up for Kubernetes even more so than what we've seen in the past year and a half. I was looking at service-catalog, and I got thinking, wow, K8S rapidly catching up to CloudFoundry. It may not be long before it starts overtaking it. I still wonder how the pre-container generation of DevOps tools will work with this -- Puppet, Chef, Ansible, etc. It seems to me that all the older-generation devops "infrastructure as code" tooling are one move behind Kubernetes.

lobster_johnson 9y ago
I wonder if the plan is to eventually split out core controllers into separate modules. For example, the replica set controller could easily be its own thing that ran as a pod; what it does, fundamentally, is ensure that the correct number of pods exists for a specific template. Kubernetes is, conceptually, MVC. There's a data store of objects that describe what the world should look like, then a bunch of controllers that use this store to continually "converge" and "repair" the world so it looks like the description, plus APIs to perform specific actions such as perform a rollout or undo. With this new addition, you get closer to erasing the conceptual distinction between "core" Kubernetes and everything else, which is great.
- hosh 9y ago
  I don't know if the core is going to get split. There might not be a reason (overhead with memory, more to supervise). It's kinda like MVC but I think it follows more closely to the control/convergence loop you are talking about (and from there, Promise Theory), whereas MVC don't really have that control loop. On the other hand, Operators are essentially non-core controllers. They can be highly specialized to a specific system (etcd, kafka, postgresql, etc.) Same with service catalogs.
  - smarterclayton 9y ago
    It's likely things will continue to subdivide gracefully, but I don't know how likely we are in the near term to split out the existing apis and controllers. The line will be drawn more strongly for net new things - do it as an extension, not in core.
- puzzle 9y ago
  In 1.7 cloud controllers are already on their way to run externally.
  - lobster_johnson 9y ago
    That's great. Kubernetes is already huge, and a pain to develop against because it takes a long time to compile and test, never mind check out the code; moving stuff out should help here. (They've fortunately taken some steps to pull out the client into separate repos, so you no longer have to link your project against the entire Kubernetes codebase.)