Deployment von Kubernetes mit Bosh

[et_pb_section bb_built=”1″ next_background_color=”#f1f1f1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.0.105″ background_layout=”light”]

Ein momentan besonders intensiv und kontrovers diskutiertes Thema ist das neue Deployment von Kubernetes, das das Verwalten und Konfigurieren von Kubernetes und Bosh langfristig vereinfachen soll. Heute möchten wir es nicht verpassen, Euch unsere Meinung zum PKS näherzubringen – natürlich nicht, ohne einige (wichtige) offene Fragen für uns und sicherlich auch für den ein oder anderen User aufzuwerfen.

[/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row _builder_version=”3.0.105″ use_custom_gutter=”on”][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.0.105″ background_layout=”light”]

Hintergrund:

• Um von Seitens Pivotal auch die Möglichkeit herzustellen, native Docker Container zu deployen, hat Pivotal den Continer-Dienst PKS aufgesetzt: https://pivotal.io/platform/pivotal-container-service

Einen Aspekt wollen wir direkt am Anfang unbedingt herausstellen:
PKS ist keine Alternative, sondern dient der Vervollständigung der Services rund um die Plattformen von Pivotal. Dieser Aspekt wird einmal mehr deutlich, indem Pivotal PKS auch wie folgt beschreibt:

• Stateful, clustered workloads like Apache Spark and Elasticsearch
• Apps that are already containerized as Docker images (like from an ISV)
• Workloads that require access to infrastructure primitiv

Wofür steht das Kubernetes Deployment jetzt genau?

Ähnlich wie bei CF gibt es auch für PKS eine Open Source Variante “Kubo” (Kubernetes/Bosh) und seit kurzer Zeit gibt es nun ein Bosh basierendes Kubernetes Deployment: https://github.com/cloudfoundry-incubator/kubo-deployment

[/et_pb_text][et_pb_text _builder_version=”3.0.105″ background_layout=”light”]

Auf dem Weg zum offiziellen Release …

• Aktuell handelt es sich hierbei noch um eine Incubator Projekt, das also noch von einem offiziellen Release entfernt ist.
• Trotzdem kann es bereits heute als derart stabil bezeichnet werden, um es sinnvoll einzusetzen.
• Das Deployment selbst basiert auf dem https://github.com/cloudfoundry-incubator/kubo-release, welches in der aktuell Form in der Version 0.11.0

Im Folgenden geht es darum zu zeigen, wie Ihr mit dem Deployment von Kubo auf bosh-lite bzw. OpenStack arbeitet. Dabei wollen wir herausstellen, wie man mit ein paar kleinen Kniffen eine vollständig lauffähigen Kubernetes Cluster aktivieren kann.

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section][et_pb_section bb_built=”1″ next_background_color=”#ffffff” prev_background_color=”#ffffff” _builder_version=”3.0.105″ background_color=”#f1f1f1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text admin_label=”Technische Einleitung” _builder_version=”3.0.105″ background_layout=”light”]

Technische Einleitung

Welcher Aspekt fällt zu Beginn der Nutzung von Kubo direkt auf?
Das ist ganz eindeutig der Aufbau des Repositories zum Deployment an sich. Leider haben die Autoren einen Aspekt aus unserer Sicht vernachlässigt: Sie haben sich nicht darauf konzentriert, die Stärken von modularen Bosh Manifest mit Bosh 2 zu nutzen. Das zeigt sich vor allem dadurch, dass anstelle von modularen Bosh Deployment Files das Repository voll von Shell Scripten (Januar 2018) ist.

Die gute Nachricht in diesem Zusammenhang: Es gibt Licht am Ende des Tunnels! Denn glücklicherweise wurden einige Anstrengungen unternommen, das Repository in die notwendig Richtung zu migrieren … wir halten euch natürlich auf dem Laufenden, sobald es hier Neuigkeiten gibt.
Des Weiteren sieht das aktuell kubo-deployment vor, einen dedizierten Director zu deployen, wobei durchaus die Sinnhaftigkeit zu hinterfragen ist

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section][et_pb_section bb_built=”1″ prev_background_color=”#f1f1f1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.0.105″ background_layout=”light”]

Und was sollte hinsichtlich des Deployments herausgestellt werden?

Zu Beginn ist es uns besonders wichtig, eines  zu betonen: Wir werden keine Shell Scripte verwenden. Stattdessen sollte das Resultat ein Deployment auf Basis eines 5 Zeilen Shell Kommandos sein, das wie folgt aussieht:

bosh deploy -d kubo manifests/cfcr.yml 

-o manifests/ops-files/vm-types.yml 

-v master_vm_type=default 

-v worker_vm_type=default 

-o manifests/ops-files/replace-name.yml 

-v deployment_name=kubo 

-o manifests/ops-files/use-runtime-config-bosh-dns.yml 

-o manifests/ops-files/availability-zones.yml

Welches “Rüstwerkzeug” ist dazu notwendig? Für eine erfolgreiche Realisierung solltet Ihr auf diese Schritte achten:

• Ein existierender Bosh Director
  • Zwei unterschiedliche vm_types in der Cloud Config
  • Stemcell 15
  • Ein Netzwerk mit 4 freien IPs
• Bosh Director mit credhub enabled `-o /workspace/releases/bosh-deployment/credhub.yml`
• Bosh Director with DNS enabled `-o /workspace/releases/bosh-deployment/local-dns.yml `
• Update runtime config: `bosh update-runtime-config /workspace/releases/bosh-deployment/runtime-configs/dns.yml`

Danach solltet Ihr das Repository auschecken via git clone https://github.com/cloudfoundry-incubator/kubo-deployment
Nach dem erfolgreichen Checkout war es notwendig zwei Files unter manifests/ops-files hinzuzufügen:

• availability-zones.yml
• replace-name.yml

availability-zones.yml

- type: remove
path: /instance_groups/name=master/azs

- type: remove
path: /instance_groups/name=worker/azs

replace-name.yml

- type: replace
path: /name
value: ((deployment_name))

[/et_pb_text][et_pb_text _builder_version=”3.0.105″ background_color=”#a8d1dd” background_layout=”light” custom_padding=”10px|10px|10px|10px”]

Ersteres ist nur notwendig, wenn keine Availability-Zones vorhanden sind (bosh-lite bspw)

Replace-name.yml ist notwendig, um zu verhindern, dass jedes Deployment cfcr genannt wird und somit nur ein paralleles Deployment möglich ist

Wurde dies erfolgreich im Repository hinzugefügt, ist es danach möglich Kubo gegen einen existierenden Director zu deployen

[/et_pb_text][et_pb_text _builder_version=”3.0.105″ background_layout=”light”]

An dieser Stelle kommen wir jetzt zu den anfangs erwähnten offenen Fragen:

• Wie kann das mit Cloud Foundry verbunden werden? → Consulting evoila
• Wo kann dies deployed werden? → Managed Multi Cloud evoila
• Wie kann man das den Kunden/Nutzern standardisiert anbieten? Durch unser OSB Service Broker Framework → OSB Framework evoila
• Das Deployment beinhaltet keinen Load Balancer, was wir bei uns durch unser OSB-HaProxy Release gelöst haben → OSB Framework evoila
• Das Deployment enthält kein Monitoring, was wir bei uns durch unser OSB-Monitoring Release gelöst haben → OSB Framework evoila

[/et_pb_text][et_pb_image _builder_version=”3.0.105″ src=”/wp-content/uploads/2018/03/screen1.png” show_in_lightbox=”on” url_new_window=”off” use_overlay=”off” always_center_on_mobile=”on” force_fullwidth=”off” show_bottom_space=”on” /][/et_pb_column][/et_pb_row][/et_pb_section]