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 einpaar Schlagwörter…
Windows GA (nur mit Flannel), Enterprise Templating, ISTIO. Hier der Link zu den Release Notes.
Ansonsten gab es eine 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 „Ressources“. 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 einpaar 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?
Also, 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 einpaar Informationen einsammeln. An diese Informationen kommt 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 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 zuerst einmal 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 jeden ans Herz gelegt, denn wir verwenden unter anderem das erstellte Volume in dem ü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 erzeugte 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 Ranger 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 einpaar andere Themen – das starten des docker Container z.B. – 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 anziegen.
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 die Windows Container kann ich aktuell nicht testen. Evtl. schaue ich mir die vereinfachte ISTIO Inbetriebnahme an, jedoch habe ich aktuell habe ich 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.