Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- it-wiki:kubernetes:cluster_upgrade [2022/11/12 06:04] – [Den Master1 wieder in das Scheduling aufnehmen] 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 221: / Zeile 218: @@
 <note important>
-Hinweis Erneuerung der Zertifikate des Clusters
+**Hinweis**
+Erneuerung der Zertifikate des Clusters
 Im Zuge eines Cluster-Upgrades werden die Zertifikate des Clusters um ein Jahr ver-
 längert. Mit dem Befehl „kubeadm alpha certs check-expiration“ können Sie
 dies überprüfen und nachvollziehen.
 </note>
+===== Upgrade Master{2,. . . } =====
+Das Vorgehen beim Upgrade weiterer Master in der Control Plane entspricht weitgehend
+dem Vorgehen des Upgrades beim Master1. Der einzige Unterschied sind die Parameter
+der upgrade-Option von kubeadm.
+==== Upgrade ====
+=== Master Nodes drainen ===
+Zunächst müssen auch die weiteren Master Nodes mit ''kubectl drain'' von ihrer Work-
+load befreit und aus dem Scheduling genommen werden:
+<code bash>
+$ kubectl drain master2 --ignore-daemonsets
+node/tmaster2 already cordoned
+WARNING: ignoring DaemonSet-managed Pods:
+    kube-system/calico-node-vz27p, kube-system/kube-proxy-sq2lm
+node/master2 drained
+$ kubectl get nodes master2
+</code>
+^NAME ^STATUS^ ROLES ^AGE ^VERSION
+|master2|Ready,SchedulingDisabled|control-plane,master|109d|v1.19.2|
+=== Status und Konfiguration überprüfen ===
+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.
+**Überprüfen des etcd:**
+<code bash>
+$ kubectl get pod -n kube-system --selector component=etcd
+</code>
+^NAME ^READY ^STATUS ^RESTARTS ^AGE
+|etcd-master1|1/1|Running|13|5d1h|
+|etcd-master2|1/1|Running|158|103d|
+|etcd-master3|1/1|Running|194|103d|
+**Überprüfen der Api-Version mit curl:**
+<code bash>
+curl https://<IP-Adress of MasterNode>:6443/version -k
+{
+"major": "1",
+"minor": "19",
+"gitVersion": "v1.19.2",
+"gitCommit": "f5743093fd1c663cb0cbc89748f730662345d44d",
+"gitTreeState": "clean",
+"buildDate": "2020-09-16T13:32:58Z",
+"goVersion": "go1.15",
+"compiler": "gc",
+"platform": "linux/amd64"
+}%
+</code>
+=== Upgrade durchführen ===
+Damit das Upgrade durchgeführt werden kann, muss zunächst auf dem jeweiligen Mas-
+ter Node die gewünschte ''kubeadm''-Version installiert werden. Dafür setzen Sie zunächst
+das Paket auf ''unhold'':
+<code bash>
+$ sudo apt-mark unhold kubeadm
+Canceled hold on kubeadm
+</code>
+Dann wird unter der Angabe der Version ''kubeadm'' installiert:
+<code bash>
+$ sudo apt-get install kubeadm=1.20.1-00
+</code>
+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.
+</code>
+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.