K3s unter Rocky Linux 8 mit k3sup

Letztes Jahr hatte ich im Blog-Eintrag CodeReady Containers for OKD unter Windows 10 ein kleines lokales Setup vorgestellt. Für Entwicklung und Test von Kubernetes Operatoren benötigt man aber auch schnell eine Umgebung aus mehreren Nodes. Mit dem Tool k3sup und der Kubernetes Distribution K3s lässt sich eine derartige Umgebung unter Rocky Linux 8 mit wenigen Befehlen aufsetzen.

Der Kubernetes Cluster besteht hierbei aus drei Rocky Linux 8 VMs (je 2 CPUs / 4 GB RAM / 20 GB Disk). Kubectl und k3sup nutze ich direkt auf meiner Entwickler-Workstation unter WSL2.

Im ersten Schritt wird k3sup lokal installiert:

curl -sLSo get_k3sup.sh https://get.k3sup.dev
bash get_k3sup.sh
sudo install k3sup /usr/local/bin/
which k3sup

Entgegen der k3s-Installationsanleitung habe ich auf den VMs die Firewall nicht deaktiviert. Stattdessen habe ich folgende Firewall-Rules eingerichtet.

Auf dem Server-Node (rock8-t05):

sudo firewall-cmd --permanent --add-port=6443/tcp
sudo firewall-cmd --permanent --add-port=10250/tcp
sudo firewall-cmd --permanent --add-port=8472/udp
sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 # pods
sudo firewall-cmd --permanent --zone=trusted --add-source=10.43.0.0/16 # services
sudo firewall-cmd --reload

Auf den Agent-Nodes (rock8-t06 und rock8-t07):

sudo firewall-cmd --permanent --add-port=10250/tcp
sudo firewall-cmd --permanent --add-port=8472/udp
sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 # pods
sudo firewall-cmd --permanent --zone=trusted --add-source=10.43.0.0/16 # services
sudo firewall-cmd --reload

Nachdem die Firewalls auf den einzelnen Nodes nun vorbereitet sind, können wir via k3sup den Server-Node (rock8-t05) aufbauen:

k3sup install --user ansible --host rock8-t05

Sobald der Server-Node steht, können die beiden Agent-Nodes eingerichtet werden:

k3sup join --user ansible --server-host rock8-t05 --host rock8-t06
k3sup join --user ansible --server-host rock8-t05 --host rock8-t07

Damit sollte der Kubernetes Cluster schon einsatzbereit sein. Dies lässt sich z.B. mit folgenden Befehlen prüfen:

$ export KUBECONFIG=~/kubeconfig
$ kubectl config set-context default
Context "default" modified.
$ kubectl cluster-info
Kubernetes control plane is running at https://rock8-t05:6443
CoreDNS is running at https://rock8-t05:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://rock8-t05:6443/api/v1/namespaces/kube-system/services/https:metrics-server:https/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
$ kubectl get node
NAME        STATUS   ROLES                  AGE     VERSION
rock8-t06   Ready    <none>                 4m22s   v1.23.6+k3s1
rock8-t07   Ready    <none>                 106s    v1.23.6+k3s1
rock8-t05   Ready    control-plane,master   8m39s   v1.23.6+k3s1

CodeReady Containers for OKD unter Windows 10

Die Firma RedHat bietet mit Openshift eine sehr umfassende Kubernetes Distribution. Bei OKD handelt es sich um das entsprechende Open Source Upstream-Projekt. Für Entwickler-Teams oder den Einsatz in der Produktion wird Openshift normalerweise in einem Cluster aus mehreren Server-Knoten oder VMs installiert. Für die Entwicklung von Images, Templates, Kubernetes-Operatoren oder um sich mit Openshift vertraut zu machen, ist eine kleine lokale Mini-Installation von Vorteil. Früher gab es hierfür z.B. minishift oder minikube. Für Openshift 4 wurde diese Form von Umgebung in "CodeReady Containers" (CRC) umbenannt.

Die Installationsanleitung für Linux, Mac OS und Windows befindet sich hier: Getting Started Guide und der OKD-Download der CRC-Umgebung hier: Download CodeReady Containers for OKD.

Zusätzlich zur Installationsanleitung sollten unter Windows 10 folgende Punkte beachtet werden:

  • Das Windows 10 System sollte mindestens 16 GB RAM haben, besser 32 GB. Bei 16 GB RAM müssen evtl. Anwendungen und Dienste vor dem Start der CRC-Umgebung gestoppt werden.
  • Der Installationsbenutzer muss zu einem lokalen Administrator werden können und zusätzlich Mitglied der Gruppe "Hyper-V-Administratoren" sein.

Installation und Start sind nach dem Download, in einer klassichen Windows Eingabeaufforderung, wie folgt möglich:

crc setup
crc start -n 8.8.8.8

Bei Fehlern kann der Debug-Output über die Zusatzoption "--log-level debug" aktiviert werden.

Für erste Tests der Umgebung kann z.B. mein Demojee auf Github genutzt werden:
https://github.com/FrankBergerITServices/openshift-jee-sample

IPv6 Konfiguration bei OVH VPS Instanzen

Manchmal ist er schwer für einfache Dinge eine saubere technische Lösung zu finden. Gutes Beispiel ist die IPv6 Konfiguration für eine VPS Instanz bei der Firma OVH. Nach meiner Erfahrung ist die Netzwerkkonfiguration, gerade bei Cloud-Angeboten, je nach Hosting Anbieter etwas komplizierter. Das Angebot von OVH basiert aber auf OpenStack und die Basis-Konfiguration innerhalb der VM erfolgt via cloud-init. D.h. egal ob Amazon AWS, Microsoft Azure oder eben OVH, unter Linux kommt immer cloud-init zum Einsatz. Aber im Fall von VPS-Instanzen bei OVH werden wohl zumindest für IPv6 keine Metadaten bereitgestellt.

Dies lässt sich auf der Kommandozeile über entsprechende HTTP-Requests testen:

[root@vps593928 ~]# curl http://169.254.169.254/2009-04-04/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
local-hostname
local-ipv4
placement/
public-hostname
public-ipv4
public-keys/
reservation-id

Via DHCP ist es offenbar ebenfalls nicht möglich die IPv6-Einstellungen dynamisch zu beziehen. Bei IPv4 funktioniert dies, bei IPv6 aber wohl nicht. Nun könnte man die Netzwerk-Konfiguration via cloud-init abschalten und die entsprechenden Konfigurationsdateien manuell pflegen. Ich wollte aber möglichst nah an der Standard-Installation bleiben, deshalb liefere ich die fehlenden IPv6-Daten in der cloud-init Konfiguration nach.

Beim Hostnamen hatte ich ähnliche Schwierigkeiten. Die Web-GUI von OVH erlaubt zwar den Namen der VPS Instanz zu ändern, die cloud-init zur Verfügung gestellten Metadaten enthalten aber immer noch den ursprünglichen Instanz-Namen von OVH. Für den Hostnamen habe ich noch keine saubere Lösung gefunden. Hier hilft nur den Hostnamen einmalig auf den gewünschten Wert zu setzen und danach die dynamische Änderung des Hostname in cloud-init zu deaktivieren.

[root@vps593928 ~]# hostnamectl set-hostname s20.e1.fm-berger.de

Die cloud-init Konfiguration für IPv6 und Hostname erfolgt dann über neue Datei /etc/cloud/cloud.cfg.d/99-custom-networking.cfg mit folgendem Inhalt:

network:
  version: 1
  config:
  - type: physical
    name: eth0
    mac_address: fa:16:3e:07:47:dd
    subnets:
      - type: dhcp
      - type: static
        address: 2001:41d0:701:1100::ab3/128
        gateway: 2001:41d0:701:1100::1

preserve_hostname: true

Nach einem Reboot der VPS Instanz sollte die IPv6-Konfiguration richtig gesetzt sein und der Hostname dürfte nicht mehr ändern.

Mit Virtualbox auf einer Zeitreise in die Zukunft

Um ein paar technische Details für das Backup-Konzept eines Kunden klären zu können, war es heute sehr hilfreich, eine VM in Virtualbox mit der Zeit in die Zukunft zu versetzen. Dazu waren folgende Schritte notwendig.

Zeitsynchronisation zwischen Host und virtueller Maschine deaktivieren:

"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" setextradata "rhel701" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1

Als nächstes muss der Zeitoffset zwischen gewünschter Zeit in der Zukunft und jetzt in Millisekunden via Powershell berechnet werden:

PS C:\Users\frank> ([datetime]"06/26/2017" - [datetime]::Now)


Days              : 11
Hours             : 6
Minutes           : 6
Seconds           : 6
Milliseconds      : 746
Ticks             : 9723667466261
TotalDays         : 11,2542447526169
TotalHours        : 270,101874062806
TotalMinutes      : 16206,1124437683
TotalSeconds      : 972366,7466261
TotalMilliseconds : 972366746,6261

Dieser Zeitoffset wird dann für die VM gesetzt:

"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" modifyvm "rhel701" --biossystemtimeoffset 972366746

In die Gegenwart zurück geht es via:

"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" setextradata "rhel701" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 0
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" modifyvm "rhel701" --biossystemtimeoffset 0

RHEL / OEL 6 DVD als yum-Repository verwenden

Welcher Linux Administrator kennt das Problem nicht, nach der Installation von Linux sollen einzelne RPM-Pakete nachinstalliert werden. Aufgrund der vielen Abhängigkeiten zwischen den Paketen ist der direkte Einsatz des Tools rpm oft mühsam. Hier hat sich der yum-Einzeiler "yum install PACKAGENAME" bewährt.

In so mancher Firmenumgebung steht aber leider nicht direkt ein YUM-Repository zur Verfügung und die Server haben meist keinen Internetzugang. YUM kann die Installations-DVD mit ein wenig Nachhilfe auch direkt als Repository verwenden. Hier am Beispiel für Oracle Enterprise Linux 6 dargestellt (die DVD wurde unter /mnt gemountet):

[root@centos6 ~]# cd /mnt
[root@centos6 mnt]# cp media.repo /etc/yum.repos.d/
[root@centos6 mnt]# vi /etc/yum.repos.d/media.repo

In der Datei muss noch ein entsprechender Eintrag für den Parameter baseurl aufgenommen werden. In diesem Fall also:

baseurl=file:///mnt