Update Tanzu Workload Management

Dies ist eine kurze Anleitung zur Aktualisierung des Tanzu Workload Managements im vSphere Cluster.

Kubernetes Release und Patch Zyklen

Kubernetes-Versionen werden in Anlehnung an die Semantic Versioning-Terminologie als x.y.z angegeben, wobei x die Hauptversion, y die Minor-Version und z die Patch-Version ist. So bezeichnet beispielsweise v1.22.6 eine Minor-Version 22 mit Patchlevel 6. Minor Versions werden ungefähr alle 3-4 Monate veröffentlicht. Dazwischen gibt es mehrere Patches innerhalb der Minor-Version.

Das Kubernetes-Projekt pflegt Release-Branches für die letzten drei kleineren Versionen (1.24, 1.23, 1.22). Seit Kubernetes 1.19 erhalten neuere Versionen etwa ein Jahr lang Patch-Support. Es ist also durchaus empfehlenswert, die Kubernetes Versionen in Tanzu auf aktuellem Stand zu halten.

Schritt 1 – vCenter aktualisieren

Dieser Schritt ist nicht zwingend erforderlich, aber empfohlen. Denn meist kommen Tanzu Updates einher mit einer neuen vCenter Version. Dies ist leicht erkennbar im vSphere-Client.

„Update Tanzu Workload Management“ weiterlesen

Upgrade eines K3s Lightweight Kubernetes Clusters

K3s ist eine schlanke, hochverfügbare Open-Source-Kubernetes-Cluster-Plattform, die für eine einfache und ressourcenschonende Installation entwickelt wurde. K3s wird in einem Paket von weniger als 60 MB geliefert. Das Paket ist für ARM-Plattformen optimiert und kann daher auch auf Hardware wie einem Raspberry Pi, oder als Gast-VM auf ESXi-on-ARM betrieben werden.

Informationen sammeln

K3s ist eine Cluster-Lösung. Daher ist die Reihenfolge, in der die Knoten aktualisiert werden, wichtig. Das Update beginnt auf dem Masterknoten. Also müssen wir zunächst herausfinden, welcher Knoten diese Rolle hat. Am einfachsten geht dies mit einem kubectl Kommando:

kubectl get node
NAME STATUS ROLES AGE VERSION
k3node1.lab.local Ready master 2y43d v1.19.3+k3s3
k3node2.lab.local Ready none 2y42d v1.19.3+k3s3
k3node3.lab.local Ready none 2y42d v1.19.3+k3s3

Wir sehen in der Ausgabe oben meine drei K3s-Knoten mit FQDN, Status, Rolle, Alter und Version. Demzufolge hat hier k3node1 die Masterrolle.

Alternativ kann man den Befehl auch im ausführlichen Modus ausführen:

kubectl get node -o wide
„Upgrade eines K3s Lightweight Kubernetes Clusters“ weiterlesen

Start- und Reboot-Probleme mit Maxtang NX6412 Mini-PC unter Linux

vExpert Geschenk von Cohesity

Seit kurzer Zeit bin ich im Besitz eines Maxtang NX6412-B11 Mini PCs. Zur VMware Explore EMEA in Barcelona verteilte Cohesity diese Barebones an vExperts. An dieser Stelle nochmal einen herzlichen Dank an Cohesity für ihren Support der Community!

Der lüfterlose MiniPC mit Elkhart Lake Chipsatz ist gut ausgestattet. Er verfügt über 2x 1 Gbit LAN, 1x USB-C (front), 2x USB 3.2 (front), 2x USB 2.0, 2x HDMI 2.0, sowie einen Audio Port.

Ausstattung der Geräterückseite

Der MiniPC wird mein Homelab bereichern. Ich hatte dafür eine Installation der Tanzu-Community-Edition geplant. Leider wurde das Projekt inzwischen von VMware eingestellt und die Entfernung der Pakete aus GitHub angekündigt. 🙁

Bestückung der Hardware

Der Barebone musste noch mit RAM und einer Flashdisk ausgestattet werden. Ich verbaute eine Samsung SSD 860 EVO Series 1TB M.2 SATA und zwei mal 16 GB SO-DIMM DDR4 3200 von Crucial.

Reboot Probleme unter Linux

Mit der SATA SSD und dem RAM war der PC bereit zum booten. Als System wurde ein Ubuntu 22.04 LTS verwendet. Nach Installation wurde ein Reboot gefordert. Dabei schaltete sich der PC jedoch nicht vollständig ab und blieb im Status „Reached target Shutdown“ stehen. Der PC musste hart abgeschaltet werden. Auch der Neustart dauerte mehrere Minuten, was für Ubuntu sehr ungewöhnlich ist. Um auszuschließen dass das Problem spezifisch für Ubuntu ist, versuchte ich eine Installation mit Fedora. Das Ergebnis war auch hier das gleiche.

Die Lösung

Nach länger Suche fand ich einen Hinweis der spezifisch für die EHL Hardware Plattform war. Die Lösung ist die Deaktivierung eines Kernelmoduls für den Intel Elkhart Lake SoC Chipsatz. Dazu wird dieses in die Blacklist.conf eingetragen.

