Suche
Container im Zaum halten

Kubernetes: Vorteile, Grundlagen & Status Quo

Lars Herrmann

© Shutterstock.com / VladisChem

Das Open-Source-Projekt Kubernetes, das bei vielen Lösungen die Basis für Container-Management bildet, stellt eine Umgebung zur automatisierten Provisionierung, Skalierung und Verwaltung von Applikations-Containern bereit. Ein Blick hinter die Kulissen zeigt die Arbeitsweise und erläutert die Vorteile.

Kubernetes wurde ursprünglich von Google-Mitarbeitern konzipiert und entwickelt. Zugleich war Google einer der ersten Unterstützer der Linux-Container-Technologie und sprach im Mai 2014 erstmals öffentlich darüber, dass die Google Cloud Services in Containern laufen. Pro Woche generierte Google mehr als zwei Milliarden Container auf der internen Plattform namens Borg, dem Vorgänger von Kubernetes.

Die umfangreichen Erfahrungen aus der Entwicklung von Borg im Laufe der Jahre haben die Kubernetes-Technologie maßgeblich beeinflusst. Red Hat war eines der ersten Unternehmen, das bereits vor der offiziellen Verfügbarkeit gemeinsam mit Google an Kubernetes gearbeitet hat, und liefert aktuell die zweitmeisten Beiträge zum Kubernetes-Upstream-Projekt. 2015 übergab Google das Kubernetes-Projekt an die neu gegründete Cloud Native Computing Foundation. Red Hat nutzt Kubernetes außerdem in deren OpenShift Container Platform.

Kubernetes bietet eine Plattform, um Container auf Clustern physischer oder virtueller Maschinen bereitzustellen und auszuführen. Als Schlüsseltechnologien nutzt Kubernetes Linux und eine Container-Runtime. Linux betreibt die Container und verwaltet Ressourcen und Sicherheit. Die Container-Runtime managt die Instanziierung und die Ressourcenzuweisung auf Host-Ebene (zum Beispiel Docker oder CRI-O).

Durch die Integration in Networking, Storage, Security und Registry Services stellt Kubernetes eine Container-Infrastruktur bereit. / Quelle: Red Hat

Mit Kubernetes können IT-Abteilungen

  • Container über mehrere Hosts hinweg orchestrieren,
  • Hardware-Ressourcen, die für die Ausführung von Unternehmensanwendungen benötigt werden, effizienter nutzen,
  • die Bereitstellung und Aktualisierung von Applikationen steuern und automatisieren,
  • Storage mounten und Speicherkapazitäten hinzufügen, um zustandsbehaftete Applikationen auszuführen,
  • Applikations-Container und deren Ressourcen skalieren.

Darüber hinaus nutzt Kubernetes die Services und Komponenten weiterer Open-Source-Projekte. Dazu zählen etwa:

  • Die Container-Registrierung mit Atomic Registry oder Docker Registry
  • Networking mit OpenvSwitch und intelligentem Edge Routing
  • Telemetrie mit Heapster, Kibana, Hawkular und Elastic
  • Security mit LDAP, SELinux, RBAC (Role-based Access Control) und OAuth (Open Authorization) mit Multi-Tenancy-Layern
  • Automatisierung mit Ansible-Playbooks für die Installation und das Cluster-Lifecycle-Management

Die wichtigsten Begriffe rund um Kubernetes

Master: Diese Maschine kontrolliert die Kubernetes Nodes. Hier erfolgen alle Task Assignments. Der Kubernetes Master ist eine Sammlung von drei Prozessen: kube-apiserver, kube-controller-manager und kube-scheduler.

Nodes: Der Kubernetes Master steuert diese Maschinen, welche die angeforderten beziehungsweise zugewiesenen Tasks ausführen.

Pod: Dabei handelt es sich um einen oder eine Gruppe von mehreren Containern, die auf einem einzelnen Node implementiert wurden. Alle Container in einem Pod teilen sich IP-Adresse, IPC, Hostname und andere Ressourcen. Sie abstrahieren Netzwerk und Storage vom darunterliegenden Container. Damit lassen sich Container einfacher in einem Cluster verschieben.

