If you are using a released version of Kubernetes, you should refer to the docs that go with that version.
The latest 1.0.x release of this document can be found [here](http://releases.k8s.io/release-1.0/docs/admin/etcd.md).Documentation for other releases can be found at releases.k8s.io.
etcd is a highly-available key value store which Kubernetes uses for persistent storage of all of its REST API objects.
Access Control: give only kube-apiserver read/write access to etcd. You do not want apiserver's etcd exposed to every node in your cluster (or worse, to the internet at large), because access to etcd is equivilent to root in your cluster.
Data Reliability: for reasonable safety, either etcd needs to be run as a cluster (multiple machines each running etcd) or etcd's data directory should be located on durable storage (e.g., GCE's persistent disk). In either case, if high availability is required--as it might be in a production cluster--the data directory ought to be backed up periodically, to reduce downtime in case of corruption.
The default setup scripts use kubelet's file-based static pods feature to run etcd in a
pod. This manifest should only
be run on master VMs. The default location that kubelet scans for manifests is
/etc/kubernetes/manifests/.
By default, Kubernetes objects are stored under the /registry key in etcd.
This path can be prefixed by using the kube-apiserver flag
--etcd-prefix="/foo".
etcd is the only place that Kubernetes keeps state.
To test whether etcd is running correctly, you can try writing a value to a
test key. On your master VM (or somewhere with firewalls configured such that
you can talk to your cluster's etcd), try:
curl -fs -X PUT "http://${host}:${port}/v2/keys/_test"