Najpierw aktualizujemy nody Master następnie workery. Aktualizujemy do najnowszej wersji pomocniczej (minor) następnie do najnowszej następnej wersji minor
1.27.7 -> 1.27.11 -> 1.28.11 -> 1.29.5
Dostępne wersje możemy sprawdzić na stronie https://github.com/rancher/rke2/releases
Automatyczna aktualizacja
Na podstawie https://docs.rke2.io/upgrades/automated_upgrade
Przygotowanie komponentów
Instalacja system-upgrade-controller. (Sprawdzić czy nie ma nowej wersji) https://github.com/rancher/system-upgrade-controller/releases
W url podmieniamy xxxxxxx na aktualny numer wersji np” v0.13.4
# kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/download/xxxxxxx/system-upgrade-controller.yamlPrzygotować plan aktualizacji osobno dla nodów master i worker
# cd /opt/kubernetes/auto-upgarde
# nano upgrade_plan.yaml
# Server plan
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
name: server-plan
namespace: system-upgrade
spec:
concurrency: 1
cordon: true
nodeSelector:
matchExpressions:
- key: node-role.kubernetes.io/control-plane
operator: In
values:
- "true"
serviceAccountName: system-upgrade
upgrade:
image: rancher/rke2-upgrade
version: v1.34.12+rke2r1
# channel: https://update.rke2.io/v1-release/channels/stable
---
# Agent plan
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
name: agent-plan
namespace: system-upgrade
spec:
concurrency: 1
cordon: true
nodeSelector:
matchExpressions:
- key: node-role.kubernetes.io/control-plane
operator: DoesNotExist
prepare:
args:
- prepare
- server-plan
image: rancher/rke2-upgrade
serviceAccountName: system-upgrade
upgrade:
image: rancher/rke2-upgrade
version: v1.34.12+rke2r1
# channel: https://update.rke2.io/v1-release/channels/stable
Dodajemy etykiety do wszystkich nodów
# kubectl label node --all rke2-upgrade=trueUpgrade klastra
Sprawdzamy aktualną wersję
# kubectl get nodesZmieniamy w upgrade_plan.yaml version pilnując ścieżki upgrade i aplikujemy nowy plan
# kubectl apply -f upgrade_plan.yamlZaraz po aplikacji nowego plany rozpocznie sie upgrade klastra
Możemy sprawdzić działanie
# kubectl -n system-upgrade get plans -o yaml
# kubectl -n system-upgrade get jobs -o yaml
# kubectl get nodesProblemy
1. Mialem przypadek, że jeden z nodów nie chał się zaktualizować automatycznie. Aby rozwiązać problem skasowałem plan i wykonałem aktualizacje ręczną tego noda.
# kubectl delete -f upgrade_plan.yaml
2. Miałem tez przypadek że jeden nod bradzo długo się aktualizował (dłużej niż 30 minut) a potem przestał odpowiadać na polecenia api np kubectl get nodes. Wszystkie pody `planera apply-server-plan …` były już zakończone.
kubectl -n system-upgrade get podsWwykonując polecenie kubectl get nodes na innym nodzie system pokazywał tego noda nadal w starej wersji
Uruchomiłe wtedy ponownie usługę rke2-server na problematycznym nodzie i ręcznie ustawiłem uncordon. Po uruchomieniu nod był zaktualizowany.
systemctl stop rke2-server
systemctl start rke2-server
kubectl uncordon <node name>3. Zdarzyło mi się, że po aktualizacji ręcznej system nadal cały czas próbuje go zaktualizować blokując noda. Aby usunąć problem odczytałem z innego noda label „plan.upgrade.cattle.io/agent-plan” i nadpisałem label w problematycznym nodzie.
# kubectl get node NODE-NAME-OK -o yaml
...
metadata:
labels:
plan.upgrade.cattle.io/agent-plan: xxxxxxxx
...
# kubectl label node NODE-NAME-PROBLEM plan.upgrade.cattle.io/server-plan=xxxxxxxx --overwrite
lub w przypadku workera
# kubectl label node NODE-NAME-PROBLEM plan.upgrade.cattle.io/agent-plan=xxxxxxxx --overwrite
# kubectl uncordon k8s-worker02
Zabbix pokazuje problemy po aktualizacji
Po aktualizacji zauważyłem że zabbix pokazuje przekroczone limity pamięci i cpu. Zauważyłem że wisiały takie pody w stanie Completed z usytawionym dużym limitem.
kubectl get pods -A -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,NODE:.spec.nodeName,CPU_REQ:.spec.containers[*].resources.requests.cpu,CPU_LIM:.spec.containers[*].resources.limits.cpu,MEM_REQ:.spec.containers[*].resources.requests.memory,MEM_LIM:.spec.containers[*].resources.limits.memory'Zabbix wlicza je do limitów i dlatego wyświetla problemy
kube-system helm-install-rke2-canal-w4x4v 0/1 Completed 5 163m 192.168.136.36 k8s-test03 <none> <none>
kube-system helm-install-rke2-coredns-4tmqj 0/1 Completed 7 163m 192.168.136.35 k8s-test02 <none> <none>
kube-system helm-install-rke2-ingress-nginx-mbw6l 0/1 Completed 0 163m <none> k8s-test03 <none> <none>
kube-system helm-install-rke2-metrics-server-r2wwv 0/1 Completed 0 163m <none> k8s-test02 <none> <none>
kube-system helm-install-rke2-runtimeclasses-hvzmt 0/1 Completed 2 163m <none> k8s-test02 <none> <none>
kube-system helm-install-rke2-snapshot-controller-2tr86 0/1 Completed 0 163m <none> k8s-test02 <none> <none>
kube-system helm-install-rke2-snapshot-controller-crd-q2r97 0/1 Completed 5 163m 10.42.2.153 k8s-test03 <none> <none> Ponieważ były w stanie Completed to je usunąłem
kubectl -n kube-system delete pod <podname>Ręczna aktualizacja
Na każdym nodzie MASTER uruchamiamy
# kubectl cordon NODE-NAME - zapobiega uruchomieniu nowych podów
# kubectl drain --ignore-daemonsets --delete-emptydir-data <NODE-NAME> - migruje pody zwalniając noda
# curl -sfL https://get.rke2.io/ | INSTALL_RKE2_VERSION=v1.27.12+rke2r1 sh -
# systemctl restart rke2-server
# kubectl uncordon NODE-NAMENa każdym workerze
# kubectl cordon NODE-NAME
# kubectl drain --ignore-daemonsets --delete-emptydir-data <NODE-NAME>
# curl -sfL https://get.rke2.io/ | INSTALL_RKE2_TYPE="agent" INSTALL_RKE2_VERSION=v1.27.12+rke2r1 sh -
# systemctl restart rke2-agent
# kubectl uncordon NODE-NAME