Kubernetes: Worum geht es dabei eigentlich? Warum ist es in aller Munde? Die Container-Orchestrierungsplattform im Überblick.

Wie Dev- und Operations-Teams Software heutzutage testen und bereitstellen, das haben containerbasierte Microservices-Architekturen maßgeblich beeinflusst und in so mancher Hinsicht grundlegend verändert. Denn Containerisierung bedeutet auch Modernisierung, vereinfacht sowohl Anwendungsskalierung als auch Deployment. Mit diesem völlig neuen Infrastruktur-Ökosystem einhergegangen sind jedoch auch neue Herausforderungen, die ihre ganz eigene Komplexität bergen.

Bei großen wie kleinen Software-Unternehmen kommt es nunmehr jeden Tag zum Deployment tausender Container-Instanzen und somit signifikanten Skalierungsanforderungen. Wie lassen sich diese handhaben?

Die Antwort: Kubernetes

Kubernetes entstammt ursprünglich der Google Development-Schmiede. Entwickelt wurde es dort als Plattform zur Container-Orchestrierung mit dem Ziel, Deployment, Skalierung und Verwaltung für containerisierte Anwendungen zu automatisieren. Seit seinem Erst-Release 2015 ist es binnen weniger Jahre zum De-facto-Standard für Container-Orchestrierung geworden und inzwischen auch das Flaggschiff-Projekt der Cloud Native Computing Foundation (CNCF). Umfassende Unterstützung leisten dabei zudem führende Tech-Unternehmen wie Google, AWS, Microsoft, IBM, Intel, Cisco und Red Hat.

So sind Deployment und Betrieb von Anwendungen in einer Microservice-Architektur mit Kubernetes optimiert möglich. Dabei wird zum Anwendungs-Deployment ein Abstraktions-Layer über mehrere Hosts gelegt. Via Kubernetes werden hier folgende Aspekte verwaltet:

• Steuerung der Ressourcenauslastung nach Anwendung oder Team
• Gleichmäßige Verteilung des Applikations-Load über die Host-Infrastruktur
• Automatisches Load Balancing für Anfragen über verschiedene Anwendungsinstanzen hinweg
• Überwachung der Ressourcenauslastung und -limits mit Neustart von Anwendungen bei übermäßiger Nutzung
• Verschiebung einer Anwendungsinstanz zu einem anderen Host bei Ressourcenmangel oder Host-Ausfall
• Automatische Nutzung zusätzlicher Ressourcen bei Verfügbarkeit durch Cluster-Erweiterung um einen Host
• Rasche Canary Deployments und Rollbacks

Warum aber haben diese Vorteile zu einem derartigen Siegeszug geführt?

Immer mehr Unternehmen setzen auf Microservices und cloudnative Architekturen. Stets zum Einsatz kommen dann auch Container, und für diese schlicht unabdingbar sind robuste Plattformen, die sich konsequent im Einsatz bewährt haben. Die Anwender selbst schätzen Kubernetes vor allem aus vier Gründen:

1. Kubernetes beschleunigt Abläufe. Mit Kubernetes lassen sich Platform-as-a-Service-Konzepte (PaaS) mit Self-Service-Modell und Abstraktions-Layer auf Hardware-Ebene gestalten. Dev-Teams können so schnell und effizient genau die Ressourcen abrufen, die sie benötigen. Werden mehr Ressourcen für zusätzliche Loads benötigt, stehen diese ebenso direkt zur Verfügung: Sämtliche Ressourcen entstammen nämlich stets einem von allen Teams genutzten Infrastruktur-Pool.

Neue Maschinen zur Ausführung einer Anwendung müssen also nicht mehr erst umständlich via Formular angefragt werden. Stattdessen kann direkt provisioniert werden, und die Ressourcen sind zeitnah einsatzbereit. Ebenso auch Kubernetes-spezifische Tools zur Automatisierung von Paketierung, Deployment und Testing. (Hierzu gehört etwa Helm, auf das wir im weiteren Verlauf genauer eingehen.)

2. Kubernetes ist kosteneffizient. Container erfordern nur geringe CPU- und Speicherressourcen und ermöglichen somit eine weitaus bessere Ressourcenauslastung als Hypervisoren und virtuelle Maschinen.

