Glossar on ayedo

Software Defined Networking

Tue, 05 Mar 2024 11:30:36 +0000

“Software Defined Networking” (SDN) ist ein Ansatz zur Netzwerkverwaltung, der die Steuerung des Netzwerkverkehrs von den physischen Geräten (wie Switches und Router) entkoppelt und in eine Softwareebene verlagert. Dies ermöglicht eine zentralisierte Verwaltung des Netzwerks durch abstrahierte Kontrollebenen, was zu einer höheren Flexibilität, einfacherer Skalierbarkeit und besserer Anpassungsfähigkeit an sich ändernde Anforderungen führt. SDN vereinfacht die Netzwerkkonfiguration und -optimierung, indem es Programmierschnittstellen (APIs) für die Entwicklung von Anwendungen bereitstellt, die Netzwerkressourcen intelligent verwalten können.

Add-ons

Sun, 03 Mar 2024 11:30:36 +0000

Add-ons (Erweiterungen) sind Ressourcen, die die Funktionalität von Kubernetes erweitern. Das Manual Installation von Erweiterungen erklärt ausführlicher, wie Sie Erweiterungen in Ihrem Cluster verwenden können, und listet einige beliebte Erweiterungen auf.

Kubernetes ist eine leistungsstarke Plattform für die Verwaltung von Containeranwendungen und bietet eine Vielzahl von Funktionen und Möglichkeiten. Mit Hilfe von Add-ons können Sie diese Funktionalitäten weiter anpassen und erweitern, um den Anforderungen Ihrer spezifischen Anwendung gerecht zu werden. Von Überwachungswerkzeugen bis hin zu Lastausgleichslösungen bieten Add-ons eine breite Palette von Erweiterungen, die Ihre Kubernetes-Umgebung noch leistungsfähiger machen können.

Admission Controller

Sun, 03 Mar 2024 11:30:36 +0000

Ein Admission Controller oder auch Zulassungscontroller ist ein Code-Abschnitt, der Anfragen an den Kubernetes-API-Server abfängt, bevor das Objekt dauerhaft gespeichert wird. Zulassungscontroller sind für den Kubernetes-API-Server konfigurierbar und können “validierend”, “verändernd” oder beides sein. Jeder Zulassungscontroller kann die Anfrage ablehnen. Verändernde Controller können die Objekte, die sie zulassen, ändern; validierende Controller dürfen dies nicht.

Der Admission Controller spielt eine wichtige Rolle im Kubernetes-Ökosystem, indem er sicherstellt, dass nur gültige und autorisierte Anfragen verarbeitet und akzeptiert werden. Durch die Interzeption von Anfragen vor ihrer dauerhaften Speicherung ermöglicht der Admission Controller die Implementierung von Sicherheitsrichtlinien, Validierungen und anderen Kontrollmechanismen auf Cluster-Ebene.

Affinity

Sun, 03 Mar 2024 11:30:36 +0000

Affinity oder auch Affinität ist in Kubernetes eine Reihe von Regeln, die dem Scheduler Hinweise darauf geben, wo Pods platziert werden sollen.

Es gibt zwei Arten von Affinität:

Knotenaffinität

Pod-zu-Pod-Affinität Die Regeln werden mithilfe der Kubernetes-Labels definiert und in den Pods angegeben. Sie können entweder erforderlich oder bevorzugt sein, je nachdem, wie streng Sie möchten, dass der Scheduler sie durchsetzt.

Die Knotenaffinität ermöglicht es Ihnen, die Pods auf bestimmten Nodeaim Cluster zu platzieren, basierend auf den von Ihnen festgelegten Regeln. Dies kann nützlich sein, um Ressourcenanforderungen zu erfüllen oder um sicherzustellen, dass bestimmte Pods in der Nähe bestimmter Datenquellen oder Dienste platziert werden.

Aggregation Layer

Sun, 03 Mar 2024 11:30:36 +0000

Die Aggregations-Schicht ermöglicht es Ihnen, zusätzliche APIs im Kubernetes-Cluster zu installieren.

Wenn Sie den Kubernetes-API-Server so konfiguriert haben, dass er zusätzliche APIs unterstützt, können Sie APIService-Objekte hinzufügen, um einen URL-Pfad im Kubernetes-API “anzufragen”.

Die Aggregations-Schicht ist ein leistungsstarkes Werkzeug, das es Ihnen ermöglicht, benutzerdefinierte APIs oder APIs von Drittanbietern nahtlos in Ihren Kubernetes-Cluster zu integrieren. Indem Sie APIService-Objekte erstellen, können Sie die APIs registrieren und bereitstellen, und der Kubernetes-API-Server behandelt sie wie jede andere native API.

Annotation

Sun, 03 Mar 2024 11:30:36 +0000

Eine Annotation ist ein Schlüssel-Wert-Paar, das verwendet wird, um beliebige nicht-identifizierende Metadaten an Objekte anzuhängen.

Die Metadaten in einer Annotation können klein oder groß, strukturiert oder unstrukturiert sein und Zeichen enthalten, die von Labels nicht erlaubt sind. Clients wie Tools und Bibliotheken können diese Metadaten abrufen.

Annotationen sind nützlich, um zusätzliche Informationen oder Kontext zu Objekten in einem Kubernetes-Cluster hinzuzufügen. Sie bieten eine flexible Möglichkeit, relevante Details zu speichern, die nicht in Labels passen oder spezielle Formatierungsanforderungen haben.

API Group

Sun, 03 Mar 2024 11:30:36 +0000

Die API-Gruppe in Kubernetes ist ein grundlegendes Konzept, das die Struktur und Organisation der Kubernetes-API maßgeblich beeinflusst. Sie ermöglicht eine logische Gruppierung von verwandten Ressourcen und Funktionen, was die Verwaltung und Erweiterung der Plattform erheblich erleichtert. Eine API-Gruppe definiert eine Sammlung von zusammenhängenden Endpunkten oder Pfaden innerhalb der API, die eine bestimmte Domäne oder eine bestimmte Funktion repräsentieren.

Durch die Möglichkeit, einzelne API-Gruppen sowie spezifische Pfade zu aktivieren oder zu deaktivieren, bietet Kubernetes eine hohe Flexibilität und Anpassungsfähigkeit. Dies ermöglicht es Administratoren, die API-Umgebung ihres Clusters genau auf ihre Anforderungen und Sicherheitsrichtlinien zuzuschneiden. Sie können unerwünschte Pfade deaktivieren oder nur bestimmten Benutzergruppen Zugriff auf bestimmte API-Gruppen gewähren, um die Sicherheit und Kontrolle zu erhöhen.

API Initiated Eviction

Sun, 03 Mar 2024 11:30:36 +0000

API-initiated eviction ist der Prozess, bei dem Sie die Eviction-API verwenden, um ein Eviction-Objekt zu erstellen, das eine kontrollierte Beendigung von Pods auslöst.

Sie können die Beendigung entweder direkt über die Eviction-API anfordern, indem Sie einen Client des kube-apiservers wie den Befehl “kubectl drain” verwenden. Wenn ein Eviction-Objekt erstellt wird, beendet der API-Server den Pod auf eine sanfte Weise.

API-initiierte Beendigungen respektieren Ihre konfigurierten PodDisruptionBudgets und terminationGracePeriodSeconds.

API-initiierte Beendigungen unterscheiden sich von Node-Pressure-Eviction. Bei Node-Pressure-Eviction wird ein Pod beendet, weil der Knoten Ressourcenknappheit hat oder aus anderen Gründen nicht mehr in der Lage ist, den Pod auszuführen. Im Gegensatz dazu wird bei API-initiierten Beendigungen die Beendigung explizit durch eine API-Anfrage ausgelöst, die die Beendigung von Pods auf eine kontrollierte und geplante Weise ermöglicht.

API Server

Sun, 03 Mar 2024 11:30:36 +0000

Der API-Server, auch bekannt als kube-apiserver, ist ein wesentlicher Bestandteil der Kubernetes-Steuerungsebene, der die Kubernetes-API freigibt. Der API-Server fungiert als Front-End für die Kubernetes-Steuerungsebene.

Die Hauptimplementierung eines Kubernetes-API-Servers ist der kube-apiserver. Der kube-apiserver ist so konzipiert, dass er horizontal skalierbar ist, das heißt, er skaliert durch Bereitstellung weiterer Instanzen. Sie können mehrere Instanzen des kube-apiserver ausführen und den Datenverkehr zwischen diesen Instanzen ausbalancieren.

Durch die Skalierbarkeit des kube-apiserver können Kubernetes-Cluster problemlos wachsen und die steigenden Anforderungen an die Verarbeitung von API-Anfragen bewältigen. Die horizontale Skalierung ermöglicht eine bessere Lastenverteilung und Ausfallsicherheit, da die Belastung auf mehrere Instanzen verteilt werden kann und Ausfälle einzelner Instanzen den Gesamtbetrieb des Clusters nicht beeinträchtigen.

App Container

Sun, 03 Mar 2024 11:30:36 +0000

App-Container sind die Container in einem Pod, die gestartet werden, nachdem alle Init-Container abgeschlossen wurden.

Ein Init-Container ermöglicht es Ihnen, Initialisierungsdetails zu trennen, die für die Gesamtarbeitslast wichtig sind, und die nicht weiter ausgeführt werden müssen, sobald der Anwendungscontainer gestartet wurde. Wenn ein Pod keine Init-Container konfiguriert hat, sind alle Container in diesem Pod App-Container.

App-Container enthalten die Hauptanwendungen oder Prozesse, die im Pod ausgeführt werden sollen. Sie werden gestartet, nachdem die Initialisierungsaufgaben der Init-Container abgeschlossen sind. App-Container sind in der Regel für die eigentliche Ausführung der Anwendungslogik oder -services zuständig und bleiben während der Lebensdauer des Pods aktiv.

Application Architect

Sun, 03 Mar 2024 11:30:36 +0000

Ein Application Architect oder auch Anwendungsarchitekt ist eine Person, die für das hochrangige Design einer Anwendung verantwortlich ist.

Ein Architekt stellt sicher, dass die Implementierung einer Anwendung es ihr ermöglicht, auf skalierbare und wartbare Weise mit ihren umgebenden Komponenten zu interagieren. Zu den umgebenden Komponenten gehören Datenbanken, Logging-Infrastrukturen und andere Mikroservices.

Die Rolle eines Anwendungsarchitekten umfasst die Gestaltung der Struktur und des Zusammenspiels verschiedener Module und Komponenten innerhalb einer Anwendung. Sie müssen sicherstellen, dass die Architektur der Anwendung die Leistungsanforderungen erfüllt, zukunftssicher ist und sich den sich ändernden Anforderungen und Bedingungen anpassen kann.

Application Developer

Sun, 03 Mar 2024 11:30:36 +0000

Ein Application Developer oder auch Anwendungsentwickler ist eine Person, die Anwendungen schreibt, die in einem Kubernetes-Cluster ausgeführt werden.

Ein Anwendungsentwickler konzentriert sich auf einen Teil einer Anwendung. Das Ausmaß ihrer Aufmerksamkeit kann erheblich variieren, je nachdem, ob sie sich auf eine kleine, spezifische Funktion oder auf die Entwicklung und Wartung eines umfangreicheren Teils der Anwendung konzentrieren.

Die Aufgaben eines Anwendungsentwicklers umfassen typischerweise das Schreiben von Code, das Testen und Debuggen von Software, das Implementieren neuer Funktionen und das Warten und Aktualisieren bestehender Anwendungen. Sie arbeiten oft eng mit anderen Entwicklern, Testern und Projektmanagern zusammen, um die Anwendungsentwicklung effizient zu gestalten und sicherzustellen, dass die erstellten Lösungen den Anforderungen und Standards entsprechen.

Applications

Sun, 03 Mar 2024 11:30:36 +0000

Die Anwendungsebene ist die Schicht, in der verschiedene containerisierte Anwendungen ausgeführt werden. In Kubernetes werden Anwendungen typischerweise als Pods repräsentiert, die Container enthalten, die spezifische Anwendungsfunktionen ausführen. Diese Container können Teil derselben oder verschiedener Workloads sein, die von Kubernetes-Objekten wie Deployments, StatefulSets oder Jobs verwaltet werden. Die Anwendungsebene bildet die oberste Schicht der Kubernetes-Architektur und ist der Bereich, in dem Endbenutzerinteraktionen stattfinden und Geschäftsanforderungen erfüllt werden.

Link zum offiziellen Glossar

Approver

Sun, 03 Mar 2024 11:30:36 +0000

Ein Approver ist eine wichtige Rolle im Entwicklungsprozess von Kubernetes, da sie die Verantwortung für die Überprüfung und Genehmigung von Codebeiträgen tragen. Während die Codeprüfung dazu dient, die Qualität und Korrektheit des Codes zu gewährleisten, geht es bei der Genehmigung um die umfassende Akzeptanz eines Beitrags. Dies bedeutet, dass ein Approver nicht nur den Code selbst überprüft, sondern auch sicherstellen muss, dass der Beitrag rückwärts- und vorwärtskompatibel ist, API- und Flaggenkonventionen einhält und keine subtilen Leistungs- oder Korrektheitsprobleme verursacht. Darüber hinaus müssen Approver die Wechselwirkungen des neuen Codes mit anderen Teilen des Systems berücksichtigen und sicherstellen, dass der Beitrag reibungslos in das Gesamtsystem integriert werden kann.

cAdvisor

Sun, 03 Mar 2024 11:30:36 +0000

cAdvisor (Container Advisor) ist ein unverzichtbares Werkzeug für die Verwaltung von Containern in Kubernetes-Clustern und anderen Containerumgebungen. Es bietet den Benutzern ein detailliertes Verständnis für die Ressourcennutzung und Leistungsmerkmale ihrer laufenden Container.

Als laufender Daemon spielt cAdvisor eine entscheidende Rolle, indem es kontinuierlich Informationen über laufende Container sammelt, aggregiert, verarbeitet und exportiert. Für jeden Container werden verschiedene Daten gespeichert, darunter Ressourcenisolationsparameter, historische Ressourcennutzung, Histogramme der vollständigen historischen Ressourcennutzung und Netzwerkstatistiken. Diese umfassenden Informationen ermöglichen es den Benutzern, die Ressourcennutzung ihrer Container zu überwachen, Engpässe zu identifizieren und Engpässe zu beheben.

Certificate

Sun, 03 Mar 2024 11:30:36 +0000

Ein Certificate oder auf deutsch Zertifikat ist eine kryptografisch sichere Datei, die verwendet wird, um den Zugriff auf den Kubernetes-Cluster zu validieren.

Zertifikate ermöglichen es Anwendungen innerhalb eines Kubernetes-Clusters, sicher auf die Kubernetes-API zuzugreifen. Sie dienen dazu, zu überprüfen, ob Clients berechtigt sind, auf die API zuzugreifen.

Die Verwendung von Zertifikaten ist eine bewährte Methode, um die Sicherheit und Integrität von Kommunikationen innerhalb des Kubernetes-Clusters zu gewährleisten. Durch die Verwendung von kryptografisch signierten Zertifikaten können Anwendungen und Benutzer ihre Identität gegenüber dem Kubernetes-API-Server nachweisen und sicherstellen, dass nur autorisierte Parteien auf sensible Cluster-Ressourcen zugreifen können.

cgroup (control group)

Sun, 03 Mar 2024 11:30:36 +0000

cgroup (Control Group) ist eine Gruppe von Linux-Prozessen mit optionaler Ressourcenisolierung, Buchführung und Grenzen. Es handelt sich um ein Merkmal des Linux-Kernels, das die Ressourcennutzung (CPU, Speicher, Festplatten-E/A, Netzwerk) für eine Sammlung von Prozessen begrenzt, Buch führt und isoliert.

cgroup ermöglicht es Administratoren, die Ressourcennutzung von Prozessen auf einem Linux-System effektiv zu kontrollieren und zu verwalten. Indem Ressourcen wie CPU-Zeit, Speicher und E/A-Bandbreite auf Gruppenebene begrenzt werden können, können Administratoren sicherstellen, dass kritische Systemressourcen fair und effizient zwischen verschiedenen Prozessen oder Gruppen von Prozessen aufgeteilt werden.

CIDR

Sun, 03 Mar 2024 11:30:36 +0000

CIDR (Classless Inter-Domain Routing) ist eine Notation zur Beschreibung von IP-Adressblöcken und wird in verschiedenen Netzwerkkonfigurationen stark verwendet.

Im Kontext von Kubernetes wird jedem Node ein Bereich von IP-Adressen über die Startadresse und eine Subnetzmaske mit CIDR zugewiesen. Dadurch können Nodes jedem Pod eine eindeutige IP-Adresse zuweisen. Obwohl CIDR ursprünglich ein Konzept für IPv4 war, wurde es auch auf IPv6 erweitert.

