Kubernetes 1.3, the latest major revision of Google’s container cluster management system. It is available as an open source project on GitHub and in Google Cloud Platform’s Container Engine service.
The new features speak to some of the latest issues involving containers today and Google’s long-term plans for a hybrid cloud built with their services.
United states of Kubernetes
On the face of it, Google can use most of the new features in Kubernetes 1.3 to further boost containers as a service on Google Cloud Platform. According to a draft copy of the blog discussing Kubernetes 1.3, most of the additions were driven by requests from businesses using Kubernetes in production. Among them is a higher number of nodes available in a cluster (it is now a maximum of 2,000); the ability to deploy services across availability zones, both on-premises and off; and easier support for stateful applications out of the box.
The container world has been looking more toward stateful application support as its fundamentals become established. Containers are immutable by default, but applications within containers depend on state to be useful, and data volume containers aren’t a complete solution.
Projects like CoreOS’s Torus and now Kubernetes and its PetSet methodology attempt to elegantly handle state. Kubernetes’ functionality in this vein is still early stage, but the long-term plan is to offer more robust handling of stateful services than competing projects like Apache Zookeeper.
Another key addition of growing importance in the container world is alpha-level support for systems with Nvidia GPUs. Apps, especially big data or numerical analysis apps, leverage GPU acceleration more readily now, and support for GPU-enabled apps in containers is getting a lift thanks to Nvidia providing a Docker plugin.
Going hybrid
Deploying across availability zones, also described in the Kubernetes blog as “cross-cluster federation,” means that services on Kubernetes can be run in clusters that live on machines hosted in more than one physical location — in other words, a hybrid cloud.
This is another indirect nod by Google (or, at least, Kubernetes) toward creating a hybrid cloud that is built almost entirely out of open components. If an organisation uses Kubernetes to organise its clusters, then it could in theory use Google Cloud Platform’s support to have its public cloud cluster nodes hosted on GCP while keeping as many others in-house as needed.
This stands in contrast to Red Hat’s vision of an open source hybrid cloud. In Red Hat’s world, you run a single unifying PaaS with native container support, such as OpenShift, both locally and remotely. Technologies like Kubernetes ride on top of OpenShift and are partly abstracted away.
Red Hat and Google might end competing most fiercely over deployment, not technology. Both sell managed versions of their respective platforms, with Google making Kubernetes consumable by way of Google Cloud Platform and Red Hat offering OpenShift in multiple public cloud incarnations.
For customers, it will come down to a choice of which platform’s philosophy is the best fit. With Red Hat, the underlying technologies (such as Kubernetes) power a larger platform; with Google, the underlying technologies are the platform.
Hitting the sweet spots
The most significant source of pressure on Google to improve Kubernetes, both the open source project and its as-a-service delivery, may be Docker. Docker recently revealed it was directly merging its Docker Swarm technology to provide many of Kubernetes’ benefits as a convenient, out-of-the-box offering without the overhead of Kubernetes. (After all, a tool that emerges from within Google is likely biased toward massive scale in both its feature set and its presumptions about how it’s set up and used.)
Google can offset Docker in two main ways. First, it can obviate any issues involved with setting up and running Kubernetes by offering it as a service. This approach only works to the extent that people use Google Cloud Platform, though.
The other, more general approach is to make Kubernetes a tool that is explicitly aimed at organisations large enough not to mind the heavy lifting needed to get it running — in other words, let Docker Swarm and Kubernetes be different products for different markets. Docker generally is aimed at a broader swath of users, so it is likely Swarm will provide the best alternative in environments where “just enough” clustering is needed — but Kubernetes will aim to be the tool for where the broadest possible scale is required.
IDG News Service
Subscribers 0
Fans 0
Followers 0
Followers