3.Kubernetes ist cloudagnostisch. Als Cloud-Plattform für Kubernetes nutzbar sind sowohl Amazon Web Services (AWS) als auch Microsoft Azure und die Google Cloud Platform (GCP). Auch eine On-Prem-Ausführung ist möglich. Workloads lassen sich so verschieben, ohne Anwendungen oder Infrastrukturen neu aufsetzen zu müssen. Etwaige Abhängigkeiten von bestimmten Anbietern bleiben somit aus.

Unternehmen wie Kublr, Cloud Foundry und Rancher bieten sogar Tooling-Lösungen zum Deployment und zur Verwaltung von Kubernetes-Clustern on-premise oder über einen beliebigen Cloud-Anbieter.

4. Die Verwaltung von Kubernetes-Implementierungen lässt sich an Cloud-Anbieter auslagern. Wie bereits bemerkt, ist Kubernetes in punkto Container-Orchestrierung der De-Facto-Standard. Umso weniger überrascht es, dass verschiedene führende Cloud-Anbieter inzwischen auch eine Fülle an eigenen Kubernetes-as-a-Service-Lösungskonzepten entwickelt haben. Amazon EKS, Google Cloud Kubernetes Engine, Azure Kubernetes Service (AKS), Red Hat OpenShift sowie IBM Cloud Kubernetes Service etwa liefern umfassende Services für Plattform-Management und entlasten Kubernetes-Nutzer somit signifikant.

Wie aber funktioniert Kubernetes genau?

Zentrale Komponente jeder Kubernetes-Implementierung sind Cluster. Ein Cluster besteht aus einer Vielzahl an virtuellen oder physischen Maschinen mit jeweils spezieller Funktion als Master oder Node. Nodes wiederum sind Hosts für je einen oder mehrere Container (in diesen laufen die Anwendungen). Der Master kommuniziert mit den Nodes und weist sie zur Erstellung bzw. Zerstörung von Containern an. Ebenso definiert er Anpassungen beim Traffic-Routing im Zuge von neuen Container-Ausrichtungen.

Das folgende Diagramm bietet einen beispielhaften Überblick eines Kubernetes-Clusters:

Wie Dev- und Operations-Teams Software heutzutage testen und bereitstellen, das haben containerbasierte Microservices-Architekturen maßgeblich beeinflusst und in so mancher Hinsicht grundlegend verändert. Denn Containerisierung bedeutet auch Modernisierung, vereinfacht sowohl Anwendungsskalierung als auch Deployment. Mit diesem völlig neuen Infrastruktur-Ökosystem einhergegangen sind jedoch auch neue Herausforderungen, die ihre ganz eigene Komplexität bergen.

Bei großen wie kleinen Software-Unternehmen kommt es nunmehr jeden Tag zum Deployment tausender Container-Instanzen und somit signifikanten Skalierungsanforderungen. Wie lassen sich diese handhaben?

Die Antwort: Kubernetes

Kubernetes entstammt ursprünglich der Google Development-Schmiede. Entwickelt wurde es dort als Plattform zur Container-Orchestrierung mit dem Ziel, Deployment, Skalierung und Verwaltung für containerisierte Anwendungen zu automatisieren. Seit seinem Erst-Release 2015 ist es binnen weniger Jahre zum De-facto-Standard für Container-Orchestrierung geworden und inzwischen auch das Flaggschiff-Projekt der Cloud Native Computing Foundation (CNCF). Umfassende Unterstützung leisten dabei zudem führende Tech-Unternehmen wie Google, AWS, Microsoft, IBM, Intel, Cisco und Red Hat.

So sind Deployment und Betrieb von Anwendungen in einer Microservice-Architektur mit Kubernetes optimiert möglich. Dabei wird zum Anwendungs-Deployment ein Abstraktions-Layer über mehrere Hosts gelegt. Via Kubernetes werden hier folgende Aspekte verwaltet:

• Steuerung der Ressourcenauslastung nach Anwendung oder Team
• Gleichmäßige Verteilung des Applikations-Load über die Host-Infrastruktur
• Automatisches Load Balancing für Anfragen über verschiedene Anwendungsinstanzen hinweg
• Überwachung der Ressourcenauslastung und -limits mit Neustart von Anwendungen bei übermäßiger Nutzung
• Verschiebung einer Anwendungsinstanz zu einem anderen Host bei Ressourcenmangel oder Host-Ausfall
• Automatische Nutzung zusätzlicher Ressourcen bei Verfügbarkeit durch Cluster-Erweiterung um einen Host
• Rasche Canary Deployments und Rollbacks

