The footprint for consul + geard is roughly the same as Kubernetes. The gossip protocol from consul has advantages and disadvantages - it allows you to detect partitions in your network quickly, but the kube service proxies also detect partitions fast (and service proxies are better than gossip in one respect because they measure actual important partitions). The proxies do not report back that data today, so that's an advantage for consul as it stands
I respect and admire what consul has done, but the practical difference between it and Openshift/kube is mostly known gaps in kube capabilities, or the relative maturity of the two products. The consul data store is very well done (it's etcd but with atomic multikey transactions, secondary indices, and better read performance and storage), and I believe we should adapt some of the same ideas in their user facing api. Certainly there's nothing preventing us from making kube as easy to run as consul (see Openshift all in one which is a single binary full deployment of kube + our extras).
Thank you for that clarification, so the advantage is in multi tenant systems at scale. What about single application, multiple backend services at scale?
Wouldnt atomic + geard + consul + registrator be a better fit or is my lack of experience in developing for large applications causing me to miss something that kube will provide an advantage in some way.
Kind Regards,
Stephen Major
It would be nice to see a write up on why kubernetes is superior to geard. I
spent some time talking with Openshift on the subject. Their reasoning is that kubernetes is better when companies scale to multiple teams. But the drawbacks are static service discovery which in the openshift project they will be working to add in support for dynamic service discovery, which I do not fully understand since I do not fully understand how kubernetes is central service discovery and geard + Consul is not.
Consul is central service discovery but not central trust chain - anyone node can declare a service (advantage) but any node can also be corrupted (disadvantage).
Geard + Consul + Jeff Lindsays Docker Registrator makes dynamic docker service discovery a breeze. Can someone please help better explain why I should drop this in favor of Kubernetes?
OpenShift is moving its focus to kube because we can do everything we could do in GearD + consul but we could run a multitenant system on it. The basic ideas of geard as an independent entity will live on in some form, but it's not a focus until we hit Openshift 3 beta 1. We've finally gotten through the Kubernetes packaging and it's in rawhide now! Following is a patch, any objections? The upstream of geard has deprecated it in favor of Kubernetes. --- fedora-atomic-docker-host.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fedora-atomic-docker-host.json b/fedora-atomic-docker-host.json index 830e9f0..ee220e5 100644 --- a/fedora-atomic-docker-host.json +++ b/fedora-atomic-docker-host.json @@ -18,8 +18,8 @@ "setools-console", "audit", "cockpit", - "geard", + "kubernetes", "etcd", "cadvisor", "docker-io"], - "units": ["docker.socket", "geard.service", "cockpit.socket"] + "units": ["docker.socket", "cockpit.socket"] } -- 1.8.3.1
|