CIDR ermöglicht eine effiziente Verwaltung von IP-Adressbereichen, indem es eine flexible Möglichkeit bietet, Adressblöcke zu definieren und zuzuweisen. Durch die Verwendung von CIDR können Administratoren IP-Adressen logisch gruppieren und die Netzwerkressourcen effizienter nutzen.

Cloud Controller Manager

Sun, 03 Mar 2024 11:30:36 +0000

Der Cloud Controller Manager ist eine essenzielle Komponente der Kubernetes-Steuerungsebene, die spezifische Steuerlogik für cloudbasierte Infrastrukturen enthält. Seine Hauptaufgabe besteht darin, eine Schnittstelle zwischen Kubernetes-Clustern und den APIs der Cloud-Anbieter zu schaffen. Durch diese Verbindung ermöglicht der Cloud Controller Manager die nahtlose Integration von Kubernetes mit den verschiedenen Diensten und Funktionen, die von Cloud-Plattformen bereitgestellt werden.

Eine der wichtigsten Funktionen des Cloud Controller Managers besteht darin, die Komponenten zu trennen, die mit der Cloud-Plattform interagieren, von den Komponenten, die ausschließlich mit dem Kubernetes-Cluster interagieren. Dies ermöglicht eine klare Trennung der Verantwortlichkeiten und erhöht die Flexibilität bei der Verwaltung von Kubernetes-Clustern in cloudbasierten Umgebungen.

Cloud Native Computing Foundation (CNCF)

Sun, 03 Mar 2024 11:30:36 +0000

Die Cloud Native Computing Foundation (CNCF) ist eine Organisation, die nachhaltige Ökosysteme aufbaut und eine Community um Projekte fördert, die Container als Teil einer Microservices-Architektur orchestrieren. Kubernetes ist eines der prominentesten Projekte der CNCF und spielt eine zentrale Rolle in der Verwaltung und Bereitstellung von Containern in cloudbasierten Umgebungen.

Als Teil der Linux Foundation ist die CNCF bestrebt, cloudbasiertes Computing allgegenwärtig zu machen. Ihr Ziel ist es, die Entwicklung und Nutzung von Cloud-nativen Technologien zu fördern und Innovationen in diesem Bereich voranzutreiben. Die CNCF unterstützt eine Vielzahl von Projekten und Initiativen, die dazu beitragen, Cloud-natives Computing zu etablieren und zu verbessern.

Cloud Provider

Sun, 03 Mar 2024 11:30:36 +0000

Cloud-Anbieter, auch bekannt als Cloud Service Provider (CSP), sind Unternehmen oder Organisationen, die Cloud-Computing-Plattformen und -Dienste bereitstellen. Diese Dienstleister spielen eine entscheidende Rolle bei der Bereitstellung von Infrastruktur, Plattformen und Diensten, die es Unternehmen ermöglichen, ihre IT-Ressourcen flexibel zu skalieren, effizienter zu nutzen und kostengünstiger zu betreiben.

Cloud-Anbieter bieten eine Vielzahl von Diensten an, darunter verwaltete Infrastruktur (Infrastructure as a Service, IaaS). Bei verwalteter Infrastruktur übernimmt der Cloud-Anbieter die Verantwortung für die Bereitstellung und Wartung von Servern, Speicher und Netzwerkinfrastruktur, während Kunden sich auf das Betreiben von Anwendungen und Diensten konzentrieren können, ohne sich um die zugrunde liegende Hardware kümmern zu müssen. Dies ermöglicht es Unternehmen, schnell skalierbare und hochverfügbare Lösungen bereitzustellen, ohne umfangreiche Investitionen in Hardware tätigen zu müssen.

Cluster

Sun, 03 Mar 2024 11:30:36 +0000

Ein Cluster ist eine Gruppe von Arbeitsmaschinen, die als Node bezeichnet werden und containerisierte Anwendungen ausführen. Jeder Cluster hat mindestens einen Arbeitsknoten.

Die Arbeitsknoten(Worker Nodes) hosten die Pods, die die Komponenten der Anwendungs-Workload sind. Der Steuerungsebene (Control Plane) verwaltet die Arbeitsknoten und die Pods im Cluster. In Produktionsumgebungen läuft die Steuerungsebene in der Regel über mehrere Computer, und ein Cluster läuft normalerweise auf mehreren Nodes, was eine Fehlerverträglichkeit und hohe Verfügbarkeit gewährleistet.

Cluster sind eine grundlegende Infrastrukturkomponente für die Bereitstellung und Verwaltung von containerisierten Anwendungen. Sie ermöglichen es Organisationen, Ressourcen effizient zu nutzen, die Skalierbarkeit zu verbessern und die Ausfallsicherheit ihrer Anwendungen zu erhöhen.

Cluster Architect

Sun, 03 Mar 2024 11:30:36 +0000

Ein Cluster-Architekt ist eine Person, die Infrastrukturen entwirft, die ein oder mehrere Kubernetes-Cluster umfassen.

Cluster-Architekten spielen eine entscheidende Rolle bei der Gestaltung von Infrastrukturen, die Kubernetes-Cluster umfassen. Sie sind dafür verantwortlich, die Architektur der Cluster zu entwerfen, um sicherzustellen, dass sie den Anforderungen der Anwendungen und Geschäftsprozesse gerecht werden. Dies umfasst die Planung und Gestaltung von Ressourcen wie Arbeitsknoten, Speicher, Netzwerke und Sicherheitsrichtlinien.

Ein wesentlicher Aspekt der Rolle eines Cluster-Architekten besteht darin, bewährte Verfahren für verteilte Systeme anzuwenden. Dazu gehören die Gewährleistung hoher Verfügbarkeit, Skalierbarkeit, Zuverlässigkeit und Sicherheit der Cluster. Cluster-Architekten müssen sich mit Technologien und Praktiken vertraut machen, die für die Verwaltung von Kubernetes-Clustern in Produktionsumgebungen relevant sind, einschließlich der Implementierung von Failover-Mechanismen, Lastenausgleich und Sicherheitsmaßnahmen.

Cluster Infrastructure

Sun, 03 Mar 2024 11:30:36 +0000

Die Infrastrukturebene stellt und pflegt virtuelle Maschinen (VMs), Netzwerke, Sicherheitsgruppen und andere Ressourcen bereit.

Die Infrastrukturebene bildet das Fundament für die Bereitstellung von Kubernetes-Clustern und bietet die grundlegenden Ressourcen, die für den Betrieb der Cluster erforderlich sind. Dazu gehören VMs, auf denen die Arbeitsknoten und Steuerungsebenen des Clusters ausgeführt werden, sowie das Netzwerk, das die Kommunikation zwischen den verschiedenen Komponenten im Cluster ermöglicht.

Die Bereitstellung und Wartung von VMs ist ein wichtiger Aspekt der Infrastrukturebene. VMs dienen als zugrunde liegende Rechenressource für die Ausführung von Containern und Pods im Kubernetes-Cluster. Die Infrastrukturebene ist dafür verantwortlich, sicherzustellen, dass ausreichend VM-Ressourcen vorhanden sind, um die Anwendungs-Workloads zu unterstützen, und dass diese Ressourcen effizient verwaltet und skaliert werden können, um den sich ändernden Anforderungen gerecht zu werden.

Cluster Operator

Sun, 03 Mar 2024 11:30:36 +0000

Ein Cluster Operator ist eine Person, die Cluster konfiguriert, steuert und überwacht.

Die Hauptverantwortung eines Cluster Operators besteht darin, einen Cluster betriebsbereit zu halten. Dies beinhaltet regelmäßige Wartungsarbeiten oder Upgrades, um sicherzustellen, dass der Cluster ordnungsgemäß funktioniert und die Anwendungen und Dienste darauf reibungslos ausgeführt werden können.

Cluster Operators spielen eine entscheidende Rolle bei der Gewährleistung der Verfügbarkeit und Leistungsfähigkeit von Kubernetes-Clustern. Sie überwachen den Zustand des Clusters, erkennen potenzielle Probleme frühzeitig und ergreifen entsprechende Maßnahmen, um Probleme zu beheben und die Stabilität des Clusters sicherzustellen.

Cluster Operatorions

Sun, 03 Mar 2024 11:30:36 +0000

Cluster Operations umfassen die Arbeit, die zur Verwaltung eines Kubernetes-Clusters erforderlich ist: die Verwaltung der täglichen Betriebsabläufe und die Koordination von Upgrades.

Beispiele für Cluster Operations umfassen:

Bereitstellung neuer Nodes zur Skalierung des Clusters: Dies umfasst die Hinzufügung neuer Arbeitsknoten (Worker Nodes) zum Cluster, um die Ressourcenkapazität zu erhöhen und die Arbeitslasten zu verteilen.

Durchführung von Software-Upgrades: Dies beinhaltet das Aktualisieren der Kubernetes-Software sowie anderer beteiligter Komponenten, um Fehlerkorrekturen, neue Funktionen und Sicherheitsverbesserungen zu implementieren.

Code Contributor

Sun, 03 Mar 2024 11:30:36 +0000

Ein Code-Contributor ist eine Person, die Code entwickelt und zur Kubernetes-Open-Source-Codebasis beiträgt. Diese Personen sind aktive Mitglieder der Community, die an einem oder mehreren Special Interest Groups (SIGs) teilnehmen.

Die Rolle eines Code-Contributors ist entscheidend für die kontinuierliche Weiterentwicklung und Verbesserung der Kubernetes-Plattform. Sie arbeiten an der Implementierung neuer Funktionen, der Behebung von Fehlern und der Optimierung der Leistung. Dies kann die Entwicklung von neuen Features, die Überarbeitung bestehender Codes oder die Implementierung von Bugfixes umfassen.

ConfigMap

Sun, 03 Mar 2024 11:30:36 +0000

Eine ConfigMap ist ein äußerst nützliches API-Objekt in Kubernetes, das dazu dient, nicht vertrauliche Konfigurationsdaten in Form von Schlüssel-Wert-Paaren zu speichern. Diese Konfigurationsdaten können dann von Pods verwendet werden, entweder als Umgebungsvariablen, Befehlszeilenargumente oder als Konfigurationsdateien, die in einem Volume gemountet werden.

Die Verwendung einer ConfigMap bietet eine Reihe von Vorteilen. Zunächst ermöglicht sie es, die Konfiguration von Anwendungen von den Container-Images zu entkoppeln. Dies bedeutet, dass Umgebungs-spezifische Konfigurationsdaten wie z.B. URLs von externen Diensten oder benutzerdefinierte Einstellungen nicht hart in den Container-Images kodiert werden müssen. Stattdessen können sie separat in einer ConfigMap gespeichert werden, was die Portabilität und Wiederverwendbarkeit der Container-Images erhöht.

Container

Sun, 03 Mar 2024 11:30:36 +0000

Ein Container ist eine leichtgewichtige und portable Ausführungsumgebung, die eine Anwendung und all ihre Abhängigkeiten in einem isolierten Paket zusammenfasst. Durch die Containerisierung werden Anwendungen von der zugrunde liegenden Infrastruktur entkoppelt, was die Bereitstellung in verschiedenen Umgebungen, wie Clouds oder Betriebssystemen, vereinfacht und das Skalieren erleichtert.

Containerisierte Anwendungen, die in Containern ausgeführt werden, bieten eine Reihe von Vorteilen. Sie sind portabel und konsistent, da sie in einer standardisierten Umgebung laufen, unabhängig von der zugrunde liegenden Infrastruktur. Dies ermöglicht eine konsistente Entwicklung, Bereitstellung und Ausführung von Anwendungen in verschiedenen Umgebungen.

Container Environment Variable

Sun, 03 Mar 2024 11:30:36 +0000

Container Environment Variables oder auch Container Umgebungsvariablen sind Name=Wert-Paare, die wertvolle Informationen über Container bereitstellen, die in einem Pod ausgeführt werden. Sie sind entscheidend für die Kommunikation und Konfiguration von Anwendungen innerhalb des Kubernetes-Clusters.

Diese Variablen dienen dazu, wichtige Informationen bereitzustellen, die von den laufenden containerisierten Anwendungen benötigt werden. Dazu gehören Details zum Dateisystem, Informationen über den Container selbst sowie andere Cluster-Ressourcen wie Dienstendpunkte. Ein typisches Beispiel ist die Konfiguration von Anwendungen, die auf Datenbanken oder anderen externen Diensten zugreifen müssen. Durch das Setzen von Umgebungsvariablen können die Anwendungen die Verbindungsinformationen zu diesen Diensten erhalten, ohne dass sie hartcodiert sein müssen.

Container Lifecycle Hooks

Sun, 03 Mar 2024 11:30:36 +0000

Container-Lifecycle-Hooks sind Mechanismen, die Ereignisse im Lebenszyklus der Container-Verwaltung offenlegen und es dem Benutzer ermöglichen, Code auszuführen, wenn diese Ereignisse eintreten.

Es gibt zwei Hooks, die den Containern zur Verfügung gestellt werden:

PostStart: Dieser Hook wird unmittelbar nach der Erstellung eines Containers ausgeführt. Er bietet eine Möglichkeit, spezifische Aktionen auszuführen, sobald der Container initialisiert und einsatzbereit ist. Beispielsweise können hier Initialisierungsaufgaben wie das Herstellen einer Verbindung zu externen Diensten oder das Laden von Konfigurationsdaten durchgeführt werden.

Container Network Interface (CNI)

Sun, 03 Mar 2024 11:30:36 +0000

Container Network Interface (CNI)-Plugins sind eine Art von Netzwerkplugin, das der appc/CNI-Spezifikation entspricht.

Die Container Network Interface (CNI) definiert eine standardisierte Schnittstelle für die Konfiguration von Container-Netzwerken in Container-Runtime-Umgebungen. CNI-Plugins sind Erweiterungen, die diese Schnittstelle implementieren und es Kubernetes ermöglichen, Netzwerkkonfigurationen für Container bereitzustellen und zu verwalten.

CNI-Plugins sind so konzipiert, dass sie in einer Vielzahl von Umgebungen und Szenarien eingesetzt werden können. Sie können verschiedene Netzwerktechnologien unterstützen, darunter Bridge, VLAN, VXLAN, Host-Gateway und viele andere. Die Wahl des geeigneten CNI-Plugins hängt von den Anforderungen und Präferenzen des Clusters ab, einschließlich der Leistung, Skalierbarkeit und Kompatibilität mit vorhandener Infrastruktur.

Container Runtime

Sun, 03 Mar 2024 11:30:36 +0000

Ein Container-Laufzeit (Container Runtime) ist eine grundlegende Komponente, die Kubernetes ermöglicht, Container effektiv auszuführen. Sie ist verantwortlich für das Verwalten der Ausführung und des Lebenszyklus von Containern innerhalb der Kubernetes-Umgebung.

Kubernetes unterstützt verschiedene Container-Laufzeiten, darunter containerd, CRI-O und jede andere Implementierung des Kubernetes CRI (Container Runtime Interface). Diese Container-Laufzeiten stellen die grundlegenden Funktionen zur Ausführung von Containern bereit und ermöglichen es Kubernetes, Container zu starten, zu stoppen, zu überwachen und zu verwalten.

Container-Laufzeiten implementieren das Kubernetes CRI-Protokoll, das eine standardisierte Schnittstelle zwischen Kubernetes und den verschiedenen Container-Laufzeiten definiert. Dadurch wird die Interoperabilität zwischen Kubernetes und den Container-Laufzeiten gewährleistet, und Kubernetes kann nahtlos mit verschiedenen Container-Laufzeiten arbeiten, ohne auf spezifische Implementierungsdetails eingehen zu müssen.

Container Runtime Interface (CRI)

Sun, 03 Mar 2024 11:30:36 +0000

Die Container Runtime Interface (CRI) ist eine API, die es Container-Laufzeiten ermöglicht, sich mit dem kubelet auf einem Node zu integrieren. Das kubelet ist ein zentraler Node-Agent in einem Kubernetes-Cluster, der für die Verwaltung von Containern auf dem Node verantwortlich ist.

Die CRI definiert eine standardisierte Schnittstelle zwischen dem kubelet und verschiedenen Container-Laufzeiten. Durch die Implementierung der CRI können Container-Laufzeiten nahtlos in Kubernetes-Cluster integriert werden, unabhängig von ihrer spezifischen Implementierung oder Technologie.

Die CRI-API spezifiziert die Methoden und Funktionen, die von einer Container-Laufzeit bereitgestellt werden müssen, um mit dem kubelet zu kommunizieren. Dazu gehören unter anderem Funktionen zum Starten, Stoppen, Überwachen und Verwalten von Containern sowie zum Abrufen von Container-Logs und Metadaten.

Container Storage Interface(CSI)

Sun, 03 Mar 2024 11:30:36 +0000

Das Container Storage Interface (CSI) definiert eine standardisierte Schnittstelle zum Bereitstellen von Speichersystemen für Container.

