Google’s Kubernetes container management system is now generally available for users of Microsoft's Azure Container Service.
ACS support is one of a set of changes Microsoft is rolling out to broaden Azure’s container management options to be more open-ended and competitive. In a blog post, Microsoft proclaimed Azure “the only public cloud platform that provides a container service with the choice of the three most popular open source orchestrators available today.”
Bringing the power to all
Microsoft emphasized "choice" when it originally introduced Azure Container Service. Although it launched without Kubernetes, Azure initially supported Mesosphere DC/OS and Docker Swarm because the majority of Microsoft's customers used them and the company believed they would be well served by the support.
Since then, Kubernetes has emerged as a clear leader among container orchestration solutions. It is used as an underpinning for deep learning frameworks and the basis for an open source serverless/“lambda” app framework, as well as offered as a managed on-premise service by one company.
Kubernetes on Azure is strictly focused on running Kubernetes within Azure, not providing it as a service elsewhere. But the GA release includes additions meant to appeal to a broad audience of both Linux and Windows Server users, such as support for the latest version of DC/OS (1.8.8).
Getting Kubernetes to work well on Azure was not inherently hard, but some missing features needed to be built, according to Brendan Burns, Partner Architect at Microsoft. High-availability clusters, for instance: “In the preview, you could only have a cluster with a single master,” said Burns. "You could have multiple worker machines, but only one brain for the cluster; if that machine failed, you had problems.” Users can now choose multiple nodes to serve as masters in case one or more fails.
Scaling was another feature that Microsoft wanted to add. “You can take an existing cluster, and you can increase its size if [you] need more capacity,” said Burns, “or you can decrease its size [as well].”
Microsoft saw such features as must-haves for the service, but found room for “polish work” elsewhere as well—for instance, a better command-line tool. Microsoft also found bugs affecting disks that were mounted and unmounted into containers in the cluster and submitted those upstream—although those fixes mainly addressed compatibility with Azure’s storage systems, rather than more general issues.
One other late-breaking addition is a preview of Windows Server Containers with Kubernetes, recently made possible by work on multiple fronts. Here again, Microsoft's concerns seem less technical than philosophical. If Kubernetes is becoming the container system of choice, Microsoft is wise not to let its container format lose out.
The do-it-yourself, developer-friendly way
Microsoft’s need to keep abreast of container trends is informed in large part by the fact that containers have become “their own platforms for application delivery,” said Burns. Based on what has been built with Kubernetes on Azure so far, these platforms “are going to be in-house platforms, but they’re building on top of the container orchestration layer as a building block,” he said.
That container orchestration layer is becoming the new virtual machine, a sign that container as a service is becoming the preference for implementing platform-as-a-service functionality. A traditional PaaS is built down to the metal or VM. But now, “I think we’re seeing container orchestration take over as the new infrastructure, on which more developer-centric platforms are being built,” said Burns.
“The container image has become the new way to package and deliver your software, and that image is language-agnostic and kind of platform-agnostic,” he continued. Orchestration layers run the containerized app, keep it healthy, and provide load balancing.
The new container-based PaaSes don’t have to be as focused on the nitty-gritty of distributed system building. They can leave those duties to Kubernetes and concentrate on providing “a rich developer experience—getting somebody from source code out to a deployed running application,” Burns said.