Warum aber haben diese Vorteile zu einem derartigen Siegeszug geführt?

Immer mehr Unternehmen setzen auf Microservices und cloudnative Architekturen. Stets zum Einsatz kommen dann auch Container, und für diese schlicht unabdingbar sind robuste Plattformen, die sich konsequent im Einsatz bewährt haben. Die Anwender selbst schätzen Kubernetes vor allem aus vier Gründen:

1. Kubernetes beschleunigt Abläufe. Mit Kubernetes lassen sich Platform-as-a-Service-Konzepte (PaaS) mit Self-Service-Modell und Abstraktions-Layer auf Hardware-Ebene gestalten. Dev-Teams können so schnell und effizient genau die Ressourcen abrufen, die sie benötigen. Werden mehr Ressourcen für zusätzliche Loads benötigt, stehen diese ebenso direkt zur Verfügung: Sämtliche Ressourcen entstammen nämlich stets einem von allen Teams genutzten Infrastruktur-Pool.

Neue Maschinen zur Ausführung einer Anwendung müssen also nicht mehr erst umständlich via Formular angefragt werden. Stattdessen kann direkt provisioniert werden, und die Ressourcen sind zeitnah einsatzbereit. Ebenso auch Kubernetes-spezifische Tools zur Automatisierung von Paketierung, Deployment und Testing. (Hierzu gehört etwa Helm, auf das wir im weiteren Verlauf genauer eingehen.)

2. Kubernetes ist kosteneffizient. Container erfordern nur geringe CPU- und Speicherressourcen und ermöglichen somit eine weitaus bessere Ressourcenauslastung als Hypervisoren und virtuelle Maschinen.

3.Kubernetes ist cloudagnostisch. Als Cloud-Plattform für Kubernetes nutzbar sind sowohl Amazon Web Services (AWS) als auch Microsoft Azure und die Google Cloud Platform (GCP). Auch eine On-Prem-Ausführung ist möglich. Workloads lassen sich so verschieben, ohne Anwendungen oder Infrastrukturen neu aufsetzen zu müssen. Etwaige Abhängigkeiten von bestimmten Anbietern bleiben somit aus.

Unternehmen wie Kublr, Cloud Foundry und Rancher bieten sogar Tooling-Lösungen zum Deployment und zur Verwaltung von Kubernetes-Clustern on-premise oder über einen beliebigen Cloud-Anbieter.

4. Die Verwaltung von Kubernetes-Implementierungen lässt sich an Cloud-Anbieter auslagern. Wie bereits bemerkt, ist Kubernetes in punkto Container-Orchestrierung der De-Facto-Standard. Umso weniger überrascht es, dass verschiedene führende Cloud-Anbieter inzwischen auch eine Fülle an eigenen Kubernetes-as-a-Service-Lösungskonzepten entwickelt haben. Amazon EKS, Google Cloud Kubernetes Engine, Azure Kubernetes Service (AKS), Red Hat OpenShift sowie IBM Cloud Kubernetes Service etwa liefern umfassende Services für Plattform-Management und entlasten Kubernetes-Nutzer somit signifikant.

Wie aber funktioniert Kubernetes genau?

Zentrale Komponente jeder Kubernetes-Implementierung sind Cluster. Ein Cluster besteht aus einer Vielzahl an virtuellen oder physischen Maschinen mit jeweils spezieller Funktion als Master oder Node. Nodes wiederum sind Hosts für je einen oder mehrere Container (in diesen laufen die Anwendungen). Der Master kommuniziert mit den Nodes und weist sie zur Erstellung bzw. Zerstörung von Containern an. Ebenso definiert er Anpassungen beim Traffic-Routing im Zuge von neuen Container-Ausrichtungen.

Das folgende Diagramm bietet einen beispielhaften Überblick eines Kubernetes-Clusters:

Kubernetes-Master

Der Kubernetes-Master ist gleichbedeutend mit dem Access Point (bzw. der Kontrollebene), über den Administratoren und andere Benutzer mit dem Cluster interagieren, um Container-Scheduling und -Deployment zu verwalten. Jeder Cluster verfügt stets über mindestens einen Master, je nach Replikationsmuster ggf. aber auch über mehrere.

Im Master erfasst sind die Zustands- und Konfigurationsdaten aus dem gesamten Cluster. Konkret gespeichert sind sie in der verteilten Schlüssel-Wert-Datenbank etcd. Jeder Node hat Zugriff auf etcd und lernt über sie, wie die Konfigurationen der laufenden Container zu verwalten sind. etcd kann dabei über den Kubernetes-Master oder in Standalone-Konfigurationen laufen.