Mit CSI können Anbieter benutzerdefinierte Speicherplugins für Kubernetes erstellen, ohne sie zum Kubernetes-Repository hinzufügen zu müssen (out-of-tree-Plugins). Um einen CSI-Treiber eines Speicheranbieters zu verwenden, muss dieser zunächst in Ihrem Cluster bereitgestellt werden. Anschließend können Sie eine Storage Class erstellen, die diesen CSI-Treiber verwendet.

Die Verwendung von CSI bietet eine Vielzahl von Vorteilen. Sie ermöglicht die Interoperabilität zwischen verschiedenen Speicherlösungen und Kubernetes, da Anbieter ihre eigenen CSI-Treiber implementieren können, die nahtlos in Kubernetes-Cluster integriert werden können. Dies erweitert die Flexibilität und Auswahlmöglichkeiten für Speicherlösungen in Kubernetes.

Containerd

Sun, 03 Mar 2024 11:30:36 +0000

containerd ist eine Container-Laufzeit mit einem Schwerpunkt auf Einfachheit, Robustheit und Portabilität. Als Container-Laufzeit läuft containerd als Daemon auf Linux- oder Windows-Systemen und übernimmt verschiedene Aufgaben im Zusammenhang mit Containern.

Eine der Hauptfunktionen von containerd besteht darin, Container-Images zu verwalten. Das bedeutet, dass containerd für das Herunterladen, Speichern und Verwalten von Container-Images verantwortlich ist. Es ermöglicht die effiziente Speicherung von Images und stellt sicher, dass diese schnell und zuverlässig von Containern verwendet werden können.

Contributor

Sun, 03 Mar 2024 11:30:36 +0000

Ein Contributor ist eine Person, die Code, Dokumentation oder ihre Zeit dem Kubernetes-Projekt oder der Community zur Verfügung stellt.

Beiträge können verschiedene Formen annehmen, darunter Pull Requests (PRs), bei denen Änderungen am Code vorgeschlagen werden, Issues, in denen Probleme oder Verbesserungsvorschläge gemeldet werden, Feedback zu bestehenden Funktionen oder Dokumentation, sowie die aktive Teilnahme an Special Interest Groups (SIGs) oder die Organisation und Teilnahme an Community-Veranstaltungen.

Contributoren sind unverzichtbare Mitglieder der Kubernetes-Community und tragen wesentlich zum Erfolg des Projekts bei. Ihre Arbeit hilft dabei, Fehler zu beheben, neue Funktionen hinzuzufügen, die Dokumentation zu verbessern und die Community durch Wissensaustausch und Unterstützung zu stärken. Sie repräsentieren eine vielfältige Gruppe von Menschen aus verschiedenen Hintergründen und Organisationen, die gemeinsam daran arbeiten, Kubernetes zu einer robusten und leistungsstarken Plattform für Container-Orchestrierung und Cloud-native Anwendungen zu machen.

Contributor License Agreement (CLA)

Sun, 03 Mar 2024 11:30:36 +0000

Ein Contributor License Agreement (CLA) definiert die Bedingungen, unter denen ein Beitragende einer Open-Source-Projektgemeinschaft eine Lizenz für seine Beiträge gewährt.

CLAs sind rechtliche Vereinbarungen, die dazu dienen, rechtliche Streitigkeiten im Zusammenhang mit beigesteuertem Material und geistigem Eigentum (IP) zu lösen. Durch die Unterzeichnung eines CLA erklärt der Beitragende, dass er das Recht hat, den Code oder andere Materialien beizutragen, und gewährt dem Open-Source-Projekt die erforderlichen Rechte zur Nutzung, Verteilung und Lizenzierung seiner Beiträge.

Control Plane

Sun, 03 Mar 2024 11:30:36 +0000

Die Control Plane ist die Container-Orchestrierungsebene, die die API und Schnittstellen zur Definition, Bereitstellung und Verwaltung des Lebenszyklus von Containern bereitstellt.

Diese Ebene besteht aus verschiedenen Komponenten, darunter (aber nicht beschränkt auf):

etcd
API-Server
Scheduler
Controller-Manager
Cloud-Controller-Manager

Diese Komponenten können als traditionelle Betriebssystemdienste (Daemons) oder als Container ausgeführt werden. Die Hosts, auf denen diese Komponenten ausgeführt werden, wurden historisch als “Masters” bezeichnet. Sie bilden das Herzstück eines Kubernetes-Clusters und sind für die Koordination und Steuerung der Cluster-Ressourcen verantwortlich.

Controller

Sun, 03 Mar 2024 11:30:36 +0000

In Kubernetes sind Controller Kontrollschleifen, die den Zustand Ihres Clusters überwachen und bei Bedarf Änderungen vornehmen oder anfordern. Jeder Controller versucht, den aktuellen Zustand des Clusters dem gewünschten Zustand näher zu bringen.

Die Controller überwachen den gemeinsamen Zustand Ihres Clusters über den API-Server (Teil der Control Plane). Einige Controller laufen auch innerhalb der Control Plane und stellen Kontrollschleifen bereit, die für den Betrieb von Kubernetes unerlässlich sind. Zum Beispiel laufen der Deployment-Controller, der DaemonSet-Controller, der Namespace-Controller und der PersistentVolume-Controller (und andere) alle innerhalb des kube-controller-managers.

CRI-O

Sun, 03 Mar 2024 11:30:36 +0000

CRI-O ist ein Tool, das es ermöglicht, OCI-Container-Runtimes mit dem Kubernetes CRI zu verwenden. Es handelt sich dabei um eine Implementierung der Container Runtime Interface (CRI), die die Verwendung von Container-Runtimes ermöglicht, die mit dem Spezifikation der Open Container Initiative (OCI) kompatibel sind.

Durch die Bereitstellung von CRI-O kann Kubernetes jede OCI-konforme Laufzeit als Container-Laufzeit für die Ausführung von Pods verwenden und OCI-Container-Images aus entfernten Registern abrufen.

Indem CRI-O als Bindeglied zwischen Kubernetes und OCI-kompatiblen Runtimes fungiert, ermöglicht es die Nutzung einer breiten Palette von Runtimes, die den OCI-Spezifikationen entsprechen. Dies bietet Flexibilität und Auswahlmöglichkeiten für die Konfiguration und Verwaltung von Containern in Kubernetes-Clustern.

Cronjob

Sun, 03 Mar 2024 11:30:36 +0000

Ein CronJob verwaltet einen Job, der in regelmäßigen Abständen gemäß einem Zeitplan ausgeführt wird. Ähnlich wie eine Zeile in einer crontab-Datei spezifiziert ein CronJob-Objekt einen Zeitplan unter Verwendung des cron-Formats.

Ein CronJob in Kubernetes ermöglicht es Entwicklern, Aufgaben zu definieren, die automatisch und periodisch ausgeführt werden sollen, ohne dass manuelle Eingriffe erforderlich sind. Dies kann nützlich sein für wiederkehrende Aufgaben wie Datensicherungen, periodische Bereinigungen oder die Ausführung von Batch-Jobs zu bestimmten Zeitpunkten.

CustomResourceDefinition

Sun, 03 Mar 2024 11:30:36 +0000

Eine CustomResourceDefinition (CRD) ist benutzerdefinierter Code, der eine Ressource definiert, die Ihrem Kubernetes-API-Server hinzugefügt wird, ohne dass ein vollständiger benutzerdefinierter Server erstellt werden muss.

CRDs ermöglichen es Ihnen, das Kubernetes-API für Ihre Umgebung zu erweitern, wenn die öffentlich unterstützten API-Ressourcen Ihre Anforderungen nicht erfüllen können. Dies gibt Ihnen die Möglichkeit, spezifische Ressourcentypen zu definieren, die speziell auf die Anforderungen Ihrer Anwendung oder Infrastruktur zugeschnitten sind.

Durch die Verwendung von CRDs können Sie benutzerdefinierte Ressourcentypen erstellen, die dieselben Funktionalitäten wie native Kubernetes-Ressourcen haben. Dies umfasst Funktionen wie CRUD-Operationen (Erstellen, Lesen, Aktualisieren, Löschen), Validierung, Statusaktualisierungen und Reaktionsmechanismen auf Ereignisse.

DaemonSet

Sun, 03 Mar 2024 11:30:36 +0000

Ein DaemonSet stellt sicher, dass eine Kopie eines Pods über eine Gruppe von Nodes in einem Cluster ausgeführt wird.

DaemonSets werden verwendet, um System-Daemons wie Protokollsammler und Überwachungsagenten bereitzustellen, die normalerweise auf jedem Node im Cluster ausgeführt werden müssen.

Das Konzept eines DaemonSets ist besonders nützlich für Anwendungen oder Dienste, die auf jedem Node im Cluster vorhanden sein müssen, um bestimmte Aufgaben auszuführen, wie z.B. das Sammeln von Protokollen, das Überwachen von Ressourcen oder das Bereitstellen von Netzwerkdiensten.

Data Plane

Sun, 03 Mar 2024 11:30:36 +0000

Die Data Plane ist die Ebene, die Kapazitäten wie CPU, Speicher, Netzwerk und Speicher bereitstellt, damit die Container ausgeführt und mit einem Netzwerk verbunden werden können.

In einem Kubernetes-Cluster bildet die Data Plane die grundlegende Infrastruktur, die für die Ausführung und den Betrieb von Containern erforderlich ist. Diese Ebene stellt sicher, dass die erforderlichen Ressourcen für die Container bereitgestellt werden, damit sie reibungslos ausgeführt werden können.

CPU und Speicher werden den Containern zugewiesen, um die Rechenleistung und den Speicherbedarf ihrer Anwendungen zu unterstützen. Das Netzwerk ermöglicht die Kommunikation zwischen den Containern sowie den Zugriff auf externe Dienste und Ressourcen. Die Speicherkapazität bietet die Möglichkeit, Daten persistent zu speichern und zu nutzen, auch über den Lebenszyklus der Container hinweg.

Deployment

Sun, 03 Mar 2024 11:30:36 +0000

Ein Deployment ist ein API-Objekt, das eine replizierte Anwendung verwaltet, typischerweise durch das Ausführen von Pods ohne lokalen Zustand.

Ein Deployment definiert die gewünschte Konfiguration für die Anwendung, einschließlich der Anzahl der replizierten Pods, der verwendeten Container-Images und der Bereitstellungsstrategie. Anschließend überwacht das Deployment ständig den Zustand der Pods und stellt sicher, dass die tatsächlichen Pods im Cluster mit der gewünschten Konfiguration übereinstimmen.

Jede Replik wird durch einen Pod repräsentiert, und die Pods werden auf die Node eines Clusters verteilt. Dadurch wird sichergestellt, dass die Anwendung über die gesamte Clusterumgebung hinweg verfügbar ist und gleichmäßig auf die verfügbaren Ressourcen verteilt wird. Wenn ein Pod ausfällt oder gelöscht wird, startet das Deployment automatisch einen neuen Pod, um sicherzustellen, dass die gewünschte Anzahl von Repliken stets vorhanden ist.

Developer

Sun, 03 Mar 2024 11:30:36 +0000

Developer oder auf deutsch “Entwickler” ist ein überladener Begriff, der je nach Kontext auf verschiedene Rollen verweisen kann. Im Bereich von Kubernetes und der Softwareentwicklung kann er verschiedene Aufgaben umfassen, darunter:

Anwendungsentwickler: Eine Person, die für das Schreiben und Entwickeln von Anwendungen verantwortlich ist, die auf Kubernetes-Clustern ausgeführt werden. Sie konzentrieren sich auf das Entwerfen, Codieren, Testen und Bereitstellen von Anwendungen unter Verwendung von Kubernetes-spezifischen Tools und Methoden.

Code-Beitragender: Jemand, der Code, Dokumentation oder seine Zeit zur Verbesserung von Kubernetes oder anderen Open-Source-Projekten beiträgt. Code-Beitragende beteiligen sich am Entwicklungsprozess, indem sie Pull-Requests einreichen, Probleme ansprechen, Feedback geben und aktiv an Diskussionen innerhalb der Community teilnehmen.

Device Plugin

Sun, 03 Mar 2024 11:30:36 +0000

Device Plugins sind Programme, die auf Worker-Nodes ausgeführt werden und Pods Zugriff auf Ressourcen ermöglichen, die eine anbieterspezifische Initialisierung oder Einrichtung erfordern.

Diese Plugins werben Ressourcen beim Kubelet, damit Pods auf Hardwarefunktionen zugreifen können, die mit dem Node zusammenhängen, auf dem der jeweilige Pod ausgeführt wird. Sie können ein Device Plugin entweder als DaemonSet bereitstellen oder die entsprechende Software direkt auf jedem Zielknoten installieren.

Device Plugins sind besonders nützlich, wenn Pods spezielle Hardwarefunktionen oder Geräte benötigen, die auf dem betreffenden Node verfügbar sind. Dies könnte beispielsweise GPUs, FPGAs oder spezielle Netzwerkgeräte umfassen.

Disruption

Sun, 03 Mar 2024 11:30:36 +0000

Disruption oder auf deutsch Störung sind unvermeidliche Ereignisse in einem Kubernetes-Cluster, die dazu führen können, dass Pods außer Betrieb gehen und Auswirkungen auf die betroffenen Arbeitslasten haben. Diese Ereignisse können sowohl freiwillig als auch unfreiwillig auftreten und erfordern eine sorgfältige Planung und Handhabung seitens des Cluster-Betreibers, um die Auswirkungen auf die laufenden Arbeitslasten zu minimieren.

Freiwillige Störungen treten auf, wenn der Cluster-Betreiber gezielt einen Pod zerstört, der zu einer bestimmten Anwendung gehört. Dies kann Teil eines geplanten Wartungsvorgangs sein, bei dem ein Pod vorübergehend außer Betrieb genommen wird, um Updates durchzuführen oder Konfigurationsänderungen vorzunehmen. Obwohl diese Störungen geplant sind, können sie dennoch Auswirkungen auf die Verfügbarkeit der Anwendung haben, insbesondere wenn die Arbeitslast nicht korrekt auf andere Pods im Cluster umgeleitet wird.

Docker

Sun, 03 Mar 2024 11:30:36 +0000

Docker (speziell Docker Engine) ist eine Softwaretechnologie, die Virtualisierung auf Betriebssystemebene bietet, auch bekannt als Container.

Docker nutzt die Ressourcenisolationsfunktionen des Linux-Kernels wie cgroups und Kernel-Namespaces sowie ein unionsfähiges Dateisystem wie OverlayFS und andere, um unabhängige Container innerhalb einer einzigen Linux-Instanz auszuführen. Dadurch wird der Overhead beim Starten und Verwalten von virtuellen Maschinen (VMs) vermieden.

Die Verwendung von Containern ermöglicht es Entwicklern, Anwendungen und ihre Abhängigkeiten in isolierten Umgebungen zu verpacken, die leichtgewichtig, portabel und konsistent sind. Dadurch können Anwendungen problemlos zwischen verschiedenen Umgebungen verschoben und bereitgestellt werden, ohne sich um Kompatibilitätsprobleme oder Abhängigkeiten auf dem Zielsystem sorgen zu müssen.

Dockershim

Sun, 03 Mar 2024 11:30:36 +0000

Der Dockershim war ein Bestandteil von Kubernetes Version 1.23 und früher. Er ermöglichte es dem kubelet, mit dem Docker Engine zu kommunizieren.

Ab Version 1.24 wurde der Dockershim aus Kubernetes entfernt. Diese Änderung wurde vorgenommen, um die Abhängigkeit von Docker als Container-Runtime zu reduzieren und die Interoperabilität mit anderen Container-Runtimes zu verbessern.

Mit dem Wegfall des Dockershims müssen Benutzer, die Docker als Container-Runtime verwenden, auf eine alternative Lösung umsteigen, wie z. B. containerd oder CRI-O. Diese Container-Runtimes bieten ähnliche Funktionen wie Docker und können nahtlos in Kubernetes integriert werden.

Downstream

Sun, 03 Mar 2024 11:30:36 +0000

“Downstream” ist ein Begriff, der je nach Kontext unterschiedliche Bedeutungen haben kann:

Im Kubernetes-Ökosystem bezieht sich “Downstream” auf den Teil der Community, der von der Kern-Kubernetes-Codebasis abhängt. Das können Anwendungen, Tools oder andere Codeprojekte sein, die auf Kubernetes aufbauen oder von dessen Funktionalitäten profitieren. Zum Beispiel können Anwendungen “downstream” von neuen Kubernetes-Funktionen profitieren, um ihre eigene Funktionalität zu verbessern.

In GitHub oder Git bezeichnet “Downstream” normalerweise eine verzweigte Repository-Version, die von der ursprünglichen (Upstream-)Codebasis abgeleitet ist. Das Downstream-Repository enthält möglicherweise spezifische Anpassungen, Erweiterungen oder Experimente im Vergleich zum Upstream-Repository.

