Deploying and managing production-grade etcd clusters on cloud providers: failure recovery, disaster recovery, backups and resizing.
Maintained by a former CoreOS engineer and inspired from the etcd-operator
designed for Kubernetes, the etcd-cloud-operator automatically bootstraps,
monitors, snapshots and recovers etcd clusters on cloud providers.
Used in place of the etcd binary and with minimal configuration, the operator
handles the configuration and lifecycle of etcd, based on data gathered from
the cloud provider and the status of the etcd cluster itself.
In other words, the operator operator is meant to help human operators sleep
at night, while their mysterious etcd data store keeps running safely, even
in the event of process, instance, network, or even availability-zone wide
failures.
Resize: By abstracting cluster management, resizing the cluster becomes
straightforward as the underlying auto-scaling group can simply be scaled as
desired.
Snapshots: Periodically, snapshots of the entire key-value space are
captured, from each of the etcd members and uploaded to an encrypted external
storage, allowing the etcd (or human) operator to restore the store at a later
time, in any etcd cluster or instance.
Failure recovery: Upon failure of a minority of the etcd members, the
managed members automatically restarts and rejoins the cluster without
breaking quorum or causing visible downtime - First by simply trying to rejoin
with their existing data set, otherwise trying to join as a new member with a
clean state, or by replacing the entire instance if necessary.
Disaster recovery: In the event of a quorum loss, consequence of the
simultaneous failure of a majority of the members, the operator coordinates
to snapshot any live members and cleanly stop then, before seeding a new cluster
from the latest data revision available once the expected amount of instances
are ready to start again.
ACL support: A user can configure the ACL of etcd by providing an init-acl config
in the config file. See init-acl.md for more information.
JWT auth token support: JWT auth token can be enabled by specifying thejwt-auth-token-config in the config file, similar to the etcd
-auth-token flag.
The JWT auth token is HIGHLY recommended for
production deployment,
especially when the init-acl config is also enabled, the JWT auth token can help
avoid the potential invalid auth token issue.
The operator and etcd cluster can be easily configured using a YAML file. The
configuration notably includes clients/peers TLS encryption/authentication, with
the ability to automatically generate self-signed certificates if encryption
is desired but authentication is not.
Running a managed etcd cluster using the operator is simply a matter of running
the operator binary in a supported auto-scaling group (as of today, AWS and Kubernetes only).
Docker: Head over to docs/docker-testing for a single-line local 3-nodes deployment.
AWS: A Terraform module is available to easily bring up production-grade etcd clusters
managed by the operator within AWS.
Kubernetes: A basic Helm chart is available to quickly get started with a 3-nodes
StatefulSet.