Seite 4: Deployment der Beispielanwendung

Die Beispielanwendung ist im GitHub-Repository des Autors namens „Hybrid Cloud Burst“ verfügbar. Der Aufbau lässt sich dem Übersichtsbild entnehmen (s. Abb. 4). Im Cluster der privaten Cloud befindet sich ein File Repository für die Ablage von trainierten Modellen. Über den zugehörigen Service ist es aus beiden Clustern erreichbar.

Mit den folgenden drei Befehlen legt man zuerst einen Namespace an, in dem Istio und der Scheduler aktiviert sind. Anschließend gilt es, das Deployment und den Service für das File-Repository anzulegen. Da es sich jeweils um Kubernetes-Federation-Ressourcen handelt, lassen sie sich automatisch auf beide Cluster anwenden.

$ kubectl –context ${PRIVATE_CLUSTER_CTX} apply -f k8s/namespace.yaml
$ kubectl –context ${PRIVATE_CLUSTER_CTX} apply -f k8s/blob-storage.yaml
$ kubectl –context ${PRIVATE_CLUSTER_CTX} apply -f k8s/blob-storage-service.yaml

Listing 4: Deployment für den privaten und den öffentlichen Cluster

Anschließend sollte der private Cluster folgendermaßen aussehen:

$ kubectl --context ${PRIVATE_CLUSTER_CTX} get all
NAME                               READY   STATUS    RESTARTS   AGE
pod/blob-storage-d4556c66f-z79f2   2/2     Running   0          2d5h

NAME                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
service/blob-storage   ClusterIP   10.0.225.183   <none>        10000/TCP   3d6h
service/kubernetes     ClusterIP   10.0.0.1       <none>        443/TCP     5d23h

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/blob-storage   1/1     1            1           3d5h

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/blob-storage-d4556c66f   1         1         1       3d5h

Listing 5: Privater Cluster nach dem initialen Deployment

Der öffentliche Cluster sollte dann entsprechend aussehen wie in Listing 6:

$ kubectl --context ${REMOTE_CLUSTER_CTX} get all 
NAME                   TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)     AGE
service/blob-storage   ClusterIP   10.0.42.74   <none>        10000/TCP   3d6h
service/kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP     7d6h

Listing 6: Öffentlicher Cluster nach dem initialen Deployment

Nun ist es möglich, einen Job anzulegen, den der Multicluster-Scheduler automatisch einem freien Cluster zuweist. In diesem Fall ist der Pod (ml-job-6ymu-xvrv2-p5bbl) dem Cluster in der Public Cloud zugewiesen. Bei dem Pod im privaten Cluster handelt es sich lediglich um den Proxy-Pod, wie Listing 7 veranschaulicht:

$ ./k8s/new-job.sh
job.batch/ml-job-6ymu created

$ kubectl --context ${PRIVATE_CLUSTER_CTX} get pods
NAME                           READY   STATUS      RESTARTS   AGE
blob-storage-d4556c66f-z79f2   2/2     Running     0          2d5h
ml-job-6ymu-xvrv2              2/2     Running   0          20

$ kubectl --context ${REMOTE_CLUSTER_CTX} get pods
NAME                      READY   STATUS    RESTARTS   AGE
ml-job-6ymu-xvrv2-p5bbl   2/2     Running   0          27s

Listing 7: Scheduling eines ML-Jobs im öffentlichen Cluster

Beim Erstellen weiterer Jobs sieht man, dass beide Cluster nach und nach stärker ausgelastet sind. Ab einem gewissen Punkt greift in der Public Cloud das Autoskalieren, dem betroffenen Cluster werden neue Nodes und damit Ressourcen hinzugefügt. Sobald die Trainingsjobs abgeschlossen sind, sinkt die Last erneut. Mit einer gewissen Verzögerung sollte dann auch die Anzahl der Nodes in der Public Cloud wieder zum Ausgangswert skalieren. Über die Mechanismen Node Selector und Node Affinity lässt sich das Verhalten des Schedulers beeinflussen, um zum Beispiel den privaten Cluster für die Ausführung eines Pods zu bevorzugen.

Fazit

Mit den entsprechenden Kubernetes-Erweiterungen lässt sich vergleichsweise einfach eine hybride Cloud mit Unterstützung für Cloud Bursting aufsetzen. Ein elementarer Baustein dafür ist die Cross-Cluster-Kommunikation, das konkrete Beispiel hat sie mit Istio umgesetzt. Die zweite wichtige Komponente ist der Multicluster-Scheduler, der dafür sorgt, dass sich die Ressourcen der hybriden Cloud zu einem gemeinsamen Pool zusammenfassen lassen. Auch wenn es nicht zwingend notwendig ist, erleichtert die Verwendung von Kubernetes Cluster Federation die Verwaltung mehrerer Cluster und ist damit besonders für größere Projekte von Nutzen.

Cloud Bursting kann dabei helfen, die Cloud bei Lastschwankungen besser zu nutzen. Durch die weite Verbreitung von Kubernetes gibt es eine große Auswahl an Cloud-Anbietern, die dafür in Frage kommen. Entwickler können auf ein wachsendes Ökosystem an Erweiterungen zurückgreifen. Weitere Projekte, die sich ebenfalls mit dem Thema Multicloud und hybride Cloud beschäftigen, sind zum Beispiel Cillium, Submariner und Google Anthos.

Young Professionals schreiben für Young Professionals

Simon Mennig

hat Wirtschaftsinformatik (B.Sc.) und Informatik mit Schwerpunkt Software Engineering (M.Sc.) studiert.
Er arbeitet als Softwareentwickler bei doubleSlash und hat umfassendes Know-how in den Bereichen IoT, Cloud Computing und Java.

Das Thema „Cloud Bursting“ war ein Teil seiner Masterarbeit bei doubleSlash.

(sih)