PLAN VOOR DE MASTER-NODE
Een manifest voor het Plan voor de K3s Server kan er alsvolgt uitzien, de uitleg staat in de comments:
---
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
# De naam geeft aan om welk K3s component het gaat. Wordt tevens gebruikt in prepare op de workers.
name: k3s-server
# De namespace is waar de system-upgrade-controller deployed wordt.
namespace: system-upgrade
spec:
# Het maximaal aantal nodes dat tegelijkertijd wordt ge-update.
concurrency: 1
# De versie die gebruikt wordt om de nodes te upgraden.
version: v1.20.2-k3s1
# Gebruikt om de master-node te kunnen upgraden.
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoSchedule"
# Geef aan welke nodes voor de upgrade in aanmerking komen.
nodeSelector:
matchExpressions:
- {key: k3s-upgrade, operator: NotIn, values: ["disabled", "false"]}
- {key: k3s-upgrade, operator: Exists}
- {key: node-role.kubernetes.io/master, operator: In, values: ["true"]}
# De te gebruiken service-account met de juiste rechten.
serviceAccountName: system-upgrade
# Keuze uit de node drainen of cordonen
#drain:
# force: true
cordon: true
# Geef aan welke image geebruikt wordt voor de upgrade.
upgrade:
image: rancher/k3s-upgrade
Enkele highlights:
version: v1.20.2-k3s1
Dit geeft aan naar welke versie van K3s we willen upgraden.
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoSchedule"
De master-node is voorzien van een taint zodat workloads op de worker-nodes ge-deployed worden. Tenzij we een toleration gebruiken en dat is uiteraard nodig als we de master-node willen upgraden.
nodeSelector:
matchExpressions:
- {key: k3s-upgrade, operator: NotIn, values: ["disabled", "false"]}
- {key: k3s-upgrade, operator: Exists}
- {key: node-role.kubernetes.io/master, operator: In, values: ["true"]}
De nodeSelector zorgt ervoor dat de upgrade alleen op de master-node uitgevoerd wordt. Daarvoor dient echter wel het label ‘k3s-upgrade‘ te bestaan waarvan de waarde niet ‘false‘ of ‘disabled‘ mag zijn.
We kiezen voor cordon van de node in plaats van drain, de workloads staan immer op de worker-nodes.
PLAN VOOR DE WORKERS
Voor de worker-nodes is het plan bijna hetzelfde, hier wordt de node echter ge-drained en we maken een voorwaarde dat eerst de master-node ge-upgrade wordt alvorens de workers aan de beurt zijn.
---
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
name: k3s-agent
namespace: system-upgrade
spec:
concurrency: 1
version: v1.20.2-k3s1
nodeSelector:
matchExpressions:
- {key: k3s-upgrade, operator: NotIn, values: ["disabled", "false"]}
- {key: k3s-upgrade, operator: Exists}
- {key: node-role.kubernetes.io/master, operator: DoesNotExist}
serviceAccountName: system-upgrade
# Prepare is de stap die gedaan wordt voordat de node drained of cordoned wordt.
prepare:
image: rancher/k3s-upgrade
args: ["prepare", "k3s-server"]
drain:
# deleteLocalData: true # default
# ignoreDaemonSets: true # default
force: true
skipWaitForDeleteTimeout: 60
#cordon: true
upgrade:
image: rancher/k3s-upgrade
de highlights
prepare:
image: rancher/k3s-upgrade
args: ["prepare", "k3s-server"]
Dit geeft dus aan dat er eerst gewacht wordt op een upgrade van de master-node.
Verder mag de role master niet aanwezig zijn maar moet wel het label ‘k3s-upgrade’ aanwezig zijn.
Zowel de server als de agent manifest worden ge-applied met kubectl en daardoor ontstaan er twee jobs die wachten op geldigheid voor taint en labels.
$ kubectl apply -f k3s-server.yml plan.upgrade.cattle.io/k3s-server created $ kubectl apply -f k3s-agent.yml plan.upgrade.cattle.io/k3s-agent created
Nu is het dus een kwestie van de labels op de nodes zetten om de upgrade-jobs te laten starten:
$ kubectl label node rpi-1 rpi-2 rpi-3 k3s-upgrade=true
Als eerste wordt nu dus de master-node ge-upgrade en zodra deze weer in Ready state is volgen de worker-nodes.
Uiteindelijk zijn alle nodes ge-upgrade naar K3s versie v1.20.2-k3s1 en zijn voorzien van een label met de upgrade ID van de Plans.
Via de CLI:
kubectl get nodes --sort-by=.metadata.name NAME STATUS ROLES AGE VERSION rpi-1 Ready control-plane,master 36h v1.20.2+k3s1 rpi-2 Ready worker 34h v1.20.2+k3s1 rpi-3 Ready worker 34h v1.20.2+k3s1
via het Dashboard van de Cluster Explorer:
