New to KubeDB? Please start here.

Supported Etcd Features

FeaturesAvailability
Clustered (single Raft cluster)
Single member cluster (replicas: 1)
Authentication & Authorization (etcd RBAC, root user)
Custom Configuration (tuning knobs only)
Externally manageable Auth Secret
Reconfigurable Health Checker
TLS: Add, Remove, Update, Rotate ( Cert Manager )
Automated Version update
Automatic Vertical Scaling
Automated Horizontal Scaling (learner add & promote)
Automated Volume Expansion
Storage Class Migration
Move Raft Leadership / Defragment / Compact
Backup/Recovery: Instant, Scheduled (KubeStash)
In-place restore into an existing cluster
Recovery from a permanent Raft quorum loss
Persistent Volume
Builtin Prometheus Discovery
Using Prometheus operator
Autoscaler (compute & storage)
Recommendation Engine
GitOps
Grafana Dashboards
Continuous Archiving / Point-In-Time Recovery
Multi-cluster / Disaster Recovery topology

A few notes on the table above:

  • Custom Configuration for etcd is limited to the typed tuning knobs exposed through spec.configuration.tuning (quotaBackendBytes, autoCompactionMode, autoCompactionRetention, snapshotCount). etcd’s --config-file is mutually exclusive with the individual command line flags KubeDB has to set for cluster bootstrap, so a free-form config file is intentionally not supported. Anything the tuning knobs do not cover can still be passed as a raw etcd flag through spec.podTemplate.spec.containers[name=etcd].args, which is appended after the operator’s own flags. See Etcd CRD and Extra etcd flags.
  • Backup/Recovery is snapshot based only. etcd has no WAL-shipping style continuous archiving primitive that can be streamed out of the cluster, so there is no point-in-time recovery between two full snapshots. See EtcdArchiver.
  • Monitoring does not deploy an exporter sidecar. etcd serves its own Prometheus metrics natively, so KubeDB points the stats Service and the ServiceMonitor straight at etcd.
  • No Grafana dashboards ship with KubeDB for etcd yet.

Life Cycle of an Etcd Object

An Etcd object goes through the following phases, reported in status.phase:

PhaseMeaning
ProvisioningThe KubeDB operator has accepted the object and is creating the offshoot resources (PetSet, Services, Secrets, RBAC).
ReadyAll members are up, the Raft cluster has quorum and the client endpoint is accepting connections.
CriticalThe client endpoint is reachable, but not every member is ready (for example a learner is still catching up).
NotReadyThe client endpoint is not reachable — quorum has been lost or every member is down.
Haltedspec.halted is true: every offshoot resource except the PVCs has been deleted.
UnknownThe phase could not be computed.

In the normal path, an Etcd object moves ProvisioningReady. When the cluster is bootstrapped from a snapshot (spec.init.archiver), the operator restores the ordinal-0 volume before the first member is ever started, so the object simply stays in Provisioning for longer; the restore’s own outcome is reported on the SuccessfullyDataRestored condition rather than as a phase.

The phase is derived from the object’s conditions — ProvisioningStarted, ReplicaReady, AcceptingConnection, Ready and Provisioned. The health checker keeps them up to date by calling etcd’s own Status() and MemberList() RPCs on the client port and treating the cluster as healthy while at least N/2+1 members answer.

User Guide

Next Steps