sudo vi /etc/modprobe.d/blacklist.conf

Folgende Zeile muss in die blacklist.conf eingefügt werden:

blacklist pinctrl_elkhartlake

Den Editor mit [ESC] [:] wq! (save und exit) verlassen.

update-initramfs –u

Der folgende Shutdown war noch verzögert, jedoch startete das Linux nach dem Neustart innerhalb weniger Sekunden.

Ich hoffe dieser Hinweis hilft meinen vExpert Kollegen. Sharing is caring. 🙂

ESXi Coredump Files verwalten

Zugegeben, das ist kein neues Thema, aber es kostete mich etwas Zeit in einem Kundenprojekt. Da dieser Blog auch als Swap-Partition meines Gehirns fungiert, habe ich es für die Zukunft niedergeschrieben. Wichtig ist die korrekte Abfolge der Schritte, damit die Änderung auch nach einem Bootvorgang erhalten bleibt.

Wofür wird ein Coredump-File benötigt?

Moderne ESXi Installationen ab Version 7 verwenden ein neues Partitions-Layout des Bootdevices. Darin werden auch Coredumps abgelegt. Jedoch nur wenn das Bootmedium kein USB-Flashmedium und keine SD-Card ist. In solchen Fällen wird der Coredump ausgelagert auf einen VMFS-Datenspeicher mit mindestens 32GB Kapazität.

Genau einen solchen Fall fand ich in einer Kundenumgebung vor. Das System wurde von vSphere 6.7 migriert und hatte daher noch das alte Boot-Layout auf einem (damals noch voll unterstützten) SD-Card RAID1. Wir fanden einen Ordner vmkdump mit Files für jeden Host auf einem der gemeinsamen VMFS-Datenspeicher. Dieser (VMFS5) Datenspeicher sollte aufgelöst und durch einen VMFS6 Datenspeicher ersetzt werden. (Randbemerkung des VCI: Es gibt keinen online Migrationspfad von VMFS5 nach VMFS6). 😉 Also mussten die vmkdump Files von dort weg.

Ablauf

Zunächst verschaffen wir uns eine Übersicht der Coredump-Files.

esxcli system coredump file list

Hier werden alle Coredump-Files aller ESXi-Hosts gelistet. Jede Zeile enthält neben dem Pfad auch die Stati Active und Configured (true oder false). Active bedeutet, dass dies das aktuelle Coredumpfile dieses Hosts ist. Wichtig ist, dass der Wert bei Configured ebenfalls den Status ‚true‘ hat. Ansonsten übersteht die Einstellung keinen Reboot. Nur das Coredump-File des aktuellen Hosts hat den Status ‚active‘. Alle anderen Files gehören zu anderen Hosts und sind daher active=false.

Im Standard wählt der Host den ersten passenden VMFS-Datenspeicher. Das ist nicht unbedingt der erwünschte.

Aktuelles Coredump-File entfernen

Zunächst löschen wir das aktive Coredump-File des Hosts. Wir müssen die Löschung erzwingen, da es als active=true gesetzt ist.

esxcli system coredump file remove --force

Führen wir das list Kommando von oben nochmals aus, so sollte eine Zeile weniger erscheinen.

Neues Coredump File erzeugen

Der folgende Befehl legt ein neues Coredump-File am Zielort an. Falls noch nicht vorhanden wird ein Ordner vmkdump erzeugt und darin das Dumpfile. Wir übergeben den gewünschten Filenamen ohne Endung, da diese (.dumpfile) automatisch erzeugt wird.

esxcli system coredump file add -d <Name | UUID> -f <filename>

Beispiel: Name des Hosts ist „ESX-01“ und der VMFS-Datenspeicher hat den Namen „Service“. Der Datenspeicher darf entweder als Anzeigename oder Datastore_UUID übergeben werden.

esxcli system coredump file add -d Service -f ESX-01

Auf dem benannten Datenspeicher wird nun ein Ordner vmkdump erzeugt und darin ein File namens ESX-01.dumpfile. Wir können dies prüfen über das list Kommando.

esxcli system coredump file list

Es erscheint eine neue Zeile mit dem vollen Pfad zum neuen Dumpfile. Der Status ist jedoch noch active=false und configured=false. Es ist sinnvoll diesen kompletten Pfad in die Zwischenablage zu kopieren, denn wir benötigen ihn im nächsten Schritt.

Dumpfile aktivieren

Wir setzen im folgenden Schritt das neu erzeugte Dumpfile aktiv. Somit bleibt die Einstellung auch nach einen Host-Reboot erhalten. Wir übergeben dabei den vollständigen Pfad zum Dumpfile. Hier eignet sich die Kopie aus der Zwischenablage und vermeidet Tippfehler.

esxcli system coredump file set -p <path_to_dumpfile>

Beispiel:

esxcli system coredump file set -p /vmfs/volumes/<UUID>/vmkdump/ESX-01.dumpfile

Ein abschließender List Befehl bestätigt das Ergebnis.

Links