Google Kubernetes

Clocker and Kubernetes are both types of Docker orchestration. Clocker is written in Java and is based on Apache Brooklyn, using technology like OASIS CAMP blueprints, which means it supports deploying applications similarly to Kubernetes, but will also provide all of the underlying Brooklyn capabilities.

Kubernetes is written in Go and maintained by Google. For applications where people have already designed a pure Docker suite of micro services, and have an existing investment in Google Cloud, it is an obvious choice.

Many of the roadmap features in the design document are either available in Clocker, or are being developed there as well.

Kubernetes

• https://github.com/GoogleCloudPlatform/kubernetes

Kubernetes controls a group of hosts and manages pods (groups of containers, with a similar result as Docker LINKs) across them via a simple placement mechanism to choose where they run. There is a custom proxy on each host to handle network traffic between logical services. The underlying architecture is built on Docker, but is theoretically pluggable in this regard. While it is developed on GCE first, it has been run on bare metal, Vagrant, AWS, and Microsoft Azure, with official support for several of these.

Comparision

	Clocker	Kubernetes
Provisioning	Any Cloud	Any Cloud
Services	Brooklyn Entities	Docker Containers
Application	CAMP Blueprint	Pod Manifest
Host Agent	None	Kubelet
Clustering	Policies	Pluggable Controllers (e.g. replication)
Placement	Strategies and Affinity DSL	Basic (pluggable)
Proxying	Application specific	Kubernetes Proxy
Networking	SDN	Native or SDN
Control Plane	Apache Brooklyn	etcd (pluggable)

Kubernetes is appropriate when:

• You already have several Docker images you're working with.

Clocker and Brooklyn are appropriate when:

• You want a blueprint which can target Docker, Cloud VMs, and other infrastructure services.
• The application requires management policies (HA, scaling, etc), affinity rules, or has other service-level requirements.
• You want to compose and share blueprints.

Clocker

Clocker produces a similar end result, an application running on containers spread across several Docker hosts, but is able to control and direct the process in a much more flexible fashion and run across any jclouds supported cloud. This is because Clocker uses Apache Brooklyn as the management plane, and Docker is only the underlying infrastructure for a blueprint's services to be deployed onto. The blueprints describe services in an infrastructure agnostic fashion but can be augmented with Docker specific controls like CPU shares or volumes, and Dockerfiles or container images to use as well as policies, enrichers, placement strategies and affinity rules, enabling complex orchestration and elasticity.

Services like the Kubernetes proxy or data replication can also be integrated into Clocker by using existing tools like Open vSwitch, Open Contrail, Flocker from ClusterHQ or Ceph. The Docker cloud that Clocker provides is itself a Brooklyn blueprint and can be extended with entities providing these services and Brooklyn will manage their deployment and configuration automatically.

Integration

Clocker can provide the VMs and Docker infrastructure onto which Kubernetes will be able to deploy. It would take a bit of work to make Kubernetes do this, but it would then free it from the dependency on Google Cloud and GCE.