Standardisiertes Glossar | Kubernetes

Dieses Glossar soll eine umfassende, standardisierte Liste der Kubernetes-Terminologie darstellen. Es enthält technische Begriffe, die für K8 spezifisch sind, sowie allgemeinere Begriffe, die einen nützlichen Kontext bieten.
Begriffe nach ihren Tags filtern
Klicken Sie auf die [+] Indikatoren unten, um eine längere Erklärung für einen bestimmten Begriff zu erhalten.
Ressourcen, die die Funktionalität von Kubernetes erweitern.
Add-Ons installieren erklärt mehr über die Verwendung von Add-Ons in Ihrem Cluster, und listet einige populäre Add-Ons auf.
In Kubernetes, ist Affinität ein Satz Regeln, die dem Scheduler Hinweise geben, wo er Pods platzieren soll.
Es gibt zwei Arten Affinität:
Die Regeln werden mithilfe der in Pods angegebenen Label und Selektoren definiert, und sie können entweder erforderlich oder bevorzugt sein, je nachdem wie streng sie möchten, dass der Scheduler sie durchsetzen soll.
Die Aggregationsschicht erlaubt Ihnen die Installation zusätzlicher Kubernetes-artiger APIs in Ihrem Cluster.
Wenn Sie den Kubernetes API Server konfiguriert haben um zusätzliche APIs zu unterstützen, können Sie APIService Objekte hinzufügen, um einen URL Pfad in der Kubernetes API zu "belegen".
Ein Key-Value Paar, dass verwendet wird um willkürliche, nicht-identifizierende Metadaten an Objekte zu binden.
Die Metadaten in einer Annotation können klein oder groß sein, strukturiert oder unstrukturiert, und können Zeichen enthalten, die nicht in Label erlaubt sind. Clients wie Tools oder Libraries können diese Metadaten abfragen.
Die Schicht, in der verschiedene containerisierte Anwendungen laufen.
Eine Person, die verantwortlich ist für das Highlevel-Design einer Anwendung.
Ein Architekt sorgt dafür, dass die Implementierung einer Anwendung eine skalierbare und verwaltbare Interaktion mit den umgebenden Komponenten ermöglicht. Umgebende Komponenten können Datenbanken, Logging-Infrastruktur und andere Microservices sein.
Eine Person, die eine Anwendung entwickelt, die in einem Kubernetes Cluster läuft.
Ein Anwendungsentwickler fokussiert auf einen Teil der Anwendung. Die Größe des Fokus kann significant variieren.
Ein Satz zugehöriger Pfade in der Kubernetes API.
Sie können jedeAPI Gruppe ein- oder ausschalten durch Änderung der Konfiguration Ihres API Servers. Sie können auch Pfade zu spezifischen Ressourcen ein- oder ausschalten. API Gruppe vereinfacht die Erweiterung der Kubernetes API. Die API Gruppe ist festgelegt durch einen REST Pfad und durch das apiVersion Feld eines serialisierten Objekts.
An entity in the Kubernetes type system, corresponding to an endpoint on the Kubernetes API. A resource typically represents an object. Some resources represent an operation on other objects, such as a permission check.
Each resource represents an HTTP endpoint (URI) on the Kubernetes API server, defining the schema for the objects or operations on that resource.
API-initiierte Räumung ist der Prozess, durch den Sie die Räumungs API verwenden, um ein Räumungsobjekt zu erstellen, dass eine geordnete Beendung des Pods auslöst.
Sie können Räumung anfragen, indem Sie direkt die Räumungs API verwenden, mithilfe eines Clients des kube-api-servers, wie der kubectl drain Befehl. Wenn ein Räumungs Objekt erstellt wird, beendet der API Server den Pod.
API-initiierte Räumungen respektieren Ihre konfigurierte PodDisruptionBudgets und terminationGracePeriodSeconds.
API-initiierte Räumung ist nicht das gleiche wie Knotendruck Räumung.
Anwendungscontainer (oder App Container) sind die Container in einem Pod, die gestartet werden, nachdem jegliche Init Container abgeschlossen haben.
Ein Init Container erlaubt es Ihnen Initialisierungsdetails, die wichtig sind für die gesamte Arbeitslast, und die nicht mehr weiter laufen müssen, sobald der Anwendungscontainer startet, sauber abzutrennen. Wenn ein Pod keine Init Container konfiguriert hat, sind alle Container in diesem Pod App Container.
Eine Person, die Kubernetes Code Beiträge überprüfen und zulassen kann.
Während Code Review sich auf Qualität und Korrektheit des Codes konzentriert, ist das Genehmigen auf die holistische Akzeptanz eines Beitrags fokussiert. Holistische Akzeptanz achtet unter anderem auf Rückwärts- und Vorwärtskompatibilität, beachten der API und Flag Konventionen, subtile Performance- und Korrektheitsprobleme, und Interaktionen mit anderen Teilendes Systems. Approver Status ist begrenzt auf einen Teil des gesamten Codes (Codebase). Approver wurden früher Maintainer genannt.
cAdvisor (Container Advisor) ermöglicht Benutzer von Container ein besseres Verständnis des Ressourcenverbrauchs und der Performance Charakteristiken ihrer laufenden Container.
Es ist ein laufender Daemon, der Informationen über laufende Container sammelt, aggregiert, verarbeitet, und exportiert. Genauer gesagt, speichert es für jeden Container die Ressourcenisolationsparameter, den historischen Ressourcenverbrauch, die Histogramme des kompletten historischen Ressourcenverbrauchs und die Netzwerkstatistiken. Diese Daten werden pro Container und maschinenweit exportiert.
Eine Gruppe Linux Prozesse mit optionaler Isolation, Erfassung und Begrenzung der Ressourcen.
cgroup ist eine Funktion des Linux Kernels, dass die Ressourcennutzung (CPU, Speicher, Platten I/O, Netzwerk) begrenzt, erfasst und isoliert, für eine Sammling Prozesse.
CIDR (Classless Inter-Domain Routing) ist eine Notation, um Blöcke von IP Adressen zu beschreiben und wird viel verwendet in verschiedenen Netzwerkkonfigurationen.
Im Kubernetes Kontext, erhält jeder Knoten eine Reihe von IP Adressen durch die Startadresse und eine Subnetzmaske unter Verwendung von CIDR. Dies erlaubt Knoten jedem Pod eine eigene IP Adresse zuzuweisen. Obwohl es ursprünglich ein Konzept für IPv4 ist, wurde CIDR erweitert um auch IPv6 einzubinden.
Bedingungen unter denen ein Mitwirkender eine Lizenz an ein Open Source Projekt erteilt für seine Mitwirkungen.
CLAs helfen dabei rechtliche Streitigkeiten rund um Mitwirkungen und geistigem Eigentum