Rancher V2.3 Upgrade [HowTo]
Letzte Woche kam die neue Rancher-Version heraus – nachzulesen hier. In Rancher V2.3 Upgrade HowTo stelle ich mein Vorgehen vor. Einen direkten Leitfaden konnte ich nicht finden, weshalb dieser Artikel seinen Weg in meinen Blog nun findet.
Aha, was bringt die V2.3?
Nun ja, so einiges. Das war ein Feature-Release, also nicht nur Fixes! Einige der neuen Features scheinen sehr spannend zu sein. Hier mal ein paar Schlagwörter: Windows GA (nur mit Flannel), Enterprise Templating, ISTIO. Hier der Link zu den Release Notes.
Ansonsten gab es ein Update der Kubernetes-Version auf 1.15.4 (stable). Das Menü hat sich unter den Projekten geändert. Die Workloads-Ansicht versteckt sich mittlerweile unterhalb von „Resources”. Die Reihenfolge der Projekt-Navigation hat sich auch signifikant geändert, der besagte Menü-Eintrag befindet sich mittlerweile an erster Stelle. Zusätzlich gibt es ein paar Menüpunkte mehr, unter anderem ISTIO.
In Rancher V2.3 Upgrade HowTo schauen wir uns nicht die neuen Features an. Ich möchte hier das Upgrade-Prozedere vorstellen.
Rancher V2.3 Upgrade… Wo? Wie?
Wer die Kubernetes einfach mit Rancher Serie verfolgt hat, sollte wissen, um welche Umgebung es geht. Für alle anderen sei dieser Artikel nochmal ans Herz gelegt. In diesem besagten Artikel beschreibe ich meine Umgebung, die Umgebung, die in diesem Artikel aktualisiert wird.
Vor der Aktualisierung befand sich Rancher in der Version 2.2.8 und der Cluster lief mit 1.14.x.
Sofern Docker noch auf den Nodes aktualisiert werden muss, der kann sich an diese Vorgehensweise halten.
Rancher V2.3 Upgrade: Master
Das Aktualisieren von Rancher an sich ist nicht schwer und hat bei mir keine 3 Minuten gedauert. Während des Upgrades – das Docker-Image wird aktualisiert – ist die Rancher UI nicht erreichbar.
Um weiter fortzufahren, müssen wir zuerst ein paar Informationen einsammeln. An diese Informationen kommt man ganz einfach per docker ps:
aytac@master:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
<containerid> rancher/rancher:<image_tag> "entrypoint.sh --acm…" 6 weeks ago Up 5 weeks 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp <container_name>
Wichtig sind die <image_tag> und <container_name> Informationen, bei mir waren diese z.B. latest und silly_sinoussi.
Docker Container stoppen
Nachdem wir die nötigen Informationen gesammelt haben, können wir jetzt fortfahren. Zuerst müssen wir den laufenden Rancher-Container stoppen. Das machen wir über den docker stop-Befehl mit Übergabe von dem Container-Namen.
docker stop <container_name>
Für mein Beispiel sieht das wie folgt aus:
docker stop silly_sinoussi
Dieser Befehl stoppt die aktuelle Instanz. Danach können wir eine Sicherung anlegen – dieser Schritt ist optional, sei aber jedem ans Herz gelegt, denn wir verwenden unter anderem das erstellte Volume im übernächsten Schritt.
Aktuelle Umgebung sichern
In diesem Schritt sichern wir das „Volume” unserer aktuellen Umgebung. Für den Fall, dass irgendetwas schief läuft, können wir somit die Daten wiederherstellen.
Zuerst erstellen wir ein Volume, welches wir dann „tarballen” und „gzippen” werden, und das alles mit Docker:
docker create --volumes-from <container_name> --name rancher-data rancher/rancher:<image_tag>
Bei mir sah dieser Befehl wie folgt aus:
docker create --volumes-from silly_sinoussi --name rancher-data rancher/rancher:latest
Mit dieser Anweisung erstellen wir ein neues Volume mit dem Namen „rancher-data”, basierend auf dem aktuellen Container und dessen Image. Nachdem die Create-Anweisung durchgelaufen ist, erstellen wir nun die Backup-Datei:
docker run --volumes-from rancher-data -v $PWD:/backup busybox tar zcvf /backup/rancher-data-backup-<rancher-version>-<Datum>.tar.gz /var/lib/rancher
Also, wenn ich diesen Befehl heute abfeuern würde – immer mit der Prämisse, dass die Rancher-Version 2.2.8 ist – würde dieser wie folgt aussehen:
docker run --volumes-from rancher-data -v $PWD:/backup busybox tar zcvf /backup/rancher-data-backup-228-20191015.tar.gz /var/lib/rancher
Mit diesem Befehl erstellen wir nun – in dem Pfad, wo der Befehl abgesetzt wird – ein gzip-Paket mit dem Inhalt aus /var/lib/rancher. Anschließend wird dieses Paket in den Backup-Ordner kopiert.
Neues Image ziehen und Rancher starten
Das Upgrade wird nun mit dem Aktualisieren des Images vollendet. Mit einem docker pull-Befehl können wir das neue Image ziehen:
docker pull rancher/rancher:<image_tag>
Ich verwende kein spezielles Image, für meinen Fall sieht der Befehl wie folgt aus:
docker pull rancher/rancher:latest
Nachdem wir das aktuelle Image gezogen haben, können wir nun unsere Rancher-Umgebung wieder starten. Hierfür gibt es verschiedene Möglichkeiten. Ich verwende Let’s Encrypt als Zertifikat-Aussteller, weshalb ich folgenden Befehl absetze:
docker run -d --volumes-from rancher-data \
--restart=unless-stopped \
-p 80:80 -p 443:443 \
rancher/rancher:<image_tag> \
--acme-domain <domain>
Für meinen Fall würde der Befehl wie folgt aussehen:
docker run -d --volumes-from rancher-data \
--restart=unless-stopped \
-p 80:80 -p 443:443 \
rancher/rancher:latest \
--acme-domain master.ak8s.de
Wir starten mit dem neuen (gezogenen) Image einen Container und binden unser im „Backup”-Schritt erzeugtes Volume ein. Zusätzlich gewährleisten wir über den Parameter --acme-domain die automatisierte Zertifikatsanfrage und Erstellung bei Let’s Encrypt.
So, damit wäre der eine Part erledigt. Unsere Rancher-Installation sollte nun die 2.3 als Version anzeigen (links unten im Browser).
Rancher hat dazu natürlich auch eine Anleitung, in der unter anderem das Wiederherstellen von dem Backup und ein paar andere Themen behandelt werden. Diese Anleitung kann über diesen Link aufgerufen werden.
Rancher V2.3 Upgrade: Cluster-Nodes
Dieser Schritt ist relativ einfach und kann über die Rancher-Oberfläche ausgeführt werden. Dafür gehen wir in die Edit-Ansicht von unserem Cluster: Global → Cluster → 3 böbl → Edit.
Unter Kubernetes Options wählen wir nun die Kubernetes-Version aus. In diesem Fall ist das die 1.15.4.
Nun bestätigen wir unsere Änderungen mit dem Save-Button. Anschließend startet der Upgrade-Prozess von den Worker-Nodes. Den Status können wir in der Cluster-Detail-Ansicht beobachten.
Nach einem erfolgreichen Upgrade sollten die Worker-Nodes die neue Kubernetes-Version in der Nodes-Ansicht anzeigen.
Fazit
Der Upgrade-Prozess dauert ungefähr eine halbe Stunde. Ob jemandem diese halbe Stunde wert ist, muss jeder selbst für sich entscheiden. Ich für meinen Teil – als alter Infrastrukturler – fühle mich unwohl, wenn ich Updates nicht installiere.
Signifikante Änderungen konnte ich nach dem Update nicht feststellen. Was mir sofort auffiel, ist die geänderte Navigation. Neue Features wie Enterprise Templates oder die Unterstützung für Windows Container kann ich aktuell nicht testen. Evtl. schaue ich mir die vereinfachte ISTIO-Inbetriebnahme an, jedoch habe ich aktuell keinen Bedarf an einem Micro-Service-Mesh, da ich mit OpenFaaS experimentiere. Und wenn doch mal die Not an einer Service-Mesh-Umgebung da sein sollte, würde ich eher zu Rancher RIO tendieren.