Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- it-wiki:kubernetes:cluster_upgrade [2022/11/12 07:43] – [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“ ===
 Damit der Master1 ein Versions-Upgrade (oder auch Downgrade) erhalten kann, muss er
-zunächst mit ''kubectl drain'' von seiner Workload befreit und aus dem Scheduler ge-
+zunächst mit ''kubectl drain'' von seiner Workload befreit und aus dem Scheduler genommen werden. Zwar laufen in der Control Plane keine Workloads im typischen Sinne
-nommen werden. Zwar laufen in der Control Plane keine Workloads im typischen Sinne
 wie auf den Workern, jedoch beispielsweise der ''coredns''-Pod:
 <code bash>
-$ kubectl get pods -n kube-system -o wide --field-selector
+$ kubectl get pods -n kube-system -o wide --field-selector spec.nodeName=master1
 </code>
-^NAME ^READY ^STATUS ^RESTARTS ^AGE|
+^NAME ^READY ^STATUS ^RESTARTS ^AGE
 |calico-node-vdm6g|1/1|Running|1|105d|
 |coredns-74ff55c5b-6k7rg|1/1|Running|0|24h|
@@ Zeile 55: / Zeile 54: @@
 <code bash>$ kubectl get nodes</code>
-^NAME ^STATUS ^ROLES ^AGE ^VERSION|
+^NAME ^STATUS ^ROLES ^AGE ^VERSION
 |master1|Ready,SchedulingDisabled|control-plane,master|106d|v1.19.2|
 |master2|Ready|control-plane,master|106d|v1.19.2|
@@ Zeile 62: / Zeile 61: @@
 |worker2|Ready|<none>|106d|v1.19.2|
-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 ''-o wide'' können Sie sich zusätzlich zu diesen Daten auch Informationen über das
-tion ''-o wide'' können Sie sich zusätzlich zu diesen Daten auch Informationen über das
+Betriebssystem, die Kernel-Version und die verwendete Container Runtime auf den jeweiligen Nodes anzeigen lassen.
-Betriebssystem, die Kernel-Version und die verwendete Container Runtime auf den je-
-weiligen Nodes anzeigen lassen.
 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
@@ Zeile 73: / Zeile 70: @@
 <code bash>$ kubectl get pod -n kube-system --selector component=etcd</code>
-^NAME ^READY ^STATUS ^RESTARTS ^AGE|
+^NAME ^READY ^STATUS ^RESTARTS ^AGE
 |etcd-master1|1/1|Running|4|29h|
 |etcd-master2|1/1|Running|149|100d|
@@ Zeile 206: / Zeile 203: @@
 Der Node ist nun wieder einsatzbereit und auf die neue Version aktualisiert:
->code bash>
+<code bash>
 $ kubectl get nodes
 </code>
-^NAME ^STATUS ^ROLES ^AGE ^VERSION|
+^NAME ^STATUS ^ROLES ^AGE ^VERSION
 |master1|Ready|control-plane,master|107d|v1.20.1|
 |master2|Ready|control-plane,master|107d|v1.19.2|
@@ Zeile 232: / Zeile 229: @@
 dem Vorgehen des Upgrades beim Master1. Der einzige Unterschied sind die Parameter
 der upgrade-Option von kubeadm.
-==== Upgrade Master{2,. . . } ====
+==== Upgrade ====
 === Master Nodes drainen ===
 Zunächst müssen auch die weiteren Master Nodes mit ''kubectl drain'' von ihrer Work-
@@ Zeile 244: / Zeile 241: @@
 $ kubectl get nodes master2
 </code>
-^NAME ^STATUS^ ROLES ^AGE ^VERSION|
+^NAME ^STATUS^ ROLES ^AGE ^VERSION
 |master2|Ready,SchedulingDisabled|control-plane,master|109d|v1.19.2|
@@ Zeile 255: / Zeile 252: @@
 </code>
-^NAME ^READY ^STATUS ^RESTARTS ^AGE|
+^NAME ^READY ^STATUS ^RESTARTS ^AGE
 |etcd-master1|1/1|Running|13|5d1h|
 |etcd-master2|1/1|Running|158|103d|
@@ Zeile 290: / Zeile 287: @@
 </code>
-Jetzt wird der Node mit dem Parameter node für die Option upgrade von kubeadm auf
+Jetzt wird der Node mit dem Parameter ''node'' für die Option ''upgrade'' von ''kubeadm'' auf
 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.
+    using your package manager.
-Damit ist das Upgrade auf dem Node durchgeführt. Jetzt müssen das kubelet und
+</code>
-kubectl auf die neue Version gebracht werden, bevor Sie den Node wieder „uncordo-
+Damit ist das Upgrade auf dem Node durchgeführt. Jetzt müssen das ''kubelet'' und
+''kubectl'' auf die neue Version gebracht werden, bevor Sie den Node wieder „uncordo-
 nen“.
+=== kubectl und kubelet upgraden ===
+Um die Binaries auf die neue Version zu upgraden, müssen diese im Paketmanager auf
+''unhold'' gesetzt werden:
+<code bash>
+$ sudo apt-mark unhold kubelet kubectl
+Canceled hold on kubelet
+Canceled hold on kubectl
+</code>
+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
+</code>
+Schließlich werden alle Pakete wieder auf ''hold'' gesetzt:
+<code bash>
+$ sudo apt-mark hold "kube*"
+kubernetes-cni was already set on hold.
+kubeadm set on hold
+kubelet set on hold
+kubectl set on hold
+</code>
+=== Node „uncordonen“ ===
+Im letzten Schritt wird der Node wieder in das Scheduling aufgenommen. Damit ist das
+Upgrade abgeschlossen:
+<code bash>
+$ kubectl uncordon master2
+node/master2 uncordoned
+$ kubectl get nodes
+</code>
+^NAME ^STATUS ^ROLES ^AGE ^VERSION
+|master1|Ready|control-plane,master|110d|v1.20.1|
+|master2|Ready|control-plane,master|109d|v1.20.1|
+|master3|Ready|control-plane,master|109d|v1.19.2|
+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 ''kubectl drain'' für den entsprechenden Worker aus:
+<code bash>
+$ kubectl drain worker1 --ignore-daemonsets
+node/worker1 cordoned
+WARNING: ignoring DaemonSet-managed Pods:
+    kube-system/calico-node-2s4lv, kube-system/kube-proxy-k54gg
+evicting pod kube-system/calico-kube-controllers-866f6f96b5-smldm
+evicting pod kube-system/coredns-74ff55c5b-j8fkn
+pod/coredns-74ff55c5b-j8fkn evicted
+pod/calico-kube-controllers-866f6f96b5-smldm evicted
+node/worker1 evicted
+</code>
+=== Upgrade des kubelet ===
+Das Upgrade des ''kubelet'' wird mit Hilfe des Paketmanagers unter Angabe der genauen
+Version vorgenommen. Optional können auch die Pakete ''kubeadm'' und ''kubectl'' in der
+neuen Version installiert werden.
+Pakete im Paketmanager auf ''unhold'' setzen:
+<code bash>
+$ sudo apt-mark unhold kubelet kubeadm kubectl
+Canceled hold on kubelet
+Canceled hold on kubeadm
+Canceled hold on kubectl
+</code>
+Anschließend werden die neuen Pakete installiert und dann wieder auf ''hold'' gesetzt:
+<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
+</code>
+Nun wird der Node wieder „uncordoned“, sodass auf ihm wieder Workloads platziert
+werden können:
+<code bash>
+$ kubectl uncordon worker1
+node/worker1 uncordoned
+</code>
+Damit ist das Upgrade für den Worker abgeschlossen:
+<code bash>
+$ kubectl get nodes worker1
+</code>
+^NAME ^STATUS ^ROLES ^AGE ^VERSION
+|worker1|Ready|<none>|109d|v1.20.1
+Verfahren Sie für alle weiteren Worker Nodes in Ihrer Data Plane auf dieselbe Weise.