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!