Downward API

Sun, 03 Mar 2024 11:30:36 +0000

Die Downward-API ist ein entscheidender Mechanismus von Kubernetes, der es Containern ermöglicht, auf Informationen über sich selbst oder ihren Kontext im Kubernetes-Cluster zuzugreifen, ohne dass die Container selbst direkt mit der Kubernetes-API interagieren müssen. Dies ist besonders nützlich, wenn Container Informationen über ihre Umgebung benötigen, ohne dass diese Informationen fest in den Containercode eingebettet werden müssen, was die Flexibilität und Portabilität der Anwendungen erhöht.

Es gibt zwei Hauptmethoden, um die Downward-API zu nutzen: die Verwendung von Umgebungsvariablen und die Verwendung eines Downward-API-Volumes. Über Umgebungsvariablen können Container direkt auf bestimmte Feldwerte des Pods oder Containers zugreifen, indem sie einfach auf die entsprechenden Umgebungsvariablen zugreifen. Auf der anderen Seite ermöglicht die Verwendung eines Downward-API-Volumes eine flexiblere Möglichkeit, Daten von Feldern des Pods oder Containers abzurufen, indem eine spezielle Datei im Dateisystem des Containers erstellt wird, die die gewünschten Informationen enthält.

Dynamic Volume Provisioning

Sun, 03 Mar 2024 11:30:36 +0000

Die Dynamic Volume Provisioning (dynamische Volumenbereitstellung) ermöglicht es Benutzern, die automatische Erstellung von Speichervolumen anzufordern.

Durch die dynamische Bereitstellung entfällt die Notwendigkeit für Cluster-Administratoren, Speicher im Voraus zu planen und zu reservieren. Stattdessen erfolgt die Speicherbereitstellung automatisch auf Benutzeranforderung hin. Die dynamische Volumenbereitstellung basiert auf einem API-Objekt, der sogenannten “StorageClass” die auf einen Volumen-Plugin verweist, welches ein Volumen bereitstellt, sowie auf einer Reihe von Parametern, die an das Volumen-Plugin übergeben werden.

Benutzer können einfach eine PersistentVolumeClaim (PVC) erstellen und dabei die gewünschte Speicherklasse (StorageClass) angeben. Die StorageClass definiert, wie das Volumen bereitgestellt werden soll, einschließlich des verwendeten Speichertyps, der Zugriffsmodi und anderer Konfigurationsoptionen. Wenn eine PVC erstellt wird, die auf eine bestimmte StorageClass verweist und keine passenden Volumes verfügbar sind, wird automatisch ein neues Volumen entsprechend den Spezifikationen der StorageClass erstellt.

Endpoints

Sun, 03 Mar 2024 11:30:36 +0000

Endpoints verfolgen die IP-Adressen von Pods mit übereinstimmenden Selektoren.

Normalerweise werden Endpoints automatisch für Kubernetes-Services generiert, basierend auf den Selektoren, die in den Service-Spezifikationen definiert sind. Diese Endpoints zeigen auf die Pods, die den Dienst bereitstellen.

In einigen Fällen kann es jedoch erforderlich sein, Endpoints manuell zu konfigurieren, insbesondere wenn der Service keine Selektoren spezifiziert hat oder wenn die Pods außerhalb des Kubernetes-Clusters laufen. In solchen Fällen können Administratoren die Endpoints manuell konfigurieren, um die IP-Adressen der Ziel-Pods anzugeben.

EndpointSlice

Sun, 03 Mar 2024 11:30:36 +0000

EndpointSlice ist eine Möglichkeit, Netzwerkendpunkte zusammen mit Kubernetes-Ressourcen zu gruppieren.

Im Wesentlichen handelt es sich bei EndpointSlice um eine skalierbare und erweiterbare Methode, um Netzwerkendpunkte zu gruppieren. Diese können von kube-proxy verwendet werden, um Netzwerkrouten auf jedem Node im Kubernetes-Cluster einzurichten.

Im Vergleich zu herkömmlichen Endpoints bietet EndpointSlice eine verbesserte Skalierbarkeit und Flexibilität. Insbesondere in Umgebungen mit einer großen Anzahl von Netzwerkendpunkten oder in komplexen Netzwerktopologien kann EndpointSlice eine effiziente Möglichkeit bieten, Endpunkte zu verwalten und die Leistung zu optimieren.

Ephemeral Container

Sun, 03 Mar 2024 11:30:36 +0000

Ephemeral Container sind eine äußerst nützliche Funktion in Kubernetes, die es Administratoren und Entwicklern ermöglicht, temporäre Container innerhalb eines laufenden Pods zu starten, um spezifische Diagnosen oder Anpassungen durchzuführen.

Ephemeral Container bieten eine schnelle und flexible Möglichkeit, Probleme in einem laufenden Pod zu untersuchen, ohne die laufende Anwendung zu beeinträchtigen. Wenn ein Pod beispielsweise unerwartetes Verhalten zeigt oder Schwierigkeiten bei der Ausführung einer bestimmten Aufgabe hat, kann ein Ephemeral Container hinzugefügt werden, um spezifische Diagnosen durchzuführen. Dies könnte das Ausführen von Befehlen zum Überprüfen von Protokollen, das Installieren von Debugging-Tools oder das Ausführen von Diagnosetests umfassen.

etcd

Sun, 03 Mar 2024 11:30:36 +0000

etcd ist ein konsistenter und hochverfügbarer Schlüssel-Wert-Speicher, der als Kubernetes-Back-End-Speicher für alle Clusterdaten verwendet wird. Als zentrales Element in der Kubernetes-Architektur dient etcd zur Speicherung von Konfigurationsinformationen, Zustandsinformationen und Metadaten, die für den Betrieb des Clusters erforderlich sind. Zu diesen Daten gehören beispielsweise Informationen über laufende Pods, Services, Bereitstellungen und Konfigurationseinstellungen.

Die Konsistenz und Hochverfügbarkeit von etcd gewährleistet, dass die Clusterdaten zuverlässig gespeichert und aktualisiert werden können, selbst unter Bedingungen wie Netzwerkpartitionen oder Ausfällen von Rechenzentren. Dies ist entscheidend für die Stabilität und Zuverlässigkeit eines Kubernetes-Clusters.

Event

Sun, 03 Mar 2024 11:30:36 +0000

Events sind Kubernetes-Objekte, die Zustandsänderungen oder bemerkenswerte Ereignisse im System beschreiben.

Sie dienen dazu, wichtige Ereignisse im Kubernetes-Cluster zu protokollieren, wie zum Beispiel das Starten oder Stoppen von Pods, Änderungen an Ressourcen oder Fehlerbedingungen. Jedes Event besteht aus einem Zeitstempel, einer Quelle, einem Grund und einer Meldung, die das Ereignis näher beschreiben.

Es ist wichtig zu beachten, dass Events eine begrenzte Aufbewahrungszeit haben und sich Auslöser und Meldungen im Laufe der Zeit ändern können. Daher sollten Verbraucher von Ereignissen nicht davon ausgehen, dass die Timing-Details eines Ereignisses mit einem bestimmten Grund eine konsistente zugrunde liegende Ursache widerspiegeln oder dass die Ereignisse mit diesem Grund fortbestehen.

Eviction

Sun, 03 Mar 2024 11:30:36 +0000

Die Eviction (deutsch: Vertreibung) ist der Prozess der Beendigung eines oder mehrerer Pods auf Nodes im Kubernetes-Cluster.

Es gibt zwei Arten von Evictions:

Node Pressure Eviction: Diese Art der Vertreibung tritt auf, wenn ein Node aufgrund von Ressourcenknappheit, wie beispielsweise unzureichendem Speicher oder CPU-Auslastung, unter Druck gerät. In solchen Fällen kann Kubernetes entscheiden, bestimmte Pods von diesem Node zu vertreiben, um die Verfügbarkeit und Leistung des Clusters sicherzustellen.

API Initated Eviction: Dies ist der Prozess, bei dem Sie die Eviction-API verwenden, um ein Eviction-Objekt zu erstellen, das die Graceful Pod-Terminierung auslöst. Dies kann durch direkten Aufruf der Eviction-API mithilfe eines Clients des kube-apiservers wie dem kubectl drain-Befehl erfolgen. Wenn ein Eviction-Objekt erstellt wird, beendet der API-Server den Pod.

Extensions

Sun, 03 Mar 2024 11:30:36 +0000

Erweiterungen sind Softwarekomponenten, die Kubernetes erweitern und eng mit ihm integriert sind, um neue Arten von Hardware zu unterstützen.

Viele Cluster-Administratoren verwenden eine gehostete oder verteilte Instanz von Kubernetes. Diese Cluster werden mit vorinstallierten Erweiterungen geliefert. Als Ergebnis werden die meisten Kubernetes-Benutzer keine Erweiterungen installieren müssen, und noch weniger Benutzer werden neue Erweiterungen erstellen müssen.

Diese Erweiterungen können verschiedene Funktionen bereitstellen, darunter zusätzliche Ressourcentypen, benutzerdefinierte Controller, Netzwerkfunktionen oder Speicherlösungen. Sie ermöglichen es Kubernetes, sich nahtlos in verschiedene Hardwareumgebungen zu integrieren und spezifische Anforderungen von Anwendungen oder Workloads zu erfüllen.

Feature Gate

Sun, 03 Mar 2024 11:30:36 +0000

Feature Gates sind eine Reihe von Schlüsseln (undurchsichtige Zeichenfolgen), die Sie verwenden können, um zu steuern, welche Kubernetes-Funktionen in Ihrem Cluster aktiviert sind.

Sie können diese Funktionen mit dem Befehlszeilenflag –feature-gates auf jedem Kubernetes-Komponenten ein- oder ausschalten. Jede Kubernetes-Komponente ermöglicht es Ihnen, eine Reihe von Feature-Gates zu aktivieren oder zu deaktivieren, die für diese Komponente relevant sind. Die Kubernetes-Dokumentation listet alle aktuellen Feature-Gates und ihre Steuerungen auf.

Feature-Gates dienen dazu, experimentelle oder sich in Entwicklung befindende Funktionen in Kubernetes zu aktivieren oder zu deaktivieren. Sie ermöglichen es Administratoren, die Einführung neuer Funktionen zu steuern und sicherzustellen, dass nur stabile Funktionen in Produktionsumgebungen aktiviert sind.

Finalizier

Sun, 03 Mar 2024 11:30:36 +0000

Finalizer oder auch Finalisierer sind namensraumbezogene Schlüssel, die Kubernetes mitteilen, dass es warten soll, bis bestimmte Bedingungen erfüllt sind, bevor es Ressourcen, die zur Löschung markiert wurden, vollständig löscht. Finalisierer benachrichtigen Controller darüber, Ressourcen aufzuräumen, die dem gelöschten Objekt gehören.

Wenn Sie Kubernetes anweisen, ein Objekt zu löschen, für das Finalisierer angegeben sind, markiert die Kubernetes-API das Objekt für die Löschung, indem sie .metadata.deletionTimestamp bevölkert, und gibt einen HTTP-Statuscode 202 (“Akzeptiert”) zurück. Das Zielobjekt bleibt in einem terminierenden Zustand, während das Kontrollflugzeug oder andere Komponenten die Aktionen ausführen, die durch die Finalisierer definiert sind. Nachdem diese Aktionen abgeschlossen sind, entfernt der Controller die entsprechenden Finalisierer aus dem Zielobjekt. Wenn das Feld metadata.finalizers leer ist, betrachtet Kubernetes die Löschung als abgeschlossen und löscht das Objekt.

FlexVolume

Sun, 03 Mar 2024 11:30:36 +0000

FlexVolume ist eine veraltete Schnittstelle zum Erstellen von externen Volume-Plugins. Das Container Storage Interface (CSI) ist eine neuere Schnittstelle, die mehrere Probleme mit FlexVolume angeht.

FlexVolumes ermöglichen es Benutzern, ihre eigenen Treiber zu schreiben und Unterstützung für ihre Volumes in Kubernetes hinzuzufügen. Die Binärdateien und Abhängigkeiten des FlexVolume-Treibers müssen auf den Hostmaschinen installiert sein. Dies erfordert Root-Zugriff. Die Storage SIG empfiehlt die Implementierung eines CSI-Treibers, sofern möglich, da dies die Einschränkungen von FlexVolumes adressiert.

Garbage Collection

Sun, 03 Mar 2024 11:30:36 +0000

Die Garbage Collection - oder auch Müllsammlung- ist ein integraler Bestandteil der Clusterwartung in Kubernetes und bezeichnet die verschiedenen Mechanismen, die verwendet werden, um ungenutzte oder nicht mehr benötigte Ressourcen zu entfernen. Dabei handelt es sich um einen proaktiven Ansatz, um die Effizienz des Clusters zu verbessern und Ressourcen freizugeben.

Kubernetes nutzt die Müllsammlung, um verschiedene Arten von Ressourcen aufzuräumen, darunter:

Ungenutzte Container und Images: Container und zugehörige Images, die nicht mehr verwendet werden oder keine aktiven Pods haben, werden entfernt, um Speicherplatz freizugeben.

Gateway API

Sun, 03 Mar 2024 11:30:36 +0000

Die Gateway-API ist eine Familie von API-Typen zur Modellierung des Service-Netzwerks in Kubernetes. Sie bietet eine Reihe von erweiterbaren, rollenorientierten und protokollbewussten API-Typen für die Modellierung des Service-Netzwerks in Kubernetes.

Die Gateway-API ermöglicht es Benutzern, komplexe Netzwerktopologien in Kubernetes zu definieren und zu verwalten, indem sie verschiedene Rollen und Protokolle berücksichtigt. Sie bietet eine flexible und skalierbare Möglichkeit, Services und deren Kommunikation innerhalb des Clusters sowie mit externen Ressourcen zu konfigurieren.

Durch die Verwendung der Gateway-API können Developer und Administratoren die Netzwerkkonfiguration in Kubernetes effektiv steuern und anpassen, um den Anforderungen ihrer Anwendungen gerecht zu werden. Dies ermöglicht eine präzise Steuerung des Datenverkehrs, die Implementierung von Sicherheitsrichtlinien und die Optimierung der Netzwerkperformance.

Group Version Resource

Sun, 03 Mar 2024 11:30:36 +0000

Group Version Resource, auch als GVR bekannt, ist eine Möglichkeit, eine eindeutige Kubernetes-API-Ressource darzustellen.

Group Version Resources (GVRs) spezifizieren die API-Gruppe, die API-Version und die Ressource (Name für die Objektart, wie sie in der URI erscheint), die mit dem Zugriff auf ein bestimmtes Objekt in Kubernetes verbunden sind. GVRs ermöglichen es Ihnen, verschiedene Kubernetes-Objekte zu definieren und zu unterscheiden, und einen stabilen Zugriff auf Objekte festzulegen, auch wenn sich die APIs ändern.

Helm Chart

Sun, 03 Mar 2024 11:30:36 +0000

Ein Helm-Chart ist ein Paket vorab konfigurierter Kubernetes-Ressourcen, das mit dem Helm-Tool verwaltet werden kann.

Charts bieten eine reproduzierbare Möglichkeit zur Erstellung und Weitergabe von Kubernetes-Anwendungen. Ein einzelnes Chart kann verwendet werden, um etwas Einfaches bereitzustellen, wie zum Beispiel einen Memcached-Pod, oder etwas Komplexes, wie einen vollständigen Webanwendungs-Stack mit HTTP-Servern, Datenbanken, Caches und so weiter.

Link zum offiziellen Glossar

Horizontal Pod Autoscaler

Sun, 03 Mar 2024 11:30:36 +0000

Der Horizontal Pod Autoscaler (HPA) ist ein leistungsstarkes Werkzeug in Kubernetes, das automatisch die Anzahl der Pod-Replikationen basierend auf der CPU-Auslastung oder benutzerdefinierten Metrikzielen skaliert. Dies ermöglicht es Kubernetes-Benutzern, ihre Anwendungen dynamisch an sich ändernde Arbeitslasten anzupassen, indem sie Ressourcen effizient nutzen.

Der HPA ist eine API-Ressource, die in der Regel mit anderen Kubernetes-Ressourcen wie ReplicationControllers, Deployments oder ReplicaSets verwendet wird. Es überwacht kontinuierlich die Ressourcenauslastung der Pods und passt die Anzahl der Replikationen automatisch an, um die gewünschte Ziel-CPU-Auslastung oder benutzerdefinierte Metriken zu erreichen.

HostAliases

Sun, 03 Mar 2024 11:30:36 +0000

Die HostAliases sind eine Zuordnung zwischen der IP-Adresse und dem Hostnamen, die in die Hostdatei eines Pods eingefügt werden.