Master kommunizieren mit dem verbleibenden Cluster über den kube-apiserver, den zentralen Access Point für die Kontrollebene. Der API-Server stellt sicher, dass die etcd-Konfigurationen mit denen im Cluster übereinstimmen.

Der Controller Manager verarbeitet Kontrollschleifen, die den Cluster-Zustand über den API-Server verwalten. Deployments, Replicas und Nodes laufen über diesen Service. So ist beispielsweise der Node-Controller verantwortlich für die Registrierung eines Node und die Überwachung seines Health-Status im gesamten Lebenszyklus.

Node-Workloads im Cluster werden vom Scheduler überwacht und verwaltet. Neue Nodes werden dabei je nach verfügbarer Kapazität und Ressourcen zugewiesen.

Der Cloud Controller Manager zeichnet dafür verantwortlich, dass Kubernetes cloudagnostisch bleibt. Er fungiert als Abstraktionsebene zwischen den APIs und Tools eines Cloud-Anbieters (z. B. Speichern und Load Balancern) und ihrem jeweiligen Kubernetes-Gegenstück.

Nodes

Alle Nodes in einem Kubernetes-Cluster müssen mit einer Container-Laufzeit konfiguriert werden, typischerweise in Form von Docker. Die Container-Laufzeit startet und verwaltet die Container beim Deployment in den Nodes. Die Anwendungen selbst wie Web-Server, Datenbanken, API-Server etc. werden in den Containern ausgeführt.

Jeder Kubernetes-Node läuft in einem Agent-Prozess, einem sogenannten Kubelet. Das Kubelet ist verantwortlich dafür, den Node-Status zu verwalten: Start, Stopp und Wartung der Anwendungs-Container basieren auf Anweisungen aus der Kontrollebene. Das Kubelet erfasst Performance- und Health-Informationen aus den Nodes, Pods und Containern, die es ausführt, und gibt diese Informationen an die Kontrollebene weiter, um Scheduling-Entscheidungen einzusteuern.

Der Kube-Proxy ist ein Netzwerk-Proxy, der auf Nodes im Cluster läuft. Er fungiert außerdem als Load Balancer für Services, die über einen Node ausgeführt werden.

Die grundlegende Scheduling-Einheit bilden Pods. Sie bestehen aus einem oder mehreren Containern aus derselben Host-Maschine. Sie können Ressourcen miteinander teilen und sind einer spezifischen IP-Adresse im Cluster zugewiesen, sodass die Anwendung Ports ohne etwaige IP-Konflikte nutzen kann.

Der gewünschte Status eines Containers in einem Pod wird über ein YAML- oder JSON-Objekt namens Pod Spec festgelegt. Diese Objekte werden über den API-Server an das Kubelet weitergeleitet.

Über einen Pod können ein oder mehrere Volumes definiert sein – eine lokale Festplatte oder ein Netzwerkspeicher etwa. Diese können dann für die Container im Pod als gemeinsam genutzter Speicherplatz freigegeben werden, beispielsweise wenn ein Container Inhalte herunter- und ein anderer diese dann an anderer Stelle wieder hochlädt. Pods – und somit Container – sind häufig kurzlebiger Natur. Kubernetes verfügt daher über eine Art Load Balancer in Form eines Service, um Anfragen leichter an mehrere Pods gleichzeitig senden zu können. Ziel eines Service sind mehrere Pods mit logischem Zusammenhang, der über Labels gekennzeichnet ist (mehr hierzu im weiteren Verlauf). Der Zugriff auf Services erfolgt standardmäßig nur von innerhalb eines Clusters. Durch Aktivierung des entsprechenden Features ist aber auch Zugriff von außerhalb des Clusters möglich.

Deployments und Replicas

Bei einem Deployment handelt es sich um ein YAML-Objekt, das die Pods und Container-Instanzen – Replicas – für jeden Pod festlegt. Die gewünschte Anzahl an Replicas pro Cluster wird mit einem ReplicaSet als Teil des Deployment-Objekts definiert. Hat ein Node, in dem ein Pod ausgeführt wird, das Ende seiner Lebensdauer erreicht, sorgt das ReplicaSet dafür, dass es zum Scheduling eines neuen Pods in einem anderen verfügbaren Node kommt.

