Overall cleanup for kubeadm setup guide. (#8981)
* Overall cleanup for kubeadm setup guide. * Add sonobuoy verification next step * Partial copyedits Hit a place where we also have formatting issues, plus a TODO (removed bc these changes go live as soon as merged). More work to do, but this should help the bottleneck for now. * Address comments from reviewers * Copy edits, fiddly bits, and clearer warnings Incorporated feedback from @mistyhacks, fixed many nits, reorganized some **Note:** content more sensibly. * Revised title per feedback
This commit is contained in:
Timothy St. Clair
committed by
k8s-ci-robot
k8s-ci-robot
parent
cb6af2a39c
commit
c09c48b2dc
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "Administration with kubeadm"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: "Upgrading or downgrading Kubernetes"
|
||||
weight: 10
|
||||
---
|
||||
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- pipejakob
|
||||
title: Upgrading kubeadm clusters from 1.6 to 1.7
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
This guide is for upgrading kubeadm clusters from version 1.6.x to 1.7.x.
|
||||
Upgrades are not supported for clusters lower than 1.6, which is when kubeadm
|
||||
became Beta.
|
||||
|
||||
**WARNING**: These instructions will **overwrite** all of the resources managed
|
||||
by kubeadm (static pod manifest files, service accounts and RBAC rules in the
|
||||
`kube-system` namespace, etc.), so any customizations you may have made to these
|
||||
resources after cluster setup will need to be reapplied after the upgrade. The
|
||||
upgrade will not disturb other static pod manifest files or objects outside the
|
||||
`kube-system` namespace.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
You need to have a Kubernetes cluster running version 1.6.x.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## On the master
|
||||
|
||||
1. Upgrade system packages.
|
||||
|
||||
Upgrade your OS packages for kubectl, kubeadm, kubelet, and kubernetes-cni.
|
||||
|
||||
a. On Debian, this can be accomplished with:
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get upgrade
|
||||
|
||||
b. On CentOS/Fedora, you would instead run:
|
||||
|
||||
sudo yum update
|
||||
|
||||
2. Restart kubelet.
|
||||
|
||||
systemctl restart kubelet
|
||||
|
||||
3. Delete the `kube-proxy` DaemonSet.
|
||||
|
||||
Although most components are automatically upgraded by the next step,
|
||||
`kube-proxy` currently needs to be manually deleted so it can be recreated at
|
||||
the correct version:
|
||||
|
||||
sudo KUBECONFIG=/etc/kubernetes/admin.conf kubectl delete daemonset kube-proxy -n kube-system
|
||||
|
||||
4. Perform kubeadm upgrade.
|
||||
|
||||
**WARNING**: All parameters you passed to the first `kubeadm init` when you bootstrapped your
|
||||
cluster **MUST** be specified here in the upgrade-`kubeadm init`-command. This is a limitation
|
||||
we plan to address in v1.8.
|
||||
|
||||
sudo kubeadm init --skip-preflight-checks --kubernetes-version <DESIRED_VERSION>
|
||||
|
||||
For instance, if you want to upgrade to `1.7.0`, you would run:
|
||||
|
||||
sudo kubeadm init --skip-preflight-checks --kubernetes-version v1.7.0
|
||||
|
||||
5. Upgrade CNI provider.
|
||||
|
||||
Your CNI provider might have its own upgrade instructions to follow now.
|
||||
Check the [addons](/docs/concepts/cluster-administration/addons/) page to
|
||||
find your CNI provider and see if there are additional upgrade steps
|
||||
necessary.
|
||||
|
||||
## On each node
|
||||
|
||||
1. Upgrade system packages.
|
||||
|
||||
Upgrade your OS packages for kubectl, kubeadm, kubelet, and kubernetes-cni.
|
||||
|
||||
a. On Debian, this can be accomplished with:
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get upgrade
|
||||
|
||||
b. On CentOS/Fedora, you would instead run:
|
||||
|
||||
sudo yum update
|
||||
|
||||
2. Restart kubelet.
|
||||
|
||||
systemctl restart kubelet
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- mml
|
||||
title: Cluster Management Guide for Version 1.6
|
||||
---
|
||||
|
||||
{{< 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).
|
||||
Reference in New Issue
Block a user