HostAliases ist eine optionale Liste von Hostnamen und IP-Adressen, die in die Hostdatei des Pods eingefügt werden, wenn sie angegeben sind. Dies ist nur für nicht-HostNetzwerk-Pods gültig.

Die Verwendung von HostAliases ermöglicht es Benutzern, benutzerdefinierte Zuordnungen zwischen IP-Adressen und Hostnamen festzulegen, die in einem Pod verwendet werden sollen. Dies kann nützlich sein, um benutzerdefinierte Namensauflösungen für Dienste oder Ressourcen in einem Kubernetes-Cluster bereitzustellen.

Image

Sun, 03 Mar 2024 11:30:36 +0000

Ein Image ist eine gespeicherte Instanz eines Containers, die eine Reihe von Software enthält, die benötigt wird, um eine Anwendung auszuführen.

Ein Image ist eine Möglichkeit, Software zu verpacken, die es ermöglicht, sie in einem Container-Repository zu speichern, auf ein lokales System herunterzuladen und als Anwendung auszuführen. Metadaten sind in dem Image enthalten, die angeben können, welches ausführbare Programm ausgeführt werden soll, wer es erstellt hat, und andere Informationen.

Images sind das Grundelement in der Containerisierungstechnologie und bilden die Basis für die Bereitstellung und Ausführung von Anwendungen in Containerumgebungen wie Docker oder Kubernetes. Sie sind portabel, da sie alle notwendigen Abhängigkeiten und Konfigurationen enthalten, um eine Anwendung über verschiedene Umgebungen hinweg konsistent auszuführen.

Ingress

Sun, 03 Mar 2024 11:30:36 +0000

Ein Ingress ist ein API-Objekt, das den externen Zugriff auf die Dienste in einem Cluster verwaltet, typischerweise über HTTP.

Ingress ermöglicht es, den externen Zugriff auf Dienste in einem Kubernetes-Cluster zu verwalten und zu steuern. Dabei können verschiedene Funktionen wie Lastenausgleich, SSL-Terminierung und namensbasiertes virtuelles Hosting bereitgestellt werden.

Durch die Verwendung von Ingress können Kubernetes-Benutzer den eingehenden HTTP-Traffic auf verschiedene Dienste in ihrem Cluster verteilen und steuern, wodurch sie eine flexiblere und skalierbare Infrastruktur für ihre Anwendungen schaffen können.

Init Container

Sun, 03 Mar 2024 11:30:36 +0000

Ein Init-Container ist ein wichtiger Bestandteil von Kubernetes-Pods, der dazu dient, bestimmte Vorbedingungen zu erfüllen, bevor die Hauptanwendungscontainer gestartet werden. Init-Container sind spezielle Container, die vor dem Start der eigentlichen Anwendungscontainer ausgeführt werden müssen. Sie dienen dazu, verschiedene Aufgaben auszuführen, wie beispielsweise das Laden von Konfigurationsdateien, das Einrichten von Umgebungsvariablen oder das Warten auf das Vorhandensein bestimmter Ressourcen.

Init-Container werden in einer streng sequenziellen Reihenfolge ausgeführt, was bedeutet, dass jeder Init-Container vollständig abgeschlossen sein muss, bevor der nächste gestartet wird. Dies gewährleistet, dass alle notwendigen Vorbereitungen abgeschlossen sind, bevor die eigentliche Anwendung gestartet wird.

Istio

Sun, 03 Mar 2024 11:30:36 +0000

Istio ist eine offene Plattform (nicht spezifisch für Kubernetes), die einen einheitlichen Ansatz für die Integration von Microservices, die Verwaltung des Datenverkehrsflusses, die Durchsetzung von Richtlinien und die Aggregation von Telemetriedaten bietet.

Die Integration von Istio erfordert keine Änderung des Anwendungs-Codes. Es handelt sich um eine Infrastrukturschicht zwischen einem Dienst und dem Netzwerk, die in Kombination mit Dienstbereitstellungen häufig als Service-Mesh bezeichnet wird. Die Steuerungsebene von Istio abstrahiert die zugrunde liegende Cluster-Management-Plattform, die Kubernetes, Mesosphere usw. sein kann.

Job

Sun, 03 Mar 2024 11:30:36 +0000

Ein Job in Kubernetes ist eine endliche oder Batch-Aufgabe, die bis zur Fertigstellung ausgeführt wird. Es erstellt ein oder mehrere Pod-Objekte und stellt sicher, dass eine bestimmte Anzahl von ihnen erfolgreich beendet wird. Während die Pods erfolgreich abgeschlossen werden, verfolgt der Job die erfolgreichen Abschlüsse.

Jobs sind nützlich für Aufgaben, die nur einmalig ausgeführt werden müssen oder für Batch-Verarbeitungsaufgaben, die eine bestimmte Anzahl von Instanzen benötigen, um erfolgreich abgeschlossen zu werden. Sie stellen sicher, dass die Aufgabe ordnungsgemäß ausgeführt wird, indem sie die Anzahl der Pods im Auge behalten und den Fortschritt überwachen.

JSON Web Token (JWT)

Sun, 03 Mar 2024 11:30:36 +0000

JSON Web Token (JWT) ist ein Mittel zur Darstellung von Ansprüchen, die zwischen zwei Parteien übertragen werden sollen. JWTs können digital signiert und verschlüsselt werden. Kubernetes verwendet JWTs als Authentifizierungstoken, um die Identität von Entitäten zu überprüfen, die Aktionen in einem Cluster durchführen möchten.

Ein JWT besteht aus drei Teilen: dem Header, den Payload und der Signatur. Der Header enthält Metadaten über den Token wie den Typ und das verwendete Signaturalgorithmus. Der Payload enthält die Ansprüche oder Informationen, die übertragen werden sollen. Die Signatur wird verwendet, um die Integrität des Tokens zu gewährleisten und sicherzustellen, dass er nicht manipuliert wurde.

kOps

Sun, 03 Mar 2024 11:30:36 +0000

kOps (Kubernetes Operations) ist ein automatisiertes Bereitstellungssystem, das nicht nur dabei hilft, produktionsreife, hochverfügbare Kubernetes-Cluster zu erstellen, zu zerstören, zu aktualisieren und zu warten, sondern auch die erforderliche Cloud-Infrastruktur bereitstellt. Aktuell wird AWS (Amazon Web Services) offiziell unterstützt, während DigitalOcean, GCE und OpenStack in der Beta-Unterstützung sind und Azure sich noch im Alpha-Status befindet.

Die wichtigsten Merkmale von kOps sind:

Vollautomatische Installation: kOps automatisiert den gesamten Bereitstellungsprozess von Kubernetes-Clustern, was die Einrichtung und Wartung erleichtert.

kube proxy

Sun, 03 Mar 2024 11:30:36 +0000

Der kube-proxy ist ein Netzwerkproxy, der auf jedem Node in Ihrem Cluster läuft und einen Teil des Kubernetes-Servicekonzepts implementiert. Er verwaltet Netzwerkregeln auf den Nodes, die die Netzwerkkommunikation zu Ihren Pods aus Netzwerksitzungen innerhalb oder außerhalb Ihres Clusters ermöglichen.

Der kube-proxy nutzt die Paketfilterungsebene des Betriebssystems, wenn diese verfügbar ist. Andernfalls leitet der kube-proxy den Datenverkehr selbst weiter. Dies ermöglicht es, dass Netzwerkanforderungen an Services und Pods innerhalb des Clusters richtig geroutet werden, unabhängig davon, auf welchem Node sie sich befinden. Der kube-proxy spielt somit eine wichtige Rolle bei der Gewährleistung der Konnektivität innerhalb des Kubernetes-Clusters.

kube scheduler

Sun, 03 Mar 2024 11:30:36 +0000

Der kube-scheduler ist eine wichtige Steuerungsebene innerhalb eines Kubernetes-Clusters, die für die effiziente Zuweisung von Pods auf die verfügbaren Node verantwortlich ist. Diese Komponente überwacht kontinuierlich die neu erstellten Pods, die noch keinen zugewiesenen Node haben, und entscheidet anhand verschiedener Faktoren, auf welchem Node sie ausgeführt werden sollen.

Bei der Entscheidung über die Platzierung von Pods berücksichtigt der kube-scheduler eine Vielzahl von Aspekten, um eine optimale Verteilung im Cluster zu gewährleisten. Dazu gehören die individuellen und kollektiven Ressourcenanforderungen der Pods, etwaiger Hardware- oder Softwarebeschränkungen, Richtlinienkonformität, Affinitäts- und Anti-Affinitätsregeln sowie Datenlokalität. Darüber hinaus berücksichtigt der Scheduler auch Faktoren wie Interferenzen zwischen Arbeitslasten und Deadlines, um sicherzustellen, dass Pods effizient und zuverlässig ausgeführt werden.

kube-controller-manager

Sun, 03 Mar 2024 11:30:36 +0000

Der kube-controller-manager ist eine Komponente der Steuerebene, die Controller-Prozesse ausführt. Logisch gesehen ist jeder Controller ein separater Prozess, aber um die Komplexität zu reduzieren, werden sie alle in eine einzige Binärdatei kompiliert und in einem einzigen Prozess ausgeführt.

Die Controller sind für die Überwachung des Zustands des Kubernetes-Clusters verantwortlich und nehmen entsprechende Maßnahmen, um sicherzustellen, dass der aktuelle Zustand mit dem gewünschten Zustand übereinstimmt. Es gibt verschiedene Controller, die unterschiedliche Aufgaben erfüllen, wie z. B. den Replication Controller, den Node Controller und den Endpoints Controller.

Kubeadm

Sun, 03 Mar 2024 11:30:36 +0000

Kubeadm ist ein leistungsstarkes Tool zur schnellen Installation von Kubernetes und zur Einrichtung eines sicheren Clusters. Es wurde entwickelt, um den Prozess der Kubernetes-Bereitstellung zu vereinfachen und sicherzustellen, dass die Clusterkonfiguration gemäß bewährten Methoden erfolgt.

Mit kubeadm können Sie sowohl die Steuerungsebene (control plane) als auch die Worker-Node-Komponenten installieren und konfigurieren. Dabei übernimmt kubeadm die Aufgabe, alle notwendigen Schritte zur Initialisierung des Clusters durchzuführen, darunter:

Einrichten der Kubernetes-Steuerungsebene: Kubeadm erstellt die erforderlichen Kubernetes-Steuerungsebene-Komponenten wie den API-Server, den Scheduler und den Controller-Manager. Diese Komponenten sind für die Verwaltung und Steuerung des Clusters verantwortlich.

Kubectl

Sun, 03 Mar 2024 11:30:36 +0000

kubectl, auch bekannt als Kubernetes Control, ist ein leistungsstarkes Befehlszeilenwerkzeug, das für die Interaktion mit der Steuerungsebene eines Kubernetes-Clusters über die Kubernetes-API entwickelt wurde. Mit kubectl können Entwickler und Administratoren verschiedene Aufgaben zur Verwaltung von Kubernetes-Ressourcen durchführen.

Hier sind einige der Hauptfunktionen von kubectl:

Kubernetes-Ressourcen verwalten: Mit kubectl können Sie Kubernetes-Ressourcen wie Pods, Services, Deployments, ReplicaSets, ConfigMaps und mehr erstellen, anzeigen, aktualisieren und löschen. Dies ermöglicht die Verwaltung der gesamten Clusterkonfiguration über die Befehlszeile.
Clusterstatus überprüfen: kubectl bietet verschiedene Befehle zum Überprüfen des Status und der Gesundheit des Kubernetes-Clusters. Sie können beispielsweise den Status von Pods, Services, Nodes und anderen Ressourcen abrufen, um sicherzustellen, dass der Cluster ordnungsgemäß funktioniert.

Kubelet

Sun, 03 Mar 2024 11:30:36 +0000

Der Kubelet ist ein Agent, der auf jedem Node im Kubernetes-Cluster läuft. Seine Hauptaufgabe besteht darin, sicherzustellen, dass die in einem Pod definierten Container auf dem jeweiligen Node ordnungsgemäß ausgeführt werden.

Hier sind einige der wichtigsten Funktionen des Kubelets:

Pod-Verwaltung: Der Kubelet erhält Pod-Spezifikationen von der Kubernetes-API und stellt sicher, dass die darin definierten Container gemäß den Spezifikationen gestartet, aktualisiert und beendet werden.

Ressourcenüberwachung: Das Kubelet überwacht die Ressourcennutzung der Container und greift bei Bedarf ein, um sicherzustellen, dass die Container innerhalb der definierten Grenzen für CPU, Arbeitsspeicher und andere Ressourcen arbeiten.

Kubernetes API

Sun, 03 Mar 2024 11:30:36 +0000

Die Kubernetes-API ist die Anwendung, die Kubernetes-Funktionalitäten über eine RESTful-Schnittstelle bereitstellt und den Zustand des Clusters speichert.

Hier sind einige wichtige Merkmale der Kubernetes-API:

RESTful-Schnittstelle: Die Kubernetes-API stellt eine RESTful-Schnittstelle bereit, über die Benutzer mit dem Cluster interagieren können. Diese Schnittstelle ermöglicht das Lesen, Erstellen, Aktualisieren und Löschen von Ressourcen im Cluster.
Zustandsverwaltung: Die Kubernetes-API speichert den Zustand des Clusters und verwaltet die Lebenszyklen der verschiedenen Ressourcen, die im Cluster ausgeführt werden. Dies umfasst Pod-Spezifikationen, Service, Replicaset, Deployment und vieles mehr.

Label

Sun, 03 Mar 2024 11:30:36 +0000

Labels sind Schlüssel/Wert-Paare, die Objekten wie Pods zugeordnet werden, um sie mit identifizierenden Attributen zu versehen, die für Benutzer bedeutsam und relevant sind. Sie werden verwendet, um Objekte zu organisieren und Teilmengen von Objekten auszuwählen. Labels sind eine wichtige Funktion von Kubernetes und bieten mehrere Vorteile:

Identifikation und Organisation: Durch das Anbringen von Labels können Benutzer Kubernetes-Objekte identifizieren und organisieren. Sie können Objekte mit ähnlichen Funktionen, Umgebungen oder anderen Kriterien markieren, um sie später leichter zu finden oder zu gruppieren.

LimitRange

Sun, 03 Mar 2024 11:30:36 +0000

LimitRange ist ein Kubernetes-Objekt, das Einschränkungen bereitstellt, um den Ressourcenverbrauch pro Container oder Pod in einem Namespace zu begrenzen.

Hier sind einige wichtige Punkte zu LimitRange:

Begrenzung der Objektmenge: LimitRange ermöglicht es Administratoren, die Anzahl der erstellbaren Objekte pro Typ zu begrenzen. Dies kann nützlich sein, um Ressourcenverbrauch und Clusterressourcen zu kontrollieren.

Begrenzung der Ressourcen: Neben der Begrenzung der Anzahl von Objekten kann LimitRange auch den Ressourcenverbrauch pro Container oder Pod einschränken. Dies umfasst CPU, Speicher und andere Ressourcen, die von Containern oder Pods angefordert oder verbraucht werden können.

Logging

Sun, 03 Mar 2024 11:30:36 +0000

Logs sind eine Liste von Ereignissen, die von einem Cluster oder einer Anwendung protokolliert werden.

Hier sind einige wichtige Punkte zu Logging in Kubernetes:

Protokollierung von Ereignissen: Logs erfassen Ereignisse, die in einem Cluster oder einer Anwendung auftreten. Dies kann Fehlermeldungen, Warnungen, Informationsmeldungen und andere relevante Ereignisse umfassen.
Debugging und Fehlerbehebung: Logs sind besonders nützlich für das Debugging und die Fehlerbehebung von Problemen in einer Anwendung oder im Cluster. Sie ermöglichen es Entwicklern und Administratoren, den Ablauf von Ereignissen zu verfolgen und potenzielle Probleme zu identifizieren.

Managed Service

Sun, 03 Mar 2024 11:30:36 +0000

Ein Managed Service ist ein Softwareangebot, das von einem Drittanbieter verwaltet wird. Im Gegensatz zu selbstverwalteten Lösungen übernimmt der Anbieter die Verantwortung für die Bereitstellung, Wartung und Skalierung des Dienstes, während der Benutzer sich auf die Verwendung und Integration konzentrieren kann.

Hier sind einige wichtige Merkmale von Managed Services:

Bereitstellung und Wartung: Der Anbieter übernimmt die Bereitstellung und Wartung des Dienstes, einschließlich der Einrichtung von Servern, der Installation von Software, der Konfiguration von Netzwerken und der Durchführung von Softwareupdates und Patches.

Manifest

Sun, 03 Mar 2024 11:30:36 +0000

Ein Manifest ist eine Spezifikation eines Kubernetes-API-Objekts im JSON- oder YAML-Format. Es beschreibt den gewünschten Zustand eines Objekts, den Kubernetes beibehalten soll, wenn das Manifest angewendet wird. Jede Konfigurationsdatei kann mehrere Manifeste enthalten.

Manifeste werden verwendet, um Kubernetes mitzuteilen, welche Ressourcen erstellt, aktualisiert oder gelöscht werden sollen. Sie enthalten Details wie den Objekttyp, Metadaten wie den Namen und die Labels des Objekts, sowie spezifische Konfigurationsparameter, die den gewünschten Zustand des Objekts definieren.

Master

Sun, 03 Mar 2024 11:30:36 +0000

“Master” ist ein veralteter Begriff, der früher als Synonym für Nodes verwendet wurde, auf denen die Steuerungsebene (Control Plane) von Kubernetes ausgeführt wird. Die Steuerungsebene umfasst Komponenten wie den API-Server, den Scheduler und den Controller-Manager, die für die Verwaltung und Steuerung des Kubernetes-Clusters verantwortlich sind.

Obwohl der Begriff “Master” immer noch gelegentlich verwendet wird, um die Nodes zu bezeichnen, die die Steuerungsebene hosten, ist er in der Kubernetes-Community aufgrund seiner impliziten Konnotationen als nicht mehr zeitgemäß angesehen. Stattdessen wird empfohlen, Begriffe wie “Control Plane” oder “Controller Nodes” zu verwenden, um die Rolle dieser Nodes im Cluster genauer zu beschreiben.

Member

Sun, 03 Mar 2024 11:30:36 +0000

Ein Mitglied in der Kubernetes-Community ist eine Person, die aktiv an der Weiterentwicklung und Verbesserung des Kubernetes-Projekts beteiligt ist. Diese Beteiligung kann sich in verschiedenen Formen manifestieren, darunter das Einreichen von Fehlerberichten (Issues), das Beheben von Fehlern, das Einreichen von Pull Requests (PRs), das Teilnehmen an Diskussionen in Foren oder in speziellen Interessengruppen (SIGs) sowie das Organisieren oder Unterstützen von Community-Veranstaltungen.

Mitglieder genießen gewisse Privilegien und Verantwortlichkeiten innerhalb der Community. Sie haben die Möglichkeit, Issues und PRs zugewiesen zu bekommen, was bedeutet, dass sie bestimmte Probleme lösen oder Änderungen am Quellcode vornehmen können. Mitglieder können auch aktive Teilnehmer in den SIGs sein, wo sie an Diskussionen teilnehmen und zur Entwicklung von Kubernetes beitragen können.

Minikube

Sun, 03 Mar 2024 11:30:36 +0000

Minikube ist ein nützliches Tool, das es Entwicklern ermöglicht, Kubernetes lokal auszuführen. Es ermöglicht das Einrichten und Betreiben einer einfachen Kubernetes-Clusterumgebung auf einem einzelnen Rechner, was ideal ist, um Kubernetes zu lernen, Anwendungen lokal zu entwickeln und zu testen sowie verschiedene Kubernetes-Funktionen zu erkunden, ohne auf eine vollständige Cloud-basierte Bereitstellung angewiesen zu sein.

Durch die Verwendung von Minikube kann ein Entwickler schnell und einfach einen Kubernetes-Cluster auf seinem eigenen Computer erstellen, ohne dass ein umfangreiches Setup oder spezielle Hardware erforderlich ist. Minikube verwendet dabei eine virtuelle Maschine (VM), um den Kubernetes-Cluster innerhalb einer isolierten Umgebung auszuführen. Dadurch wird sichergestellt, dass die lokale Entwicklungsumgebung nicht durch die Kubernetes-Ressourcen beeinträchtigt wird.

Mirror Pod

Sun, 03 Mar 2024 11:30:36 +0000

Ein Mirror Pod ist ein Objekt, das vom Kubelet verwendet wird, um einen statischen Pod zu repräsentieren. Wenn das Kubelet einen statischen Pod in seiner Konfiguration findet, versucht es automatisch, ein Pod-Objekt auf dem Kubernetes-API-Server dafür zu erstellen. Dies bedeutet, dass der Pod auf dem API-Server sichtbar ist, aber nicht von dort aus gesteuert werden kann.

Mit anderen Worten, ein Mirror Pod ist eine Spiegelung des statischen Pods auf dem Kubernetes-API-Server, die vom Kubelet verwaltet wird. Obwohl der Mirror Pod auf dem API-Server existiert, kann er nicht von dort aus gesteuert oder verwaltet werden. Beispielsweise hat das Löschen eines Mirror Pods keine Auswirkungen auf das Verhalten des kubelet-Dienstes, der den Pod ausführt. Der Mirror Pod wird weiterhin ausgeführt, solange er in der Konfiguration des kubelets vorhanden ist.

Mixed Version Proxy (MVP)

Sun, 03 Mar 2024 11:30:36 +0000

Der Mixed Version Proxy, auch als MVP bekannt, ist eine Funktion in Kubernetes, die es einem kube-apiserver ermöglicht, eine Ressourcenanfrage an einen anderen Peer-API-Server weiterzuleiten. Dies ist besonders nützlich in Clustern, in denen mehrere API-Server mit unterschiedlichen Kubernetes-Versionen ausgeführt werden.

Die Notwendigkeit für den MVP entsteht, wenn ein Kubernetes-Cluster aufgrund von Upgrades oder verteilten Bereitstellungen API-Server unterschiedlicher Versionen enthält. In solchen Fällen können bestimmte Ressourcen möglicherweise nicht von allen API-Servern ordnungsgemäß bedient werden. Der MVP ermöglicht es einem API-Server, Ressourcenanfragen an den richtigen API-Server mit der passenden Version weiterzuleiten, um sicherzustellen, dass die Anfragen ordnungsgemäß verarbeitet werden.

Name

Sun, 03 Mar 2024 11:30:36 +0000

Ein “Name” ist eine clientbereitgestellte Zeichenfolge, die sich auf ein Objekt in einer Ressourcen-URL bezieht, wie z.B. “/api/v1/pods/some-name”. In Kubernetes kann jedes Objekt einen eindeutigen Namen haben, der es identifiziert. Ein bestimmter Name kann jedoch nur für ein Objekt einer bestimmten Art zur gleichen Zeit existieren. Wenn ein Objekt gelöscht wird, kann ein neues Objekt mit demselben Namen erstellt werden.

Der Name eines Objekts ist ein wichtiger Identifikator in Kubernetes, da er verwendet wird, um auf das Objekt zuzugreifen, es zu identifizieren und mit ihm zu interagieren. Beispielsweise können Ressourcen wie Pods, Services, Deployments usw. einen Namen haben, der es den Benutzern ermöglicht, sie eindeutig zu identifizieren und auf sie zuzugreifen. Die Einzigartigkeit des Namens gewährleistet, dass keine Konflikte zwischen verschiedenen Objekten entstehen, und erleichtert die Verwaltung und den Betrieb des Kubernetes-Clusters.

Namespace

Sun, 03 Mar 2024 11:30:36 +0000

Ein Namespace ist eine Abstraktion, die von Kubernetes verwendet wird, um die Isolierung von Gruppen von Ressourcen innerhalb eines einzelnen Clusters zu unterstützen. Mit Namespaces können Objekte in einem Cluster organisiert werden, und sie bieten eine Möglichkeit, die Ressourcen des Clusters zu unterteilen. Die Namen von Ressourcen müssen innerhalb eines Namespaces eindeutig sein, aber nicht über Namespaces hinweg. Die auf Namespaces basierende Abgrenzung gilt nur für Namespaced-Objekte (z. B. Deployments, Services usw.) und nicht für Cluster-weite Objekte (z. B. StorageClass, Nodes, PersistentVolumes usw.). Durch die Verwendung von Namespaces können verschiedene Teams oder Anwendungen ihre Ressourcen in einem gemeinsamen Kubernetes-Cluster verwalten, ohne dass sie sich gegenseitig beeinträchtigen. Dies fördert die Organisation, das Management und die Skalierbarkeit von Kubernetes-Clustern, da es eine logische Trennung der Ressourcen ermöglicht. Jeder Namespace fungiert als isolierte Umgebung, in der Ressourcen definiert und verwaltet werden können, und ermöglicht es Administratoren, Berechtigungen und Zugriffssteuerungen auf Namespace-Ebene festzulegen.

Network Policy

Sun, 03 Mar 2024 11:30:36 +0000

Network Policy sind Spezifikationen darüber, wie Gruppen von Pods miteinander und mit anderen Netzwerkendpunkten kommunizieren dürfen. Sie ermöglichen es Ihnen, deklarativ zu konfigurieren, welche Pods miteinander kommunizieren dürfen, welche Namespaces miteinander kommunizieren dürfen, und spezifisch welche Portnummern durch jede Richtlinie erzwungen werden sollen. Network Policies verwenden Labels, um Pods auszuwählen, und definieren Regeln, die festlegen, welcher Datenverkehr zu den ausgewählten Pods zugelassen ist.

Network Policies werden durch einen unterstützten Netzwerk-Plugin bereitgestellt, das von einem Netzwerkanbieter bereitgestellt wird. Es ist wichtig zu beachten, dass das Erstellen einer Netzwerkressource ohne einen Controller, der sie implementiert, keine Auswirkungen hat. Die Netzwerkrichtlinie wird vom Netzwerkplugin umgesetzt und kann dazu beitragen, die Sicherheit in einem Kubernetes-Cluster zu verbessern, indem sie den Datenverkehr zwischen verschiedenen Pods und Namespaces steuert und einschränkt. Sie ermöglichen eine granulare Kontrolle darüber, welche Pods miteinander kommunizieren dürfen, basierend auf definierten Regeln und Richtlinien.

Node

Sun, 03 Mar 2024 11:30:36 +0000

Ein Node ist eine Arbeitsmaschine in Kubernetes, die für die Ausführung von Pods zuständig ist. Ein Node kann entweder eine virtuelle Maschine (VM) oder eine physische Maschine sein, abhängig von der Art des Clusters. Er verfügt über lokale Dienste oder Daemons, die erforderlich sind, um Pods auszuführen, und wird von der Control Plane verwaltet. Zu den Daemons auf einem Node gehören kubelet, kube-proxy und ein Containerlaufzeitdienst, der das Container Runtime Interface (CRI) implementiert, wie z. B. Docker.

Node-pressure-eviction

Sun, 03 Mar 2024 11:30:36 +0000

Node-pressure-eviction, auch als Kubelet-Eviction bekannt, ist ein entscheidender Prozess im Kubernetes-Clustermanagement. Wenn die Ressourcen wie CPU, Speicher, Festplattenspeicherplatz oder Dateisysteminodes auf einem Nodeknapp werden, greift das Kubelet ein und entscheidet proaktiv, welche Pods auf diesem Node beendet werden sollen, um Ressourcen freizugeben.

Der Node-pressure-eviction-Prozess wird durch das Kubelet überwacht, das ständig die Ressourcenauslastung auf jedem Node im Cluster überprüft. Sobald das Kubelet feststellt, dass ein Node überlastet ist und dringend Ressourcen benötigt werden, startet es den Eviction-Prozess. Dabei werden bestimmte Pods auf dem Node ausgewählt und beendet, um Platz für neue Pods und die Freigabe von Ressourcen zu schaffen.

Object

Sun, 03 Mar 2024 11:30:36 +0000

Ein Objekt im Kontext von Kubernetes ist eine Entität, die verwendet wird, um den Zustand und das Verhalten eines Clusters zu definieren und zu repräsentieren. Die Kubernetes-API nutzt diese Objekte, um die gewünschten Zustände der verschiedenen Ressourcen im Cluster zu beschreiben. Im Wesentlichen ist ein Kubernetes-Objekt eine Art “Intentionserklärung”, die angibt, wie ein Teil der Cluster-Workload aussehen soll.

Diese Objekte können verschiedene Arten von Ressourcen darstellen, darunter Pods, Services, Deployment, Konfigurationskarten, Secrets und vieles mehr. Jedes Objekt hat eine eindeutige Identität und spezifische Eigenschaften, die seinen Zweck und seine Funktionalität im Cluster definieren.

Operation Pattern

Sun, 03 Mar 2024 11:30:36 +0000

Das Operator-Pattern ist ein Systemdesign, das einen Controller mit einer oder mehreren benutzerdefinierten Ressourcen verknüpft. Es ermöglicht die Erweiterung von Kubernetes, indem zusätzliche Controller zum Cluster hinzugefügt werden, die über die eingebauten Controller von Kubernetes hinausgehen.

Im Rahmen des Operator-Pattern fungiert eine laufende Anwendung als Controller und hat API-Zugriff, um Aufgaben gegen eine benutzerdefinierte Ressource im Steuerungsebene auszuführen. Diese benutzerdefinierte Ressource ist speziell für die Bedürfnisse der Anwendung definiert und kann beispielsweise Zustände und Konfigurationen repräsentieren.

Persistent Volume

Sun, 03 Mar 2024 11:30:36 +0000

Ein Persistent Volume (PV) ist ein API-Objekt, das einen Speicherbereich im Cluster repräsentiert. Es steht als allgemeine, anpassbare Ressource zur Verfügung, die über den Lebenszyklus eines einzelnen Pods hinaus bestehen bleibt.

PersistentVolumes (PVs) bieten eine API, die Details darüber abstrahiert, wie Speicher bereitgestellt wird, im Gegensatz dazu, wie er verwendet wird. PVs werden direkt in Szenarien eingesetzt, in denen Speicher im Voraus erstellt werden kann (statische Bereitstellung). Für Szenarien, die eine bedarfsgesteuerte Speicherbereitstellung erfordern (dynamische Bereitstellung), werden stattdessen Persistent Volume Claims (PVCs) verwendet.

Persistent Volume Claim

Sun, 03 Mar 2024 11:30:36 +0000

Ein Persistent Volume Claim (PVC) beansprucht Speicherressourcen, die in einem Persisten Volume definiert sind, damit sie als Volume in einem Container bereitgestellt werden können.

Ein PVC gibt an, wie viel Speicherplatz benötigt wird, wie auf den Speicher zugegriffen wird (nur lesen, lesen und schreiben und/oder exklusiv) und wie er zurückgefordert wird (behalten, wiederverwenden oder löschen). Einzelheiten zum Speicher selbst werden im Persisten tVolume-Objekt beschrieben.

Durch die Verwendung von PVCs können Entwickler oder Benutzer innerhalb des Kubernetes-Clusters auf Speicher zugreifen, ohne sich um die zugrunde liegende Speicherinfrastruktur kümmern zu müssen. PVCs erleichtern die Bereitstellung von Speicher für Anwendungen und ermöglichen eine flexible und bedarfsgerechte Nutzung von Speicherressourcen in Kubernetes.

Platform Developer

Sun, 03 Mar 2024 11:30:36 +0000

Ein Plattformentwickler ist eine Person, die die Kubernetes-Plattform an die Anforderungen ihres Projekts anpasst.

Ein Plattformentwickler kann beispielsweise benutzerdefinierte Ressourcen verwenden oder die Kubernetes-API mit der Aggregationsfunktion erweitern, um die Funktionalität ihrer Instanz von Kubernetes speziell für ihre Anwendung zu erweitern. Einige Plattformentwickler sind auch Beitragende und entwickeln Erweiterungen, die der Kubernetes-Community zur Verfügung gestellt werden. Andere entwickeln proprietäre kommerzielle oder standortspezifische Erweiterungen.

Link zum offiziellen Glossar

Pod

Sun, 03 Mar 2024 11:30:36 +0000

Ein Pod ist die kleinste und grundlegendste Einheit in Kubernetes, die eine Gruppe von miteinander verbundenen Containern umfasst und als eine atomare Einheit behandelt wird. Diese Container teilen sich denselben Netzwerk- und Speicherbereich und werden gemeinsam auf einem Node ausgeführt. Ein Pod kann einen oder mehrere Container enthalten, die eng miteinander zusammenarbeiten, um eine bestimmte Anwendung oder eine Gruppe von Aufgaben zu erfüllen.

Die Verwendung von Pods bietet mehrere Vorteile. Zum einen ermöglichen sie die einfache Gruppierung von Containern, die zusammenarbeiten müssen, um eine Anwendung bereitzustellen. Dies fördert eine modulare und skalierbare Architektur, da neue Funktionen oder Dienste durch das Hinzufügen zusätzlicher Container zu einem Pod implementiert werden können. Darüber hinaus ermöglicht Kubernetes die horizontale Skalierung von Pods, indem mehrere Instanzen desselben Pods erstellt werden, um die Last auf dem Cluster zu verteilen.

Pod Disruption

Sun, 03 Mar 2024 11:30:36 +0000

Pod-Unterbrechung ist der Prozess, bei dem Pods auf Nodes entweder freiwillig oder unfreiwillig beendet werden.

