// the find
coreos/etcd-operator
etcd operator creates/configures/manages etcd clusters atop Kubernetes
etcd-operator automates etcd cluster lifecycle on Kubernetes — provisioning, scaling, rolling upgrades, and backup/restore — via a custom resource definition. This was the reference implementation for the Kubernetes operator pattern when it came out of CoreOS. It has been archived since 2020 and requires Kubernetes 1.8+ with etcd 3.2.13+, both ancient by now.
The reconciliation loop in pkg/cluster/reconcile.go is a clean example of how to implement the operator pattern before controller-runtime existed — worth reading if you're learning how operators work at the primitive level. Backup/restore is split into three separate operators (main, backup, restore) with pluggable storage backends (S3, GCS, ABS, OSS), which is the right architecture for that problem. The design docs under doc/design/ are unusually thorough — cluster lifecycle, TLS rotation, disaster recovery — and explain the decisions behind the code, not just the code itself. The e2e test suite covers real failure scenarios: pod deletion, operator restart mid-operation, rolling upgrades across etcd versions.
Archived in 2020 and no longer maintained — the last etcd version it explicitly supports (3.2.13) is years behind current etcd releases. The modern replacement is the Bitnami/VMware etcd-operator or just using the etcd Helm chart with StatefulSets; do not adopt this for production. Uses dep (Gopkg.toml/Gopkg.lock) instead of Go modules, which means the build toolchain is itself obsolete. The backup and restore operators are explicitly documented as 'example implementations', not production-grade — a significant asterisk for what's supposed to be an operations tool.