Apprenda-led Team Preps Kubernetes to Manage Windows Containers – InApps Technology 2022

Apprenda is leading work to modify the Kubernetes orchestration engine so that it can also manage Windows containers, just like it manages those that run on Linux.

The Kubernetes’ Windows Special Interest Group is spearheading the effort, and having Apprenda do much of the heavy lifting makes sense. The company, having offered enterprise-focused platform services since 2007, has cultivated a deep understanding of Microsoft Windows Server and .Net architectures. It branched out into Kubernetes earlier this year, purchasing Kubernetes’ startup Kismatic, and releasing its own commercial Kubernetes toolkit.

A version Kubernetes that could run Windows containers would expand the number of enterprise applications the orchestration engine could manage — and potentially broaden its possible user base — and the user base for containers, considerably.

According to Gartner, 85 percent of enterprise software currently runs on Windows. Microsoft “.Net is not going away anytime soon,” said Michael Michael, Apprenda senior director of products, during a presentation of the new technology at the Kubecon conference earlier this month. The augmented software would give organizations, “a truly hybrid environment between Linux and Windows,” he said.

There are two types of Windows Server Containers. The basic Windows container shares the Windows Server kernel with all the other Windows containers. The Hyper-V container, built for security, is embedded in a virtual machine, complete with its own kernel. This version of Kubernetes will support both. The API is the same for calling both containers, just a difference in a flag to distinguish the two.

“When we started architecting our solution one of our main goals is that we didn’t want to modify anything on etcd or the master components,” Michael said. The etcd software is a key-value store used to keep track of containers.,

Luckily, Kubectl and the master components, which would run on a Linux server, required no modifications, thanks to Microsoft’s adherence to the Docker API.

Because of Kubernetes’ modular architecture, the development team could confine all the work they needed to do to providing an abstraction layer to Kubernetes’ kube-proxy, which talks to the front end network components, and to the Kubelet components, which acts as a node agent for each server node. Both are placed on the worker nodes running Windows Server. (CoreOS took a similar approach modifying Kubernetes to support CoreOS’ rkt container format as well, Michael pointed out).

See Michael’s diagram here to see how it all works together:

Graphic courtesy of Apprenda.

The team had to root out all the low-level primitives for Linux and replace them with their closest Windows equivalents. “The bulk of the changes and most of the complexity was around networking,” Michael said.

The team had to grapple with two types of networking issues: inter-pod communications and intra-pod communications. Both of which requires Windows containers to be handled slightly differently than Linux ones, he explained.

Linux containers within a single pod share a single networking namespace, allowing them to communicate. The pod has a single IP number, so the containers talk amongst themselves by localhost calls. Windows doesn’t have a networking namespace abstraction, however, so each container keeps its own IP address and networking stack.

Windows also doesn’t have any native support for software-defined networking (SDN), so SDN techniques such as overlay networks won’t work too effectively with Windows. “You couldn’t get a single IP to a pod that was routable across an entire cluster,” Michael said. Instead, the development team used Windows’ Routing and Remote Access Service (RRAS) for discoverability.

Work also had to be done for kube-proxy as well, many providing workarounds to the fact that Windows doesn’t have a single equivalent to iptables, a utility system used to set up rules on where network packets should be routed.

Microsoft engineers have been helping Apprenda with this effort, said Microsoft Partner Architect Brendan Burns, also at Kubecon conference. Here is a demo of the software in action:

The development team is aiming to have experimental “alpha” version of these capabilities ready for the Kubernetes 1.5 release due later this year. After this initial work is completed, work will commence at supporting Kubernetes’ advanced features, such as native networking overlay support and persistent volume storage support.

Feature image: The Windows Kubernetes’ development team at Kubecon 2016.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.