Nachdem nun endlich unsere Rancher-Installation läuft, gehts heute endlich mal an die Einrichtung eines Kubernetes-Clusters. Dazu loggen wir uns in Rancher ein und gehen auf „Global“ und wählen „Add Cluster“ aus. Wir wollen heute noch keinen Cluster in der Cloud anlegen. Das machen wir später einmal. Heute erstellen wir einen „Custom“ Cluster auf unseren Nodes.

Man wählt zunächst einen Namen, wie zum Beispiel „k8s“. Im unteren Bereich hat man die Möglichkeit, noch diverse Einstellungen, wie z.B. die Kubernetes-Version festzulegen. Ich belasse es zunächst bei der Standardvorgabe. Allerdings möchte ich, dass die Kubernetes-Komponenten über das wireguard-Interface miteinander reden, das wir bereits eingerichtet haben. Einen Einstieg dazu gibt es hier.

Wir gehen auf „Edit as YAML“ und passen den Teil „network“ an:

  network:
    mtu: 0
    options:
      canal_iface: wg0
      flannel_backend_type: vxlan
    plugin: canal

Entscheidend ist der Eintrag „canal_iface“. In der Rancher-Dokumentation gibt’s noch mehr Details. Wir klicken auf Next und schon existiert unser Cluster. Dieser braucht natürlich noch Nodes. Hier nochmal der Plan:

Name	Cores	RAM	IP	Zweck
defiant	4	8 GB	10.0.0.1	Rancher-Installation
discovery	6	16 GB	10.0.0.2	Master, Worker
reliant	8	30 GB	10.0.0.3	Worker
yorktown	6	16 GB	10.0.0.4	Worker

Wir erstellen nun als erstes den Master Node. Ich selektiere hier alle Rollen und trage in den Advanced Options die zu nutzenden IPs ein. Bei der public-IP gibt man die „ganz normale“ öffentliche IP des Servers an. Bei der internen IP geben wir die Wireguard IP-Adresse an. Als Beispiel für „discovery“:

Das erzeugte Kommando kopieren wir uns, und führen es auf dem Server „discovery“ aus. Ich klicke dann auf Done und warte, bis der Cluster „Ready“ ist. Man kann vermutlich auch alle 3 Nodes in einem Rutsch hinzufügen, ich habe das aber immer nacheinander gemacht. Den zweiten Node fügen wir hinzu, in dem wir auf „Edit“ klicken und dann im unteren Bereich genau so den nächsten Node hinzufügen. Wir wählen dabei aber immer nur die Role „Worker“ aus. Wie gesagt, dieses Setup hat nicht den Anspruch einer Produktionsumgebung mit hoher Verfügbarkeit. Im echten Leben würde man sicherlich auf den Mastern keine Workload haben wollen und natürlich mehrere Master installieren.

Wenn alle 3 Nodes hinzugefügt sind, sollte die Übersicht unter „Nodes“ so ähnlich aussehen:

Perfekt, der Cluster läuft!

Wenn man lokal mit kubectl auf den Cluster zugreifen möchte, holt man sich noch die Kubeconfig unter „Cluster“ und speichert den Inhalt lokal in der Datei ˜/.kube/config. Natürlich muss man sich lokal vorher noch den kubectl-client installieren. Auf dem Mac geht das wunderbar mit Homebrew:

brew install kubectl

Danach kann man mit kubectl schon mit seinem Cluster arbeiten und die erste Workload deployen oder sich z.B. die nodes anzeigen lassen:

~ » kubectl get nodes                                                                                                                
NAME        STATUS   ROLES                      AGE   VERSION
discovery   Ready    controlplane,etcd,worker   23d   v1.17.4
reliant     Ready    worker                     23d   v1.17.4
yorktown    Ready    worker                     23d   v1.17.4

Beim nächsten Mal deployen wir die erste Applikation auf dem Cluster.