We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Kubernetes 101

00:00

Formal Metadata

Title
Kubernetes 101
Subtitle
From 0 to K8s
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Kubernetes hat sich als Standard für die Orchestrierung von Docker-Containern etabliert und den Kampf gegen Swarm gewonnen. Der große Vorteil von Kubernetes als Container Orchestrierungswerkzeug ist die Verbesserung der Verfügbarkeit und Stabilität von verteilten Anwendungen durch die dynamische Verteilung der Container. Beginnen werden wir beim Einstieg in die Container Welt mit der Erläuterung verschiedener Grundbegriffe. Docker ist ein Containerbasiertes System, welches weitere Ebenen der Abstraktion im Vergleich zu virtuellen Maschinen zur Verfügung stellt. In Containern läuft jedoch nicht mehr die komplette OS Umgebung, sondern nur die für die Ausführung von Applikationen benötigten Daten. Container bestehten aus einer Reihe von Layern. Wie diese zustande kommen ist Teil eines Dockerfile, welches wir besprechen werden. Basierend hierauf steigen wir in die Kubernetes Welt ein. Kubernets hat sich als Standard für die Orchestrierung von Docker-Containern etabliert. Zuerst werden wir dort die häufig verwendeten Objekte kennen lernen und wie diese zusammenarbeiten: 1. Pods 2. Deployments 3. Services 4. Secrets/Configmaps 5. PVC/PV Die für den Betrieb eines Kubernetes Clusters benötigten Komponenten und deren Verteilung werden anschließend vorgestellt. Als einen besonderen Punkt wenden wir uns dem Thema HA im Cluster zu und versuchen Single Points of Failures im Cluster zu vermeiden. Sicherheitsaspekte spielen Im Bereich Enterprise eine wichtige Rolle. Hierzu werden wir uns RBAC, Namespaces und Isolated Pods anschauen. Nach dem theoretischen Teil analysieren wir, wie wir eine Anwendung in unser Cluster deployen können und diesen Deploymentprozess nachverfolgen und debuggen können. Hierbei werden wir sowohl die Kubernetes CLI als auch das Kubernetes Dashboard kennen lernen. Als Start werden wir das Tool Minikube nutzen, welches auf einem lokalen Rechner ein Single-Node Kubernetes deployed, was für die Entwicklung von Anwendungen ein optimales Spielfeld bietet. Weitere Themen werden der Package Manager Helm, die Container-Plattform OpenShift und Deployment Pipelines bilden, welche wir schon im praktischen Einsatz haben. Als kleines Schmankerl bietet sich im letzten Teil des Talks an über das Thema Monitoring von Kubernetes zu referrieren. Der Talk wird sich maßgeblich auf das Verständnis der Architektur und deren Komponenten fokussieren. Es werden Möglichkeiten und Tools aufgezeigt welche das Setup eines Kubernetes Clusters maßgeblich vereinfach können, ohne im Detail diese während des Workshops auszuführen.
15
Thumbnail
1:16:56
20
Thumbnail
59:24
23
Thumbnail
10:02
48
Thumbnail
50:08
56
76
Thumbnail
12:05
Service (economics)WEBZahlCluster analysisIP addressNoten <Programm>Router (computing)XMLUMLLecture/Conference
DemosceneVirtual machineNoten <Programm>Object (grammar)JSONXMLUML
OpenVZFreeBSDLINUXGoogleOperator (mathematics)Run-time systemGraphical user interfaceBorder Gateway ProtocolLaptopComponent-based software engineeringVolumeNoten <Programm>Lösung <Mathematik>Exploratory data analysisBefehlsprozessorProcess (computing)Computer animation
VAX/VMSNoten <Programm>Atomic nucleusVirtual machineUpdate
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
Version <Informatik>Installable File SystemMainframe computerLecture/ConferenceMeeting/InterviewXMLUML
Installable File SystemJDKMobile appChain ruleXMLProgram flowchart
Installable File SystemProviderFlow separationLINUXBefehlsprozessorExt functorOmega <Programm>Run-time systemPlug-in (computing)NFSIP addressSAP <Marke>FRAMEWORK <Programm>Mobile appMainframe computerDatabaseXMLUML
Noten <Programm>Computer animation
Open sourceNoten <Programm>Run-time systemXML
Limit (category theory)Run-time systemConfiguration spaceWeb pageWEBLecture/ConferenceXML
Block (periodic table)NFSSCSISoftware repositoryECCE <Programm>Social classSet (mathematics)Noten <Programm>Computer animationXML
Electronic data processingInternetdienstCluster analysisSelektorVersion <Informatik>Noten <Programm>InformationService (economics)Lecture/ConferenceXML
Kubuntu <Programm>Web pageProgram flowchart
Service (economics)SSLCluster analysisProxy serverNoten <Programm>Cluster analysisComputer animationXML
Kubuntu <Programm>Cluster analysisRun-time systemXML
Rollenbasierte ZugriffskontrolleService (economics)APIMilitary operationIP addressCluster analysisLecture/ConferenceXML
Cluster analysisSet (mathematics)
Cluster analysisSSLProgram flowchartComputer animation
Open sourceIBMWindows AzureVersion <Informatik>Error messageThomas BayesInternet service providerLecture/ConferenceXML
Black boxInstanz <Informatik>Lecture/Conference
Black boxThomas KuhnLecture/Conference
Black boxOpen sourceHypercubeFunktionalitätComputer hardwareLecture/ConferenceMeeting/Interview
Open sourceXMLLecture/Conference
Service (economics)Matrix (mathematics)ERNA <Programm>Cluster analysisSSLPoint cloudHypercubeStatistikerFRAMEWORK <Programm>XML
Lecture/Conference
Flock (web browser)ACIDInternetdienstDemosceneLimit (category theory)MUSE <Lernprogramm>Computer animation
9 (number)Turbo-CodeDemosceneMono-FrameworkMUSE <Lernprogramm>Limit (category theory)INGA <Programm>Flock (web browser)WebsiteComa BerenicesThomas KuhnEnterprise architectureCodeSource codeComputer animationXML
MUSE <Lernprogramm>Coma BerenicesMenu (computing)Gastropod shellTurbo-CodeDemosceneFlock (web browser)Limit (category theory)MALAGA <Programm>Mono-FrameworkComputer animation
Flock (web browser)DemosceneMUSE <Lernprogramm>Mono-FrameworkJDFCLOU <Programm>Temporal logicService (economics)Thomas KuhnMaxima and minimaTOUR <Programm>NP-completeComputer animationSource code
SummationMaxima and minimaVacuumCASA <Programm>Enterprise architectureCodeGraphical user interfaceComputer animationLecture/Conference
openSUSEXMLComputer animation
Transcript: German(auto-generated)
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
normales Netzwerk und musst die Anfragen quasi, da musst du quasi die Anfragen an die physischen Maschinen deines Clusters weiterleiten.
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
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
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.
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
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.
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
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.
Ü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.
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.
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.
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
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.
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.
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.
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
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,
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,
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,
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
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.
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,
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
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
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.
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.
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.
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.
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.
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,
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
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.
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.
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.