Ein DaemonSet setzt Daemon-Deployment und -Ausführung in einem Pod auf vorab festgelegten Nodes um. DaemonSets kommen primär zur Bereitstellung von Services oder Wartung in Pods zum Einsatz. Ein gutes Beispiel ist hier etwa der Agent von New Relic Infrastructure: Auch sein Deployment in allen Nodes eines Clusters läuft über ein DaemonSet.

Namespaces

Mit Namespaces lassen sich auf physischen Clustern zusätzliche virtuelle Varianten erstellen. Namespaces kommen in Umgebungen mit vielen Benutzern und Teams oder Projekten ideal zum Einsatz. Ressourcenkontingente können mit ihnen neu zugewiesen und Cluster-Ressourcen logisch isoliert werden.

Labels

Labels sind Schlüssel-Wert-Paare, die Pods und anderen Objekten in Kubernetes zugewiesen werden können. Labels gestatten es Kubernetes-Nutzern, bestimmte Objekt-Untergruppen zu organisieren. Beim Monitoring von Kubernetes-Objekten lassen sich dadurch relevante Informationen fokussierter und somit rascher im Kontext erschließen.

StatefulSets und persistente Speicher-Volumes

StatefulSets weisen Pods spezifische IDs zu. Dies ist etwa dann hilfreich, wenn Pods in andere Nodes verschoben werden sollen, Pod-Netzwerke anzupassen sind oder Daten zwischen ihnen persistieren sollen. Ganz ähnlich persistente Speicher-Volumes: Sie liefern Speicher-Ressourcen für einen Cluster, auf den Pods im Zuge ihres Deployments Zugriff anfordern können.

Weitere nützliche Komponenten

Die Kubernetes-Komponenten im Folgenden bieten zusätzliche Vorteile und Möglichkeiten, sind aber für die Kernfunktionalität von Kubernetes nicht zwingend vonnöten.

Kubernetes DNS

Hierbei handelt es sich um einen Mechanismus für DNS-basierte Service Discovery zwischen Pods. Er kann parallel zu bestehenden DNS-Servern betrieben werden.

Logs auf Cluster-Ebene

Bestehende Logging-Tools können mit Kubernetes integriert werden und Anwendungs- und System-Logs auf Cluster-Ebene speichern, ausgegeben auf Standardausgabe und Standardfehler. Es ist jedoch zu beachten, dass Kubernetes über keine native Log-Speicherung verfügt. Es ist also stets eine externe Lösung notwendig.

Helm: Verwaltung von Kubernetes-Anwendungen

Helm ist eine Registry der CNCF zur Verwaltung von Anwendungspaketen für Kubernetes. Helm-Diagramme sind vorkonfigurierte Anwendungsressourcen, die heruntergeladen und in der Kubernetes-Umgebung bereitgestellt werden können. In einer Umfrage aus dem Jahr 2020 der CNCF nannten 63 % der Befragten Helm als bevorzugtes Tool zur Paketverwaltung für Kubernetes-Anwendungen. Helm-Diagramme helfen DevOps-Teams insbesondere beim Einstieg in die Verwaltung von Anwendungen in Kubernetes. Bestehende Helm-Diagramme können leicht gemeinsam genutzt, versioniert und in Dev- und Produktionsumgebung bereitgestellt werden.

Kubernetes und Istio: Eine populäre Kombination

In einer Microservices-Umgebung versteht man unter einem Service Mesh einen Infrastruktur-Layer, über den mehrere Service-Instanzen miteinander kommunizieren können. Mit diesem Service Mesh lässt sich außerdem auch konfigurieren, wie verschiedene Service-Instanzen kritisch wichtige Abläufe durchführen: Service Discovery, Load Balancing, Datenverschlüsselung, Authentifizierung und Autorisierung. Ein solches Service Mesh ist beispielsweise Istio, ein gemeinsames Projekt von Google und IBM, das sich immer größerer Beliebtheit erfreut.

Auch die Entwickler selbst bilden hier freilich keine Ausnahme: IBM Cloud etwa nutzt Istio, um Herausforderungen im Hinblick auf Kontrolle, Transparenz und Sicherheit infolge einer signifikanten Kubernetes-Implementierung zu adressieren. Hier kommen folgende Vorteile zum Tragen:

