
Kubernetes 1.7: Security Hardening, Stateful Application Updates and Extensibility - clhodapp
http://blog.kubernetes.io/2017/06/kubernetes-1.7-security-hardening-stateful-application-extensibility-updates.html
======
philips
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
"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
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
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
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.

------
djb_hackernews
Does Kubernetes support adding "middleware" between it and docker? ie when it
comes time to do a container start, it calls my custom plugin instead of
docker directly? I read the docs about extensibility and it didn't seem so.

~~~
puzzle
What kind of plugins are you thinking of?

~~~
djb_hackernews
This is a very simple example. But we require setting the pid limit cgroup.
Right now Kubernetes doesn't support this (again, just an example, there are a
lot of things kubernetes doesn't support that we need beyond pid limits).

So it'd be nice to be able to proxy the call to docker to inject our own
config before hitting docker. It looks like CRI is exactly what we'd need,
possibly maintaining our own fork of the docker shim? Trying to figure out if
there is a way to put in arbitrary data in the config sent to the docker
shim[0]

[0]
[https://github.com/kubernetes/kubernetes/blob/master/pkg/kub...](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/cri/v1alpha1/runtime/api.pb.go)

------
Perceptes
Has the apt repo been updated? `apt-get install kubelet` is still giving me
v1.6.6. I'm using `deb [http://apt.kubernetes.io/](http://apt.kubernetes.io/)
kubernetes-xenial main` as the apt source.

Edit: I think it's a mistake. Reported here:
[https://github.com/kubernetes/release/issues/358](https://github.com/kubernetes/release/issues/358)

------
SjuulJanssen
I just checked Google container engine. It's not available yet in the update
list for GCE

~~~
gtirloni
Kubernetes is a community project, not directly tied to GKE release dates [0]

K8s 1.6 was released on March 28 and GKE made that version available on April
4. I would expect a similar wait time to 1.7.

0 - [https://cloud.google.com/container-engine/release-
notes#supp...](https://cloud.google.com/container-engine/release-
notes#supported_kubernetes_versions)

~~~
timdorr
It may be a little more delayed because of the US 4th of July holiday:

> There will be no release for the week of July 3rd, since this is a holiday
> in the US. The next release is planned for the week of July 10th.

