An application built around ZooKeeper’s client protocol may tempt a team to reuse that interface while storing coordination data in etcd. zetcd was a proxy designed to translate those requests to an etcd backend. Its repository is archived, and matching the wire protocol does not prove equivalent behavior for sessions, watches, locks or failure recovery. Any inherited use needs tests of the application’s actual coordination contract rather than a connection-string change treated as a safe migration.
Current guidance
The historical chart runs etcd-io/zetcd, which accepts ZooKeeper protocol requests and translates them to an etcd backend. Its repository is archived. The README includes a cross-check mode that compares an isolated candidate with a ZooKeeper oracle, emphasizing that compatibility needs testing rather than being guaranteed merely by speaking the client protocol.
An application may rely on sessions, ephemeral nodes, watches, sequential nodes, ACLs or failure timing. Those behaviors are part of its coordination contract, and differences can affect leader election or locking even when simple reads and writes succeed. A proxy also adds an operational component and does not eliminate etcd quorum, storage and backup requirements.
For an inherited deployment, inventory client libraries and the ZooKeeper features they actually use. Rehearse representative failure and reconnection cases before choosing native ZooKeeper or an application-supported alternative. Preserve namespace data and access rules with a documented migration process; do not redirect a production connection string as an experiment. No maintained drop-in successor or complete current compatibility certification was established here, so this archived shim is not recommended as a shortcut for a new migration.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Original publication: 2018-09-20T13:48:32+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
A ZooKeeper “personality” for etcd. Point a ZooKeeper client at zetcd to dispatch the operations on an etcd cluster.
Protocol encoding and decoding heavily based on go-zookeeper. This chart runs zetcd, a ZooKeeper “personality” for etcd.
Prerequisites
- Kubernetes 1.4+ with Beta APIs enabled
- Suggested: PV provisioner support in the underlying infrastructure to support backups of etcd
Running zetcd on Docker
Official docker images of tagged zetcd releases for containerized environments are hosted at quay.io/etcd-io/zetcd. Use docker run to launch the zetcd container with the same configuration as the go get an example:
docker run –net host -t quay.io/etcd-io/zetcd -endpoints localhost:2379
Cross-checking
In cross-checking mode, zetcd dynamically tests a fresh isolated “candidate” zetcd cluster against a fresh isolated ZooKeeper “oracle” cluster for divergences. This mode dispatches requests to both zetcd and ZooKeeper, then compares the responses to check for equivalence. If the responses disagree, it is flagged in the logs. Use the flags -zkbridge to configure a ZooKeeper endpoint and -oracle zk to enable checking.
Cross-check zetcd’s ZooKeeper emulation with a native ZooKeeper server endpoint at localhost:2182 like so:
zetcd –zkaddr 0.0.0.0:2181 –endpoints localhost:2379 –debug-zkbridge localhost:2182 –debug-oracle zk –logtostderr -v 9
zetcd: running ZooKeeper apps without ZooKeeper
Distributed systems commonly rely on a distributed consensus to coordinate work. Usually, the systems providing distributed consensus guarantee information is delivered in order and never suffer split-brain conflicts. The usefulness, but rich design space, of such systems is evident by the proliferation of implementations; projects such as chubby, ZooKeeper, etcd, and consul, despite differing in philosophy and protocol, all focus on serving similar basic key-value primitives for distributed consensus. As part of making etcd the most appealing foundation for distributed systems, the etcd team developed a new proxy, zetcd, to serve ZooKeeper requests with an unmodified etcd cluster.
ZooKeeper is the first popular open source software in this vein, making it the preferred backend for many distributed systems. These systems would conceptually work with etcd as well, but they don’t in practice for historical reasons. An etcd cluster can’t drop-in for ZooKeeper; etcd’s data model and client protocol is incompatible with ZooKeeper applications. Neither can ZooKeeper applications be expected to natively support etcd; if the system already works, there’s little motivation to further complicate it with new backends. Fortunately, the etcd v3 API is expressive enough to emulate ZooKeeper’s data model client-side with an ordinary proxy: zetcd, a new open source project developed by the etcd team. Today marks zetcd’s first beta release, v0.0.1, setting the stage for managing and deploying zetcd in production systems.
The zetcd proxy sits in front of an etcd cluster and serves an emulated ZooKeeper client port, letting unmodified ZooKeeper applications run on top of etcd. At a high level, zetcd ingests ZooKeeper client requests, fits them to etcd’s data model and API, issues the requests to etcd, then returns translated responses back to the client. The proxy’s performance is competitive with ZooKeeper proper and simplifies ZooKeeper cluster management with etcd features and tooling. This post will show how to use zetcd, how zetcd works, and share some performance benchmarks.
Getting started with zetcd
All zetcd needs to get running is a go compiler, an internet connection to fetch the source code, and a system that can run etcd. The following example will build zetcd from source and run a few ZooKeeper commands against it. This is not suggested for serious deployments due to building etcd and zetcd from development branches, but it’s the simplest way to give it a try.
The post Zetcd appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →