Google Leads Coalition For Container Management

Google I/O 2014: 10 Big Developments

An unlikely group of allies has formed to promote Google's Kubernetes container migration and management system. Kubernetes means "helmsman" in Greek, and Google has used its extensive experience in running Linux containers to build the Kubernetes system.

It's now backed by IBM, Red Hat, Microsoft, and Docker. They will all work to ensure that container management is standardized as much as the surging Docker format for dictating the way container workloads will be built.

"Google has the best infrastructure in the world. Our infrastructure engine is the best that money can buy," boasts Craig McLuckie, product manager for Kubernetes and the Google Cloud Platform, which includes Google App Engine and Compute Engine.

Each member of the group will contribute developers and coordinate efforts to make Kubernetes a more general-purpose container management system, one that's been tested for production use. McLuckie claims Kubernetes can handle the provisioning of containers, migrate them, monitor them as they run, assess their operational status, and provide dynamic scheduling and load balancing.

[Want to learn more about how CoreOS plans to make containers more efficient? See CoreOS Unveils Linux Containers As A Service.]

"We're contributing heavily to the Docker project. We also want Kubernetes to go wherever you take a Docker container," McLuckie told us in an interview.

McLuckie says containers in the multi-tenant cloud will in most instances run inside a virtual machine to provide an added layer of isolation. Containers divide up a physical host into discrete sets of resources for each application, and many containers can run together on a single host. But they don't have enough defenses to shield themselves from active malware lurking in a neighboring container on the same host. So multi-tenant hosts will most likely assign a virtual machine to each customer, then run multiple Docker containers inside the VM, sacrificing some of the efficiency gains that play out more favorably in Google's own more homogenous environment.

Figure 1: Kubernetes means "helmsman" in Greek.

"Containers running under Kubernetes are not a replacement for virtual machine technology," says McLuckie. Rather, they are an alternative way to migrate and run workloads, one that is highly flexible about which target environments they may move into. The destination doesn't need much more than the designated Linux kernel that the workload was intended to run under. In addition, many containers from the same customer might run efficiently together inside one virtual machine, instead of each workload requiring the overhead of its own VM.

In addition, Kubernetes lets administrators assign priorities to workloads. If a customer-facing website or application gets more traffic, a larger share of the virtual machine's resources can be diverted to it rather than keeping a secondary load running at the same pace.

One of the appeals of containers is their ease of monitoring for demand and scaling up once demand appears. A cloud customer might have 10 containers identical to one that's running, but the 10 are doing nothing until traffic builds. The Kubernetes management system can then fire up additional containers and route traffic to them in much less time than it takes to fire up virtual machines, because the operating system for the additional containers was already running, with no additional copies needed. Each instance of a virtual machine must have its own operating system.

"We've decoupled the world of the application from the world of the operating system," says McLuckie, pointing out one of the chief differences between

Next Page

virtual machines and containers. In the virtual machine, the two remain tightly coupled together.

Also included in the group of Kubernetes backers are CoreOS, a company based on a lightweight version of Linux designed for running containers; Mesophere, a company formed around the Apache open-source project Mesos, used to pool servers, virtual machines, and cloud software into a single resource; and SaltStack, a company using Salt open-source code for building a large-scale configuration and server management system.

Google announced at the first DockerCon developer conference June 10 that it would make Kubernetes open-source code. It's since established the code on Github for free download, and a group of 36 contributors has formed around the project. It repeated its pledge to maintain Kubernetes as open-source at its own developer conference, Google I/O, on June 25.

McLuckie said Wednesday that Google would like to see a standardized way of managing containers follow on the heels of Docker's successful standardization of formatting container workloads. Doing so will make the migration and management of workloads in the cloud, including Google's App Engine and Compute Engine, easier.

Google has extensive experience in managing Linux containers. Two of its engineers, Rohit Seth and Paul Menage, are credited with coming up with the Linux control groups (cgroups) that were a necessary step prior to the formation of Linux containers. Google runs its internal search, Gmail, and Google Apps operations in containers, launching 2 billion each week.

"At Google, we're no strangers to containers." Google can use them for its internal operations because it runs multiple, homogenous datacenters with software that it's built. For App Engine and Compute Engine, however, workloads are coming in from the outside, and each container host will be running as a virtual machine, capable of hosting several containerized workloads from the same customer.

"We didn't see anyone bringing Google-style management to the community." Google-style management might also favor Google-style cloud operations, such as App Engine and Compute Engine.

McLuckie says Google will seek to broaden management of the Kubernetes project rather than leaving control in Google's hands. For starters, Google plans to name a Red Hat contributor to Kubernetes as a project committer, a position of authority over the code submitted by other developers. Currently, McLuckie pointed out, all committers are Google developers.

In a Google blog post Thursday, Red Hat's Paul Cormier, president of products and technologies, said: "Through this collaboration with Google on Kubernetes, we are contributing to the evolution of cloud computing and helping deliver the promises that container technologies offer to the open hybrid cloud."

Microsoft's Scott Guthrie, executive VP of the Cloud and Enterprise Group, also quoted in the blog, said: "Microsoft will help contribute code to Kubernetes to enable customers to easily manage containers that can run anywhere." Guthrie made it clear he expects Microsoft's Azure to be running containers, as well as more Linux-oriented cloud services.

The combination of backers behind Kubernetes is an indication of how containers are likely to usher in a more sophisticated way of doing things through a cloud service or other form of remote datacenter. The IT manager or other workload owner will have more options for moving things around with containers, with fewer prerequisites to meet: No hypervisor needs to be lined up in advance, and no translation of the workload from its native VM state to the cloud's preferred VM need take place.

IT leaders who don't embrace public cloud concepts will find their business partners looking elsewhere for computing capabilities. Get the new Frictionless IT issue of InformationWeek Tech Digest today (registration required).