Replication Controller: Mit diesem Tool steuern Administratoren, wie viele identische Kopien eines Pods irgendwo in dem Cluster laufen sollen.

Service: Damit lassen sich Work Definitions von den Pods entkoppeln. Kubernetes Service Proxies übermitteln Service Requests automatisch an den richtigen Pod – egal, wo dieser sich im Cluster befindet und selbst dann, wenn er ersetzt wurde.

Kubelet: Dieser Dienst läuft auf den Nodes. Er liest die Container- Manifeste aus und stellt sicher, dass die definierten Container gestartet und ausgeführt werden.

Kubectl: Dieses Tool übermittelt auf Befehlszeilenebene Kommandos an Kubernetes-Cluster. Damit lassen sich Kubernetes-Objekte erstellen, untersuchen, aktualisieren und löschen.

Kubernetes läuft beispielsweise auf Red Hat Enterprise Linux Atomic Host und interagiert mit Container Pods. Ein Administrator oder das DevOps-Team übermitteln Befehle an den Kubernetes Master, der diese dann an die Nodes weiterleitet. / Quelle: Red Hat

Aktuelle Schwerpunkte von Kubernetes

Seit September 2017 ist Kubernetes in der Version 1.8 verfügbar. Die Mitglieder der Community konzentrierten sich bei der Entwicklung auf fünf Bereiche: Service Automation, Workload Diversity, Security Improvements, Extensibility und Cluster Stability.

Service Automation

Eine der Neuerungen von Kubernetes 1.8 im Bereich Service Automation ist Horizontal Pod Autoscaling (HPA). HPA ermöglicht Kubernetes die automatische Skalierung der Anzahl der Pods auf Basis der Nutzung. Anfangs beschränkte sich Kubernetes auf die Skalierung basierend auf der CPU-Auslastung. Durch die Einbeziehung von Custom Metrics erhalten die Benutzer eine größere Flexibilität bei der Skalierung von Workloads.

Custom Metrics für HPA ermöglichen eine Skalierung auf Basis beliebiger Metriken. HPA Status Conditions zeigen den aktuellen Status oder Blockierungsprobleme für HPA an. Die Monitoring Pipeline Metrics HPA API bietet eine Schnittstelle zur Skalierung auf Basis beliebiger Metriken und Request-Prozentwerten.

Workload Diversity

Die Workload Diversity befasst sich mit zwei Aspekten. Bei dem ersten geht es um Batch oder Task Based Commuting. Viele Anwender sind daran interessiert, einige Batch-Workloads auf ihre OpenShift-Cluster zu verlagern. Neu hinzugekommen sind daher einige Features, die sich im Alphastadium befinden und sich mit Batch Retries, den Wartezeiten zwischen Fehlversuchen und anderen Aktivitäten befassen, die für die Steuerung großer, paralleler oder serieller Implementierungen erforderlich sind. Der zweite Aspekt betrifft scheduleJob, das jetzt zu cronJobs wurde und sich im Betastadium befindet.

Sehr spannend ist, was in der Resource Management Working Group geschieht, die einigen Code zu Kubernetes 1.8 beisteuerte. Hier ist in den nächsten Releases von Kubernetes mit Features wie Device Manager, CPU Manager und HugePages zu rechnen.

Security Improvements: Role-based Access Control

Die Red Hat OpenShift Container Platform war eine der ersten Kubernetes-Lösungen, die Multi-Tenancy unterstützt. Mit der Mandantenfähigkeit ergibt sich gleichzeitig die Notwendigkeit, eine rollenbasierte Zugriffskontrolle (Role-based Access Control, RBAC) für den Cluster zu entwickeln. RBAC Version 1 ist mit Kubernetes 1.8 allgemein verfügbar. Die RBAC-Autorisierung ist ein direkter Port des Autorisierungssystems von OpenShift seit Version 3.0 und ermöglicht eine granulare Zugriffskontrolle auf die Kubernetes-API.

