mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-02-14 17:49:59 +00:00
⏫ Bump up version numbers in upgrade labs
This commit is contained in:
Jérôme Petazzoni
@@ -103,7 +103,7 @@ class: extra-details
|
||||
|
||||
---
|
||||
|
||||
## `WithWaitGroup`,
|
||||
## `WithWaitGroup`
|
||||
|
||||
- When we shutdown, tells clients (with in-flight requests) to retry
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
- It's *recommended* to run consistent versions across a cluster
|
||||
|
||||
(mostly to have feature parity and latest security updates)
|
||||
(mostly to have feature parity and laoldversion security updates)
|
||||
|
||||
- It's not *mandatory*
|
||||
|
||||
@@ -20,7 +20,7 @@
|
||||
|
||||
.lab[
|
||||
|
||||
- Log into node `test1`
|
||||
- Log into node `oldversion1`
|
||||
|
||||
- Check the version of kubectl and of the API server:
|
||||
```bash
|
||||
@@ -81,7 +81,7 @@
|
||||
|
||||
## What version are we running anyway?
|
||||
|
||||
- When I say, "I'm running Kubernetes 1.15", is that the version of:
|
||||
- When I say, "I'm running Kubernetes 1.18", is that the version of:
|
||||
|
||||
- kubectl
|
||||
|
||||
@@ -157,17 +157,17 @@
|
||||
|
||||
## Kubernetes uses semantic versioning
|
||||
|
||||
- Kubernetes versions look like MAJOR.MINOR.PATCH; e.g. in 1.17.2:
|
||||
- Kubernetes versions look like MAJOR.MINOR.PATCH; e.g. in 1.18.20:
|
||||
|
||||
- MAJOR = 1
|
||||
- MINOR = 17
|
||||
- PATCH = 2
|
||||
- MINOR = 18
|
||||
- PATCH = 20
|
||||
|
||||
- It's always possible to mix and match different PATCH releases
|
||||
|
||||
(e.g. 1.16.1 and 1.16.6 are compatible)
|
||||
(e.g. 1.18.20 and 1.18.15 are compatible)
|
||||
|
||||
- It is recommended to run the latest PATCH release
|
||||
- It is recommended to run the laoldversion PATCH release
|
||||
|
||||
(but it's mandatory only when there is a security advisory)
|
||||
|
||||
@@ -181,9 +181,9 @@
|
||||
|
||||
- All components support a difference of one¹ MINOR version
|
||||
|
||||
- This allows live upgrades (since we can mix e.g. 1.15 and 1.16)
|
||||
- This allows live upgrades (since we can mix e.g. 1.18 and 1.19)
|
||||
|
||||
- It also means that going from 1.14 to 1.16 requires going through 1.15
|
||||
- It also means that going from 1.18 to 1.20 requires going through 1.19
|
||||
|
||||
.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.]
|
||||
@@ -214,7 +214,7 @@ and kubectl, which can be one MINOR ahead or behind API server.]
|
||||
|
||||
- We will change the version of the API server
|
||||
|
||||
- We will work with cluster `test` (nodes `test1`, `test2`, `test3`)
|
||||
- We will work with cluster `oldversion` (nodes `oldversion1`, `oldversion2`, `oldversion3`)
|
||||
|
||||
---
|
||||
|
||||
@@ -242,7 +242,7 @@ and kubectl, which can be one MINOR ahead or behind API server.]
|
||||
|
||||
.lab[
|
||||
|
||||
- Log into node `test1`
|
||||
- Log into node `oldversion1`
|
||||
|
||||
- Check API server version:
|
||||
```bash
|
||||
@@ -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.16.0`
|
||||
- Look for the `image:` line, and update it to e.g. `v1.19.0`
|
||||
|
||||
]
|
||||
|
||||
@@ -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.16.0.
|
||||
Note 1: kubeadm thinks that our cluster is running 1.19.0.
|
||||
<br/>It is confused by our manual upgrade of the API server!
|
||||
|
||||
Note 2: kubeadm itself is still version 1.15.9.
|
||||
<br/>It doesn't know how to upgrade do 1.16.X.
|
||||
Note 2: kubeadm itself is still version 1.18.20..
|
||||
<br/>It doesn't know how to upgrade do 1.19.X.
|
||||
|
||||
---
|
||||
|
||||
@@ -335,28 +335,28 @@ Note 2: kubeadm itself is still version 1.15.9.
|
||||
]
|
||||
|
||||
Problem: kubeadm doesn't know know how to handle
|
||||
upgrades from version 1.15.
|
||||
upgrades from version 1.18.
|
||||
|
||||
This is because we installed version 1.17 (or even later).
|
||||
This is because we installed version 1.22 (or even later).
|
||||
|
||||
We need to install kubeadm version 1.16.X.
|
||||
We need to install kubeadm version 1.19.X.
|
||||
|
||||
---
|
||||
|
||||
## Downgrading kubeadm
|
||||
|
||||
- We need to go back to version 1.16.X (e.g. 1.16.6)
|
||||
- We need to go back to version 1.19.X.
|
||||
|
||||
.lab[
|
||||
|
||||
- View available versions for package `kubeadm`:
|
||||
```bash
|
||||
apt show kubeadm -a | grep ^Version | grep 1.16
|
||||
apt show kubeadm -a | grep ^Version | grep 1.19
|
||||
```
|
||||
|
||||
- Downgrade kubeadm:
|
||||
```
|
||||
sudo apt install kubeadm=1.16.6-00
|
||||
sudo apt install kubeadm=1.19.8-00
|
||||
```
|
||||
|
||||
- Check what kubeadm tells us:
|
||||
@@ -366,7 +366,7 @@ We need to install kubeadm version 1.16.X.
|
||||
|
||||
]
|
||||
|
||||
kubeadm should now agree to upgrade to 1.16.6.
|
||||
kubeadm should now agree to upgrade to 1.19.8.
|
||||
|
||||
---
|
||||
|
||||
@@ -382,7 +382,7 @@ kubeadm should now agree to upgrade to 1.16.6.
|
||||
|
||||
- Perform the upgrade:
|
||||
```bash
|
||||
sudo kubeadm upgrade apply v1.16.6
|
||||
sudo kubeadm upgrade apply v1.19.8
|
||||
```
|
||||
|
||||
]
|
||||
@@ -397,7 +397,7 @@ kubeadm should now agree to upgrade to 1.16.6.
|
||||
|
||||
.lab[
|
||||
|
||||
- Log into node `test3`
|
||||
- Log into node `oldversion3`
|
||||
|
||||
- View available versions for package `kubelet`:
|
||||
```bash
|
||||
@@ -406,7 +406,7 @@ kubeadm should now agree to upgrade to 1.16.6.
|
||||
|
||||
- Upgrade kubelet:
|
||||
```bash
|
||||
sudo apt install kubelet=1.16.6-00
|
||||
sudo apt install kubelet=1.19.8-00
|
||||
```
|
||||
|
||||
]
|
||||
@@ -417,7 +417,7 @@ kubeadm should now agree to upgrade to 1.16.6.
|
||||
|
||||
.lab[
|
||||
|
||||
- Log into node `test1`
|
||||
- Log into node `oldversion1`
|
||||
|
||||
- Check node versions:
|
||||
```bash
|
||||
@@ -463,10 +463,10 @@ kubeadm should now agree to upgrade to 1.16.6.
|
||||
- Download the configuration on each node, and upgrade kubelet:
|
||||
```bash
|
||||
for N in 1 2 3; do
|
||||
ssh test$N "
|
||||
sudo apt install kubeadm=1.16.6-00 &&
|
||||
ssh oldversion$N "
|
||||
sudo apt install kubeadm=1.19.8-00 &&
|
||||
sudo kubeadm upgrade node &&
|
||||
sudo apt install kubelet=1.16.6-00"
|
||||
sudo apt install kubelet=1.19.8-00"
|
||||
done
|
||||
```
|
||||
]
|
||||
@@ -475,7 +475,7 @@ kubeadm should now agree to upgrade to 1.16.6.
|
||||
|
||||
## Checking what we've done
|
||||
|
||||
- All our nodes should now be updated to version 1.16.6
|
||||
- All our nodes should now be updated to version 1.19.8
|
||||
|
||||
.lab[
|
||||
|
||||
@@ -492,13 +492,13 @@ class: extra-details
|
||||
|
||||
## Skipping versions
|
||||
|
||||
- This example worked because we went from 1.15 to 1.16
|
||||
- This example worked because we went from 1.18 to 1.19
|
||||
|
||||
- If you are upgrading from e.g. 1.14, you will have to go through 1.15 first
|
||||
- If you are upgrading from e.g. 1.16, you will have to go through 1.17 first
|
||||
|
||||
- This means upgrading kubeadm to 1.15.X, then using it to upgrade the cluster
|
||||
- This means upgrading kubeadm to 1.17.X, then using it to upgrade the cluster
|
||||
|
||||
- Then upgrading kubeadm to 1.16.X, etc.
|
||||
- Then upgrading kubeadm to 1.18.X, etc.
|
||||
|
||||
- **Make sure to read the release notes before upgrading!**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user