Concepts

Architecture

Overview

Ochonetes is simply a Kubernetes pod that runs both a standalone Zookeeper plus a little portal Python application (which interestingly is an Ochopod container itself). The portal job is to host a set of tools that will talk to the Kubernetes master and Ochopod containers (for instance to deploy stuff).

Why using such a proxy mechanism ? Well, mostly to encapsulate logic and avoid ending up with a fat CLI on your end. Additionally this allows to have all the inter-container I/O performed within the cluster (e.g no firewalling headache for you). Of course for a real PaaS this is also where you would inject access control, credentials and so on.

In other words you deploy our proxy pod and talk to it from then on. Easy.

Why Ochopod ?

Because Kubernetes - even if totally awesome - will not perform fine grained orchestration for you. You know what I mean by fine grained: the ability to form relationships between your containers without the need for an extrinsic control mechanism (look at the Ochopod documentation for more details).

In our case we will leverage the replication controller semantics from Kubernetes. One Ochopod cluster maps to one or more replication controllers. Each controller runs a bunch of pods which in turn run a Docker container embedding Ochopod.

Thanks to the super cool Kubernetes design we don’t even bother about port remapping. The pod IP is all we need.

Where is Zookeeper ?

As you remember Ochopod relies on Zookeeper for its internal leader elections and metadata storage. Our containers will simply look the proxy pod up and use that IP (the said proxy colocates the portal and a Zookeeper process).

Note

Yes I know you are going to say I just use a single standalone Zookeeper which is not really HA. This is true at the moment but we will probably morph the design a bit soon to lift this constraint. We potentially could leverage the cluster’s Etcd instead.