Supporting different operating systems shows the flexibility of the Kubernetes system.
The "core" of Kubernetes is an API server backed by the etcd key-value store (diagram[1]). Everything is a client of this API server: the scheduler, the kubectl CLI, and the nodes that run the workloads themselves.
This means the agent that starts and babysits the containers, called the Kubelet, can be reimplemented for some other operating system, as has been done here, without a ton of coordination across other components.
Further, because of Kubernetes's labeling system[2] it is easy for a workload to express constraints like the need to run on machines with certain features using a nodeSelector[3].
There is a lot to do before getting Windows support fully working but today it is a great showcase of Kubernetes's flexibility.
I'm anxious to see if OpenShift ends up supporting Windows Server - we've got a fair amount of .Net applications that are impossible to port to the CoreCLR due to various vender supplied libraries and a fairly deep use of Windows authentication with them (we can abstract the authentication for our applications to an auth service and use JWT or OpenID connect, but lord knows how we could get these 3rd party libs to work).
Cloud Foundry can already manage Windows applications and has been doing so for some time now. There's also a .NET Core buildpack for those who are OK with using it.
The underlying components (Garden and Diego) were written with this possibility in mind, long before Microsoft themselves made any move to simplify containerisation on their platform. It'll definitely become easier in newer versions of Windows as Microsoft expose more APIs to implementors.
But lots of people won't move in a hurry, so backwards compatibility is done the hard way. I don't know much about the hard way.
Disclosure: I work for Pivotal, the major donor of engineering on Cloud Foundry. By coincidence in the same office as the Greenhouse team ("Garden on Windows", geddit?).
I looked at CloudFoundry as an option, but I was underwhelmed at the platform seeming like it was more designed for companies to provide their own PaaS with it as a base for orchestration than it being a ready-to-go solution. It's great that Diego can support Windows apps, but CloudFoundry doesn't look like a great solution for a team like ours who just wants a set of nice tooling to deploy and manage our applications without having to jump to the CLI for everything (I may be comfortable with this, but I do work in a primarily .Net shop).
We're mostly focused on getting the core enabled in Kubernetes. I would like to see it happen once some of the wrinkles in Windows support get ironed out.
Windows Server Containers can run two installation types of Windows: Nano Server, and Windows Server Core. any type of application that can run under those two operating systems is supported in containers.
For example, Windows Server Core supports the full .NET ecosystem.
Michael Michael
SIG-Windows Lead for Kubernetes
@michmike77
Does nano server support 32 bit binaries now? I played with Windows Server 2016 containers on Azure earlier this year, and nano did not support 32 bits then. That rules out a huge amount of legacy Windows Server SW.
The "core" of Kubernetes is an API server backed by the etcd key-value store (diagram[1]). Everything is a client of this API server: the scheduler, the kubectl CLI, and the nodes that run the workloads themselves.
This means the agent that starts and babysits the containers, called the Kubelet, can be reimplemented for some other operating system, as has been done here, without a ton of coordination across other components.
Further, because of Kubernetes's labeling system[2] it is easy for a workload to express constraints like the need to run on machines with certain features using a nodeSelector[3].
There is a lot to do before getting Windows support fully working but today it is a great showcase of Kubernetes's flexibility.
[1] https://speakerdeck.com/philips/tectonic-summit-day-2-keynot... [2] http://kubernetes.io/docs/user-guide/labels/ [3] http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_...