• Verknüpfung von Services und Traffic-Steuerung
• Bereitstellung von Sicherheitsfeatures für Interaktionen zwischen Microservices mit flexiblen Autorisierungs- und Authentifizierungsrichtlinien
• Einrichtung eines Kontrollpunkts zur Verwaltung von Services in der Produktion
• Einblicke in Service-Abläufe mit einem Adapter, der Daten von Istio an New Relic überträgt – und damit Monitoring-Möglichkeiten für Microservice-Performance aus Kubernetes zusammen mit bereits abgerufenen Anwendungsdaten

Herausforderungen bei der Kubernetes-Implementierung

Seit seinem Erst-Release hat Kubernetes bereits eine beachtliche Erfolgsgeschichte geschrieben. Doch gerade bei einem derart rasanten Wachstum gibt es natürlich auch gewisse Stolperschwellen, die es bei der Einführung von Kubernetes zu beachten gilt.

1. Die Tech-Landschaft rund um Kubernetes kann bisweilen etwas Verwirrung stiften. Open-Source-Technologien wie Kubernetes finden bei Entwicklern enormen Anklang, ermöglichen sie doch explosive Innovationszyklen. Zu viel Innovativität kann aber schon einmal auch für etwas Chaos sorgen – speziell dann, wenn die Codebase sich so dynamisch entwickelt, dass ihre Benutzer mit der Umsetzung nicht mehr ganz so einfach Schritt halten können. Kommen obendrein noch verschiedenste Plattform- und Managed-Service-Anbieter hinzu, sind Kubernetes-Neulinge anfangs leicht überfordert.

2. Die Pläne von Dev- und IT-Teams am Innovationspuls sind nicht immer mit Business-Prioritäten vereinbar. Ermöglichen die Budgetvorgaben kaum mehr als den Erhalt des Status quo, ist zusätzlichen Geldern für Experimentierprojekte mit Kubernetes nur schwer beizukommen, zumal diese Projekte häufig signifikanten Zeit- und Personaleinsatz bedeuten. Enterprise-IT-Teams sind zudem zumeist risikoavers und nur eingeschränkt änderungsagil.

3. Vielen Teams fehlt es in Teilen noch an der für Kubernetes wichtigen Expertise. Erst vor wenigen Jahren mussten Entwickler und IT-Ops ihre Methodik und Frameworks an Container anpassen. Nun kommt hier auch noch Container-Orchestrierung hinzu. Wer Kubernetes implementieren möchte, benötigt Unterstützung von hochqualifizierten Allround-Profis, die programmieren können, in operativen Belangen versiert und en détail mit diversen Themen rund um Anwendungs-, Speicher- und Daten-Workflows vertraut sind.

4. Kubernetes kann in der Verwaltung etwas komplex sein. Und so findet sich etwa im Kubernetes Failure Stories GitHub Repo eine ganze Kollektion an Horrorszenarien – von DNS-Ausfällen bis hin zu „Fehlern in verteilten Systemen mit Kaskadeneffekt“.

Unterwegs Richtung Kubernetes? New Relic kann helfen.

Erfolgreiche Nutzung von Kubernetes erfordert Klarheit und Transparenz zur Performance von Clustern und Workloads – rasch und ohne Umschweife. Mit New Relic analysieren Sie alle Cluster zentral über ein Interface, ganz ohne Code-Updates, Anwendungs-Redeployments oder langwierige Standardisierungsprozesse mit Ihren Teams. Auto-telemetry with Pixie vermittelt Ihnen in Minuten sofortige Transparenz in Kubernetes-Cluster und -Workloads.

Mit dem Kubernetes Cluster Explorer erhalten Sie eine zentrale Ansicht zur Analyse aller Kubernetes-Entitäten: Nodes, Namespaces, Deployments, ReplicaSets, Pods, Container und Workloads. Jedes „Kuchenstück“ im Diagramm steht für einen Node, jedes Sechseck für einen Pod. Zur Analyse der Anwendungs-Performance inklusive Log-Dateien muss einfach nur ein Pod ausgewählt werden.
 

Performance-Analyse für Pods und Anwendungen  

Auch die Distributed Traces jeder Anwendung lassen sich analysieren. Ein Klick auf einen einzelnen Span vermittelt Einblick in alle zugehörigen Kubernetes-Attribute wie zum Beispiel Pods, Cluster und Deployments.

Aus Anwendungen in Ihren Clustern können Sie zudem Distributed-Tracing-Daten abrufen.

Bei diesem Blog-Post handelt es sich um ein Update eines ursprünglich im Juli 2018 erschienenen Artikels.