kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Move guide topics: Upgrade for 1.6. (#3383) 

* Move guide topics: Upgrade for 1.6.

* Add missing word.
reviewable/pr3385/r1
Steve Perry 2017-04-13 13:48:07 -07:00 committed by GitHub
parent f0f34f3132
commit eff5ac2694
3 changed files with 30 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
_data/tasks.yml
View File

@ -88,6 +88,7 @@ toc:
- title: Administering a Cluster
section:
- docs/tasks/administer-cluster/overview.md
- docs/tasks/administer-cluster/upgrade-1-6.md
- docs/tasks/administer-cluster/assign-pods-nodes.md
- docs/tasks/administer-cluster/reserve-compute-resources.md
- docs/tasks/administer-cluster/dns-horizontal-autoscaling.md

23
docs/admin/upgrade-1-6.md
View File

@ -1,26 +1,9 @@
---
assignees:
- mml
title: Cluster Management Guide for Version 1.6
title: Cluster Management for Version 1.6
---
* TOC
{:toc}
{% include user-guide-content-moved.md %}
This document outlines the potentially disruptive changes that exist in the 1.6 release cycle. Operators, administrators, and developers should
take note of the changes below in order to maintain continuity across their upgrade process.
## Cluster defaults set to etcd 3
In the 1.6 release cycle, the default backend storage layer has been upgraded to fully leverage [etcd 3 capabilities](https://coreos.com/blog/etcd3-a-new-etcd.html) by default.
For new clusters, there is nothing an operator will need to do, it should "just work". However, if you are upgrading from a 1.5 cluster, care should be taken to ensure
continuity.
It is possible to maintain v2 compatibility mode while running etcd 3 for an interim period of time. To do this, you will simply need to update an argument passed to your apiserver during
startup:
```
$ kube-apiserver --storage-backend='etcd2' $(EXISTING_ARGS)
```
However, for long-term maintenance of the cluster, we recommend that the operator plan an outage window in order to perform a [v2->v3 data upgrade](https://coreos.com/etcd/docs/latest/upgrades/upgrade_3_0.html).
[Cluster Management for Version 1.6](/docs/tasks/administer-cluster/upgrade-1-6/)

26
docs/tasks/administer-cluster/upgrade-1-6.md Normal file
View File

@ -0,0 +1,26 @@
---
assignees:
- mml
title: Cluster Management Guide for Version 1.6
---
* TOC
{:toc}
This document outlines the potentially disruptive changes that exist in the 1.6 release cycle. Operators, administrators, and developers should
take note of the changes below in order to maintain continuity across their upgrade process.
## Cluster defaults set to etcd 3
In the 1.6 release cycle, the default backend storage layer has been upgraded to fully leverage [etcd 3 capabilities](https://coreos.com/blog/etcd3-a-new-etcd.html) by default.
For new clusters, there is nothing an operator will need to do, it should "just work". However, if you are upgrading from a 1.5 cluster, care should be taken to ensure
continuity.
It is possible to maintain v2 compatibility mode while running etcd 3 for an interim period of time. To do this, you will simply need to update an argument passed to your apiserver during
startup:
```
$ kube-apiserver --storage-backend='etcd2' $(EXISTING_ARGS)
```
However, for long-term maintenance of the cluster, we recommend that the operator plan an outage window in order to perform a [v2->v3 data upgrade](https://coreos.com/etcd/docs/latest/upgrades/upgrade_3_0.html).