Freiwillige Unterbrechungen werden absichtlich von Anwendungsbesitzern oder Cluster-Administratoren gestartet. Unfreiwillige Unterbrechungen sind unbeabsichtigt und können durch unvermeidbare Probleme wie Nodes, die keine Ressourcen mehr haben, oder durch versehentliche Löschungen ausgelöst werden.

Link zum offiziellen Glossar

Pod Disruption Budget (PDB)

Sun, 03 Mar 2024 11:30:36 +0000

Ein Pod Disruption Budget, auch bekannt als PDB, ermöglicht es einem Anwendungsbesitzer, ein Objekt für eine replizierte Anwendung zu erstellen. Dieses Objekt stellt sicher, dass eine bestimmte Anzahl oder Prozentsatz von Pods mit einem bestimmten Label zu keinem Zeitpunkt freiwillig beendet werden.

Der Zweck eines PDB besteht darin, sicherzustellen, dass eine Anwendung während Wartungsarbeiten oder anderen geplanten Unterbrechungen weiterhin eine Mindestanzahl von Pods aufrechterhalten kann, um die Verfügbarkeit zu gewährleisten. Dies ist besonders wichtig für replizierte Anwendungen, bei denen das Ausfallen eines Pods durch eine geplante Unterbrechung zu einer Beeinträchtigung der Dienstleistung führen kann.

Pod Lifecycle

Sun, 03 Mar 2024 11:30:36 +0000

Der Pod-Lifecycle beschreibt die Abfolge der Zustände, durch die ein Pod während seiner Lebensdauer durchläuft. Es gibt fünf mögliche Phasen eines Pods: Pending (Ausstehend), Running (Aktiv), Succeeded (Erfolgreich abgeschlossen), Failed (Fehlgeschlagen) und Unknown (Unbekannt). Eine allgemeine Beschreibung des Pod-Zustands wird im PodStatus-Phasenfeld zusammengefasst.

Pending (Ausstehend): Der Pod wurde erstellt, aber noch nicht an einen Node zugewiesen und gestartet.
Running (Aktiv): Der Pod wurde auf einem Node zugewiesen und mindestens ein Container innerhalb des Pods wurde gestartet und läuft.
Succeeded (Erfolgreich abgeschlossen): Alle Container im Pod wurden erfolgreich ausgeführt und beendet.
Failed (Fehlgeschlagen): Mindestens einer der Container im Pod hat einen Fehler gemeldet oder ist unerwartet beendet worden.
Unknown (Unbekannt): Der Zustand des Pods kann nicht abgerufen werden.

Diese Phasen des Pod-Lifecycle ermöglichen es Administratoren und Entwicklern, den Zustand von Pods zu überwachen und auf Ereignisse zu reagieren, die während des Betriebs auftreten können.

Pod Priority

Sun, 03 Mar 2024 11:30:36 +0000

Pod-Priorität gibt die Bedeutung eines Pods im Vergleich zu anderen Pods an. Sie ermöglicht es, die Planungspriorität eines Pods höher oder niedriger als die anderer Pods festzulegen. Dies ist eine wichtige Funktion für Produktionsworkloads in Clustern.

Die Priorität eines Pods kann helfen, die Reihenfolge festzulegen, in der Pods gestartet und verteilt werden, insbesondere wenn Ressourcen knapp sind. Ein Pod mit höherer Priorität wird bevorzugt behandelt und hat eine höhere Chance, auf einem Knoten gestartet zu werden, selbst wenn die Ressourcen knapp sind. Dies kann helfen, sicherzustellen, dass kritische Workloads priorisiert werden, während weniger wichtige Workloads zurückgestellt werden können, um die Gesamtstabilität des Clusters zu gewährleisten.

Pod Security Police

Sun, 03 Mar 2024 11:30:36 +0000

Pod Security Policy ermöglicht eine feinkörnige Autorisierung für die Erstellung und Aktualisierung von Pods.

Es handelt sich um eine clusterweite Ressource, die sicherheitsrelevante Aspekte der Pod-Spezifikation kontrolliert. Die Pod Security Policy-Objekte definieren eine Reihe von Bedingungen, die ein Pod erfüllen muss, um vom System akzeptiert zu werden, sowie Standards für die entsprechenden Felder. Die Steuerung der Pod-Sicherheitsrichtlinie wird als optionaler Zulassungscontroller implementiert.

Pod Security Policy wurde ab Kubernetes v1.21 als veraltet markiert und in v1.25 entfernt. Als Alternative verwenden Sie Pod Security Admission oder ein Drittanbieter-Zulassungs-Plugin.

Preemption

Sun, 03 Mar 2024 11:30:36 +0000

In Kubernetes ist die Vorbelegung (Preemption) ein Mechanismus, der entwickelt wurde, um bei der Planung von Pods niedriger Priorität vorhandene Pods von Nodes zu entfernen, um Platz für Pods mit höherer Priorität zu schaffen, die aufgrund von Ressourcenbeschränkungen nicht geplant werden können. Wenn der Scheduler versucht, einen ausstehenden Pod auf einem Node zu platzieren, aber feststellt, dass nicht genügend Ressourcen verfügbar sind, wird der Vorbelegungsprozess ausgelöst.

Während der Vorbelegung identifiziert der Scheduler vorhandene Pods auf dem Node, die eine niedrigere Priorität als der ausstehende Pod haben. Diese Pods niedrigerer Priorität werden dann zur Räumung markiert, um Ressourcen auf dem Node für den Pod mit höherer Priorität freizugeben. Der Scheduler stellt sicher, dass die Gesamtauslastung der Ressourcen auf dem Node auch nach der Vorbelegung innerhalb akzeptabler Grenzen bleibt.

Probe

Sun, 03 Mar 2024 11:30:36 +0000

Eine Probe ist eine Überprüfung, die der Kubelet regelmäßig gegen einen Container durchführt, der in einem Pod läuft. Diese Überprüfungen dienen dazu, den Zustand und die Gesundheit des Containers zu definieren und Informationen für den Lebenszyklus des Containers bereitzustellen. Es gibt drei Arten von Proben, die von Kubernetes unterstützt werden:

Liveness Probe: Überprüft, ob der Container am Leben ist. Wenn die Liveness-Probe fehlschlägt, wird der Container als nicht gesund markiert und möglicherweise neu gestartet.

Proxy

Sun, 03 Mar 2024 11:30:36 +0000

Ein Proxy ist ein Server, der als Vermittler für einen entfernten Dienst fungiert. Wenn ein Client mit einem Proxy interagiert, übermittelt der Proxy die Daten des Clients an den tatsächlichen Server und leitet die Antwort des Servers zurück an den Client.

Im Kontext von Kubernetes ist kube-proxy ein Netzwerkproxy, der auf jedem Knoten im Cluster läuft und einen Teil des Kubernetes-Servicekonzepts implementiert. Seine Hauptaufgabe besteht darin, den Netzwerkverkehr zu den Pods zu leiten, die die Dienste des Clusters bereitstellen.

QoS class

Sun, 03 Mar 2024 11:30:36 +0000

Die QoS-Class (Quality of Service Class) bietet Kubernetes eine Möglichkeit, Pods innerhalb des Clusters in verschiedene Klassen einzuteilen und Entscheidungen über die Planung und Räumung zu treffen. Die QoS-Class eines Pods wird zum Zeitpunkt der Erstellung basierend auf seinen Anforderungen und Grenzen für Rechenressourcen festgelegt. QoS-Class werden verwendet, um Entscheidungen über die Planung und Räumung von Pods zu treffen. Kubernetes kann einem Pod eine der folgenden QoS-Class zuweisen: Garantiert, Erweiterbar oder BestEffort.

Quantity

Sun, 03 Mar 2024 11:30:36 +0000

Eine “Quantity” ist eine Darstellung von kleinen oder großen Zahlen unter Verwendung von SI-Suffixen. Quantitäten werden verwendet, um Zahlen auf kompakte Weise darzustellen, wobei ganze Zahlen und SI-Suffixe verwendet werden. Bruchzahlen werden mit Milli-Einheiten dargestellt, während große Zahlen mit Kilo-, Mega- oder Giga-Einheiten dargestellt werden können.

Zum Beispiel wird die Zahl 1,5 als 1500m dargestellt, während die Zahl 1000 als 1k und 1000000 als 1M dargestellt werden kann. Sie können auch binäre Suffixe verwenden; die Zahl 2048 kann als 2Ki geschrieben werden.

RBAC (Role-Based Access Control)

Sun, 03 Mar 2024 11:30:36 +0000

RBAC (Role-Based Access Control) ist ein Mechanismus zur Verwaltung von Autorisierungsentscheidungen in Kubernetes. Es ermöglicht Administratoren, Zugriffsrichtlinien dynamisch über die Kubernetes-API zu konfigurieren. Dies geschieht mithilfe von Rollen und Rollenbindungen.

Eine Rolle definiert die Berechtigungen, die einem Benutzer oder einer Gruppe von Benutzern für bestimmte Ressourcen im Cluster zugewiesen werden. Diese Berechtigungen umfassen Aktionen wie Lesen, Schreiben, Löschen usw. Rollen können auf Namespace-Ebene oder clusterweit definiert werden und können spezifische oder allgemeine Berechtigungen enthalten.

Replica

Sun, 03 Mar 2024 11:30:36 +0000

Eine Replica ist eine Kopie oder Duplikat eines Pods oder einer Gruppe von Pods. Replikas gewährleisten hohe Verfügbarkeit, Skalierbarkeit und Ausfallsicherheit, indem sie mehrere identische Instanzen eines Pods aufrechterhalten.

Replikas werden häufig in Kubernetes eingesetzt, um den gewünschten Anwendungsstatus und die Zuverlässigkeit zu erreichen. Sie ermöglichen das Skalieren der Workloads und die Verteilung über mehrere Nodes in einem Cluster.

Durch die Definition der Anzahl von Replikas in einem Deployment oder ReplicaSet stellt Kubernetes sicher, dass die angegebene Anzahl von Instanzen ausgeführt wird, und passt die Anzahl bei Bedarf automatisch an.

Replicaset

Sun, 03 Mar 2024 11:30:36 +0000

Ein ReplicaSet ist ein Objekt in Kubernetes, das darauf abzielt, eine bestimmte Anzahl von replizierten Pods aufrechtzuerhalten, die eine Anwendung oder einen Service darstellen. Es ist eine Möglichkeit, die Skalierung und Verfügbarkeit von Pods in einem Kubernetes-Cluster zu steuern.

Im Wesentlichen definiert ein ReplicaSet, wie viele identische Kopien eines Pods gleichzeitig ausgeführt werden sollen. Es überwacht ständig den aktuellen Zustand der Pods und startet automatisch neue Pods oder beendet vorhandene Pods, um sicherzustellen, dass die gewünschte Anzahl von Kopien immer aktiv ist.

ReplicationController

Sun, 03 Mar 2024 11:30:36 +0000

Ein ReplicationController ist ein Ressourcenobjekt in Kubernetes, das die Replica einer Anwendung verwaltet, indem es sicherstellt, dass eine bestimmte Anzahl von Instanzen eines Pods gleichzeitig ausgeführt wird. Es ist eine Möglichkeit, die Skalierung und Verfügbarkeit von Pods in einem Kubernetes-Cluster zu steuern.

Der ReplicationController überwacht kontinuierlich die Anzahl der laufenden Pods und startet automatisch neue Pods oder beendet vorhandene Pods, um sicherzustellen, dass die gewünschte Anzahl von Kopien der Anwendung immer aktiv ist. Wenn beispielsweise aufgrund von Ausfällen oder Skalierungsanforderungen die Anzahl der Pods sinkt oder steigt, passt der ReplicationController die Anzahl der Pods entsprechend an.

Resource Quotas

Sun, 03 Mar 2024 11:30:36 +0000

Resource Quotas in Kubernetes bieten einen Mechanismus zur Einschränkung des Gesamtverbrauchs von Ressourcen innerhalb eines Namespaces. Diese Quotas ermöglichen es Cluster-Administratoren, Beschränkungen für verschiedene Aspekte festzulegen, wie z. B. die Anzahl der Objekte, die erstellt werden können, und die Gesamtmenge an Rechenressourcen, die von Ressourcen innerhalb eines bestimmten Namespace verbraucht werden können.

Durch die Konfiguration von Ressourcenquoten können Administratoren verhindern, dass einzelne Projekte oder Teams die Clusterressourcen monopolisieren, und eine gerechte Ressourcenzuweisung für verschiedeneNamespace sicherstellen. Dies hilft, zu verhindern, dass ein Namespace die Leistung oder Verfügbarkeit von Ressourcen für andere, die denselben Cluster teilen, negativ beeinflusst.

Reviewer

Sun, 03 Mar 2024 11:30:36 +0000

Ein Reviewer ist eine Person, die Code auf Qualität und Richtigkeit in einem bestimmten Bereich des Projekts überprüft. Diese Person sollte über fundierte Kenntnisse des Code-Bereichs sowie der Software-Engineering-Prinzipien verfügen. Die Rolle des Reviewers besteht darin, sicherzustellen, dass der Code den Standards entspricht, Fehler minimiert und die bestmögliche Qualität aufweist. Reviewer spielen eine wichtige Rolle im Entwicklungsprozess, indem sie Feedback geben, Probleme identifizieren und Verbesserungsvorschläge machen, um sicherzustellen, dass der Code den Anforderungen und Erwartungen entspricht.

Secret

Sun, 03 Mar 2024 11:30:36 +0000

Secrets sind eine wichtige Ressource in Kubernetes, die es ermöglicht, sensible Informationen sicher in einem Cluster zu verwalten.

Arten von Secrets: Kubernetes unterstützt verschiedene Arten von Secrets, darunter generische Secrets, Docker-Registry-Secrets, TLS-Secrets und SSH-Secrets. Jeder Typ ist darauf ausgelegt, bestimmte Arten von sensiblen Informationen zu speichern.

Verwendung von Secrets: Secrets können von Pods auf verschiedene Arten verwendet werden. Zum Beispiel können sie als Umgebungsvariablen in Containern bereitgestellt werden, um sensible Konfigurationsinformationen zu übergeben. Sie können auch als Volumen in Pods gemountet werden, um sensible Daten sicher zu speichern und zwischen verschiedenen Containern oder Pods zu teilen.

Security Context

Sun, 03 Mar 2024 11:30:36 +0000

Der Security Context (Sicherheitskontext) ist ein wichtiges Konzept in Kubernetes, das es ermöglicht, Privilegien und Zugriffskontrolle für Pods und Container zu definieren. Hier sind einige wichtige Punkte zum Sicherheitskontext:

Benutzer und Gruppen: Mit dem Sicherheitskontext können Sie festlegen, unter welchem Benutzer und welcher Gruppe die Prozesse innerhalb eines Pods oder Containers ausgeführt werden sollen. Dies ermöglicht eine granulare Steuerung über die Identität, unter der Anwendungen innerhalb des Pods arbeiten.
Privilegien: Sie können auch Privilegien für Pods oder Container festlegen, um bestimmte Aktionen oder Systemressourcen einzuschränken oder zu gewähren. Dies kann helfen, potenzielle Sicherheitslücken zu minimieren, indem unnötige Berechtigungen entfernt werden.

Selector

Sun, 03 Mar 2024 11:30:36 +0000

Ein Selector ist ein Mechanismus in Kubernetes, der es Benutzern ermöglicht, eine Liste von Ressourcen basierend auf Labels zu filtern. Labels sind Schlüssel/Wert-Paare, die Ressourcen in Kubernetes markieren und organisieren.

Mit einem Selector können Benutzer spezifizieren, welche Ressourcen sie aus einer Liste abrufen möchten, indem sie Kriterien basierend auf den Labels der Ressourcen angeben. Dies ermöglicht eine präzise Auswahl von Ressourcen, die bestimmte Anforderungen erfüllen.

Beispielweise können Sie mit einem Selector alle Pods abrufen, die mit einem bestimmten Label versehen sind, oder nur diejenigen Services auswählen, die einer bestimmten Kategorie zugeordnet sind.

Service

Sun, 03 Mar 2024 11:30:36 +0000

Ein Service ist eine Methode zum Bereitstellen einer Netzwerkanwendung, die in Ihrem Cluster als ein oder mehrere Pods ausgeführt wird.

Der Service identifiziert eine Gruppe von Pods, die eine bestimmte Netzwerkanwendung implementieren, und bietet einen einheitlichen, stabilen Endpunkt für den Zugriff auf diese Anwendung. Dies wird normalerweise durch einen Selector bestimmt, der die Pods auswählt, die durch den Service abgebildet werden sollen. Wenn Pods hinzugefügt oder entfernt werden, passt der Service automatisch die Menge der zugehörigen Pods an, um sicherzustellen, dass der Datenverkehr ordnungsgemäß geroutet wird.

Service Catalog

Sun, 03 Mar 2024 11:30:36 +0000

