1 00:00:00,000 --> 00:00:18,450 *35C3 Vorspannmusik* 2 00:00:18,450 --> 00:00:23,920 Herald: Hallo, hallo! Okay, unser nächster Speaker hier ist der Tobias von "Code for 3 00:00:23,920 --> 00:00:30,890 Münster" und hat das Thema Kubernetes Development oder so – und ich habe keine 4 00:00:30,890 --> 00:00:33,550 Ahnung, was das ist und er konnte es mir so schnell auch nicht wirklich verständlich 5 00:00:33,550 --> 00:00:37,690 erklären, aber er wird das jetzt für euch sicher ausführlich machen. Also ein 6 00:00:37,690 --> 00:00:40,939 kleiner Applaus für Tobias bitte. *Applause* 7 00:00:40,939 --> 00:00:47,039 Tobias: Vielen Dank! Ja, also ich werde jetzt in ein paar Minuten mal versuchen 8 00:00:47,039 --> 00:00:51,920 Kubernetes so ein bisschen die Architektur zu erklären und warum ich 9 00:00:51,920 --> 00:00:58,109 glaube, dass das ein ganz gute Plattform ist um eben in "Code-for-Labs" seine Apps zu 10 00:00:58,109 --> 00:01:03,569 deployen und dann auch weiter maintainen zu können. Wer von euch weiß ungefähr, was 11 00:01:03,569 --> 00:01:11,279 Kubernetes ist? Ja top! Und kennt ihr auch alle schon Docker und Container- 12 00:01:11,279 --> 00:01:15,700 Technologie? Also grundsätzlich, wenn irgendwelche fragen sind, haut die einfach 13 00:01:15,700 --> 00:01:19,619 zwischendurch raus. Wir können hier auch so ein bisschen, einfach so, Frage-und-Antwort 14 00:01:19,619 --> 00:01:27,829 machen. Ansonsten fange ich einfach mal so an. In Münster treffen wir uns regelmäßig, 15 00:01:27,829 --> 00:01:35,039 seit drei Jahren mittlerweile, unter dem Topic "Code for Münster" und ich glaube seit 16 00:01:35,039 --> 00:01:38,810 zwei Jahren haben wir auch schon ein Kubernetes-Cluster laufen. Ich selber mache 17 00:01:38,810 --> 00:01:45,929 auch beruflich einiges damit, also auch deswegen habe ich da eigentlich Spaß dran 18 00:01:45,929 --> 00:01:50,219 und mittlerweile, bei uns in Münster, sind glaube ich auch schon so drei Leute, die 19 00:01:50,219 --> 00:01:54,890 theoretisch Kubernetes betreuen könnten und grundsätzlich jeder der neu irgendwie 20 00:01:54,890 --> 00:02:02,280 dazu kommt, kommt nicht darum, irgendwie Docker kennen zu lernen, aber hat auch 21 00:02:02,280 --> 00:02:08,919 durchaus viele Vorteile und ich hoffe die kriege ich jetzt rüber gebracht. Wir können 22 00:02:08,919 --> 00:02:13,860 mit dem spaßigsten Teil beginnen, da versuche ich was zu zeichnen. Wenn das 23 00:02:13,860 --> 00:02:17,530 jetzt irgendwie gar nicht klappt, dann habe ich die Zeichnung von gestern aus dem Zug noch, 24 00:02:17,530 --> 00:02:23,440 die ich Ihnen zeigen könnte. Grundsätzlich zur Architektur von Kubernetes: Es gibt 25 00:02:23,440 --> 00:02:31,819 da drei Grundprinzipien. Das eine ist das alles, was man gegen die Kubernetes-API 26 00:02:31,819 --> 00:02:36,569 schicken möchte, also alles was nachher im Cluster laufen soll, das definiert man 27 00:02:36,569 --> 00:02:43,680 vorher in einer Datei, in einem Manifest. Das ist klassischerweise in YAML, kann auch JSON 28 00:02:43,680 --> 00:02:47,319 sein, aber es ist einfach ein strukturiertes Format. Ich kann mal kurz 29 00:02:47,319 --> 00:02:56,489 ein Beispiel, glaube ich, auch zeigen. Hier, das sind alle unsere Sachen, die wir bei 30 00:02:56,489 --> 00:03:06,110 uns im Cluster laufen lassen und eine Beispiel-App hier. Da haben wir halt einige 31 00:03:06,110 --> 00:03:11,490 Dateien. Die wichtigste ist diese hier, das sieht am Anfang ein bisschen wild aus, 32 00:03:11,490 --> 00:03:16,090 im Endeffekt, wenn man Docker kennt und Containerisierung, ist das die Zeile. Man 33 00:03:16,090 --> 00:03:22,189 sagt dieses Image soll ausgeführt werden und kann dazu noch ein paar Dinge angeben 34 00:03:22,189 --> 00:03:25,630 und dann gibt es noch so weitere Abstraktions-Geschichten, wie Service und 35 00:03:25,630 --> 00:03:29,629 Ingress, erzähl ich gleich auch noch was dazu. 36 00:03:29,629 --> 00:03:35,369 Am Anfang mag das alles ein bisschen viel sein, hat aber den Vorteil, 37 00:03:35,369 --> 00:03:39,650 dass eben egal auf welchem Cloud-Provider man läuft oder ob man selber Server 38 00:03:39,650 --> 00:03:47,090 betreibt, man quasi nur diese Kubernetes- Abstraktionsschicht braucht und man 39 00:03:47,090 --> 00:03:54,740 sich gegenseitig aushelfen kann, gerade speziell in diese "Code-For-Labs". Also 40 00:03:54,740 --> 00:04:01,269 diese Manifeste kann die Kubernetes-API verstehen. Das heißt, am Anfang haben wir 41 00:04:01,269 --> 00:04:15,000 hier - ach so - unsere YAML-Dateien und dann die Kubernetes-API, die läuft auf einem 42 00:04:15,000 --> 00:04:27,031 Server. Das Ganze ist dann die Control Plane von Kubernetes, quasi das ist das 43 00:04:27,031 --> 00:04:32,320 Herzstück und alles was wir machen, über die Kommandozeile oder Ähnliches, geht über 44 00:04:32,320 --> 00:04:38,580 den API-Server. Der API-Server hat dann noch eine Datenbank im Hintergrund, weil er 45 00:04:38,580 --> 00:04:45,220 selbst einfach nicht viel macht. Der nimmt einfach nur die Manifeste entgegen, legt die in 46 00:04:45,220 --> 00:04:51,580 der Datenbank ab und verteilt die dann eventuell an Controller, die es dann noch 47 00:04:51,580 --> 00:04:58,000 gibt und davon kann's dann mehrere geben. Also an sich, die Struktur, serverseitig, ist 48 00:04:58,000 --> 00:05:06,650 relativ simpel. Dann hat man noch weitere Server, die nennen wir einfach nur "Nodes", 49 00:05:06,650 --> 00:05:14,790 und jeder von diesen Servern hat eine Software laufen, nennt sich "Cubelet", und der 50 00:05:14,790 --> 00:05:25,610 API-Server unterhält sich mit denen dann in erster Linie und, ja, das ist im Grunde 51 00:05:25,610 --> 00:05:28,970 die Grundstruktur. Auf all diesen Nodes läuft dann Docker oder eine andere 52 00:05:28,970 --> 00:05:36,550 Containerisierungsform und die Idee, das Besondere jetzt oder ein weiterer 53 00:05:36,550 --> 00:05:40,240 Architekturpunkt von Kubernetes ist, dass er ständig vergleicht: Was möchten wir 54 00:05:40,240 --> 00:05:47,380 eigentlich, dass auf dem Cluster läuft – das sind eben unsere YAML Manifeste – 55 00:05:47,380 --> 00:05:52,430 und über die Cubelets kann er eben erfragen: Was läuft wirklich? Also sobald es eine 56 00:05:52,430 --> 00:05:58,410 Differenz gibt, kann er hingehen und versuchen, das irgendwie auszugleichen. Also 57 00:05:58,410 --> 00:06:02,550 wenn irgendeine App abgestürzt ist oder zu viel Speicher gebraucht hat oder ist 58 00:06:02,550 --> 00:06:07,370 Netzwerkprobleme gab, dann kriegt er das mit. Das ist eventuell 59 00:06:07,370 --> 00:06:12,460 ein Unterschied gegenüber einem Setup, wo man selber Docker-Container startet oder 60 00:06:12,460 --> 00:06:27,540 über "Docker Compose" oder Ähnliches. Gibt's so weit schon mal Fragen? Sonst ist das im 61 00:06:27,540 --> 00:06:32,230 Grunde das Wichtigste, was so Kubernetes angeht. Und es soll jetzt ja auch nicht 62 00:06:32,230 --> 00:06:37,810 jeder in den Code-for-Labs komplett das Bedienen von Kubernetes 63 00:06:37,810 --> 00:06:43,660 beherrschen müssen. Das ist bei uns in Münster auch nicht der Fall, aber trotzdem 64 00:06:43,660 --> 00:06:47,750 hilft es, dass man mit mehreren Leuten gemeinsam Dinge auf dem Cluster spielt 65 00:06:47,750 --> 00:06:59,190 oder auf Servern laufen lässt. Diese YAML- Manifeste kann man nämlich sehr gut 66 00:06:59,190 --> 00:07:05,200 einfach alle in einem Git-Repo liegen haben. Diese YAML-Manifeste schickt man 67 00:07:05,200 --> 00:07:10,510 gegen die Kubernetes-API, indem man auf der Kommandozeile "cubecontrol apply" ausführt, 68 00:07:10,510 --> 00:07:15,020 kann man rekursiv machen über ganze Verzeichnisse. Und hier bei uns in Münster 69 00:07:15,020 --> 00:07:20,520 habt ihr eben schon gesehen, das sind quasi die Verzeichnisse mit allen Apps, die wir 70 00:07:20,520 --> 00:07:27,530 drauf laufen lassen haben und – halt alle Änderungen, die am Server, einem Cluster, 71 00:07:27,530 --> 00:07:33,160 geschehen sollen, laufen über dieses Repo. Also das heißt: Die Leute stellen Pull- 72 00:07:33,160 --> 00:07:38,530 Requests, wenn eine neue App rein soll oder wenn irgendwelche Konfigurationen geändert 73 00:07:38,530 --> 00:07:42,830 werden oder neue Versionen ausgerollt werden soll – und andere können drüber 74 00:07:42,830 --> 00:07:52,960 schauen, ob das okay ist und das Ganze dann committen, mergen und dann kann man es 75 00:07:52,960 --> 00:07:57,720 gegen den Cluster spielen. Das heißt, es ist nicht so, dass irgendjemand mit SSH auf 76 00:07:57,720 --> 00:08:03,440 Maschinen draufgeht und da dann irgendwelche Details konfiguriert und man 77 00:08:03,440 --> 00:08:07,490 hat nachher mehrere Server und typischerweise weiß keiner so genau wie 78 00:08:07,490 --> 00:08:14,550 wichtig welche Konfigurationseinstellung ist oder irgendwelche Sicherheitspatches 79 00:08:14,550 --> 00:08:20,170 jetzt schon drauf sind oder eben nicht. In diesem Kubernetes-Setup können wir 80 00:08:20,170 --> 00:08:25,400 theoretisch auch hingehen und den ganzen Cluster wegschmeißen, neue Server 81 00:08:25,400 --> 00:08:29,550 aufsetzen und alles gegen den Server spielen und die Sachen kämen dann wieder 82 00:08:29,550 --> 00:08:34,559 hoch. Abgesehen von dem Kram, den man in den Datenbanken oder auf dem Filesystem hat, da 83 00:08:34,559 --> 00:08:39,032 muss man sich dann eben um die Backups kümmern, aber theoretisch ist es ein 84 00:08:39,032 --> 00:08:48,970 relativ klar strukturierter Ansatz, also man hat gut einsehbar, was auf dem Cluster 85 00:08:48,970 --> 00:08:54,310 laufen soll und Kubernetes sorgt dann dafür, dass es auch der Fall ist. Man hat einige 86 00:08:54,310 --> 00:08:59,769 Abstraktionsmöglichkeiten, wenn es um die Domainverwaltung geht oder Let's Encrypt, 87 00:08:59,769 --> 00:09:05,640 zeig ich gleich kurz. Und man hat quasi dann auch, wenn man sich dieses Repo 88 00:09:05,640 --> 00:09:13,310 anschaut, dann so ein Audit Log. Also man weiß, was passiert ist, wer wann was gemacht hat, 89 00:09:13,310 --> 00:09:19,269 sodass man durchaus mit mehreren Leuten gemeinsam so ein Cluster betreiben kann 90 00:09:19,269 --> 00:09:23,170 und solange ein paar Leute Kubernetes verstehen, können die halt aushelfen und es 91 00:09:23,170 --> 00:09:33,430 ist nicht irgendwie eine Person, die nur Zugang hat und an der dann alles hängt. Also ein 92 00:09:33,430 --> 00:09:42,800 Beispiel ist die unsere "Traffics Shiny App". Da kam einer zu uns, der gut R konnte, hatte 93 00:09:42,800 --> 00:09:46,629 aber noch keine Idee von Docker und meinte, bei ihnen an der Uni gehen sie auch 94 00:09:46,629 --> 00:09:51,959 einfach per SSH auf die Maschinen und starten da irgendwas und – Aber da 95 00:09:51,959 --> 00:09:57,579 wir das halt gar nicht mehr machen, haben wir ihm soweit Docker beigebracht – oder es 96 00:09:57,579 --> 00:10:01,550 hat ihn auch interessiert und im Endeffekt, wenn er an seiner App halt was Neues 97 00:10:01,550 --> 00:10:08,060 gebastelt hat, dann kann er auf GitHub hingehen und ein neues Release erzeugen, als 98 00:10:08,060 --> 00:10:15,920 ein Beispiel für eine sehr einfache Pipeline. Und das würde dann automatisch einen neuen 99 00:10:15,920 --> 00:10:27,620 Build anstoßen, auf dem Docker-Hub. Und dann läuft auf dem Cluster ein Tool von der 100 00:10:27,620 --> 00:10:33,790 Firma "weaveworks", das einfach im Cluster sitzt und die ganze Zeit auf dem Docker-Hub 101 00:10:33,790 --> 00:10:38,560 schaut, ob neue Images da sind. Und sobald er eine neue Version findet, würde 102 00:10:38,560 --> 00:10:45,550 er die auf den Cluster schieben. Also, da muss man jetzt auch nicht unbedingt den 103 00:10:45,550 --> 00:10:50,570 Docker-Hub nehmen, man kann auch Quay nehmen, anstatt GitHub auch GitLab. GitLab hat 104 00:10:50,570 --> 00:10:56,329 selber für Kubernetes, glaube ich, ein paar Tools und Integrationen. Aber theoretisch 105 00:10:56,329 --> 00:11:01,829 können halt Leute, die auch eben gar keine Lust haben an Server-Management, mit 106 00:11:01,829 --> 00:11:06,490 relativ simplen Sachen ihre neue App basteln, sagen neues Release und wenn sie ein 107 00:11:06,490 --> 00:11:16,470 bisschen warten, ist die automatisch dann auf dem Cluster in der neuen Version. Wenn 108 00:11:16,470 --> 00:11:21,079 jetzt mehrere Leute gemeinsam auf dem Cluster unterwegs sind, dann möchte man ja 109 00:11:21,079 --> 00:11:26,759 trotzdem, auch wenn sie gegenseitig sich freundlich gesinnt sind, ein bisschen 110 00:11:26,759 --> 00:11:35,410 Isolation haben, sodass man ihnen die – wenn eine App irgendwie Amok läuft, 111 00:11:35,410 --> 00:11:41,639 dass das dann nicht alle anderen mit runter reißt – und da bietet Kubernetes auch von 112 00:11:41,639 --> 00:11:49,329 Haus aus eine Menge Sachen. Einmal kann man nach Namespaces isolieren. Hier, das 113 00:11:49,329 --> 00:11:54,720 wäre das Kommandozeilen-Tool "CubeControl". Hier sieht man jetzt die Namespaces, die 114 00:11:54,720 --> 00:12:00,509 laufen und die Apps kann man mehr oder weniger gegeneinander über Namespaces 115 00:12:00,509 --> 00:12:05,379 isolieren. Aber so könnte man neben meinem Team oder eben auch einem Code-For-Lab in 116 00:12:05,379 --> 00:12:13,589 die Namespace zuweisen und ihnen den Zugriff auf anderen Namespaces verhindern. 117 00:12:13,589 --> 00:12:17,379 Und was auch noch interessant ist: Man kann dann nachher die Container, die man laufen 118 00:12:17,379 --> 00:12:23,249 lässt, denen kann man jeweils zuweisen, wie viel Speicher sie maximal benutzen dürfen 119 00:12:23,249 --> 00:12:26,709 oder wie viel CPU und in Zukunft wahrscheinlich auch noch ein paar mehr 120 00:12:26,709 --> 00:12:33,649 Sachen. Das definiert man dann genauso in den in den YAML-Manifesten. Deswegen sehen 121 00:12:33,649 --> 00:12:43,500 die halt sehr komplex aus, weil man darüber alles Mögliche nachher einrichten kann. Es 122 00:12:43,500 --> 00:12:51,930 gibt dann – ja – also Kubernetes wird, alle drei Monate gibt es ein neues Release und 123 00:12:51,930 --> 00:13:00,399 da kommen eigentlich halt laufend neue Features rein. Es wird von einer Foundation, 124 00:13:00,399 --> 00:13:09,990 von der "Cloud Native Computing Foundation" heißt sie glaube ich, soweit betreut und im 125 00:13:09,990 --> 00:13:14,199 Hintergrund stehen halt alle möglichen großen Firmen und auch viele kleine, von 126 00:13:14,199 --> 00:13:20,209 RedHat, Microsoft, Amazon, Google logischerweise und die gesamte Entwicklung 127 00:13:20,209 --> 00:13:26,420 geschieht aber komplett offen, also man kann alles auf GitHub – Kubernetes verfolgen 128 00:13:26,420 --> 00:13:29,949 und es gibt so Special Interest Groups für die verschiedenen Bereiche, eben auch bei 129 00:13:29,949 --> 00:13:35,660 Netzwerk-Geschichten oder Rechte- Geschichten, die machen auch teilweise 130 00:13:35,660 --> 00:13:40,249 wöchentliche Treffen, wo man sich dann irgendwie zuschalten kann über Hangout. Also das 131 00:13:40,249 --> 00:13:45,680 ganze System ist halt sehr offen und die Community ist sehr wichtig in dem ganzen 132 00:13:45,680 --> 00:13:52,580 Entwicklungsprozess und laufend gibt es halt weitere Features vor allem in Sachen 133 00:13:52,580 --> 00:14:01,839 Sicherheit, ja, oder auch Dinge, die uns das Leben einfacher machen. Zum Beispiel 134 00:14:01,839 --> 00:14:07,149 gibt es eine Abstraktionsschicht, das nennt sich Ingresses. Also wir haben unsere Apps 135 00:14:07,149 --> 00:14:12,509 jetzt in Containern laufen auf dem Cluster. Jetzt hätten wir gerne, dass wir 136 00:14:12,509 --> 00:14:17,649 die von außen immer die Domain erreichen können. Und da gibt es einfach ein Tool das 137 00:14:17,649 --> 00:14:26,819 man installieren kann. Das nennt sich – das ist im Endeffekt ein Proxy auf Basis von 138 00:14:26,819 --> 00:14:35,540 NGINX, hier haben wir nur Text, wir können mal kurz bei uns schauen, die werden auch 139 00:14:35,540 --> 00:14:40,889 über die YAML-Manifeste definiert und hier sehen wir jetzt die 140 00:14:40,889 --> 00:14:46,869 verschiedenen Domains und die verweisen jeweils dann quasi über einen 141 00:14:46,869 --> 00:14:52,170 Zwischenschritt noch auf die Container, die laufen. Das heißt, wir definieren, ich habe 142 00:14:52,170 --> 00:15:01,839 glaube ich, wo hab ichs, wahrscheinlich hier – Genau. Das sieht im Endeffekt so aus. Auch 143 00:15:01,839 --> 00:15:08,940 wieder für diese "Traffics Shiny App", da tragen wir ein: Das soll die Domain 144 00:15:08,940 --> 00:15:17,350 sein, verweist auf Container, die unter dem Namen laufen und außerdem hätten wir gerne 145 00:15:17,350 --> 00:15:24,040 das automatisch Let's Encrypt eingerichtet wird. Also derjenige, der diese App bastelt 146 00:15:24,040 --> 00:15:28,709 und auf den Cluster schiebt, braucht sich selbst darum auch nicht kümmern. Er muss 147 00:15:28,709 --> 00:15:33,269 nur sagen, wie die Adresse heißen soll, dann wird es angelegt, im Hintergrund "Let´s 148 00:15:33,269 --> 00:15:40,150 Encrypt"-Zertifikate erzeugt – die werden auch passend erneuert. Man muss es nur halt 149 00:15:40,150 --> 00:15:42,949 einmal definieren, dass man das gerne haben möchte und man muss noch ein Cert- 150 00:15:42,949 --> 00:15:49,310 Manager im Cluster laufen lassen. Also im Endeffekt: Dieser Ingres-Controller oder 151 00:15:49,310 --> 00:15:55,410 die Cert-Manager, die laufen die ganze Zeit im Hintergrund und gucken, ob eine neue 152 00:15:55,410 --> 00:16:00,579 Ingress-Definition gegen die Kubernetes- API geschickt wird. Und sobald sie das 153 00:16:00,579 --> 00:16:05,520 sehen, konfigurieren sie NGINX neu, holen sich die "Let's Encrypt"-Zertifikate, legen 154 00:16:05,520 --> 00:16:12,149 die passend ab. Also alles Dinge, die man sich im Detail anschauen kann, wenn man 155 00:16:12,149 --> 00:16:26,199 möchte, aber eben nicht unbedingt muss. Was natürlich auch ganz nett ist, wenn man 156 00:16:26,199 --> 00:16:33,079 einmal Monitoring für den Cluster eingerichtet hat – oder eben Logdateien, die 157 00:16:33,079 --> 00:16:37,170 kann man alle zentral sich von all den Containern holen, die über mehrere Server 158 00:16:37,170 --> 00:16:45,050 verteilt laufen und dann zentral sich anschauen. Also zu Monitoring wird oft 159 00:16:45,050 --> 00:16:52,129 Prometheus im Hintergrund eingesetzt und Graphana, und so kann man sich Dashboards 160 00:16:52,129 --> 00:16:56,290 irgendwie basteln und jeweils dann auch für eine bestimmte App oder für einen Namespace 161 00:16:56,290 --> 00:17:02,220 filtern und den tatsächlichen CPU oder Netzwerkverkehr sich anschauen. Also es 162 00:17:02,220 --> 00:17:06,550 muss halt nur einmal gemacht werden und auch wenn neue Apps eingerichtet werden 163 00:17:06,550 --> 00:17:13,540 und hoch kommen, läuft automatisch alles mit ins Monitoring oder Logging über 164 00:17:13,540 --> 00:17:22,540 Elasticsearch und Kibana. Ja, und dann kann man auf der Basis auch Alerts definieren 165 00:17:22,540 --> 00:17:28,329 und die in seinen Slack-Channel (also Open- Knowledge-Channel) theoretisch irgendwie 166 00:17:28,329 --> 00:17:32,430 schicken lassen und dann könnten ein paar Freiwillige sich darum kümmern, wenn sie 167 00:17:32,430 --> 00:17:42,240 sehen, dass irgendwas im Argen liegt. Paar Sachen gibt es auch bei uns immer noch zu 168 00:17:42,240 --> 00:17:48,310 verbessern. Also einmal zur Zeit nutzen wir den Standardweg zur Authentifizierung. Das 169 00:17:48,310 --> 00:17:54,160 sind Zertifikate bei Kubernetes. Das kann man eventuell auch eleganter lösen über 170 00:17:54,160 --> 00:17:59,490 ein Keycloak-Setup und dann hauen wir unsere Leute in eine GitHub-Gruppe und die 171 00:17:59,490 --> 00:18:03,700 bekommen dann darüber Zugriff. Wir haben auch schon laufen ein verteiltes 172 00:18:03,700 --> 00:18:13,880 Dateisystem. Also alle unsere drei Server laufen zur Zeit bei Scaleway, und die haben 173 00:18:13,880 --> 00:18:17,890 halt irgendwie keinen Cloudspeicher. Deswegen muss man sich halt selber darum 174 00:18:17,890 --> 00:18:24,830 kümmern, dass man sein System am besten verteilt laufen lässt, weil wir ja 175 00:18:24,830 --> 00:18:30,160 auch ausfallsicher sein wollen, falls mal ein Node irgendwie komplett abschmiert. 176 00:18:30,160 --> 00:18:34,480 Und da gibt es auch verschiedene Sachen, die fürs Kubernetes Umfeld gebastelt 177 00:18:34,480 --> 00:18:40,660 werden. Zum Beispiel OpenEBS. Da kann man dann einfach die dis definieren, 178 00:18:40,660 --> 00:18:47,380 die bei den bei den Servern hängen und sagt, wie stark die Replizierung sein soll. 179 00:18:47,380 --> 00:18:52,520 Wir spielen ein bisschen rum. Also da gibt es auch immer Versionsupdates und man muss 180 00:18:52,520 --> 00:18:56,560 gucken, wie gut man das migriert kriegt. Ist noch ein bisschen testweise, aber auch 181 00:18:56,560 --> 00:19:03,690 theoretisch dann die Möglichkeit, dass man einfach eine App starten lässt, der 182 00:19:03,690 --> 00:19:08,060 Speicher OpenEBS zuweist und egal, ob diese App nachher – auf welchem Server 183 00:19:08,060 --> 00:19:16,830 die nachher startet, kriegt die Zugriff auf ihre Daten. Das ist falsch, da muss 184 00:19:16,830 --> 00:19:23,770 man ein Leerzeichen zwischen. So weit von mir. Wir haben unser Setup bei 185 00:19:23,770 --> 00:19:29,500 "Code for Münster" laufen. Ich selber kann auch gerne noch mehr zu Kubernetes erzählen. 186 00:19:29,500 --> 00:19:37,360 Also auch die nächsten ein, zwei Tage. @webwurst ist das Kürzel auf Twitter, GitHub, 187 00:19:37,360 --> 00:19:43,570 Gmail oder einfach googlen. Der Name ist nicht so oft verwendet. Ja, also die Grundidee für 188 00:19:43,570 --> 00:19:47,780 den Talk war ein bisschen, dass, wenn andere Code-for-Labs irgendwie auch Lust haben... Am 189 00:19:47,780 --> 00:19:51,180 meisten Sinn macht es wahrscheinlich, dass man sich Server teilt. Also wir haben eben 190 00:19:51,180 --> 00:19:56,030 drei Server, die jetzt jeweils – die insgesamt ungefähr 100 Gigabyte RAM 191 00:19:56,030 --> 00:20:02,370 haben. Das ist uns eigentlich zu viel, aber kleinere sind irgendwie wieder teurer. Also 192 00:20:02,370 --> 00:20:07,250 falls sich Leute zusammentun wollen oder einfach nur neugierig sind auf Kubernetes 193 00:20:07,250 --> 00:20:13,730 und wie man das sinnvoll einsetzt, haben wir die Beispiele, helfen gerne aus – ja, und 194 00:20:13,730 --> 00:20:20,920 würden gerne auch zusammenarbeit mit anderen Code-for-Labs. Vielen Dank. 195 00:20:20,920 --> 00:20:26,510 *Applaus* 196 00:20:26,510 --> 00:20:31,760 Herald: Tobias – danke dir. So, wir haben noch ein bisschen Zeit für Fragen. Also wenn 197 00:20:31,760 --> 00:20:35,070 irgendwer eine Frage hat, dann könnt ihr mal irgendein Zeichen geben. Dann komme ich 198 00:20:35,070 --> 00:20:46,040 gerne mit dem Mikrofon zu euch. Mensch 1: Ich hätte 'ne Frage, und zwar: 199 00:20:46,040 --> 00:20:52,540 Ich hab das eben nicht ganz verstanden. OpenEBS wolltet ihr als verteiltes Dateisystem 200 00:20:52,540 --> 00:20:59,440 später einsetzen. Was nutzt ihr jetzt und wieso habt ihr euch für OpenEBS entschieden? 201 00:20:59,440 --> 00:21:04,240 Tobias: Wir hatten uns vorher mal Rook angeschaut. Wir haben jetzt OpenEBS schon 202 00:21:04,240 --> 00:21:07,920 laufen, aber ich nenne es noch experimentell. Also version 0.7 läuft, 203 00:21:07,920 --> 00:21:14,020 gerade 0.8 ist glaube ich raus. Warum? Ich hatte mit denen auf der auf der KubeCon 204 00:21:14,020 --> 00:21:17,990 in Kopenhagen gesprochen und das sind irgendwie 200 Leute im Team, die viel Storage 205 00:21:17,990 --> 00:21:24,400 schon gemacht haben, komplett Open Source und ich glaube, die haben da ganz gute 206 00:21:24,400 --> 00:21:28,530 ideen – auch wenn das relativ komplex ist, was die da so schreiben zu ihrer 207 00:21:28,530 --> 00:21:32,550 Architektur. Aber ja, das ist einfach der Grund. Wir sind auch offen für anderes, wenn's 208 00:21:32,550 --> 00:21:37,620 gute Erfahrungen gibt, wenn du welche hast... Mensch1: Nee, also ich frage deshalb, weil 209 00:21:37,620 --> 00:21:43,280 wir haben nämlich auch den Instanzen, mit denen ich bisher Erfahrungen gesammelt 210 00:21:43,280 --> 00:21:48,240 habe, war das immer das große Fragezeichen am Ende: Was was benutzen wir als Persistant 211 00:21:48,240 --> 00:21:55,650 Storage? Weil ich finde, da sind die Hürden sehr hoch für einen Einstieg, sage ich 212 00:21:55,650 --> 00:22:01,640 mal. – oder was auch immer man da irgendwie als als Dateisystem benutzen kann... 213 00:22:01,640 --> 00:22:04,440 Und deswegen war ich einfach nur neugierig. 214 00:22:04,440 --> 00:22:06,370 Tobias: Das stimmt. Mensch1: Weil, die Entscheidung steht 215 00:22:06,370 --> 00:22:09,740 uns auch noch bevor. Tobias: Alternativ, wenn du eine verteilte 216 00:22:09,740 --> 00:22:15,651 Datenbank hast, kannst du eben auch Local Storage benutzen, aber – ja – musst du 217 00:22:15,651 --> 00:22:20,520 halt irgendwie über die Datenbank dann gehen. Ja. 218 00:22:20,520 --> 00:22:23,590 Herald: Hier hinten war noch... 219 00:22:23,590 --> 00:22:27,630 Mensch 2: Hallo. Ich wollte fragen: Wie lange hat es dauert, euch das ganze Setup aufzusetzen 220 00:22:27,630 --> 00:22:32,020 und seid ihr irgendwo darauf gestoßen, wo ihr das nicht so umsetzen konntet, wie ihr 221 00:22:32,020 --> 00:22:36,000 das umsetzen wolltet, beim Alarming oder Monitoring oder so? Also irgendwas rein 222 00:22:36,000 --> 00:22:41,630 hacken haben müssen? Tobias: Das Ganze ist schwer zu sagen. Als 223 00:22:41,630 --> 00:22:47,831 wir angefangen haben, hatten wir auch relativ – ich glaube, da gab es noch nicht so 224 00:22:47,831 --> 00:22:51,400 super viel fertiges Tooling. Ich glaub, Prometheus und Graphana hatten wir selbst 225 00:22:51,400 --> 00:22:57,330 gebastelt, dann mit Docker auch noch, und das war so "learning by doing" auch ein bisschen. 226 00:22:57,330 --> 00:23:02,630 Aber mittlerweile sehe ich jetzt eben halt: Storage ist immer ein bisschen eine 227 00:23:02,630 --> 00:23:07,810 Schwierigkeit oder verteilte Datenbanken, aber grundsätzlich – der Aufbau von dem 228 00:23:07,810 --> 00:23:14,820 System oder eben auch diese einfache Pipeline mit Flux, das steht halt und 229 00:23:14,820 --> 00:23:22,480 tut. Also, da haben wir keine großen Probleme gerade. Auch im Monitoring ändert 230 00:23:22,480 --> 00:23:27,690 sich halt laufend was. Also am spannendsten ist jetzt der Prometheus Operator 231 00:23:27,690 --> 00:23:31,720 eventuell und da gibt es dann Kube Prometheus, und die generieren dir eine 232 00:23:31,720 --> 00:23:36,310 ganze Menge Dashboards, und du hast auch eine Art Programmiersprache dann für die 233 00:23:36,310 --> 00:23:40,790 Dashboards, die du verwenden kannst. Ja, es gibt ständig was Neues zu entdecken und 234 00:23:40,790 --> 00:23:46,460 auszuprobieren. Herald: Okay, hier war noch jemand... 235 00:23:46,460 --> 00:23:56,091 Mensch 3: Vielleicht könnt ihr auch noch probieren, die StorageOS. ich 236 00:23:56,091 --> 00:24:01,780 habe mit den Leuten auch geredet auch in Kopenhagen. Sieht auch interessant aus. 237 00:24:01,780 --> 00:24:05,230 Und dann, Sie haben drei Server? Tobias: Ja. 238 00:24:05,230 --> 00:24:07,510 Mensch 3: So, das sind drei Master und auch Node? 239 00:24:07,510 --> 00:24:12,610 Tobias: Ja. Also wir haben den Master halt nur auf einem laufen, aber 240 00:24:12,610 --> 00:24:16,430 trotzdem nutzen wir den auch für normale – Mensch 3: Nur ein Master? 241 00:24:16,430 --> 00:24:19,470 Tobias: Ja, wir haben einen Master, und wenn der down geht, 242 00:24:19,470 --> 00:24:23,490 läuft ja der restliche Kram auch noch weiter, bis wir ihn wieder hochziehen. 243 00:24:23,490 --> 00:24:26,530 Das Ding ist, dass wir das eben auch alles hobbymäßig machen und selber 244 00:24:26,530 --> 00:24:34,960 finanzieren. Also für das Code-for... auch nur einer. Funktioniert aber, wenn 245 00:24:34,960 --> 00:24:38,640 ich den einfach neu starte, dann warte ich fünf Minuten und dann hat sich 246 00:24:38,640 --> 00:24:44,400 alles wieder gefunden. Ja, und die Apps auf den anderen Nodes laufen halt eh weiter und 247 00:24:44,400 --> 00:24:48,540 können weiter von außen erreichbar sein. Mensch 3: Habt ihr schon mal gedacht, ein 248 00:24:48,540 --> 00:24:55,120 Operator? Dann bräuchte man nicht die Storage distribuieren, aber dann 249 00:24:55,120 --> 00:25:01,690 alle sieben, dann wird zum Beispiel Postgres, der wird realisiert und der Operator, der 250 00:25:01,690 --> 00:25:04,560 handelt das. Tobias: Ja, gucken wir uns auf jeden Fall 251 00:25:04,560 --> 00:25:11,850 an, was es da gibt. Oft hat man eben nicht – Elasticsearch tut es ganz gut, wenn man 252 00:25:11,850 --> 00:25:17,080 das Ding in dreifach laufen lässt. Postgres und MySQL kann man ganz gut hochziehen als 253 00:25:17,080 --> 00:25:23,530 Operator über mehrere Nodes, aber sobald irgendwas schief läuft, können die 254 00:25:23,530 --> 00:25:27,480 Operator zur Zeit da noch nicht aushelfen. Dann muss man die man alle manuell neu 255 00:25:27,480 --> 00:25:31,130 starten. Das ist okay, aber irgendwie – es gibt nicht so viel was sich selbst dann 256 00:25:31,130 --> 00:25:32,970 repariert. Wird wahrscheinlich noch kommen, aber – 257 00:25:32,970 --> 00:25:40,080 Herald: Du hattest eine Frage? Mensch 4: Du hattest gerade, wenn der 258 00:25:40,080 --> 00:25:44,880 Master kaputt geht, dann funktionieren die Services trotzdem weiter. Wie macht ihr das 259 00:25:44,880 --> 00:25:48,810 dann mit diesem Ingress, also wo kommt das DNS an? 260 00:25:48,810 --> 00:25:53,960 Tobias: Wir haben es versucht über so einen DNS Round Robin. Also es war einfach – 261 00:25:53,960 --> 00:25:59,420 Der Ingress Controller läuft auf allen – dingens. Ja gerne was Besseres, aber bei Scaleway, wo wir 262 00:25:59,420 --> 00:26:02,830 sind, die haben halt keinen Loadbalancer davor. Also die bieten das nicht irgendwie als 263 00:26:02,830 --> 00:26:06,840 Service an. Die haben wohl eine IP, die man von Node zu Node ziehen kann, aber auch nicht 264 00:26:06,840 --> 00:26:12,770 gleichzeitig an mehrere. Ja, es ist halt ein günstiges Setup für Code-for. Wenn sich mehr 265 00:26:12,770 --> 00:26:17,420 zusammentun, können wir vielleicht auch etwas Spannenderes uns überlegen. Ja, aber 266 00:26:17,420 --> 00:26:28,441 bisher ist es einfach so gelöst. Wir haben jetzt ja auch nicht so lebenswichtige Apps, genau. 267 00:26:28,441 --> 00:26:41,340 Herald: Okay, hat noch jemand eine Frage? Ich sehe keine mehr. Sonst schreit noch mal jemand. 268 00:26:41,340 --> 00:26:47,390 Tobias: Gut, also wenn noch irgendwie Fragen später sind: Schreibt auf "Open- 269 00:26:47,390 --> 00:26:51,340 Knowledge-Slack, Code for Münster" oder @webwurst oder über Twitter oder sonstwie. 270 00:26:51,340 --> 00:26:55,820 Würde ich mich gerne unterhalten mit Leuten. Herald: Dann nochmal Applaus für Tobias, bitte. 271 00:26:55,820 --> 00:27:01,520 *Applaus* Tobias: Vielen Dank. 272 00:27:01,520 --> 00:27:07,394 *Abspannmusik* 273 00:27:07,394 --> 00:27:24,409 Untertitel erstellt von c3subtitles.de im Jahr 2019. Mach mit und hilf uns!