Komplexität reduzieren mit Kubernetes auf Produktionsniveau

NGINX | 05. Februar 2021

Redaktion – Dieser Beitrag ist Teil einer zehnteiligen Serie:

  1. Komplexität mit produktionsreifem Kubernetes reduzieren (dieser Beitrag)
  2. So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Traffic-Management
  3. So verbessern Sie die Transparenz in Kubernetes
  4. Sechs Möglichkeiten, Kubernetes mithilfe von Traffic-Management-Tools abzusichern
  5. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
  6. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit
  7. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 3: Open Source vs. Standardlösung vs. kommerzielle Lösung
  8. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für den NGINX Ingress Controller
  9. So wählen Sie ein Service Mesh aus
  10. Leistungstests von NGINX Ingress Controllern in einer dynamischen Kubernetes-Cloud-Umgebung

Sie können die vollständige Blogreihe auch als kostenloses E-Book herunterladen: „Kubernetes von der Test- in die Produktionsumgebung überführen“.

2020 war ein Jahr, das nur wenige von uns je vergessen werden. Die plötzliche Schließung von Schulen, Unternehmen und öffentlichen Einrichtungen isolierte uns unvermittelt von unserem sozialen Umfeld und ließ uns im Ungewissen über unsere Sicherheit und finanzielle Stabilität. Stellen Sie sich nun einen Moment lang vor, dies wäre im Jahr 2000 oder sogar 2010 geschehen. Was wäre anders gewesen? Technologie. Ohne die hochwertigen digitalen Dienste, die für uns selbstverständlich sind – Gesundheitsversorgung, Videostreaming und Tools für die Zusammenarbeit aus der Ferne – wäre eine Pandemie eine völlig andere Erfahrung. Was unterschied die Technologie des Jahres 2020 so sehr von der früherer Jahrzehnte? Container und Microservices.

Microservices-Architekturen, die in der Regel Container und Kubernetes nutzen, fördern das Unternehmenswachstum und Innovationen, indem sie die Markteinführungszeit für digitale Erlebnisse verkürzen. Ob ergänzend zu herkömmlichen Architekturen oder als eigenständige Lösung: Diese modernen Anwendungstechnologien ermöglichen eine bessere Skalierbarkeit und Flexibilität, schnellere Bereitstellungen und sogar Kosteneinsparungen.

Bereits vor 2020 hatten die meisten unserer Kunden damit begonnen, Microservices als Teil ihrer Strategie für die digitale Transformation einzuführen. Die Pandemie hat die Modernisierung von Anwendungen jedoch erheblich beschleunigt. Unsere Umfrage aus dem Jahr 2020 unter NGINX-Benutzern ergab, dass 60 % der Befragten Microservices in Produktionsumgebungen einsetzen – gegenüber 40 % im Jahr 2019. Zudem sind Container mehr als doppelt so beliebt wie andere moderne Anwendungstechnologien.

Kubernetes ist der De-facto-Standard für die Verwaltung containerisierter Anwendungen, wie die Umfrage 2020 der Cloud Native Computing Foundation (CNCF) belegt. Demnach nutzen 91 % der Befragten Kubernetes – 83 % davon in der Produktion. Bei der Einführung von Kubernetes sind viele Unternehmen auf erhebliche Änderungen an der Architektur vorbereitet, werden jedoch von den organisatorischen Auswirkungen überrascht, die der großflächige Betrieb moderner Anwendungstechnologien mit sich bringt. Wenn Sie Kubernetes einsetzen, sind Sie wahrscheinlich bereits auf alle drei dieser geschäftskritischen Hindernisse gestoßen:

  • Kultur
    Auch wenn Anwendungsteams moderne Ansätze wie agile Entwicklung und DevOps einführen, unterliegen sie in der Regel weiterhin Conways Gesetz, dem zufolge „Organisationen Systeme entwerfen, die ihre eigenen Kommunikationsstrukturen widerspiegeln“. Mit anderen Worten: Verteilte Anwendungen werden von verteilten Teams entwickelt, die unabhängig voneinander arbeiten, sich aber Ressourcen teilen. Diese Struktur ermöglicht es Teams zwar, schnell zu arbeiten, fördert jedoch auch die Bildung von Silos. Zu den Folgen zählen schlechte Kommunikation (die wiederum eigene Folgen hat), Sicherheitslücken, eine unüberschaubare Vielfalt an Tools, uneinheitliche Automatisierungspraktiken und Konflikte zwischen Teams.
  • Komplexität
    Für die Implementierung unternehmenstauglicher Microservices-Technologien müssen Unternehmen eine Reihe wichtiger Komponenten zusammenstellen, die Transparenz, Sicherheit und Traffic-Management gewährleisten. In der Regel nutzen Teams dafür Infrastrukturplattformen, cloudnative Dienste und Open-Source-Tools. Jede dieser Strategien hat ihre Berechtigung, bringt jedoch auch Nachteile mit sich, die die Komplexität erhöhen können. Allzu oft entscheiden sich verschiedene Teams innerhalb eines Unternehmens für unterschiedliche Strategien, um dieselben Anforderungen zu erfüllen, wodurch „betriebliche Altlasten“ entstehen. Darüber hinaus entscheiden sich Teams zu einem bestimmten Zeitpunkt für Prozesse und Tools und verwenden diese ungeachtet der sich ändernden Anforderungen an die Bereitstellung und den Betrieb moderner, Microservices-basierter Anwendungen in Containern weiter. Die interaktive Cloud-Native-Landschaft der CNCF veranschaulicht anschaulich die Komplexität der Infrastruktur, die zur Unterstützung Microservices-basierter Anwendungen erforderlich ist. Unternehmen müssen sich umfassende Kenntnisse in einer Vielzahl unterschiedlicher Technologien aneignen. Mögliche Folgen sind die Abhängigkeit von einer bestimmten Infrastruktur, Schatten-IT, eine unübersichtliche Tool-Landschaft und eine steile Lernkurve für die mit der Wartung der Infrastruktur betrauten Personen.
  • Sicherheit
    Sicherheitsanforderungen unterscheiden sich bei Cloud-nativen und herkömmlichen Anwendungen erheblich, da Strategien wie eine abgeschottete Sicherheitsarchitektur in Kubernetes nicht praktikabel sind. Das große Ökosystem und die verteilte Struktur containerisierter Anwendungen führen zu einer deutlich größeren Angriffsfläche. Zudem bietet die Abhängigkeit von externen SaaS-Anwendungen Mitarbeitern und Außenstehenden wesentlich mehr Möglichkeiten, Schadcode einzuschleusen oder Informationen auszuschleusen. Darüber hinaus wirken sich die in den Bereichen Kultur und Komplexität beschriebenen Folgen – insbesondere die unkontrollierte Verbreitung von Tools – unmittelbar auf die Sicherheit und Ausfallsicherheit Ihrer modernen Anwendungen aus. Der Einsatz unterschiedlicher Tools in Ihrem gesamten Ökosystem zur Lösung desselben Problems ist nicht nur ineffizient, sondern stellt auch SecOps-Teams vor enorme Herausforderungen, da sie lernen müssen, jede einzelne Komponente korrekt zu konfigurieren.

Die Lösung: Kubernetes für den Produktionseinsatz

Wie bei den meisten organisatorischen Problemen liegt die Lösung zur Bewältigung der Herausforderungen von Kubernetes in einer Kombination aus Technologie und Prozessen. Im weiteren Verlauf dieses Beitrags konzentrieren wir uns auf die technologische Komponente. Halten Sie jedoch Ausschau nach künftigen Blogbeiträgen zu Prozessen und anderen Themen.

Da Kubernetes eine Open-Source-Technologie ist, gibt es zahlreiche Möglichkeiten, sie zu implementieren. Während einige Unternehmen lieber eine eigene Standard-Kubernetes-Lösung aufsetzen, schätzen viele die Kombination aus Flexibilität, klaren Vorgaben und Support, die Dienste wie Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Red Hat OpenShift Container Platform, und Rancher bieten.

Kubernetes-Plattformen können den Einstieg erleichtern, konzentrieren sich jedoch eher auf die Breite als auf die Tiefe ihres Serviceangebots. Sie erhalten dort zwar möglicherweise alle benötigten Services aus einer Hand, doch bieten diese wahrscheinlich nicht den Funktionsumfang, den Sie für eine echte Produktionsreife in großem Maßstab benötigen. Insbesondere fehlt der Fokus auf fortschrittlichen Netzwerk- und Sicherheitsfunktionen – und genau hier enttäuscht Kubernetes unserer Erfahrung nach viele Kunden.

Um Kubernetes produktionsreif zu machen, müssen Sie drei weitere Komponenten in dieser Reihenfolge hinzufügen:

  1. Eine skalierbare Ingress-/Egress-Ebene, über die Datenverkehr in den Cluster hinein- und aus ihm herausgeleitet wird
    Dies wird durch einen Ingress-Controller erreicht. Dabei handelt es sich um einen spezialisierten Load Balancer, der die Komplexität der Kubernetes-Vernetzung abstrahiert und Dienste innerhalb eines Kubernetes-Clusters mit Diensten außerhalb des Clusters verbindet. Diese Komponente wird produktionstauglich, wenn sie Funktionen umfasst, die die Ausfallsicherheit erhöhen (z. B. erweiterte Zustandsprüfungen und Prometheus-Metriken), eine schnelle Skalierung ermöglichen (dynamische Neukonfiguration) und Self-Service unterstützen (rollenbasierte Zugriffskontrolle [RBAC]).
    Topologiediagramm einer Kubernetes-Umgebung mit einem generischen Ingress-Controller, der eine skalierbare Ingress-/Egress-Ebene bereitstellt
  2. Integrierte Sicherheit zum Schutz vor Bedrohungen im gesamten Cluster
    Während außerhalb des Clusters eine „grobgranulare“ Absicherung ausreichen kann, ist innerhalb des Clusters eine „feingranulare“ Absicherung erforderlich. Je nach Komplexität Ihres Clusters gibt es drei Stellen, an denen Sie möglicherweise eine flexible Web Application Firewall (WAF) bereitstellen müssen: auf dem Ingress-Controller, als Proxy für einzelne Services und als Proxy für einzelne Pods. Dank dieser Flexibilität können Sie für sensible Anwendungen – etwa für die Abrechnung – strengere Kontrollen und bei geringerem Risiko weniger strenge Kontrollen anwenden.
    Topologiediagramm einer Kubernetes-Umgebung mit einer WAF neben einem generischen Ingress-Controller
  3. Eine skalierbare Ost-West-Traffic-Ebene zur Optimierung des Datenverkehrs innerhalb des Clusters
    Diese dritte Komponente wird benötigt, sobald Ihre Kubernetes-Anwendungen eine Komplexität und Größenordnung erreicht haben, die sich mit einfachen Tools nicht mehr bewältigen lässt. In dieser Phase benötigen Sie ein Service Mesh. Dabei handelt es sich um ein Orchestrierungstool, das eine noch präzisere Steuerung des Datenverkehrs und einen noch differenzierteren Schutz für Anwendungsdienste innerhalb des Clusters ermöglicht. Ein Service Mesh ist in der Regel dafür zuständig, das Anwendungsrouting zwischen containerisierten Anwendungen zu verwalten, eigenständige Richtlinien für gegenseitiges TLS (mTLS) zwischen Diensten bereitzustellen und durchzusetzen sowie Einblicke in die Verfügbarkeit und Sicherheit von Anwendungen zu bieten.
    Topologiediagramm einer Kubernetes-Umgebung mit einer neben einem generischen Ingress-Controller bereitgestellten WAF sowie einem Service Mesh, das eine skalierbare Ost-West-Ebene bereitstellt

Bei der Auswahl dieser Komponenten sollten Sie Portabilität und Transparenz priorisieren. Plattformunabhängige Komponenten reduzieren die Komplexität und verbessern die Sicherheit, da Ihre Teams weniger Tools erlernen und absichern müssen und Workloads je nach Geschäftsanforderungen leichter verlagert werden können. Die Bedeutung von Transparenz und Monitoring kann kaum überschätzt werden. Integrationen mit beliebten Tools wie Grafana und Prometheus ermöglichen eine zentrale Gesamtansicht Ihrer Infrastruktur und sorgen dafür, dass Ihr Team Probleme erkennt, bevor Ihre Kunden darauf stoßen. Darüber hinaus gibt es weitere ergänzende Technologien, die für den produktiven Einsatz von Kubernetes zwar nicht zwingend erforderlich, aber dennoch wesentliche Bestandteile der modernen Anwendungsentwicklung sind. Wenn Unternehmen beispielsweise bereit sind, herkömmliche Anwendungen zu modernisieren, besteht einer der ersten Schritte darin, Microservices mit einem API-Gateway zu entwickeln.

Wie NGINX Sie unterstützen kann

Unsere Kubernetes-Lösungen sind plattformunabhängig und umfassen die drei Komponenten, die Sie für den produktiven Einsatz von Kubernetes benötigen: NGINX Ingress Controller als Ingress-/Egress-Ebene, NGINX App Protect als WAF und NGINX Service Mesh als Ost-West-Ebene.

Topologiediagramm einer Kubernetes-Umgebung mit NGINX App Protect WAF, bereitgestellt zusammen mit einem NGINX Ingress Controller und NGINX Service Mesh

Diese Lösungen können Kubernetes zu Ihrem besten Freund machen, indem sie Sie in vier zentralen Bereichen unterstützen:

  • Automatisierung – Bringen Sie Ihre Apps schneller und sicherer auf den Markt
    Stellen Sie Apps bereit, skalieren, schützen und aktualisieren Sie sie mithilfe der Funktionen des NGINX Ingress Controller für Traffic-Routing und App-Onboarding in Kombination mit der automatischen Bereitstellung von NGINX Plus-Sidecars durch NGINX Service Mesh.
  • Sicherheit – Schützen Sie Ihre Kunden und Ihr Unternehmen vor bestehenden und neu auftretenden Bedrohungen
    Reduzieren Sie potenzielle Ausfallpunkte, indem Sie NGINX App Protect an einer beliebigen Stelle im Cluster bereitstellen und gleichzeitig NGINX Service Mesh und NGINX Ingress Controller verwenden, um die Ende-zu-Ende-Verschlüsselung zwischen Diensten zu steuern und durchzusetzen.
  • Performance – Bieten Sie die digitalen Erlebnisse, die Ihre Kunden und Benutzer erwarten
    Bewältigen Sie mühelos Lastspitzen und Sicherheitsbedrohungen ohne Leistungseinbußen – mit NGINX-Lösungen, die andere WAFs, Ingress-Controller und Load Balancer übertreffen.
  • Einblicke – Entwickeln Sie Ihr Unternehmen weiter und bieten Sie Ihren Kunden einen besseren Service
    Gewinnen Sie mit NGINX Ingress Controller und NGINX Service Mesh gezielte Einblicke in die Performance und Verfügbarkeit Ihrer Anwendungen. Detaillierte Traces zeigen Ihnen, wie Anfragen in Ihren Microservices-Anwendungen verarbeitet werden.

Mit NGINX bereit für den Produktivbetrieb

NGINX Ingress Controller ist als kostenlose 30-Tage-Testversion erhältlich, die NGINX App Protect zum Schutz Ihrer containerisierten Anwendungen umfasst. Wir empfehlen, das dauerhaft kostenlose NGINX Service Mesh hinzuzufügen (zum Download unter f5.com verfügbar), um Ihre Testversion optimal zu nutzen. Derzeit können Sie Ihre eigene Lizenz (BYOL) in der Cloud Ihrer Wahl verwenden.


Teilen

Über den Autor

Jenn Gile
Jenn GileLeiter Produktmarketing, NGINX

Weitere Blogbeiträge von Jenn Gile

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.