Setup mit OpenShift und Kubernetes

Betrachten wird nun ein einfaches Setup auf der Basis von OpenShift. Das PaaS-Framework verwendet das Kubernetes-Framework für das Container-Management. Hierfür finden sich im Trireme-GitHub-Repository [5] ein paar sehr schöne Beispiele, die das Konzept gut erklären und sich für den Einstieg eignen. Das Setup von OpenShift ist nicht Teil des Artikels. Wir verweisen an dieser Stelle auf die Open-Shift-Webseite [6], auf der Sie eine Vielzahl von unterschiedlichen Dokumenten vorfinden. Grundsätzlich lassen sich die in diesem Artikel aufgeführten Beispiele aber auch auf vielen anderen Plattformen nachvollziehen. Die Dokumentation [7] zu Trireme enthält hierfür nützliche Hinweise. Als ersten Schritt klonen wir das Trireme-Kubernetes-git-Repository mit

# git clone https://github.com/aporeto-inc/trireme-kubernetes.git

Dann sollten Sie natürlich testen, ob der Zugriff auf den zuvor erzeugten Kubernetes-Cluster problemfrei funktioniert. Dies ist auch eine gute Gelegenheit, die Versionen der eingesetzten Software-Komponenten zu überprüfen. Wir verwenden für die Beispiele in diesem Artikel ein nicht mehr ganz aktuelles Kubernetes, was allerdings zu keinen größeren Schwierigkeiten geführt hat:

# oc version

oc v3.1.1.6-64-g80b61da

kubernetes v1.1.0-origin-1107-g4c8e6f4

Im nächsten Schritt erfolgt der Open-Shift-Login als System-Benutzer. Wir nutzen für dieses Beispiel einen neuen Open-Shift-Cluster, den wir mittels »oc cluster up« eingerichtet haben. Als Umgebung innerhalb von OpenShift kommt für dieses Beispiel das bereits vorhandene "default"-Projekt zum Einsatz:

# oc login 10.1.2.2:8443

# oc project default

Damit der Pod, in dem später die Trireme-Software läuft, auch über die notwendigen Rechte verfügt, müssen wir den Service-Account, den wir für dieses Projekt nutzen, dem sogenannten "privileged security context constraint" (SCC) hinzufügen. Der Account, der hier im Abschnitt "users" hinzugefügt wird, lautet "system:serviceaccount:default:default":

# oc edit scc privileged

[...]

users:

- system:serviceaccount:openshift-infra:build-controller

- system:serviceaccount:default:router

- system:serviceaccount:default:default

Im Anschluss sollte der folgende Befehl bestätigen, dass alles geklappt hat:

# oc describe scc privileged|grep

    Users

    Users:

    system:serviceaccount:openshift-infra:build-controller,system:serviceaccount:default:router, system:serviceaccount: default:default

Dem Service-Account müssen wir nun das Recht zuweisen, den OpenShift-Cluster administrieren zu dürfen. Auch hierfür greifen wir wieder auf das OpenShift-Kommandozeilen-Tool "oc" zurück:

# oc adm policy add-cluster-role-to-user cluster-admin system:serviceaccount:default:default

Vergewissern Sie sich an dieser Stelle, dass der Service-Account nun tatsächlich über die Rolle "cluster-admin" verfügt:

# oc describe clusterPolicyBindings :default|grep -A1 cluster-admins RoleBinding[cluster-admins]:

    Role: cluster-admin

    Groups: system:cluster-admins

    ServiceAccounts: default/default

Damit sind die vorbereitenden Maßnahmen für unser OpenShift-Projekt abgeschlossen. Als Nächstes gilt es, den Trireme-Container zu konfigurieren und auf die Cluster-Nodes zu verteilen.

Schlüsselverteilung mit Trireme Pod

Das bereits erwähnte Github-Repository Trireme-Kubernetes [5] stellt hierfür einige Konfigurationsdateien zur Verfügung. Diese passen Sie an die lokale Umgebung an. In diesem Beispiel kommt der Einfachheit halber ein preshared Key zur Signierung der Attribut-Sets der Pods zum Einsatz. Dieser ist in der Datei "daemonSetPSK.yaml" zu hinterlegen. Hier ist auch der IP-Adressraum zu definieren, der in der lokalen Umgebung für die Pods zum Einsatz kommt:

# cd trireme-kubernetes/deployment/Trireme/KubeDaemonSet

# grep -A1 TRIREME_NETS daemonSetPSK.yaml

- name: TRIREME_NETS

value: 172.17.0.0/16

Alle anderen Werte aus dieser Beispieldatei können so übernommen werden. Im Anschluss richten wir das Secrets-Objekt ein. Auch hierfür stellt das Github-Repository ein Skript zur Verfügung:

# sh createPSK.sh

# oc get secrets
NAME           TYPE                DATA           AGE
[…]
trireme          Opaque              1                 10s

Das kleine Shell-Skript macht dabei eigentlich nichts anderes, als das Tool "kubectl" aufzurufen, um das zuvor in der YAML-Datei definierte Secret an die Kubernetes-API zu übergeben. In älteren Kubernetes-Installationen klappt dies jedoch nicht fehlerfrei. Hier bietet es sich an, zuerst ein Secret-Objekt als YAML-Datei zu definieren um diese dann mittels »kubectl create -f mysecret.yaml« an Kubernetes zu senden. Hier ist ein Beispiel für eine solche YAML-Datei:

apiVersion: v1

data:

    triremepsk:

    dmVtaFBCV045NXorMXc0WW9ZY21IZz09

kind: Secret

metadata:

    name: trireme

    namespace: default

type: Opaque

Mit dem Befehl in Listing 1 lässt sich dann verifizieren, ob alles geklappt hat und Kubernetes das soeben eingerichtete Secret kennt.

Bild 2: Trireme stellt eine Art Enforcement-Modul für die Kubernetes Network Policy dar.

Nutzen Sie einen reinen Kubernetes-Cluster ohne OpenShift, erzeugen Sie die entsprechenden Kubernetes-Objekte natürlich auch einfach mittels »kubectl« und müssen hierfür nicht zwingend auf das OpenShift-Tool "oc" zurückgreifen. Schließlich müssen Sie sicherstellen, dass der Pod, in dem die Trireme-Anwendung läuft, auf allen Knoten zur Verfügung steht. In der Kubernetes-Welt erledigen Sie das am einfachsten mit Hilfe eines DaemonSets. Auch hierfür existiert bereits eine YAML-Datei, mit der Sie ein solches DaemonSet-Objekt erzeugen:

# oc create -f daemonSetPSK.yaml

daemonset "trireme" created

Wie gewohnt zeigt »oc get daemonset« an, ob das Objekt erfolgreich angelegt wurde. Im Anschluss sollte zumindest ein einzelner Trireme-Pod zur Verfügung stehen. Wir verwenden für dieses Beispiel lediglich ein Single-Node-OpenShift-System (siehe Listing 2).

# oc get pods
NAME                                  READY           STATUS           RESTARTS           AGE
docker-registry-2-twwzp      1/1                  Running            0                           22h
router-1-ujbxp                     2/2                  Running            0                           22h
trireme-rw4g3                      1/1                  Running            0                           3h