Der Servicekatalog war eine ehemalige Erweiterungs-API, die es Anwendungen ermöglichte, die in Kubernetes-Clustern ausgeführt werden, externe gemanagte Softwareangebote wie einen Datenspeicherdienst, der von einem Cloud-Anbieter angeboten wird, einfach zu nutzen.

Er bot eine Möglichkeit, externe Managed Services ohne detaillierte Kenntnisse darüber, wie diese Dienste erstellt oder verwaltet werden, aufzulisten, bereitzustellen und zu binden.

Der Servicekatalog erleichterte die Integration von Anwendungen in Kubernetes-Cluster mit externen Diensten, indem er einen standardisierten Ansatz für die Interaktion mit diesen Diensten bereitstellte. Dies ermöglichte es Entwicklern, Dienste aus einer Vielzahl von Quellen nahtlos in ihre Anwendungen zu integrieren, ohne sich um die spezifischen Implementierungsdetails kümmern zu müssen.

ServiceAccount

Sun, 03 Mar 2024 11:30:36 +0000

Ein ServiceAccount stellt eine Identität für Prozesse bereit, die in einem Pod ausgeführt werden.

Wenn Prozesse innerhalb von Pods auf den Cluster zugreifen, werden sie vom API-Server als ein bestimmter Serviceaccount authentifiziert, zum Beispiel “default”. Wenn Sie einen Pod erstellen und keinen Serviceaccount angeben, wird automatisch der Standard-Serviceaccount im gleichen Namespace zugewiesen. Dies ermöglicht es den Prozessen, mit dem Kubernetes-API-Server zu interagieren und auf Ressourcen im Cluster zuzugreifen, während gleichzeitig ihre Identität überwacht und kontrolliert wird.

Shuffle-sharding

Sun, 03 Mar 2024 11:30:36 +0000

Shuffle-sharding ist eine Technik zur Zuweisung von Anfragen an Warteschlangen, die eine bessere Isolierung als die Hashfunktion modulo die Anzahl der Warteschlangen bietet.

Oft geht es darum, verschiedene Anfrageströme voneinander zu isolieren, damit ein Strom mit hoher Intensität nicht die Ströme mit geringer Intensität überlagert. Eine einfache Möglichkeit, Anfragen in Warteschlangen zu platzieren, besteht darin, einige Merkmale der Anfrage zu hashen, modulo die Anzahl der Warteschlangen, um den Index der zu verwendenden Warteschlange zu erhalten. Die Hashfunktion verwendet als Eingabe Merkmale der Anfrage, die sich mit den Strömen decken. Zum Beispiel ist dies im Internet oft das 5-Tupel aus Quell- und Zieladresse, Protokoll sowie Quell- und Zielport.

Sidecar Container

Sun, 03 Mar 2024 11:30:36 +0000

Sidecar-Container sind eine oder mehrere Container, die in der Regel gestartet werden, bevor andere App-Container gestartet werden. Sidecar-Container ähneln regulären App-Containern, haben jedoch einen anderen Zweck: Der Sidecar stellt einen Pod-lokalen Dienst für den Haupt-App-Container bereit. Im Gegensatz zu Init-Containern bleiben Sidecar-Container nach dem Start des Pods weiterhin aktiv. Lesen Sie auch Sidecar-Container für weitere Informationen.

Link zum offiziellen Glossar

SIGS (Special interest group)

Sun, 03 Mar 2024 11:30:36 +0000

SIGs (Special Interest Groups) sind eine essentielle Struktur innerhalb der Kubernetes-Community, die dazu beiträgt, das komplexe Ökosystem des Projekts zu verwalten und zu erweitern. Jedes SIG konzentriert sich auf ein spezifisches Thema oder einen bestimmten Aspekt von Kubernetes und wird von Community-Mitgliedern geleitet, die ein gemeinsames Interesse an diesem Bereich haben. Die SIGs müssen sich an die SIG Rollen und organisatorischen Regeln halten Diese Gruppen spielen eine entscheidende Rolle bei der Entwicklung, Dokumentation und Verbesserung verschiedener Aspekte des Kubernetes-Ökosystems.

Spec

Sun, 03 Mar 2024 11:30:36 +0000

Die Spec (Spezifikation) in Kubernetes ist ein entscheidender Bestandteil jedes Objekts, sei es ein Pod, ein Service oder eine andere Ressource. Sie definiert den gewünschten Zustand und die Konfiguration des jeweiligen Objekts, und Kubernetes arbeitet kontinuierlich daran, sicherzustellen, dass das Objekt diesem Zustand entspricht. Die Spec ist in der Regel in der YAML- oder JSON-Syntax verfasst und enthält verschiedene Einstellungen und Parameter, die spezifisch für jedes Objekt sind.

Für Pods umfasst die Spec beispielsweise Angaben zu den Containern, den Volumes, den Netzwerkeinstellungen und anderen relevanten Konfigurationen. Für Services definiert die Spec die Portweiterleitungen, die Art der Dienstbereitstellung und andere Netzwerkeinstellungen. StatefulSets haben spezifische Einstellungen für die Replikation, Persistenz und Reihenfolge der Bereitstellung von Pods.

Statefulset

Sun, 03 Mar 2024 11:30:36 +0000

Ein StatefulSet in Kubernetes verwaltet die Bereitstellung und Skalierung einer Gruppe von Pods und bietet Garantien für die Reihenfolge und Eindeutigkeit dieser Pods. Ähnlich wie bei einer Bereitstellung (Deployment) verwaltet ein StatefulSet Pods, die auf einer identischen Container-Spezifikation basieren. Im Gegensatz zu einer Bereitstellung behält ein StatefulSet jedoch eine eindeutige Identität für jeden seiner Pods bei. Diese Pods werden aus derselben Spezifikation erstellt, sind aber nicht austauschbar: Jeder hat einen persistenten Bezeichner, den er über jede Neuverplanung hinweg beibehält.

Static Pod

Sun, 03 Mar 2024 11:30:36 +0000

Ein Static Pod ist ein Pod, der direkt vom kubelet-Daemon auf einem bestimmten Node verwaltet wird, ohne dass der API-Server ihn beobachtet. Im Gegensatz zu regulären Pods, die über die Kubernetes-API verwaltet werden, werden Static Pods lokal auf dem Node definiert und gestartet.

Static Pods bieten eine Möglichkeit, Pods auf einem Kubernetes-Node zu starten, ohne dass der API-Server beteiligt ist. Sie sind nützlich für systemnahe Dienste oder Infrastrukturkomponenten, die unabhängig von der API-Serververfügbarkeit ausgeführt werden müssen. Da sie nicht von der Kubernetes-API verwaltet werden, unterstützen Static Pods keine ephemeren Container, die während der Laufzeit dynamisch hinzugefügt werden können. Alle Konfigurationen und Änderungen müssen direkt auf dem Node vorgenommen werden, auf dem der Static Pod ausgeführt wird.

Storage Class

Sun, 03 Mar 2024 11:30:36 +0000

Eine StorageClass ist ein wichtiger Bestandteil von Kubernetes, der es Administratoren ermöglicht, die verschiedenen verfügbaren Speichertypen im Cluster zu beschreiben und zu konfigurieren. Diese Funktion bietet Flexibilität und Automatisierung bei der Bereitstellung von persistentem Speicher für Anwendungen.

Die StorageClass definiert die Eigenschaften und Konfigurationen eines Speichertyps, einschließlich Aspekte wie die Art des Speichers (z. B. blockbasiert oder dateibasiert), die Speichergröße, Zugriffskontrollen, Replikation, Backup-Richtlinien und vieles mehr. Dies ermöglicht es Administratoren, Speichertypen basierend auf den Anforderungen ihrer Anwendungen zu erstellen und zu verwalten.

Sysctl

Sun, 03 Mar 2024 11:30:36 +0000

Sysctl ist eine halbstandardisierte Schnittstelle zum Lesen oder Ändern der Attribute des laufenden Unix-Kernels. Auf Unix-ähnlichen Systemen ist sysctl sowohl der Name des Tools, das Administratoren zum Anzeigen und Ändern dieser Einstellungen verwenden, als auch der Systemaufruf, den das Tool verwendet.

Durch sysctl können Administratoren verschiedene Einstellungen des Betriebssystems anpassen, um die Leistung, Sicherheit und Funktionalität des Kernels anzupassen. Diese Einstellungen umfassen Parameter wie Netzwerkeinstellungen, Dateisysteme, Speicher- und Prozessverwaltung, Netzwerkschnittstellen und vieles mehr.

Taint

Sun, 03 Mar 2024 11:30:36 +0000

Ein “Taint” ist ein Kernobjekt in Kubernetes, das aus drei erforderlichen Eigenschaften besteht: Schlüssel, Wert und Effekt. Taints verhindern die Planung von Pods auf Nodes oder Node-Gruppen.

Taints und Tolerations arbeiten zusammen, um sicherzustellen, dass Pods nicht auf ungeeigneten Nodes geplant werden. Ein oder mehrere Taints werden einem Node zugewiesen. Ein Node sollte nur einen Pod planen, der die entsprechenden Tolerations für die konfigurierten Taints aufweist.

Taints werden normalerweise verwendet, um Nodes zu markieren, die möglicherweise bestimmte Einschränkungen haben oder für spezielle Aufgaben vorgesehen sind. Zum Beispiel könnten Sie einen Node mit einem Taint markieren, der angibt, dass er nur für speicherintensive Pods geeignet ist. In diesem Fall würden nur Pods mit der entsprechenden Tolerierung für den Speicher-Taint auf diesem Node geplant werden.

Toleration

Sun, 03 Mar 2024 11:30:36 +0000

Eine “Toleration” ist ein Kernobjekt in Kubernetes, das aus drei erforderlichen Eigenschaften besteht: Schlüssel, Wert und Effekt. Tolerations ermöglichen die Planung von Pods auf Nodes oder Node-Gruppen, die entsprechende Taints aufweisen.

Tolerations und Taints arbeiten zusammen, um sicherzustellen, dass Pods nicht auf ungeeigneten Nodes geplant werden. Eine oder mehrere Tolerations werden einem Pod zugewiesen. Eine Toleration gibt an, dass der Pod auf Nodes oder Node-Gruppen mit passenden Taints geplant werden darf (aber nicht muss).

UID

Sun, 03 Mar 2024 11:30:36 +0000

Eine UID (User Identifier) ist eine von Kubernetes generierte Zeichenfolge, um Objekte eindeutig zu identifizieren. Jedes Objekt, das im Laufe des gesamten Lebenszyklus eines Kubernetes-Clusters erstellt wird, verfügt über eine eindeutige UID. Diese dient dazu, zwischen historischen Vorkommnissen ähnlicher Entitäten zu unterscheiden.

Die UID ist eine wichtige Komponente, um sicherzustellen, dass Objekte eindeutig identifiziert werden können, unabhängig davon, ob sie momentan vorhanden sind oder in der Vergangenheit erstellt wurden. Sie wird verwendet, um auf bestimmte Objekte zuzugreifen, sie zu referenzieren und sie von anderen Objekten zu unterscheiden. Die UID wird vom Kubernetes-System automatisch generiert und kann nicht vom Benutzer geändert werden.

Upstream

Sun, 03 Mar 2024 11:30:36 +0000

“Upstream” kann je nach Kontext verschiedene Bedeutungen haben:

Im Kubernetes-Community-Kontext bezieht sich “upstream” oft auf den Kern des Kubernetes-Codebasis, auf den das allgemeine Ökosystem, andere Codes oder Tools von Drittanbietern angewiesen sind. Zum Beispiel können Community-Mitglieder vorschlagen, dass ein Feature “upstream” verschoben wird, damit es im Kerncode statt in einem Plugin oder einem Tool von Drittanbietern liegt.
In GitHub oder Git bezieht sich “upstream” auf das ursprüngliche Repository, von dem ein Repository abgezweigt wurde. Das ursprüngliche Repository wird als “upstream” bezeichnet, während das abgezweigte Repository als “downstream” betrachtet wird.

User-Namespace

Sun, 03 Mar 2024 11:30:36 +0000

Das User-Namespaces-Feature im Linux-Kernel ermöglicht es einem nicht-root Benutzer, Superuser- (“root”) Berechtigungen zu emulieren. Dies ist besonders nützlich für “rootless containers”, bei denen Container ohne Superuser-Rechte außerhalb des Containers ausgeführt werden können.

Durch die Verwendung von User-Namespaces können nicht-root Benutzer privilegierte Aktionen innerhalb eines Containers ausführen, ohne dass sie über root-Berechtigungen auf dem Host-System verfügen müssen. Dies trägt dazu bei, die Sicherheit zu verbessern, indem potenzielle Schadensmöglichkeiten bei Container-Angriffen eingeschränkt werden.

Volume

Sun, 03 Mar 2024 11:30:36 +0000

Ein Volume in Kubernetes ist ein Verzeichnis, das Daten enthält und den Containern in einem Pod zugänglich ist. Anders als bei herkömmlichen Containern, die auf dem Dateisystem des Host-Betriebssystems basieren, wird ein Kubernetes-Volume innerhalb des Pod-Ökosystems verwaltet.

Ein Kubernetes-Volume besteht so lange wie der Pod, der es umgibt. Dadurch überlebt ein Volume alle Container, die innerhalb des Pods ausgeführt werden, und die Daten im Volume bleiben auch nach dem Neustart der Container erhalten.

Volume-Plugin

Sun, 03 Mar 2024 11:30:36 +0000

Ein Volume-Plugin ermöglicht die Integration von Speicher innerhalb eines Pods in Kubernetes. Es ermöglicht das Anhängen und Einbinden von Speichervolumes, die von einem Pod verwendet werden können. Volume-Plugins können in Baumstruktur (in-tree) oder außerhalb des Baumes (out-of-tree) implementiert sein.

In-Tree-Plugins sind Teil des Kubernetes-Quellcodes und folgen seinem Veröffentlichungszyklus. Sie werden gemeinsam mit Kubernetes entwickelt, gepflegt und veröffentlicht. Out-of-Tree-Plugins hingegen werden unabhängig von Kubernetes entwickelt. Sie können von Drittanbietern entwickelt und bereitgestellt werden, um spezielle Anforderungen an Speicherintegration zu erfüllen, die nicht von den standardmäßigen in-tree-Plugins abgedeckt werden.

Working Group

Sun, 03 Mar 2024 11:30:36 +0000

Eine working group - auf deutsch Arbeitsgruppe oder kurz : WG - erleichtert die Diskussion und/oder Umsetzung eines kurzlebigen, spezifischen oder entkoppelten Projekts für einen Ausschuss, eine SIG oder eine SIG-übergreifende Bemühung.

Arbeitsgruppen sind eine Möglichkeit, Personen zu organisieren, um eine spezifische Aufgabe zu erfüllen. Sie werden oft gebildet, um bestimmte Probleme anzugehen oder Projekte durchzuführen, die nicht innerhalb der üblichen Strukturen wie einer SIG oder einem Ausschuss behandelt werden können. Arbeitsgruppen können zeitlich begrenzt sein und sich auf eng umrissene Aufgaben konzentrieren, bevor sie ihre Ziele erreichen oder aufgelöst werden.

Workload

Sun, 03 Mar 2024 11:30:36 +0000

Eine Workload ist eine Anwendung, die auf Kubernetes läuft. Sie kann aus einer oder mehreren Komponenten bestehen, die verschiedene Teile der Anwendung repräsentieren, wie beispielsweise Frontend, Backend oder Datenbank. Um die verschiedenen Teile einer Anwendung auf Kubernetes zu verwalten, können verschiedene Kernobjekte verwendet werden, die als Workload-Objekte bezeichnet werden. Dazu gehören unter anderem:

DaemonSet: Stellt sicher, dass eine Kopie einer bestimmten Pod-Vorlage auf jedem Node im Cluster ausgeführt wird.
Deployment: Definiert einen Satz von identischen Pods, die eine Anwendung repräsentieren, und ermöglicht die Skalierung und Aktualisierung dieser Pods.
Job: Führt eine bestimmte Aufgabe oder einen Batch-Job aus, bis ein erfolgreicher Abschluss erreicht ist.
ReplicaSet): Sichert eine spezifizierte Anzahl von replizierten Pods und gewährleistet ihre Verfügbarkeit und Skalierbarkeit.
StatefulSet: Bietet eine Möglichkeit, Pods mit einer eindeutigen Identität und persistenten Speicher zu verwalten, wodurch die Reihenfolge und Einzigartigkeit der Pods gewährleistet wird.

Zusammen repräsentieren diese Workload-Objekte die verschiedenen Arten von Anwendungen und Aufgaben, die auf einem Kubernetes-Cluster ausgeführt werden können. Sie bieten Mechanismen zur Verwaltung, Skalierung und Wartung von Anwendungen und Diensten in einer Container-Umgebung.