I’ve been programming Orbit Control as a tool to deploy Docker containers for around half a year which we have been running in production without any issues. Recently (Nov 2014) Google released Kubernetes, its cluster container manager, which slipped under my radar until now. Kubernetes seem to contain several nice design features which I had already adopted into Orbitctl, so it looks like a nice product after a quick glance. Here’s a quick summary on the differences and similarities between Kubernetes and Orbitctl.

• Both use etcd to store central state.
• Both deploy agents which use the central state from etcd to converge the machine into the desired state.
• Kubernetes relies on SaltStack for bootstrapping the machines. Currently we use Chef to bootstrap our machines but for Orbitctl it’s just one static binary which needs to be shipped into the machine, so no big difference here.
• Orbitctl has just “services” without any deeper grouping. Kubernetes adds to this by defining that a Service is a set of Pods. Each pod contains containers which must be running in the same machine.
• Orbit doesn’t provice any mechanisms for networking. The containers within a Kubernetes Pod share a single network entity (ie. and IP address) and the IP address is routable and accessible between machines running the pods. This seems to help preventing port conflicts in a Kubernetes deployment.
• Orbit provides a direct access for Docker api which doesn’t hide anything where Kubernetes encapsulates several Docker details (like networking, volume mounts etc) into its own manifest format.
• Orbitctl has “tags”, Kubernetes has “labels” which have more use cases within Kubernetes than what Orbit currently has for its tags.
• Orbitctl relies on operators to specify which machines (according to tag) run which service. Kubernetes has some kind of automatic scheduler which can take cpu and memory requirements in account when it distributes the pods.
• Both use json to define services with pretty similar syntax which is then loaded using a command line tool into etcd.
• Orbitctl can automatically configure haproxies to specific set of services within a deployment. Kubernetes has similar software router, but it can’t support haproxy yet. There’s open issues on this, so it is coming in the future.
• Kubernetes has several networking enchantments coming up later in their own feature roadmap. Read more here.
• Both have support for health checks.
• Orbit supports deployments across multiple availability zones but not across multiple regions. Kubernetes says it’s not supposed to be distributed across availability zones, probably because its lacking some HA features as it has a central server.

Kubernetes looks really promising, at least when they reach 1.0 version which has nice planned list of features. Currently its lacking some critical features like haproxy configuration, support for deployments across availability zones so it’s not production ready for us, but it’s definitively something to keep an eye on.