Kubernetes 101
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Subtitle |
| |
Title of Series | ||
Number of Parts | 94 | |
Author | ||
License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/45621 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
FrOSCon 201956 / 94
7
10
12
14
15
16
17
20
22
23
26
27
28
29
30
31
32
33
36
37
38
39
41
44
45
48
52
53
55
56
57
58
60
61
62
64
66
67
74
76
77
78
79
81
83
84
93
00:00
Service (economics)WEBZahlCluster analysisIP addressNoten <Programm>Router (computing)XMLUMLLecture/Conference
01:34
DemosceneVirtual machineNoten <Programm>Object (grammar)JSONXMLUML
02:34
OpenVZFreeBSDLINUXGoogleOperator (mathematics)Run-time systemGraphical user interfaceBorder Gateway ProtocolLaptopComponent-based software engineeringVolumeNoten <Programm>Lösung <Mathematik>Exploratory data analysisBefehlsprozessorProcess (computing)Computer animation
07:02
VAX/VMSNoten <Programm>Atomic nucleusVirtual machineUpdate
08:17
EmulationBIOSComputer hardwareFlow separationLocal ringWindows RegistrySpoke-hub distribution paradigmDemosceneInternetRollback (data management)Variable (mathematics)Service (economics)Moment (mathematics)Direction (geometry)Web pageWindows RegistryEmulationVirtual machineHard disk driveMobile appMainframe computerInstanz <Informatik>XML
14:23
Version <Informatik>Installable File SystemMainframe computerLecture/ConferenceMeeting/InterviewXMLUML
15:19
Installable File SystemJDKMobile appChain ruleXMLProgram flowchart
18:03
Installable File SystemProviderFlow separationLINUXBefehlsprozessorExt functorOmega <Programm>Run-time systemPlug-in (computing)NFSIP addressSAP <Marke>FRAMEWORK <Programm>Mobile appMainframe computerDatabaseXMLUML
25:24
Noten <Programm>Computer animation
26:22
Open sourceNoten <Programm>Run-time systemXML
30:07
Limit (category theory)Run-time systemConfiguration spaceWeb pageWEBLecture/ConferenceXML
32:54
Block (periodic table)NFSSCSISoftware repositoryECCE <Programm>Social classSet (mathematics)Noten <Programm>Computer animationXML
35:37
Electronic data processingInternetdienstCluster analysisSelektorVersion <Informatik>Noten <Programm>InformationService (economics)Lecture/ConferenceXML
41:18
Kubuntu <Programm>Web pageProgram flowchart
42:16
Service (economics)SSLCluster analysisProxy serverNoten <Programm>Cluster analysisComputer animationXML
43:30
Kubuntu <Programm>Cluster analysisRun-time systemXML
44:41
Rollenbasierte ZugriffskontrolleService (economics)APIMilitary operationIP addressCluster analysisLecture/ConferenceXML
45:54
Cluster analysisSet (mathematics)
47:26
Cluster analysisSSLProgram flowchartComputer animation
48:49
Open sourceIBMWindows AzureVersion <Informatik>Error messageThomas BayesInternet service providerLecture/ConferenceXML
50:52
Black boxInstanz <Informatik>Lecture/Conference
52:14
Black boxThomas KuhnLecture/Conference
53:27
Black boxOpen sourceHypercubeFunktionalitätComputer hardwareLecture/ConferenceMeeting/Interview
54:42
Open sourceXMLLecture/Conference
56:32
Service (economics)Matrix (mathematics)ERNA <Programm>Cluster analysisSSLPoint cloudHypercubeStatistikerFRAMEWORK <Programm>XML
59:15
Lecture/Conference
01:04:25
Flock (web browser)ACIDInternetdienstDemosceneLimit (category theory)MUSE <Lernprogramm>Computer animation
01:06:36
9 (number)Turbo-CodeDemosceneMono-FrameworkMUSE <Lernprogramm>Limit (category theory)INGA <Programm>Flock (web browser)WebsiteComa BerenicesThomas KuhnEnterprise architectureCodeSource codeComputer animationXML
01:07:36
MUSE <Lernprogramm>Coma BerenicesMenu (computing)Gastropod shellTurbo-CodeDemosceneFlock (web browser)Limit (category theory)MALAGA <Programm>Mono-FrameworkComputer animation
01:08:35
Flock (web browser)DemosceneMUSE <Lernprogramm>Mono-FrameworkJDFCLOU <Programm>Temporal logicService (economics)Thomas KuhnMaxima and minimaTOUR <Programm>NP-completeComputer animationSource code
01:09:35
SummationMaxima and minimaVacuumCASA <Programm>Enterprise architectureCodeGraphical user interfaceComputer animationLecture/Conference
01:11:42
openSUSEXMLComputer animation
Transcript: German(auto-generated)
00:00
Und dann hat man den Ingress, also der Ingress leitet quasi die Anfragen an die Services weiter. Dann ist aber auch noch, du hast die physischen Maschinen und da brauchst du quasi dein
00:23
normales Netzwerk und musst die Anfragen quasi, da musst du quasi die Anfragen an die physischen Maschinen deines Clusters weiterleiten.
00:42
Korrekt. Ja, also wie läuft das, ich habe eine IP-Adresse für meinen Service, muss ich denn dann an eine bestimmte Maschine weiterleiten oder wie lange funktioniert das? Also sehr beliebt an der Stelle finde ich den sogenannten Begriff der Floating-IP. Floating-IP ist quasi eine IP, die ich zwischen Maschinen scheren kann und in dieser Floating-IP
01:05
kann ich ja beispielsweise, wenn ich einen intelligenten Notbalancer schon davor habe oder einen intelligenten Router davor habe, kann ich ja quasi checken, sind meine Notes dahinter erreichbar. Und diese Service-IP ist ja quasi nur nach außen hin, ja, so dieser DNS-Eintrag hier
01:28
google.de erreiste unter 8888, was dann dahinter passiert, ob ich dann diese IP durch meinen Router dann auf die Note weiterleite oder in der Note quasi diese Floating-IP verpasse, gibt es beide Möglichkeiten.
01:43
Aber das macht da nicht mehr Kubernetes oder also die Floating-IP? Die Floating-IP kann Kubernetes selber verwalten, das ist ja das Schöne, ich kann da ja diverse Objekte definieren, das habe ich beispielsweise auch selber gemacht. Ich habe einen Container, der einfach nur guckt, sind alle meine Notes erreichbar
02:03
und wenn meine Notes erreichbar sind, guckt er, was haben die in diesem Monat schon an Treffik gemacht, weil ich habe ja bei jedem Cloud-Provider normalerweise ein gewisses Freilimit und danach muss ich bezahlen und wenn ich dann über eine gewisse Grenze muss ich noch mehr bezahlen oder dann mein Note wird beispielsweise abgeschaltet und der schiebt die dann zwischen die Notes hin und her.
02:23
Ja, danke. Noch zusätzlich, also für die einfache Konfiguration, du hast einen Ingress-Controller, der hat eine IP, das ist ein Layer-7-Load-Balancer, da leitest du alles. Du hast eine IP, wie du die verteilst, BGP oder was auch immer, die Cloud-Provider
02:43
haben dafür auch eine API, dass man diese Cloud-Public-IP direkt automatisch holt und du hast einen Ingress-Controller, da läuft alles an. Solange du nicht mit Note-Ports arbeitest, läuft da alles auf einer IP an und darauf kannst du dich dann von Kubernetes weiter verteilen.
03:01
Übrigens, die Ingress-Controller sind genauso austauschbar, wie wir von Operators gesprochen haben, das ist dieses Plugin-System, was der Kubernetes jetzt wird, dass man jede Komponente dann austauschen kann.
03:21
Also für Ingress-Controller kann man verschiedene Engine, X, A, Proxy, Traffic nutzen und die kann man dann auch austauschen. Und das passiert jetzt für viele Kubernetes-Komponenten. Also Kubernetes ist ja an der meisten Stellen einfach eine Abstraktion von, wie wir gelernt haben, von Storage, wir sprechen Storage an und von diversen anderen Dingen.
03:45
Und ihr sagt einfach nur von außen hier, bitte sorg dafür, dass der Portal dreimal läuft und dem Rest will ich mich nicht kümmern. Weitere Fragen? Dann zeig mal was.
04:00
Wir haben ja Minikube schon erwähnt, ja? Also Minikube ist ein Kubernetes-Cluster mit einer Note, den ihr lokal laufen lassen könnt auf eurem Laptop. Könnt ihr halt eurem Entwickler in die Hand rücken und sagen, hier entwickeln wir erstmal einen Minikube und wenn das alles in Minikube laufen hast, danach können wir mal sprechen, ob wir das Ganze mal bei uns
04:21
dann wirklich in der Produktionsumgebung mal testweise laufen lassen. Wie ich schon erwähnt, Minikube ist ein Single-Cluster, deswegen haben wir hier im Bereich der Notes auch nur eine Note. Die macht quasi alles, die macht ETCD, die macht Kubernetes-Buster, die macht auch die Kubernetes-Note selber.
04:40
Im Bereich Persistent Volumes trägst Minikube ein bisschen. Wir sehen ja, wir haben hier gewisse Persistent Volumes. Das ist aber nichts anderes, wie wir jetzt in der Storage-Klasse sehen, als ein Minikube-Postpass. Das heißt, er montet einfach eine Fahrt von der VM in die Kubernetes-Container rein.
05:03
Was haben wir noch? Wir können, haben wir vorhin schon gelernt haben, die Kubernetes-Namespace, da haben wir ein bisschen was. Und da würden wir uns jetzt einfach mal angucken. Ich habe da einfach dieses Minikube von GitLab, dieses Helmschad, deployed und schauen uns einfach mal an, was wir da so an Ressourcen finden.
05:23
Sehen wir so ein bisschen Deployments, wir sehen Jobs, wir haben Pods, wir haben Replica-Sets, wir haben Stateful-Sets und wir haben Ingresser. Das heißt, wenn ich jetzt mal in die Deployments reingucke, sehen wir hier jeweils, wie viele Pods wir gewünscht haben
05:41
und wie viele laufen. Das heißt, in diesem Fall sehen wir jetzt überall die Anzahl, die wir gewünscht haben, ist auch erfüllt. Also ist alles gut gelaufen. Dann, wenn wir dann in die Pod-Ansicht selber gucken, sehen wir die einzelnen Pods, sehen wo die laufen, welchen Status die haben. Hier sehen wir zum Beispiel ein GitLab-Menu,
06:00
Create Buckets, sehen Terminated, Completed. Dieser Pod hat da einfach die Aufgabe, irgendwas zu erstellen und danach soll er sterben. Das heißt, wenn ihr beispielsweise in eurer Umgebung sagt, hier bevor der Container starten kann, da muss ein S3-Bucket da sein, könnte man dann wunderbar einen Container schreiben, der sorgt einfach beim hochfahren,
06:20
ist das S3-Bucket da? Wenn ja, okay, sterbe ich sofort, ist nicht da, leg es gerade an und leg mich danach schlafen. Und wir haben natürlich auch die Möglichkeit über dieses Symbol uns die Kubernetes-Logs oder die Pod-Logs anzuschauen. Das, was man hier in der GUI sieht, kann man auch alles mit der kubectl machen,
06:44
sage ich mal, da verzichte ich an dieser Stelle momentan drauf, im Rahmen dieser Präsentation ein bisschen mehr Zeitraum befahren zu haben. Ich wollte nicht mal was zeigen. Und zwar haben wir unser GitLab Unicorn. Und GitLab Unicorn ist nichts anderes als quasi
07:04
grafische Oberfläche, nenne ich es mal, von GitLab. Das heißt, wenn wir jetzt auf unseren GitLab Container mal gehen, sehen wir natürlich, ist ein Self-Sign-Certificate. Das Self-Sign-Certificate, können wir uns sogar anschauen, ist nicht ein Secret.
07:21
Und wenn wir das dann, das Self-Sign-Certifikat akzeptieren, hätten wir jetzt die Möglichkeit, uns in GitLab einzuloggen. Das will ich einfach mal zeigen, was passiert, wenn jetzt dieses Deployment stirbt oder wenn ich jetzt beispielsweise sage, von diesem Deployment will ich nicht mehr zwei haben, sondern ich will das jetzt einfach mal weghaben,
07:42
weil das belastet meine Note zu sehr und ich will einfach mal ein bisschen speicherfrei haben. Dann kann ich das sogenannte Scale anwenden. Und wie wir vorhin ja gelernt haben, ist ein Deployment ist nichts anderes als ein deklarativ oder gibt uns
08:03
die Möglichkeit, deklarative Updates zu fahren. Das heißt, ich sage jetzt einfach mal Null. Und wenn wir dann nochmal auf unsere GitLab Seite sehen, sehen wir ein 503, weil wir sprechen zwar weiterhin über
08:22
unseren Ingress, den Service an, aber der Service hat natürlich keine healthy Pots im Hintergrund und sagt deswegen natürlich 503. Und wie wir alle wissen, alles, was 500 ist, sind Fehler im Backend. Wenn wir das Ganze jetzt dann wieder hoch skalieren, können wir natürlich genau in die andere Richtung auch machen.
08:41
Jetzt sagen wir da zwei. Da einen kurzen Moment. Kannst du zeigen, wie die starten? So genau. Und dann sehen wir hier im Bereich Pots. Da startet irgendwas.
09:01
Dann können wir uns auch die Logs angucken. Jetzt ist er gestartet und wenn wir jetzt wieder auf die Webseite gehen, dauert noch ein kurzer Moment anscheinend. Ja, Live-Nest-Probe. Live-Nest-Probe, da muss auch... Oh, Readiness-Probe fehlt.
09:24
Schade. Natürlich, das war doch klar Demo. Demo. Ich dachte schon, bisher läuft so gut irgendwas. Health Check Connection Refuse. Ich glaube, weil wir momentan kein Internet haben.
09:40
Ah ja, hier ist es mit dem Internet. Der checkt halt, ob... Okay, habt ihr noch weitere Fragen? Wir haben noch ein bisschen Zeit. Genau, ein bisschen noch in der grafischen Oberfläche kann ich euch noch was zeigen, wenn Fragen dazu sind. Sonstige Fragen.
10:01
Alternativ kann ich euch ein bisschen was zu Helm erzählen. Ich glaube, jeder, der Kubernetes gehört hat, hat schon von Helm gehört. Also Helm ist der Package Manager. Helm ist der Package Manager von Kubernetes oder für Kubernetes. Das heißt, diese Objekte, die wir erstellt haben, ConfigMaps, Deployments,
10:23
Secrets, Services usw. Das sind YAML-Dateien, die man dem Kubernetes füttert. Kubernetes erstellt daraus Ressourcen und deploit Pots usw. Das heißt, Helm ist nichts anderes
10:41
als ein Templating Engine dafür. Das war es, so einfach. Man steht da Variablen rein, man hat eine Values-YAML, wo die Variablen ersetzt werden, sodass man dieses Deployment in Dev, in Stage und in Production benutzen kann, aber halt mit anderen Variablen da drinnen.
11:00
Da ist einfach ein Golang Templating Engine dahinter und er ersetzt halt die Variablen und pusht das automatisch noch zu Kubernetes. Da gibt es noch ein paar diverse Features wie Rollbacks, dass er die letzte Änderung speichert, dass man Rollback machen kann, aber im einfachsten ist es einfach ein Templating Engine.
11:26
Okay, wenn keine Fragen da sind, dann beenden wir. Vielen Dank für die Teilnahme. Ich hoffe, das hat euch was gebracht. Ich stehe natürlich für Diskussionen oder Anmerkungen gerne zur Verfügung.