mirror of https://github.com/kubernetes/kops.git
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
This commit is contained in:
Ole Markus With
parent
b42bd45b2f
commit
fd47b131c8
|
|
@ -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`.
|
||||
|
||||
|
|
@ -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_)
|
||||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue