Remove outdated etcd docs

* The roadmap is more or less complete
* The etcd-manger page contained outdated info already convered in the etcd migration docs

Neither pages were linked anywhere in the docs

docs/etcd/manager.md

@@ -1,71 +0,0 @@
-## etcd-manager
-
-etcd-manager is a kubernetes-associated project that kops will use to manage
-etcd (at least that is the plan per the roadmap).
-
-etcd-manager uses many of the same ideas as the existing etcd implementation
-built into kops, but it addresses some limitations also:
-
-* separate from kops - can be used by other projects
-* allows etcd2 -> etcd3 upgrade (along with minor upgrades)
-* allows cluster resizing (e.g. going from 1 to 3 nodes)
-
-If using kubernetes >= 1.12 (which will not formally be supported until kops 1.12), note that etcd-manager will be used by default.  You can override this with the `cluster.spec.etcdClusters[*].provider=Legacy` override.  This can be specified:
-
-* as an argument to `kops create cluster`: `--overrides cluster.spec.etcdClusters[*].provider=Legacy`
-* on an existing cluster with `kops set cluster cluster.spec.etcdClusters[*].provider=Legacy`
-* by setting the field using `kops edit` or `kops replace`, manually making the same change as `kops set cluster ...`
-
-(Note you will probably have to `export KOPS_FEATURE_FLAGS=SpecOverrideFlag`)
-
-## How to use etcd-manager
-
-Reminder: etcd-manager is alpha, and we encourage you to back up the data in
-your kubernetes cluster.
-
-To create a test cluster:
-```bash
-kops create cluster test.k8s.local --zones us-east-1c --master-count 3
-kops update cluster test.k8s.local --yes
-
-# Wait for cluster to boot up
-kubectl get nodes
-```
-
-You can enable the etcd-manager - it will adopt the existing etcd data, though
-it won't change the configuration:
-
-```bash
-# Enable etcd-manager
-kops set cluster cluster.spec.etcdClusters[*].provider=Manager
-
-kops update cluster --yes
-kops rolling-update cluster --yes
-```
-
-After the masters restart, you will still be running etcd 2.2.  You can change
-the version of etcd:
-
-```bash
-kops set cluster cluster.spec.etcdClusters[*].version=3.2.18
-
-kops update cluster --yes
-kops rolling-update cluster --yes
-```
-
-It should be safe to combine the etcd-manager adoption and etcd upgrade into a
-single restart, but we are working on boosting test coverage.
-
-When you're done, you can shut down the cluster:
-
-```bash
-kops delete cluster example.k8s.local --yes
-```
-
-You can also do this for existing clusters. though remember that this is still
-young software, so please back up important cluster data first.  You just run the
-two `kops set cluster` commands.  Note that `kops set cluster` is just an easy
-command line way to set some fields in the cluster spec - if you're using a
-GitOps approach you can change the manifest files directly. You can also `kops
-edit cluster`.
-

docs/etcd/roadmap.md

@@ -1,56 +0,0 @@
-# Kops and etcd
-
-Kops currently manages etcd using a daemon that runs on the masters called protokube.  protokube
-is responsible for:
-
-* mapping volumes so that exactly one master runs each member of the etcd cluster,
-even when the masters are dynamic (in autoscaling groups).
-* mapping DNS names so that etcd nodes can discover each other even as they move around.
-
-We are following the [approach recommended by the authors of etcd](https://github.com/coreos/etcd/issues/5418)
-
-protokube has additional responsibilities also, so we call this the protokube-integrated etcd support.
-
-Generally, splitting up protokube is part of the general kops roadmap, where we aim to split out our integrated
-tooling into composable tooling that can be upgraded (or even used) separately.
-
-## Limitations
-
-The current approach for managing etcd makes certain tasks hard:
-
-* upgrades/downgrades between etcd versions
-* resizing the cluster
-
-To address these limitations, we plan to adopt the [etcd-manager](https://github.com/kopeio/etcd-manager) as
-it matures.
-
-To make adoption easier, the etcd-manager has added a standalone backup tool, that can backup etcd into the
-[expected structure](https://github.com/kopeio/etcd-manager/blob/master/docs/backupstructure.md), even if you are not running the etcd-manager.  It should be possible to then use
-the etcd-manager from that backup.
-
-## Roadmap
-
-### _kops 1.9_
-
-* Use the etcd-backup tool to allow users to opt-in to backups with the protokube-integrated etcd support, in the format that etcd-manager expects
-
-Goal: Users can enable backups on a running cluster.
-
-### _kops 1.10_
-
-* Make the etcd-backup tool enabled-by-default, so everyone should have backups.
-* Allow users to opt-in to the full etcd-manager.
-* Make etcd3 the default for new clusters, now that we have an upgrade path.
-
-Goal: Users that want to move from etcd2 to etcd3 can enable backups
-on an existing cluster (running kops 1.9 or later), then enable the etcd-manager (with kops 1.10 or later).
-
-### _kops 1.11_
-
-* Make the etcd-manager the default, deprecate the protokube-integrated approach
-
-Goal: Users are fully able to manage etcd - moving between versions or resizing their clusters.
-
-### _untargeted_
-
-* Remove the protokube-integrated etcd support (_untargeted_)

docs/operations/etcd_administration.md

@@ -1,5 +1,19 @@
 # Etcd Administration Tasks
 
+## etcd-manager
+
+etcd-manager is a kubernetes-associated project that kops uses to manage
+etcd.
+
+etcd-manager uses many of the same ideas as the existing etcd implementation
+built into kops, but it addresses some limitations also:
+
+* separate from kops - can be used by other projects
+* allows etcd2 -> etcd3 upgrade (along with minor upgrades)
+* allows cluster resizing (e.g. going from 1 to 3 nodes)
+
+When using kubernetes >= 1.12 etcd-manager will be used by default. See [../etcd3-migration.md] for upgrades from older clusters.
+
 ## Backups
 
 Backups and restores of etcd on kops are covered in [etcd_backup_restore_encryption.md](etcd_backup_restore_encryption.md)

docs/operations/etcd_backup_restore_encryption.md

@@ -17,7 +17,7 @@ of 0.1%-0.2% per year.
 
 ### Backups using etcd-manager
 
-Backups are done periodically and before cluster modifications using [etcd-manager](../etcd/manager.md)
+Backups are done periodically and before cluster modifications using [etcd-manager](etcd_administration.md)
 (introduced in kops 1.12). Backups for both the `main` and `events` etcd clusters
 are stored in object storage (like S3) together with the cluster configuration.