From eff5ac2694d73e46cc3a501b251017649c3462af Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Thu, 13 Apr 2017 13:48:07 -0700 Subject: [PATCH] Move guide topics: Upgrade for 1.6. (#3383) * Move guide topics: Upgrade for 1.6. * Add missing word. --- _data/tasks.yml | 1 + docs/admin/upgrade-1-6.md | 23 +++-------------- docs/tasks/administer-cluster/upgrade-1-6.md | 26 ++++++++++++++++++++ 3 files changed, 30 insertions(+), 20 deletions(-) create mode 100644 docs/tasks/administer-cluster/upgrade-1-6.md diff --git a/_data/tasks.yml b/_data/tasks.yml index dd09b41a3a..eadea98265 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -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 diff --git a/docs/admin/upgrade-1-6.md b/docs/admin/upgrade-1-6.md index d84debc99a..8cb97e0df8 100644 --- a/docs/admin/upgrade-1-6.md +++ b/docs/admin/upgrade-1-6.md @@ -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/) diff --git a/docs/tasks/administer-cluster/upgrade-1-6.md b/docs/tasks/administer-cluster/upgrade-1-6.md new file mode 100644 index 0000000000..d84debc99a --- /dev/null +++ b/docs/tasks/administer-cluster/upgrade-1-6.md @@ -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).