*35C3 Vorspannmusik*
Herald: Hallo, hallo! Okay, unser nächster Speaker hier ist der Tobias von "Code for
Münster" und hat das Thema Kubernetes Development oder so – und ich habe keine
Ahnung, was das ist und er konnte es mir so schnell auch nicht wirklich verständlich
erklären, aber er wird das jetzt für euch sicher ausführlich machen. Also ein
kleiner Applaus für Tobias bitte. *Applause*
Tobias: Vielen Dank! Ja, also ich werde jetzt in ein paar Minuten mal versuchen
Kubernetes so ein bisschen die Architektur zu erklären und warum ich
glaube, dass das ein ganz gute Plattform ist um eben in "Code-for-Labs" seine Apps zu
deployen und dann auch weiter maintainen zu können. Wer von euch weiß ungefähr, was
Kubernetes ist? Ja top! Und kennt ihr auch alle schon Docker und Container-
Technologie? Also grundsätzlich, wenn irgendwelche fragen sind, haut die einfach
zwischendurch raus. Wir können hier auch so ein bisschen, einfach so, Frage-und-Antwort
machen. Ansonsten fange ich einfach mal so an. In Münster treffen wir uns regelmäßig,
seit drei Jahren mittlerweile, unter dem Topic "Code for Münster" und ich glaube seit
zwei Jahren haben wir auch schon ein Kubernetes-Cluster laufen. Ich selber mache
auch beruflich einiges damit, also auch deswegen habe ich da eigentlich Spaß dran
und mittlerweile, bei uns in Münster, sind glaube ich auch schon so drei Leute, die
theoretisch Kubernetes betreuen könnten und grundsätzlich jeder der neu irgendwie
dazu kommt, kommt nicht darum, irgendwie Docker kennen zu lernen, aber hat auch
durchaus viele Vorteile und ich hoffe die kriege ich jetzt rüber gebracht. Wir können
mit dem spaßigsten Teil beginnen, da versuche ich was zu zeichnen. Wenn das
jetzt irgendwie gar nicht klappt, dann habe ich die Zeichnung von gestern aus dem Zug noch,
die ich Ihnen zeigen könnte. Grundsätzlich zur Architektur von Kubernetes: Es gibt
da drei Grundprinzipien. Das eine ist das alles, was man gegen die Kubernetes-API
schicken möchte, also alles was nachher im Cluster laufen soll, das definiert man
vorher in einer Datei, in einem Manifest. Das ist klassischerweise in YAML, kann auch JSON
sein, aber es ist einfach ein strukturiertes Format. Ich kann mal kurz
ein Beispiel, glaube ich, auch zeigen. Hier, das sind alle unsere Sachen, die wir bei
uns im Cluster laufen lassen und eine Beispiel-App hier. Da haben wir halt einige
Dateien. Die wichtigste ist diese hier, das sieht am Anfang ein bisschen wild aus,
im Endeffekt, wenn man Docker kennt und Containerisierung, ist das die Zeile. Man
sagt dieses Image soll ausgeführt werden und kann dazu noch ein paar Dinge angeben
und dann gibt es noch so weitere Abstraktions-Geschichten, wie Service und
Ingress, erzähl ich gleich auch noch was dazu.
Am Anfang mag das alles ein bisschen viel sein, hat aber den Vorteil,
dass eben egal auf welchem Cloud-Provider man läuft oder ob man selber Server
betreibt, man quasi nur diese Kubernetes- Abstraktionsschicht braucht und man
sich gegenseitig aushelfen kann, gerade speziell in diese "Code-For-Labs". Also
diese Manifeste kann die Kubernetes-API verstehen. Das heißt, am Anfang haben wir
hier - ach so - unsere YAML-Dateien und dann die Kubernetes-API, die läuft auf einem
Server. Das Ganze ist dann die Control Plane von Kubernetes, quasi das ist das
Herzstück und alles was wir machen, über die Kommandozeile oder Ähnliches, geht über
den API-Server. Der API-Server hat dann noch eine Datenbank im Hintergrund, weil er
selbst einfach nicht viel macht. Der nimmt einfach nur die Manifeste entgegen, legt die in
der Datenbank ab und verteilt die dann eventuell an Controller, die es dann noch
gibt und davon kann's dann mehrere geben. Also an sich, die Struktur, serverseitig, ist
relativ simpel. Dann hat man noch weitere Server, die nennen wir einfach nur "Nodes",
und jeder von diesen Servern hat eine Software laufen, nennt sich "Cubelet", und der
API-Server unterhält sich mit denen dann in erster Linie und, ja, das ist im Grunde
die Grundstruktur. Auf all diesen Nodes läuft dann Docker oder eine andere
Containerisierungsform und die Idee, das Besondere jetzt oder ein weiterer
Architekturpunkt von Kubernetes ist, dass er ständig vergleicht: Was möchten wir
eigentlich, dass auf dem Cluster läuft – das sind eben unsere YAML Manifeste –
und über die Cubelets kann er eben erfragen: Was läuft wirklich? Also sobald es eine
Differenz gibt, kann er hingehen und versuchen, das irgendwie auszugleichen. Also
wenn irgendeine App abgestürzt ist oder zu viel Speicher gebraucht hat oder ist
Netzwerkprobleme gab, dann kriegt er das mit. Das ist eventuell
ein Unterschied gegenüber einem Setup, wo man selber Docker-Container startet oder
über "Docker Compose" oder Ähnliches. Gibt's so weit schon mal Fragen? Sonst ist das im
Grunde das Wichtigste, was so Kubernetes angeht. Und es soll jetzt ja auch nicht
jeder in den Code-for-Labs komplett das Bedienen von Kubernetes
beherrschen müssen. Das ist bei uns in Münster auch nicht der Fall, aber trotzdem
hilft es, dass man mit mehreren Leuten gemeinsam Dinge auf dem Cluster spielt
oder auf Servern laufen lässt. Diese YAML- Manifeste kann man nämlich sehr gut
einfach alle in einem Git-Repo liegen haben. Diese YAML-Manifeste schickt man
gegen die Kubernetes-API, indem man auf der Kommandozeile "cubecontrol apply" ausführt,
kann man rekursiv machen über ganze Verzeichnisse. Und hier bei uns in Münster
habt ihr eben schon gesehen, das sind quasi die Verzeichnisse mit allen Apps, die wir
drauf laufen lassen haben und – halt alle Änderungen, die am Server, einem Cluster,
geschehen sollen, laufen über dieses Repo. Also das heißt: Die Leute stellen Pull-
Requests, wenn eine neue App rein soll oder wenn irgendwelche Konfigurationen geändert
werden oder neue Versionen ausgerollt werden soll – und andere können drüber
schauen, ob das okay ist und das Ganze dann committen, mergen und dann kann man es
gegen den Cluster spielen. Das heißt, es ist nicht so, dass irgendjemand mit SSH auf
Maschinen draufgeht und da dann irgendwelche Details konfiguriert und man
hat nachher mehrere Server und typischerweise weiß keiner so genau wie
wichtig welche Konfigurationseinstellung ist oder irgendwelche Sicherheitspatches
jetzt schon drauf sind oder eben nicht. In diesem Kubernetes-Setup können wir
theoretisch auch hingehen und den ganzen Cluster wegschmeißen, neue Server
aufsetzen und alles gegen den Server spielen und die Sachen kämen dann wieder
hoch. Abgesehen von dem Kram, den man in den Datenbanken oder auf dem Filesystem hat, da
muss man sich dann eben um die Backups kümmern, aber theoretisch ist es ein
relativ klar strukturierter Ansatz, also man hat gut einsehbar, was auf dem Cluster
laufen soll und Kubernetes sorgt dann dafür, dass es auch der Fall ist. Man hat einige
Abstraktionsmöglichkeiten, wenn es um die Domainverwaltung geht oder Let's Encrypt,
zeig ich gleich kurz. Und man hat quasi dann auch, wenn man sich dieses Repo
anschaut, dann so ein Audit Log. Also man weiß, was passiert ist, wer wann was gemacht hat,
sodass man durchaus mit mehreren Leuten gemeinsam so ein Cluster betreiben kann
und solange ein paar Leute Kubernetes verstehen, können die halt aushelfen und es
ist nicht irgendwie eine Person, die nur Zugang hat und an der dann alles hängt. Also ein
Beispiel ist die unsere "Traffics Shiny App". Da kam einer zu uns, der gut R konnte, hatte
aber noch keine Idee von Docker und meinte, bei ihnen an der Uni gehen sie auch
einfach per SSH auf die Maschinen und starten da irgendwas und – Aber da
wir das halt gar nicht mehr machen, haben wir ihm soweit Docker beigebracht – oder es
hat ihn auch interessiert und im Endeffekt, wenn er an seiner App halt was Neues
gebastelt hat, dann kann er auf GitHub hingehen und ein neues Release erzeugen, als
ein Beispiel für eine sehr einfache Pipeline. Und das würde dann automatisch einen neuen
Build anstoßen, auf dem Docker-Hub. Und dann läuft auf dem Cluster ein Tool von der
Firma "weaveworks", das einfach im Cluster sitzt und die ganze Zeit auf dem Docker-Hub
schaut, ob neue Images da sind. Und sobald er eine neue Version findet, würde
er die auf den Cluster schieben. Also, da muss man jetzt auch nicht unbedingt den
Docker-Hub nehmen, man kann auch Quay nehmen, anstatt GitHub auch GitLab. GitLab hat
selber für Kubernetes, glaube ich, ein paar Tools und Integrationen. Aber theoretisch
können halt Leute, die auch eben gar keine Lust haben an Server-Management, mit
relativ simplen Sachen ihre neue App basteln, sagen neues Release und wenn sie ein
bisschen warten, ist die automatisch dann auf dem Cluster in der neuen Version. Wenn
jetzt mehrere Leute gemeinsam auf dem Cluster unterwegs sind, dann möchte man ja
trotzdem, auch wenn sie gegenseitig sich freundlich gesinnt sind, ein bisschen
Isolation haben, sodass man ihnen die – wenn eine App irgendwie Amok läuft,
dass das dann nicht alle anderen mit runter reißt – und da bietet Kubernetes auch von
Haus aus eine Menge Sachen. Einmal kann man nach Namespaces isolieren. Hier, das
wäre das Kommandozeilen-Tool "CubeControl". Hier sieht man jetzt die Namespaces, die
laufen und die Apps kann man mehr oder weniger gegeneinander über Namespaces
isolieren. Aber so könnte man neben meinem Team oder eben auch einem Code-For-Lab in
die Namespace zuweisen und ihnen den Zugriff auf anderen Namespaces verhindern.
Und was auch noch interessant ist: Man kann dann nachher die Container, die man laufen
lässt, denen kann man jeweils zuweisen, wie viel Speicher sie maximal benutzen dürfen
oder wie viel CPU und in Zukunft wahrscheinlich auch noch ein paar mehr
Sachen. Das definiert man dann genauso in den in den YAML-Manifesten. Deswegen sehen
die halt sehr komplex aus, weil man darüber alles Mögliche nachher einrichten kann. Es
gibt dann – ja – also Kubernetes wird, alle drei Monate gibt es ein neues Release und
da kommen eigentlich halt laufend neue Features rein. Es wird von einer Foundation,
von der "Cloud Native Computing Foundation" heißt sie glaube ich, soweit betreut und im
Hintergrund stehen halt alle möglichen großen Firmen und auch viele kleine, von
RedHat, Microsoft, Amazon, Google logischerweise und die gesamte Entwicklung
geschieht aber komplett offen, also man kann alles auf GitHub – Kubernetes verfolgen
und es gibt so Special Interest Groups für die verschiedenen Bereiche, eben auch bei
Netzwerk-Geschichten oder Rechte- Geschichten, die machen auch teilweise
wöchentliche Treffen, wo man sich dann irgendwie zuschalten kann über Hangout. Also das
ganze System ist halt sehr offen und die Community ist sehr wichtig in dem ganzen
Entwicklungsprozess und laufend gibt es halt weitere Features vor allem in Sachen
Sicherheit, ja, oder auch Dinge, die uns das Leben einfacher machen. Zum Beispiel
gibt es eine Abstraktionsschicht, das nennt sich Ingresses. Also wir haben unsere Apps
jetzt in Containern laufen auf dem Cluster. Jetzt hätten wir gerne, dass wir
die von außen immer die Domain erreichen können. Und da gibt es einfach ein Tool das
man installieren kann. Das nennt sich – das ist im Endeffekt ein Proxy auf Basis von
NGINX, hier haben wir nur Text, wir können mal kurz bei uns schauen, die werden auch
über die YAML-Manifeste definiert und hier sehen wir jetzt die
verschiedenen Domains und die verweisen jeweils dann quasi über einen
Zwischenschritt noch auf die Container, die laufen. Das heißt, wir definieren, ich habe
glaube ich, wo hab ichs, wahrscheinlich hier – Genau. Das sieht im Endeffekt so aus. Auch
wieder für diese "Traffics Shiny App", da tragen wir ein: Das soll die Domain
sein, verweist auf Container, die unter dem Namen laufen und außerdem hätten wir gerne
das automatisch Let's Encrypt eingerichtet wird. Also derjenige, der diese App bastelt
und auf den Cluster schiebt, braucht sich selbst darum auch nicht kümmern. Er muss
nur sagen, wie die Adresse heißen soll, dann wird es angelegt, im Hintergrund "Let´s
Encrypt"-Zertifikate erzeugt – die werden auch passend erneuert. Man muss es nur halt
einmal definieren, dass man das gerne haben möchte und man muss noch ein Cert-
Manager im Cluster laufen lassen. Also im Endeffekt: Dieser Ingres-Controller oder
die Cert-Manager, die laufen die ganze Zeit im Hintergrund und gucken, ob eine neue
Ingress-Definition gegen die Kubernetes- API geschickt wird. Und sobald sie das
sehen, konfigurieren sie NGINX neu, holen sich die "Let's Encrypt"-Zertifikate, legen
die passend ab. Also alles Dinge, die man sich im Detail anschauen kann, wenn man
möchte, aber eben nicht unbedingt muss. Was natürlich auch ganz nett ist, wenn man
einmal Monitoring für den Cluster eingerichtet hat – oder eben Logdateien, die
kann man alle zentral sich von all den Containern holen, die über mehrere Server
verteilt laufen und dann zentral sich anschauen. Also zu Monitoring wird oft
Prometheus im Hintergrund eingesetzt und Graphana, und so kann man sich Dashboards
irgendwie basteln und jeweils dann auch für eine bestimmte App oder für einen Namespace
filtern und den tatsächlichen CPU oder Netzwerkverkehr sich anschauen. Also es
muss halt nur einmal gemacht werden und auch wenn neue Apps eingerichtet werden
und hoch kommen, läuft automatisch alles mit ins Monitoring oder Logging über
Elasticsearch und Kibana. Ja, und dann kann man auf der Basis auch Alerts definieren
und die in seinen Slack-Channel (also Open- Knowledge-Channel) theoretisch irgendwie
schicken lassen und dann könnten ein paar Freiwillige sich darum kümmern, wenn sie
sehen, dass irgendwas im Argen liegt. Paar Sachen gibt es auch bei uns immer noch zu
verbessern. Also einmal zur Zeit nutzen wir den Standardweg zur Authentifizierung. Das
sind Zertifikate bei Kubernetes. Das kann man eventuell auch eleganter lösen über
ein Keycloak-Setup und dann hauen wir unsere Leute in eine GitHub-Gruppe und die
bekommen dann darüber Zugriff. Wir haben auch schon laufen ein verteiltes
Dateisystem. Also alle unsere drei Server laufen zur Zeit bei Scaleway, und die haben
halt irgendwie keinen Cloudspeicher. Deswegen muss man sich halt selber darum
kümmern, dass man sein System am besten verteilt laufen lässt, weil wir ja
auch ausfallsicher sein wollen, falls mal ein Node irgendwie komplett abschmiert.
Und da gibt es auch verschiedene Sachen, die fürs Kubernetes Umfeld gebastelt
werden. Zum Beispiel OpenEBS. Da kann man dann einfach die dis definieren,
die bei den bei den Servern hängen und sagt, wie stark die Replizierung sein soll.
Wir spielen ein bisschen rum. Also da gibt es auch immer Versionsupdates und man muss
gucken, wie gut man das migriert kriegt. Ist noch ein bisschen testweise, aber auch
theoretisch dann die Möglichkeit, dass man einfach eine App starten lässt, der
Speicher OpenEBS zuweist und egal, ob diese App nachher – auf welchem Server
die nachher startet, kriegt die Zugriff auf ihre Daten. Das ist falsch, da muss
man ein Leerzeichen zwischen. So weit von mir. Wir haben unser Setup bei
"Code for Münster" laufen. Ich selber kann auch gerne noch mehr zu Kubernetes erzählen.
Also auch die nächsten ein, zwei Tage. @webwurst ist das Kürzel auf Twitter, GitHub,
Gmail oder einfach googlen. Der Name ist nicht so oft verwendet. Ja, also die Grundidee für
den Talk war ein bisschen, dass, wenn andere Code-for-Labs irgendwie auch Lust haben... Am
meisten Sinn macht es wahrscheinlich, dass man sich Server teilt. Also wir haben eben
drei Server, die jetzt jeweils – die insgesamt ungefähr 100 Gigabyte RAM
haben. Das ist uns eigentlich zu viel, aber kleinere sind irgendwie wieder teurer. Also
falls sich Leute zusammentun wollen oder einfach nur neugierig sind auf Kubernetes
und wie man das sinnvoll einsetzt, haben wir die Beispiele, helfen gerne aus – ja, und
würden gerne auch zusammenarbeit mit anderen Code-for-Labs. Vielen Dank.
*Applaus*
Herald: Tobias – danke dir. So, wir haben noch ein bisschen Zeit für Fragen. Also wenn
irgendwer eine Frage hat, dann könnt ihr mal irgendein Zeichen geben. Dann komme ich
gerne mit dem Mikrofon zu euch. Mensch 1: Ich hätte 'ne Frage, und zwar:
Ich hab das eben nicht ganz verstanden. OpenEBS wolltet ihr als verteiltes Dateisystem
später einsetzen. Was nutzt ihr jetzt und wieso habt ihr euch für OpenEBS entschieden?
Tobias: Wir hatten uns vorher mal Rook angeschaut. Wir haben jetzt OpenEBS schon
laufen, aber ich nenne es noch experimentell. Also version 0.7 läuft,
gerade 0.8 ist glaube ich raus. Warum? Ich hatte mit denen auf der auf der KubeCon
in Kopenhagen gesprochen und das sind irgendwie 200 Leute im Team, die viel Storage
schon gemacht haben, komplett Open Source und ich glaube, die haben da ganz gute
ideen – auch wenn das relativ komplex ist, was die da so schreiben zu ihrer
Architektur. Aber ja, das ist einfach der Grund. Wir sind auch offen für anderes, wenn's
gute Erfahrungen gibt, wenn du welche hast... Mensch1: Nee, also ich frage deshalb, weil
wir haben nämlich auch den Instanzen, mit denen ich bisher Erfahrungen gesammelt
habe, war das immer das große Fragezeichen am Ende: Was was benutzen wir als Persistant
Storage? Weil ich finde, da sind die Hürden sehr hoch für einen Einstieg, sage ich
mal. – oder was auch immer man da irgendwie als als Dateisystem benutzen kann...
Und deswegen war ich einfach nur neugierig.
Tobias: Das stimmt. Mensch1: Weil, die Entscheidung steht
uns auch noch bevor. Tobias: Alternativ, wenn du eine verteilte
Datenbank hast, kannst du eben auch Local Storage benutzen, aber – ja – musst du
halt irgendwie über die Datenbank dann gehen. Ja.
Herald: Hier hinten war noch...
Mensch 2: Hallo. Ich wollte fragen: Wie lange hat es dauert, euch das ganze Setup aufzusetzen
und seid ihr irgendwo darauf gestoßen, wo ihr das nicht so umsetzen konntet, wie ihr
das umsetzen wolltet, beim Alarming oder Monitoring oder so? Also irgendwas rein
hacken haben müssen? Tobias: Das Ganze ist schwer zu sagen. Als
wir angefangen haben, hatten wir auch relativ – ich glaube, da gab es noch nicht so
super viel fertiges Tooling. Ich glaub, Prometheus und Graphana hatten wir selbst
gebastelt, dann mit Docker auch noch, und das war so "learning by doing" auch ein bisschen.
Aber mittlerweile sehe ich jetzt eben halt: Storage ist immer ein bisschen eine
Schwierigkeit oder verteilte Datenbanken, aber grundsätzlich – der Aufbau von dem
System oder eben auch diese einfache Pipeline mit Flux, das steht halt und
tut. Also, da haben wir keine großen Probleme gerade. Auch im Monitoring ändert
sich halt laufend was. Also am spannendsten ist jetzt der Prometheus Operator
eventuell und da gibt es dann Kube Prometheus, und die generieren dir eine
ganze Menge Dashboards, und du hast auch eine Art Programmiersprache dann für die
Dashboards, die du verwenden kannst. Ja, es gibt ständig was Neues zu entdecken und
auszuprobieren. Herald: Okay, hier war noch jemand...
Mensch 3: Vielleicht könnt ihr auch noch probieren, die StorageOS. ich
habe mit den Leuten auch geredet auch in Kopenhagen. Sieht auch interessant aus.
Und dann, Sie haben drei Server? Tobias: Ja.
Mensch 3: So, das sind drei Master und auch Node?
Tobias: Ja. Also wir haben den Master halt nur auf einem laufen, aber
trotzdem nutzen wir den auch für normale – Mensch 3: Nur ein Master?
Tobias: Ja, wir haben einen Master, und wenn der down geht,
läuft ja der restliche Kram auch noch weiter, bis wir ihn wieder hochziehen.
Das Ding ist, dass wir das eben auch alles hobbymäßig machen und selber
finanzieren. Also für das Code-for... auch nur einer. Funktioniert aber, wenn
ich den einfach neu starte, dann warte ich fünf Minuten und dann hat sich
alles wieder gefunden. Ja, und die Apps auf den anderen Nodes laufen halt eh weiter und
können weiter von außen erreichbar sein. Mensch 3: Habt ihr schon mal gedacht, ein
Operator? Dann bräuchte man nicht die Storage distribuieren, aber dann
alle sieben, dann wird zum Beispiel Postgres, der wird realisiert und der Operator, der
handelt das. Tobias: Ja, gucken wir uns auf jeden Fall
an, was es da gibt. Oft hat man eben nicht – Elasticsearch tut es ganz gut, wenn man
das Ding in dreifach laufen lässt. Postgres und MySQL kann man ganz gut hochziehen als
Operator über mehrere Nodes, aber sobald irgendwas schief läuft, können die
Operator zur Zeit da noch nicht aushelfen. Dann muss man die man alle manuell neu
starten. Das ist okay, aber irgendwie – es gibt nicht so viel was sich selbst dann
repariert. Wird wahrscheinlich noch kommen, aber –
Herald: Du hattest eine Frage? Mensch 4: Du hattest gerade, wenn der
Master kaputt geht, dann funktionieren die Services trotzdem weiter. Wie macht ihr das
dann mit diesem Ingress, also wo kommt das DNS an?
Tobias: Wir haben es versucht über so einen DNS Round Robin. Also es war einfach –
Der Ingress Controller läuft auf allen – dingens. Ja gerne was Besseres, aber bei Scaleway, wo wir
sind, die haben halt keinen Loadbalancer davor. Also die bieten das nicht irgendwie als
Service an. Die haben wohl eine IP, die man von Node zu Node ziehen kann, aber auch nicht
gleichzeitig an mehrere. Ja, es ist halt ein günstiges Setup für Code-for. Wenn sich mehr
zusammentun, können wir vielleicht auch etwas Spannenderes uns überlegen. Ja, aber
bisher ist es einfach so gelöst. Wir haben jetzt ja auch nicht so lebenswichtige Apps, genau.
Herald: Okay, hat noch jemand eine Frage? Ich sehe keine mehr. Sonst schreit noch mal jemand.
Tobias: Gut, also wenn noch irgendwie Fragen später sind: Schreibt auf "Open-
Knowledge-Slack, Code for Münster" oder @webwurst oder über Twitter oder sonstwie.
Würde ich mich gerne unterhalten mit Leuten. Herald: Dann nochmal Applaus für Tobias, bitte.
*Applaus* Tobias: Vielen Dank.
*Abspannmusik*
Untertitel erstellt von c3subtitles.de im Jahr 2019. Mach mit und hilf uns!