it-wiki:kubernetes:cluster_upgrade
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
| it-wiki:kubernetes:cluster_upgrade [2022/11/12 07:36] – [Upgrade Master{2,. . . }] marko | it-wiki:kubernetes:cluster_upgrade [2024/02/07 07:11] (aktuell) – [Upgrade Worker Node] marko | ||
|---|---|---|---|
| Zeile 19: | Zeile 19: | ||
| === Den Master1 „drainen“ === | === Den Master1 „drainen“ === | ||
| Damit der Master1 ein Versions-Upgrade (oder auch Downgrade) erhalten kann, muss er | Damit der Master1 ein Versions-Upgrade (oder auch Downgrade) erhalten kann, muss er | ||
| - | zunächst mit '' | + | zunächst mit '' |
| - | nommen | + | |
| wie auf den Workern, jedoch beispielsweise der '' | wie auf den Workern, jedoch beispielsweise der '' | ||
| <code bash> | <code bash> | ||
| - | $ kubectl get pods -n kube-system -o wide --field-selector | + | $ kubectl get pods -n kube-system -o wide --field-selector |
| </ | </ | ||
| - | ^NAME ^READY ^STATUS ^RESTARTS ^AGE| | + | ^NAME ^READY ^STATUS ^RESTARTS ^AGE |
| |calico-node-vdm6g|1/ | |calico-node-vdm6g|1/ | ||
| |coredns-74ff55c5b-6k7rg|1/ | |coredns-74ff55c5b-6k7rg|1/ | ||
| Zeile 55: | Zeile 54: | ||
| <code bash>$ kubectl get nodes</ | <code bash>$ kubectl get nodes</ | ||
| - | ^NAME ^STATUS ^ROLES ^AGE ^VERSION| | + | ^NAME ^STATUS ^ROLES ^AGE ^VERSION |
| |master1|Ready, | |master1|Ready, | ||
| |master2|Ready|control-plane, | |master2|Ready|control-plane, | ||
| Zeile 62: | Zeile 61: | ||
| |worker2|Ready|< | |worker2|Ready|< | ||
| - | Die Version bezieht sich hier auf die Version des Kubelets auf den Nodes. Mit der Op- | + | Die Version bezieht sich hier auf die Version des Kubelets auf den Nodes. Mit der Option |
| - | tion '' | + | Betriebssystem, |
| - | Betriebssystem, | + | |
| - | weiligen | + | |
| Sollte der etcd-Cluster fehlerhaft sein und es kommt bei dem Upgrade zu einem Ausfall | Sollte der etcd-Cluster fehlerhaft sein und es kommt bei dem Upgrade zu einem Ausfall | ||
| des Nodes, so kann das Quorum zwischen den etcd-Clustereinheiten nicht ausgeführt | des Nodes, so kann das Quorum zwischen den etcd-Clustereinheiten nicht ausgeführt | ||
| Zeile 73: | Zeile 70: | ||
| <code bash>$ kubectl get pod -n kube-system --selector component=etcd</ | <code bash>$ kubectl get pod -n kube-system --selector component=etcd</ | ||
| - | ^NAME ^READY ^STATUS ^RESTARTS ^AGE| | + | ^NAME ^READY ^STATUS ^RESTARTS ^AGE |
| |etcd-master1|1/ | |etcd-master1|1/ | ||
| |etcd-master2|1/ | |etcd-master2|1/ | ||
| Zeile 206: | Zeile 203: | ||
| Der Node ist nun wieder einsatzbereit und auf die neue Version aktualisiert: | Der Node ist nun wieder einsatzbereit und auf die neue Version aktualisiert: | ||
| - | >code bash> | + | <code bash> |
| $ kubectl get nodes | $ kubectl get nodes | ||
| </ | </ | ||
| - | ^NAME ^STATUS ^ROLES ^AGE ^VERSION| | + | ^NAME ^STATUS ^ROLES ^AGE ^VERSION |
| |master1|Ready|control-plane, | |master1|Ready|control-plane, | ||
| |master2|Ready|control-plane, | |master2|Ready|control-plane, | ||
| Zeile 232: | Zeile 229: | ||
| dem Vorgehen des Upgrades beim Master1. Der einzige Unterschied sind die Parameter | dem Vorgehen des Upgrades beim Master1. Der einzige Unterschied sind die Parameter | ||
| der upgrade-Option von kubeadm. | der upgrade-Option von kubeadm. | ||
| - | ==== Upgrade | + | ==== Upgrade ==== |
| === Master Nodes drainen === | === Master Nodes drainen === | ||
| Zunächst müssen auch die weiteren Master Nodes mit '' | Zunächst müssen auch die weiteren Master Nodes mit '' | ||
| Zeile 244: | Zeile 241: | ||
| $ kubectl get nodes master2 | $ kubectl get nodes master2 | ||
| </ | </ | ||
| - | ^NAME ^STATUS^ ROLES ^AGE ^VERSION| | + | ^NAME ^STATUS^ ROLES ^AGE ^VERSION |
| |master2|Ready, | |master2|Ready, | ||
| Zeile 250: | Zeile 247: | ||
| Auch vor den Upgrades weiterer Master Nodes ist es sinnvoll, den Status des etcd-Clusters | Auch vor den Upgrades weiterer Master Nodes ist es sinnvoll, den Status des etcd-Clusters | ||
| sowie die Version der Api des Masters zu überprüfen. | sowie die Version der Api des Masters zu überprüfen. | ||
| - | Überprüfen des etcd: | + | **Überprüfen des etcd:** |
| <code bash> | <code bash> | ||
| $ kubectl get pod -n kube-system --selector component=etcd | $ kubectl get pod -n kube-system --selector component=etcd | ||
| </ | </ | ||
| - | ^NAME ^READY ^STATUS ^RESTARTS ^AGE| | + | ^NAME ^READY ^STATUS ^RESTARTS ^AGE |
| |etcd-master1|1/ | |etcd-master1|1/ | ||
| |etcd-master2|1/ | |etcd-master2|1/ | ||
| |etcd-master3|1/ | |etcd-master3|1/ | ||
| + | |||
| + | **Überprüfen der Api-Version mit curl:** | ||
| + | <code bash> | ||
| + | curl https://< | ||
| + | { | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | }% | ||
| + | </ | ||
| + | |||
| + | === Upgrade durchführen === | ||
| + | Damit das Upgrade durchgeführt werden kann, muss zunächst auf dem jeweiligen Mas- | ||
| + | ter Node die gewünschte '' | ||
| + | das Paket auf '' | ||
| + | <code bash> | ||
| + | $ sudo apt-mark unhold kubeadm | ||
| + | Canceled hold on kubeadm | ||
| + | </ | ||
| + | |||
| + | Dann wird unter der Angabe der Version '' | ||
| + | <code bash> | ||
| + | $ sudo apt-get install kubeadm=1.20.1-00 | ||
| + | </ | ||
| + | |||
| + | Jetzt wird der Node mit dem Parameter '' | ||
| + | den Versionsstand des Master1 gebracht: | ||
| + | <code bash> | ||
| + | $ sudo kubeadm upgrade node | ||
| + | [...] | ||
| + | [upgrade] The configuration for this node was successfully updated! | ||
| + | [upgrade] Now you should go ahead and upgrade the kubelet package | ||
| + | using your package manager. | ||
| + | </ | ||
| + | |||
| + | Damit ist das Upgrade auf dem Node durchgeführt. Jetzt müssen das '' | ||
| + | '' | ||
| + | nen“. | ||
| + | |||
| + | === kubectl und kubelet upgraden === | ||
| + | Um die Binaries auf die neue Version zu upgraden, müssen diese im Paketmanager auf | ||
| + | '' | ||
| + | <code bash> | ||
| + | $ sudo apt-mark unhold kubelet kubectl | ||
| + | Canceled hold on kubelet | ||
| + | Canceled hold on kubectl | ||
| + | </ | ||
| + | Anschließend werden die Pakete mit Angabe der Version installiert: | ||
| + | <code bash> | ||
| + | $ sudo apt-get install kubelet=1.20.1-00 kubectl=1.20.1-00 | ||
| + | </ | ||
| + | Schließlich werden alle Pakete wieder auf '' | ||
| + | <code bash> | ||
| + | $ sudo apt-mark hold " | ||
| + | kubernetes-cni was already set on hold. | ||
| + | kubeadm set on hold | ||
| + | kubelet set on hold | ||
| + | kubectl set on hold | ||
| + | </ | ||
| + | |||
| + | === Node „uncordonen“ === | ||
| + | Im letzten Schritt wird der Node wieder in das Scheduling aufgenommen. Damit ist das | ||
| + | Upgrade abgeschlossen: | ||
| + | <code bash> | ||
| + | $ kubectl uncordon master2 | ||
| + | node/ | ||
| + | $ kubectl get nodes | ||
| + | </ | ||
| + | ^NAME ^STATUS ^ROLES ^AGE ^VERSION | ||
| + | |master1|Ready|control-plane, | ||
| + | |master2|Ready|control-plane, | ||
| + | |master3|Ready|control-plane, | ||
| + | |||
| + | Für alle weiteren Master Nodes verfahren Sie nach in der gleichen Art. | ||
| + | |||
| + | ===== Upgrade Data Plane ===== | ||
| + | Das Upgrade der Data Plane besteht im Prinzip ausschließlich aus dem Angleichen der | ||
| + | Version des kubelets der Worker Nodes auf die entsprechende Version der Master No- | ||
| + | des in der Control Plane. Dabei wird der Worker Node aus dem Scheduling entfernt und | ||
| + | von Workloads bereinigt, bevor im Anschluss die neue Version des kubelets installiert | ||
| + | und er wieder ins Scheduling aufgenommen wird. | ||
| + | |||
| + | ==== Upgrade Worker Node ===== | ||
| + | === Node drainen === | ||
| + | Führen Sie '' | ||
| + | <code bash> | ||
| + | $ kubectl drain worker1 --ignore-daemonsets | ||
| + | node/ | ||
| + | WARNING: ignoring DaemonSet-managed Pods: | ||
| + | kube-system/ | ||
| + | evicting pod kube-system/ | ||
| + | evicting pod kube-system/ | ||
| + | pod/ | ||
| + | pod/ | ||
| + | node/ | ||
| + | </ | ||
| + | |||
| + | === Upgrade des kubelet === | ||
| + | Das Upgrade des '' | ||
| + | Version vorgenommen. Optional können auch die Pakete '' | ||
| + | neuen Version installiert werden. | ||
| + | Pakete im Paketmanager auf '' | ||
| + | <code bash> | ||
| + | $ sudo apt-mark unhold kubelet kubeadm kubectl | ||
| + | Canceled hold on kubelet | ||
| + | Canceled hold on kubeadm | ||
| + | Canceled hold on kubectl | ||
| + | </ | ||
| + | |||
| + | Anschließend werden die neuen Pakete installiert und dann wieder auf '' | ||
| + | <code bash> | ||
| + | $ sudo apt-get install kubelet=1.20.1-00 kubectl=1.20.1-00 | ||
| + | kubeadm=1.20.1-00 | ||
| + | $ sudo apt-mark hold kubeadm kubelet kubectl | ||
| + | kubeadm set on hold | ||
| + | kubelet set on hold | ||
| + | kubectl set on hold | ||
| + | </ | ||
| + | |||
| + | Nun wird der Node wieder „uncordoned“, | ||
| + | werden können: | ||
| + | <code bash> | ||
| + | $ kubectl uncordon worker1 | ||
| + | node/ | ||
| + | </ | ||
| + | |||
| + | Damit ist das Upgrade für den Worker abgeschlossen: | ||
| + | <code bash> | ||
| + | $ kubectl get nodes worker1 | ||
| + | </ | ||
| + | ^NAME ^STATUS ^ROLES ^AGE ^VERSION | ||
| + | |worker1|Ready|< | ||
| + | |||
| + | Verfahren Sie für alle weiteren Worker Nodes in Ihrer Data Plane auf dieselbe Weise. | ||
it-wiki/kubernetes/cluster_upgrade.1668238561.txt.gz · Zuletzt geändert: von marko