Introducing zetcd

A big use case of this that we are thinking about is enabling people to use the etcd Operator[1], which makes it simple to run etcd clusters on Kubernetes, to back their ZooKeeper applications.<p>The neat thing about the etcd Operator is you can define a cluster and the etcd Operator takes care of normal operations by using the Kubernetes API.<p><pre><code> apiVersion: &quot;etcd.coreos.com&#x2F;v1beta1&quot; kind: &quot;Cluster&quot; metadata: name: &quot;example-etcd-cluster&quot; spec: size: 5 version: &quot;3.1.8&quot; </code></pre> Pretty neat!<p>Anyways, the zetcd project is still super young but would love more folks to try it out. As the post says folks have already tried using Kafka, Mesos, and others.<p>[1] <a href="https:&#x2F;&#x2F;coreos.com&#x2F;blog&#x2F;introducing-the-etcd-operator.html" rel="nofollow">https:&#x2F;&#x2F;coreos.com&#x2F;blog&#x2F;introducing-the-etcd-operator.html</a>

I did some quick testing with Apache Curator (note: I&#x27;m the main author of Curator) and it looks like zetcd isn&#x27;t implementing the create2 opcode and several others. If the goal is to really be ZK compatible it has a long way to go. I&#x27;m not sure who the target of this is. But, I&#x27;ll keep following and try to get the Curator tests to run when it&#x27;s further along.

Interesting. Maybe hashicorp should release an etcd compatible layer for Consul. Or CockroachDB even. Both have one thing etcd does not...inbuilt WAN support.

Great idea, we only run Zookeeper because of Kafka but everything else is in Consul so the idea of this existing is pretty neat.

So how does zetcd handle the zookeeper session? It&#x27;s in zetcd and then the &quot;ephemeral nodes&quot; are removed from etcd if the zk client session expires? This is handled by the proxy?<p>This seems to be the major design compatibility item between the two is that the zookeeper protocol has a session state and so supports ephemeral nodes. If a gc pauses the jvm for a long time the client session will expire. In etcd there is ttl instead (zookeeper always lacked ttl as it wasn&#x27;t needed)

Another reason to use zetcd over Zookeeper is security. I don&#x27;t believe it is possible yet to use TLS for Zookeeper-to-Zookeeper communication (clients can connnect to Zookeeper using TLS). The Jira covering this feature [0]. This will increasingly be a problem for those running Zookeeper for Mesos, Kafka etc. from a security and risk point of view.<p>[0] <a href="https:&#x2F;&#x2F;issues.apache.org&#x2F;jira&#x2F;browse&#x2F;ZOOKEEPER-236" rel="nofollow">https:&#x2F;&#x2F;issues.apache.org&#x2F;jira&#x2F;browse&#x2F;ZOOKEEPER-236</a>

A few years ago I tried to reimplement the server connections directly in Zookeeper to be HTTP connections and a REST-like API and try to use long-polling and some other things. I got some code written, but no prototype up and I had to put it aside. This was initially before etcd was really going (I think it was at version 0.2 when I started the work). I had always hoped somebody else would try the same thing, but no such luck.