Update cluster upgrade section

We now go from 1.22 to 1.23.

Updating to 1.22 was necessary because Kubernetes 1.27
deprecated kubeadm config v1beta2, which forced us to
upgrade to v1beta3, which was only introduced in 1.22.
In other words, our scripts can only install Kubernetes
1.22+ now.
This commit is contained in:
Jérôme Petazzoni
2023-05-12 07:23:36 +02:00
parent 980bc66c3a
commit c611f55dca
3 changed files with 55 additions and 36 deletions

View File

@@ -456,7 +456,7 @@ _cmd_kube() {
pssh "
sudo tee /etc/apt/preferences.d/kubernetes <<EOF
Package: kubectl kubeadm kubelet
Pin: version $KUBEVERSION*
Pin: version $KUBEVERSION-*
Pin-Priority: 1000
EOF"
fi

View File

@@ -7,7 +7,7 @@ USER_PASSWORD=training
# For a list of old versions, check:
# https://kubernetes.io/releases/patch-releases/#non-active-branch-history
KUBEVERSION=1.22.1
KUBEVERSION=1.22.17
STEPS="
wait

View File

@@ -81,7 +81,7 @@
## What version are we running anyway?
- When I say, "I'm running Kubernetes 1.20", is that the version of:
- When I say, "I'm running Kubernetes 1.22", is that the version of:
- kubectl
@@ -157,15 +157,15 @@
## Kubernetes uses semantic versioning
- Kubernetes versions look like MAJOR.MINOR.PATCH; e.g. in 1.20.15:
- Kubernetes versions look like MAJOR.MINOR.PATCH; e.g. in 1.22.17:
- MAJOR = 1
- MINOR = 20
- PATCH = 15
- MINOR = 22
- PATCH = 17
- It's always possible to mix and match different PATCH releases
(e.g. 1.20.0 and 1.20.15 are compatible)
(e.g. 1.22.17 and 1.22.5 are compatible)
- It is recommended to run the latest PATCH release
@@ -181,9 +181,9 @@
- All components support a difference of one¹ MINOR version
- This allows live upgrades (since we can mix e.g. 1.20 and 1.21)
- This allows live upgrades (since we can mix e.g. 1.22 and 1.23)
- It also means that going from 1.20 to 1.22 requires going through 1.21
- It also means that going from 1.22 to 1.24 requires going through 1.23
.footnote[¹Except kubelet, which can be up to two MINOR behind API server,
and kubectl, which can be one MINOR ahead or behind API server.]
@@ -254,7 +254,7 @@ and kubectl, which can be one MINOR ahead or behind API server.]
sudo vim /etc/kubernetes/manifests/kube-apiserver.yaml
```
- Look for the `image:` line, and update it to e.g. `v1.24.0`
- Look for the `image:` line, and update it to e.g. `v1.24.1`
]
@@ -308,11 +308,11 @@ and kubectl, which can be one MINOR ahead or behind API server.]
]
Note 1: kubeadm thinks that our cluster is running 1.24.0.
Note 1: kubeadm thinks that our cluster is running 1.24.1.
<br/>It is confused by our manual upgrade of the API server!
Note 2: kubeadm itself is still version 1.20.15..
<br/>It doesn't know how to upgrade do 1.21.X.
Note 2: kubeadm itself is still version 1.22.1..
<br/>It doesn't know how to upgrade do 1.23.X.
---
@@ -324,7 +324,7 @@ Note 2: kubeadm itself is still version 1.20.15..
- Upgrade kubeadm:
```
sudo apt install kubeadm
sudo apt install kubeadm=1.27.0-00
```
- Check what kubeadm tells us:
@@ -335,28 +335,28 @@ Note 2: kubeadm itself is still version 1.20.15..
]
Problem: kubeadm doesn't know know how to handle
upgrades from version 1.20.
upgrades from version 1.22.
This is because we installed version 1.24 (or even later).
This is because we installed version 1.27.
We need to install kubeadm version 1.21.X.
We need to install kubeadm version 1.23.X.
---
## Downgrading kubeadm
- We need to go back to version 1.21.X.
- We need to go back to kubeadm version 1.23.X.
.lab[
- View available versions for package `kubeadm`:
```bash
apt show kubeadm -a | grep ^Version | grep 1.21
apt show kubeadm -a | grep ^Version | grep 1.23
```
- Downgrade kubeadm:
```
sudo apt install kubeadm=1.21.0-00
sudo apt install kubeadm=1.23.0-00
```
- Check what kubeadm tells us:
@@ -366,23 +366,42 @@ We need to install kubeadm version 1.21.X.
]
kubeadm should now agree to upgrade to 1.21.X.
kubeadm should now agree to upgrade to 1.23.X.
---
## Reverting our manual API server upgrade
- First, we should revert our `image:` change
(so that kubeadm executes the right migration steps)
.lab[
- Edit the API server pod manifest:
```bash
sudo vim /etc/kubernetes/manifests/kube-apiserver.yaml
```
- Look for the `image:` line, and restore it to the original value
(e.g. `v1.22.17`)
- Wait for the control plane to come back up
]
---
## Upgrading the cluster with kubeadm
- Ideally, we should revert our `image:` change
(so that kubeadm executes the right migration steps)
- Or we can try the upgrade anyway
- Now we can let kubeadm do its job!
.lab[
- Perform the upgrade:
```bash
sudo kubeadm upgrade apply v1.19.8
sudo kubeadm upgrade apply v1.23.0
```
]
@@ -397,7 +416,7 @@ kubeadm should now agree to upgrade to 1.21.X.
.lab[
- Log into node `oldversion3`
- Log into node `oldversion2`
- View available versions for package `kubelet`:
```bash
@@ -406,7 +425,7 @@ kubeadm should now agree to upgrade to 1.21.X.
- Upgrade kubelet:
```bash
sudo apt install kubelet=1.19.8-00
sudo apt install kubelet=1.23.0-00
```
]
@@ -464,9 +483,9 @@ kubeadm should now agree to upgrade to 1.21.X.
```bash
for N in 1 2 3; do
ssh oldversion$N "
sudo apt install kubeadm=1.21.14-00 &&
sudo apt install kubeadm=1.23.0-00 &&
sudo kubeadm upgrade node &&
sudo apt install kubelet=1.21.14-00"
sudo apt install kubelet=1.23.0-00"
done
```
]
@@ -475,7 +494,7 @@ kubeadm should now agree to upgrade to 1.21.X.
## Checking what we've done
- All our nodes should now be updated to version 1.21.14
- All our nodes should now be updated to version 1.23.0
.lab[
@@ -492,13 +511,13 @@ class: extra-details
## Skipping versions
- This example worked because we went from 1.20 to 1.21
- This example worked because we went from 1.22 to 1.23
- If you are upgrading from e.g. 1.16, you will have to go through 1.17 first
- If you are upgrading from e.g. 1.21, you will have to go through 1.22 first
- This means upgrading kubeadm to 1.17.X, then using it to upgrade the cluster
- This means upgrading kubeadm to 1.22.X, then using it to upgrade the cluster
- Then upgrading kubeadm to 1.18.X, etc.
- Then upgrading kubeadm to 1.23.X, etc.
- **Make sure to read the release notes before upgrading!**