Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- it-wiki:kubernetes:cluster_upgrade [2022/11/16 07:28] – [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 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 333: / Zeile 330: @@
 $ kubectl get nodes
 </code>
-^NAME ^STATUS ^ROLES ^AGE ^VERSION|
+^NAME ^STATUS ^ROLES ^AGE ^VERSION
 |master1|Ready|control-plane,master|110d|v1.20.1|
 |master2|Ready|control-plane,master|109d|v1.20.1|
@@ Zeile 340: / Zeile 337: @@
 Für alle weiteren Master Nodes verfahren Sie nach in der gleichen Art.
-==== Upgrade Data Plane ====
+===== 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-
@@ Zeile 347: / Zeile 344: @@
 und er wieder ins Scheduling aufgenommen wird.
-=== Upgrade Worker Node ====
+==== Upgrade Worker Node =====
-Node drainen
+=== 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.