OpenShift Pods mittels Java starten

Um in der OpenShift dynamisch neue Kubernetes Objekte zu erzeugen, kann der Java Client für Kubernetes und OpenShift 3 von fabric8.io verwendet werden. Dieser Client nutzt die REST API der Kubernetes/OpenShift Plattform, um verschiedene Aktionen auszuführen.

Wir verwenden den Kubernetes Client beispielsweise, um in der OpenShift neue Pods zu starten und nach der Berechnung diese wieder zu beenden. Wir haben uns ganz bewusst für den Kubernetes und nicht für den OpenShift Client entschieden. So sind wir plattformunabhängig und können auf andere Kubernetes Plattformen wechseln, ohne unsere Implementierung ändern zu müssen (Open-Closed Prinzip).

Beispiel

Zu Beginn erstellen wir einen Kubernetes Client. Dafür wird die Kubernetes URL der Plattform benötigt:

Mit dem Client starten wir jetzt einen neuen Pod:

Damit auf den soeben erstellten Pod zugegriffen werden kann, legen wir jetzt noch ein Service an:

Wenn der Pod nicht mehr benötigt wird, wird zuerst der Service wieder gelöscht:

Und danach den Pod:

Fazit

Der Client ist sehr mächtig. Er bietet die Möglichkeit eine Kubernetes Plattform dynamisch mittels Java zu orchestrieren. Wenn man sich mit Kubernetes auskennt, wird man keine Probleme bei der Anwendung des Java Clients haben.

Versucht es doch einfach selber.

Openshift: Service Discovery

In meinem vorherigen Blogpost https://blog.doubleslash.de/neue-anwendungen-openshift-origin-erstellen/ habe ich eine kleine Beispielanwendung mit zwei Pods (Wildfly/MySQL) erstellt.

Das Wildfly Image unterstützt von Haus aus sogenannte ServiceDiscovery. Aber was ist das und wozu brauche ich das?

ServiceDiscovery beschreib bei Openshift eine Möglichkeit Services automatisch zu finden.

In Openshift werden IP Adressen dynamisch vergeben. Das bedeutet, dass ein Pod, der einmal verfügbar war einen Endpunkt im IP Bereich 10.168.* bekommt. Beim nächsten Start oder bei Skalierung wird ein neuer Endpunkt generiert und dem Container zugewiesen.

Somit kann ein Zusammenspiel von Containern nicht zuverlässig funktionieren. Ausserdem würde das Loadbalancing zum Container keinen Effekt haben, wenn es lediglich möglich ist einen Pod als Ziel zu konfigurieren.

Openshift stellt hier sogenannte Services als Bindeglied zwischen Routing und Container bereit. Ein Service bekommt wie ein Container eine IP. Diese ist jedoch in einem anderen Bereich (per Default 172.30.*). Der Vorteil der Service IP ist, dass diese einmal für die Laufzeit des Services vergeben wird. Über die eine Service IP wird auch das Loadbalanceing zum eigentlichen Pod durchgeführt.

Mehr