Neu sind auch sofort einsatzfähige RoleBindings, die von Discovery Roles über User-facing Roles bis zu Framework Control Roles und Controller Roles reichen. Dazu kommt die Integration mit Escalation Prevention und Node Bootstrapping und die Möglichkeit, RoleBindings und ClusterRoleBindings anzupassen und zu erweitern.

Lesen Sie auch: Kubeflow: Maschinelles Lernen für Kubernetes

Extensibility

Aufgrund der Arbeit der CLI Special Interest Group wird es möglich sein, dass kubectl – ein Command-Line-Tool zur Steuerung von Kubernetes-Clustern – mit Plug-ins arbeiten kann. Diese Funktion befindet sich noch in einem frühen Stadium und soll es erlauben, kubectl zu erweitern, ohne das Code-Repository klonen zu müssen. Entwickler schreiben den gewünschten Code in einer beliebigen Sprache und setzen dann den Befehl ab. Dies führt zu neuen Unterbefehlen, indem eine ausführbare Datei an einem bestimmten Speicherort auf der Festplatte abgelegt wird.

Die Custom Resource Definitions, über die bei Kubernetes 1.7 gesprochen wurden, befinden sich im Betastadium. Sie ermöglichen die Erweiterung der Kubernetes-API, um Funktionen bereitzustellen, die nicht in Core Kubernetes enthalten sind, aber für Benutzer wie APIs aussehen.

Cluster Stability

Um die Cluster-Stabilität zu steigern, ist in Kubernetes 1.8 ein Client Side Event Filter hinzugekommen. Er soll übermäßigen Datenverkehr auf dem API-Server stoppen, der durch interne Cluster-Komponenten verursacht wird. Neu ist auch die Möglichkeit, die Zahl der vom API-Server verarbeiteten Events zu limitieren. Schwellwerte können global auf einem Server, pro Namespace, pro User und pro Source + Object gesetzt werden.

Darüber hinaus hat Red Hat daran gearbeitet, API-Nutzern – insbe-sondere solchen, die große Datenmengen abrufen müssen – zu ermöglichen, dass sie die Ergebnisse in Pages erhalten. Dadurch wird der durch umfangreiche Queries verursachte Memory Allocation Impact verringert.

Verfolgt die IT das DevOps-Konzept, das auf einer engen Verzahnung von Entwicklung und IT-Betrieb basiert, kann die Kombination aus Container-Applikations-Plattform und Virtualisierung die jeweiligen Stärken optimal ausspielen. / Quelle: Red Hat

Ausblick: Leichtgewichtige Container-Runtime für Kubernetes

Neu in Kubernetes 1.8 ist abschließend auch eine stabile Version der leichtgewichtigen Container Runtime CRI-O. Damit ist es möglich, OCI-kompatible (Open Container Initiative) Container in Kubernetes zu nutzen – ohne zusätzlichen Code oder weitere Tools. Zum jetzigen Zeitpunkt unterstützt CRI-O als Container Runtimes runc und Clear Containers und sollte theoretisch jede Art von OCI-Runtime nutzen können. Die Community arbeitet aktuell an der Weiterentwicklung von CRI-O.

Derzeit konzentriert sich CRI-O darauf, Container zu starten und zu stoppen. Zwar verfügt CRI-O über ein Command Line Interface, es ist jedoch nur dazu gedacht CRI-O selbst zu testen und eignet sich nicht dazu, um Container in einer Produktivumgebung zu managen. Eine Möglichkeit, um Container via CRI-O zu erstellen und zu betreiben bietet beispielsweise Red Hat OpenShift Container Platform.

Verwandte Themen:

Geschrieben von
Lars Herrmann
Lars Herrmann
Lars Herrmann ist General Manager Integrated Solutions und Container Strategy bei Red Hat.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.