It's only a matter of time before every major cloud vendor offers a version of Kubernetes as a service. Now it’s IBM’s turn.
This morning IBM announced the next logical step in its work with Docker containers: Kubernetes support on its Bluemix Container Service. Currently available in a limited beta, its feature set should match Google's and Microsoft's offerings.
Kubernetes, the Bluemix way
Previously, the default for managing Docker containers on Bluemix Container Service was to spin them up individually by hand or to use Bluemix’s container groups metaphor, where Bluemix directly managed multiple containers running the same image.
Kubernetes is meant to provide several advantages for container deployments: easier scaling, better visibility into the state of a cluster, and so on. IBM says its implementation of Kubernetes on Bluemix includes everything users would expect from a stock Kubernetes deployment, as well as some IBM-specific features.
For example, see how it deploys master nodes, the parts of a cluster that accept commands and delegate them to the other machines in the cluster. IBM claims master nodes in its Kubernetes implementation are “highly available and fully managed by IBM”—presumably in contrast to simply providing and supporting a VM with Kubernetes that’s spun and run by the customer.
Some features for Bluemix Container Service are essentially conventional Docker/Kubernetes features writ large—such as a per-organization Docker private image registry with image scanning and vulnerability detection built in, or support for Kubernetes secrets (API keys and more) when communicating with other Bluemix resources. Other features, like “binding of Bluemix services, such as Watson APIs, Blockchain, data services, or internet of things” to Kubernetes-deployed apps, more prominently promote Bluemix, allowing Kubernetes-powered apps plug into Bluemix-exclusive services.
Why mess with a good thing?
IBM arrives late to a party that already includes Google and Microsoft. Google has had a leg up on everyone else in offering Kubernetes as a service because it invented the underlying technology. It also worked to Google’s advantage that its public cloud was relatively sparse; it could provide Kubernetes support on its cloud without having to make concessions to many legacy components.
Microsoft late last year added Kubernetes for its container services, after originally supporting Docker Swarm and Mesosphere DC/OS as orchestration solutions. Microsoft delayed its entry because a lot of behind-the-scenes work was needed to add Kubernetes support to Azure and to open-source that work. Kubernetes clusters themselves are provisioned on Azure by way of a QuickStart template and managed with the CLI, rather than by way of a dedicated managed service.
Amazon's ECS (EC2 Container Services) doesn’t have a dedicated Kubernetes service; instead it offers a more general Docker as a service, with orchestration and scheduling provided by ECS itself, or through the Blox projects.
Though late to the party, IBM is taking one crucial step for any cloud incarnation of an open source service: It's allowing the user to lift the hood and plug directly into the original API set. That’s important with cloud container services like Kubernetes, since the promise of a cloud built from open components was that workloads wouldn’t become dependent on the clouds where they're hosted.
Granted, IBM—or any cloud provider—could try to make a strong case for its cloud versus someone else’s by promoting how well Kubernetes runs at scale on its cloud and works with the proprietary services to enrich those applications. But having Kubernetes at the core and in a form others know is still the most worthwhile draw.
[This post has been updated with details and clarifications about Microsoft's and Amazon's offerings.]