Chancen und Herausforderungen der technologischen Entwicklung in Cloud Native

Heutzutage wird Cloud Native immer beliebter, und die CNCF definiert Cloud Native wie folgt:

Basierend auf einer modernen und dynamischen Umgebung, auch bekannt als Cloud-Umgebung.
Mit Containerisierung als grundlegender Technologie, einschließlich Service Mesh, unveränderlicher Infrastruktur, deklarativer API usw.
Zu den wichtigsten Merkmalen gehören automatische Skalierung, Verwaltbarkeit, Beobachtbarkeit, Automatisierung, häufige Änderungen usw.

Laut der CNCF-Umfrage 2021 gibt es in der Kubernetes-Community eine sehr bedeutende Anzahl (über 62.000) von Mitwirkenden. Mit dem aktuellen Technologietrend investieren immer mehr Unternehmen mehr Kosten in Cloud Native und steigen frühzeitig in die Spur ein, um eine aktive Cloud-Bereitstellung zu ermöglichen. Warum setzen Unternehmen auf Cloud Native während der Entwicklung, und was bedeutet Cloud Native für sie?

Technische Vorteile von Cloud Native

Die Beliebtheit von Cloud Native ergibt sich aus seinen Vorteilen auf technischer Ebene. Es gibt zwei Hauptaspekte der Cloud-Native-Technologie, darunter die Containerisierung, angeführt von Docker, und die Container-Orchestrierung, angeführt von Kubernetes.

Docker hat Container-Images in die Technologiewelt eingeführt und sie zu einer standardisierten Bereitstellungseinheit gemacht. Tatsächlich gab es vor Docker bereits Containerisierungstechnologien. Lassen Sie uns über eine neuere Technologie sprechen, LXC (Linux Containers) im Jahr 2008. Im Vergleich zu Docker ist LXC weniger beliebt, da Docker Container-Images bereitstellt, die standardisierter und einfacher zu migrieren sind. Außerdem hat Docker den DockerHub-Dienst geschaffen, der zum weltweit größten Repository für Container-Images geworden ist. Darüber hinaus kann die Containerisierungstechnologie auch eine gewisse Ressourcenisolierung erreichen, einschließlich nicht nur CPU-, Speicher- und anderer Ressourcenisolierung, sondern auch Netzwerkstack-Isolierung, was die Bereitstellung mehrerer Anwendungsinstanzen auf derselben Maschine erleichtert.

Kubernetes wurde aufgrund des Booms von Docker populär. Die Container-Orchestrierungstechnologie, angeführt von Kubernetes, bietet mehrere wichtige Funktionen, wie Fehlerselbstheilung, Ressourcenplanung und Dienstorchestrierung. Kubernetes verfügt über einen integrierten DNS-basierten Dienstermittlungsmechanismus, und dank seiner Planungsarchitektur kann es sehr schnell skaliert werden, um die Dienstorchestrierung zu erreichen.

Immer mehr Unternehmen setzen aktiv auf Kubernetes und transformieren ihre Anwendungen, um die Kubernetes-Bereitstellung zu starten. Und das Cloud Native, über das wir sprechen, basiert tatsächlich auf der Voraussetzung von Kubernetes, dem Eckpfeiler der Cloud-Native-Technologie.

Vorteile der Containerisierung

Standardisierte Bereitstellung

Container-Images sind mittlerweile zu einer standardisierten Bereitstellungseinheit geworden. Durch die Containerisierungstechnologie können Benutzer die Bereitstellung direkt über ein Container-Image abschließen, anstatt über Binärdateien oder Quellcode. Durch den Verpackungsmechanismus des Container-Images können Sie denselben Dienst mit demselben Image starten und dasselbe Verhalten in jeder Container-Laufzeitumgebung erzeugen.

Tragbar und leichtgewichtig, kostensparend

Die Containerisierungstechnologie erreicht eine gewisse Isolierung durch die Fähigkeiten des Linux-Kernels, was wiederum die Migration erleichtert. Darüber hinaus kann die Containerisierungstechnologie Anwendungen direkt ausführen, was in der technischen Implementierung im Vergleich zur Virtualisierungstechnologie leichter ist, ohne dass ein Betriebssystem in der virtuellen Maschine benötigt wird.

Alle Anwendungen können den Kernel teilen, was Kosten spart. Und je größer die Anwendung, desto größer die Kosteneinsparungen.

Bequemlichkeit der Ressourcenverwaltung

Beim Starten eines Containers können Sie die CPU-, Speicher- oder Festplatten-IO-Eigenschaften festlegen, die für den Containerdienst verwendet werden können, was eine bessere Planung und Bereitstellung von Ressourcen ermöglicht, wenn Anwendungsinstanzen über Container gestartet werden.

Vorteile der Container-Orchestrierung

Vereinfachung des Workflows

In Kubernetes ist die Anwendungsbereitstellung einfacher zu verwalten als in Docker, da Kubernetes deklarative Konfigurationen verwendet. Beispielsweise kann ein Benutzer einfach in einer Konfigurationsdatei deklarieren, welches Container-Image die Anwendung verwenden wird und welche Dienstports freigegeben werden, ohne dass zusätzliche Verwaltung erforderlich ist. Die der deklarativen Konfiguration entsprechenden Operationen vereinfachen den Workflow erheblich.

Effizienzsteigerung und Kosteneinsparung

Ein weiterer vorteilhafter Aspekt von Kubernetes ist die Failover-Funktion. Wenn ein Knoten in Kubernetes ausfällt, plant Kubernetes die Anwendungen automatisch auf andere normale Knoten um und bringt sie zum Laufen. Der gesamte Wiederherstellungsprozess erfordert keine menschliche Intervention und Operation, was nicht nur die Betriebseffizienz auf operativer Ebene verbessert, sondern auch Zeit und Kosten spart.

Mit dem Aufstieg von Docker und Kubernetes werden Sie feststellen, dass ihr Aufkommen große Innovationen und Chancen für die Anwendungsbereitstellung gebracht hat. Container-Images als standardisierte Bereitstellungseinheiten verkürzen den Bereitstellungsprozess und erleichtern die Integration in CI/CD-Systeme.

Angesichts der Tatsache, dass die Anwendungsbereitstellung immer schneller wird, wie folgt die Anwendungsarchitektur dem Cloud-Native-Trend?

Evolution der Anwendungsarchitektur: von Monolithen, Microservices zu Service Mesh

Der Ausgangspunkt der Evolution der Anwendungsarchitektur ist immer noch die monolithische Architektur. Mit zunehmender Größe und Anforderungen der Anwendungen konnte die monolithische Architektur den Bedürfnissen der kollaborativen Teamentwicklung nicht mehr gerecht werden, sodass verteilte Architekturen schrittweise eingeführt wurden.

Unter den verteilten Architekturen ist die Microservice-Architektur die beliebteste. Die Microservice-Architektur kann Dienste in mehrere Module aufteilen, die miteinander kommunizieren, die Dienstregistrierung und -ermittlung abschließen und gemeinsame Fähigkeiten wie Flussbegrenzung und Schaltkreisunterbrechung erreichen.

Darüber hinaus gibt es verschiedene Muster, die in einer Microservice-Architektur enthalten sind. Zum Beispiel das Muster der pro-Dienst-Datenbank, bei dem jeder Microservice durch eine individuelle Datenbank repräsentiert wird, ein Muster, das Auswirkungen auf Datenbankebene auf die Anwendung vermeidet, aber möglicherweise mehr Datenbankinstanzen einführt.

Ein weiteres ist das API-Gateway-Muster, das den Eingangsverkehr des Clusters oder der gesamten Microservice-Architektur über ein Gateway empfängt und die Verkehrsverteilung über APIs abschließt. Dies ist eines der am häufigsten verwendeten Muster, und Gateway-Produkte wie Spring Cloud Gateway oder Apache APISIX können angewendet werden.

Die beliebten Architekturen erstrecken sich schrittweise auf Cloud-Native-Architekturen. Kann eine Microservice-Architektur unter Cloud Native einfach das ursprüngliche Microservice als Container-Image erstellen und direkt auf Kubernetes migrieren?

Theoretisch scheint dies möglich zu sein, aber in der Praxis gibt es einige Herausforderungen. In einer Cloud-Native-Microservice-Architektur müssen diese Komponenten nicht nur in Containern laufen, sondern auch andere Aspekte wie Dienstregistrierung, -ermittlung und Konfiguration umfassen.

Der Migrationsprozess beinhaltet auch geschäftliche Transformation und Anpassung, was die Migration von gemeinsamer Logik wie Authentifizierung, Autorisierung und Beobachtbarkeit-bezogenen Fähigkeiten (Protokollierung, Überwachung usw.) auf K8s erfordert. Daher ist die Migration von der ursprünglichen physischen Maschinenbereitstellung auf die K8s-Plattform viel komplexer als es scheint.

In diesem Fall können wir das Sidecar-Modell verwenden, um das obige Szenario zu abstrahieren und zu vereinfachen.

Typischerweise kommt das Sidecar-Modell in Form eines Sidecar-Proxys vor, der sich von der linken Seite des folgenden Diagramms zur rechten Seite entwickelt, indem einige allgemeine Fähigkeiten (wie Authentifizierung, Autorisierung, Sicherheit usw.) in das Sidecar verlagert werden. Wie Sie im Diagramm sehen können, wurde dieses Modell von der Wartung mehrerer Komponenten auf die Wartung von nur zwei Dingen (Anwendung + Sidecar) angepasst. Gleichzeitig enthält das Sidecar-Modell selbst einige gemeinsame Komponenten, sodass es nicht von der Geschäftsseite selbst gewartet werden muss, wodurch das Problem der Microservice-Kommunikation leicht gelöst wird.

sidecar

Um die komplexen Szenarien der separaten Konfiguration und des wiederholten Radbaus zu vermeiden, wenn für jeden Microservice ein Sidecar eingeführt wird, kann der Prozess durch die Einführung einer Steuerungsebene oder durch die Injektion der Steuerungsebene implementiert werden, was schrittweise das aktuelle Service Mesh bildet.

Service Mesh erfordert normalerweise zwei Komponenten, d.h. Steuerungsebene + Datenebene. Die Steuerungsebene schließt die Verteilung der Konfiguration und die Ausführung der zugehörigen Logik ab, wie Istio, das derzeit am beliebtesten ist. Auf der Datenebene können Sie ein API-Gateway wie Apache APISIX für die Verkehrsweiterleitung und Dienstkommunikation wählen. Dank der hohen Leistung und Skalierbarkeit von APISIX ist es auch möglich, einige Anpassungsanforderungen und benutzerdefinierte Logik durchzuführen. Das Folgende zeigt die Architektur der Service-Mesh-Lösung mit Istio+APISIX.

Der Vorteil dieser Lösung besteht darin, dass Sie, wenn Sie von der vorherigen Microservice-Architektur zu einer Cloud-Native-Architektur migrieren möchten, massive Änderungen auf der Geschäftsseite vermeiden können, indem Sie direkt eine Service-Mesh-Lösung verwenden.

Technische Herausforderungen von Cloud Native

Der vorherige Artikel erwähnte einige der Vorteile des aktuellen Cloud-Native-Trends in technischer Hinsicht. Allerdings hat jede Medaille zwei Seiten. Obwohl einige frische Elemente und Chancen gebracht werden können, werden Herausforderungen aufgrund der Beteiligung bestimmter Technologien auftreten.

Probleme durch Containerisierung und K8s

Im ersten Teil des Artikels erwähnten wir, dass die Containerisierungstechnologie einen gemeinsamen Kernel verwendet, und der gemeinsame Kernel bringt Leichtigkeit, aber schafft einen Mangel an Isolierung. Wenn ein Container-Escape auftritt, kann der entsprechende Host angegriffen werden. Um diesen Sicherheitsherausforderungen gerecht zu werden, wurden Technologien wie sichere Container eingeführt.

Darüber hinaus bieten Container-Images zwar eine standardisierte Bereitstellungsmethode, sind aber anfällig für Angriffe, wie z.B. Supply-Chain-Angriffe.

Ebenso hat die Einführung von K8s Herausforderungen in der Komponentensicherheit mit sich gebracht. Die Zunahme der Komponenten hat zu einem Anstieg der Angriffsfläche geführt, sowie zu zusätzlichen Schwachstellen im Zusammenhang mit den zugrunde liegenden Komponenten und Abhängigkeitsebenen. Auf der Infrastrukturebene beinhaltet die Migration von traditionellen physischen oder virtuellen Maschinen zu K8s Infrastrukturtransformationskosten und mehr Arbeitskosten, um Cluster-Datensicherungen, periodische Upgrades und Zertifikatserneuerungen durchzuführen.

Außerdem ist in der Kubernetes-Architektur der apiserver die Kernkomponente des Clusters und muss den gesamten internen und externen Verkehr verarbeiten. Um Grenzsicherheitsprobleme zu vermeiden, wird daher die Frage, wie der apiserver geschützt werden kann, zu einer Schlüsselfrage. Zum Beispiel können wir Apache APISIX verwenden, um ihn zu schützen.

Sicherheit

Die Verwendung neuer Technologien erfordert zusätzliche Aufmerksamkeit auf der Sicherheitsebene:

Auf der Netzwerksicherheitsebene kann eine feinkörnige Kontrolle des Verkehrs durch Network Policy oder andere Verbindungsverschlüsselungsmethoden wie mTLS implementiert werden, um ein Zero-Trust-Netzwerk zu bilden.
Auf der Datensicherheitsebene bietet K8s die Secret-Ressource zur Handhabung vertraulicher Daten, aber tatsächlich ist sie nicht sicher. Die Inhalte der Secret-Ressource sind in Base64 kodiert, was bedeutet, dass Sie auf die Inhalte durch Base64-Decodierung zugreifen können, insbesondere wenn sie in etcd platziert sind, was direkt gelesen werden kann, wenn Sie Zugriff auf etcd haben.
Auf der Berechtigungssicherheitsebene gibt es auch eine Situation, in der RBAC-Einstellungen nicht angemessen sind, was dazu führt, dass ein Angreifer das entsprechende Token verwendet, um mit dem apiserver zu kommunizieren und das Angriffsziel zu erreichen. Diese Art von Berechtigungseinstellung ist meist in Controller- und Operator-Szenarien zu sehen.

Beobachtbarkeit

Die meisten Cloud-Native-Szenarien beinhalten einige beobachtbarkeitsbezogene Operationen wie Protokollierung, Überwachung usw.

In K8s, wenn Sie Protokolle auf verschiedene Arten sammeln möchten, müssen Sie sie direkt auf jedem K8s-Knoten durch Aggregation sammeln. Wenn Protokolle auf diese Weise gesammelt würden, müsste die Anwendung auf die Standardausgabe oder Standardfehler exportiert werden.

Wenn das Geschäft jedoch keine relevanten Änderungen vornimmt und weiterhin alle Anwendungsprotokolle in eine Datei im Container schreibt, bedeutet dies, dass für die Protokollsammlung in jeder Instanz ein Sidecar benötigt wird, was die Bereitstellungsarchitektur extrem komplex macht.

Zurück zur Architektur-Governance-Ebene stellt die Auswahl von Überwachungslösungen in der Cloud-Native-Umgebung auch einige Herausforderungen dar. Sobald die Lösungsauswahl falsch ist, sind die nachfolgenden Nutzungskosten sehr hoch, und der Verlust kann enorm sein, wenn die Richtung falsch ist.

Außerdem gibt es auf der Überwachungsebene Kapazitätsprobleme. Während der Bereitstellung einer Anwendung in K8s können Sie einfach deren Ratenbegrenzung konfigurieren, um die Ressourcendetails zu begrenzen, die die Anwendung verwenden kann. In einer K8s-Umgebung ist es jedoch immer noch ziemlich einfach, Ressourcen zu überverkaufen, Ressourcen zu übernutzen und Speicher aufgrund dieser Bedingungen zu überlaufen.

Darüber hinaus führt eine weitere Situation in einem K8s-Cluster, in der die gesamten Cluster- oder Knotenressourcen erschöpft sind, zur Ressourcenvertreibung, was bedeutet, dass bereits auf einem Knoten laufende Ressourcen auf andere Knoten vertrieben werden. Wenn die Ressourcen eines Clusters knapp sind, kann ein Knotensturm leicht dazu führen, dass der gesamte Cluster abstürzt.

Anwendungsevolution und Multi-Cluster-Muster

Auf der Ebene der Anwendungsarchitekturevolution ist das Kernproblem die Dienstermittlung.

K8s bietet standardmäßig einen DNS-basierten Dienstermittlungsmechanismus, aber wenn das Geschäft die Koexistenz von Cloud-Geschäft und Bestandsgeschäft beinhaltet, wird es komplizierter, einen DNS-Dienstermittlungsmechanismus zu verwenden, um die Situation zu bewältigen.

Gleichzeitig, wenn Unternehmen Cloud-Native-Technologie wählen, werden sie mit der Expansion der Geschäftsskala schrittweise in Richtung Multi-Knoten-Verarbeitung gehen, was dann Multi-Cluster-Probleme mit sich bringt.

Zum Beispiel möchten wir Kunden ein höheres Verfügbarkeitsmodell durch mehrere Cluster bieten, und diesmal wird es die Orchestrierung von Diensten zwischen mehreren Clustern, die Multi-Cluster-Lastverteilung und Synchronisationskonfiguration sowie die Handhabung und Bereitstellungsstrategien für Cluster in Multi-Cloud- und Hybrid-Cloud-Szenarien betreffen. Dies sind einige der Herausforderungen, denen man sich stellen wird.

Wie APISIX die digitale Transformation ermöglicht

Apache APISIX ist ein Cloud-Native-API-Gateway unter der Apache Software Foundation, das dynamisch, in Echtzeit und leistungsstark ist und reichhaltige Verkehrsmanagementfunktionen wie Lastausgleich, dynamisches Upstream, Canary-Release, Schaltkreisunterbrechung, Authentifizierung, Beobachtbarkeit usw. bietet. Sie können Apache APISIX verwenden, um traditionellen Nord-Süd-Verkehr sowie Ost-West-Verkehr zwischen Diensten zu handhaben.

Derzeit, basierend auf der oben beschriebenen Architekturevolution und Anwendungsänderungen, wurden auch APISIX-basierte Ingress-Controller- und Service-Mesh-Lösungen in Apache APISIX abgeleitet, um Unternehmen bei der digitalen Transformation besser zu unterstützen.

APISIX Ingress-Lösung

Apache APISIX Ingress Controller ist eine Kubernetes Ingress Controller-Implementierung, die hauptsächlich als Verkehrsgateway für die Handhabung von Nord-Süd-Kubernetes-Verkehr dient.

Die APISIX Ingress Controller-Architektur ähnelt APISIX darin, dass es eine separate Architektur für die Steuerungsebene und die Datenebene gibt. In diesem Fall wird APISIX als Datenebene für die tatsächliche Verkehrsverarbeitung verwendet.

Derzeit unterstützt der APISIX Ingress Controller die folgenden drei Konfigurationsmethoden und ist mit allen APISIX-Plugins sofort kompatibel:

Unterstützung für native Ingress-Ressourcen von K8s. Dieser Ansatz ermöglicht es dem APISIX Ingress Controller, ein höheres Maß an Anpassungsfähigkeit zu haben. Bisher ist der APISIX Ingress Controller die am meisten unterstützte Version eines Open-Source- und einflussreichen Ingress-Controller-Produkts.
Unterstützung für die Verwendung benutzerdefinierter Ressourcen. Die aktuellen benutzerdefinierten Ressourcen des APISIX Ingress Controllers sind eine Reihe von CRD-Spezifikationen, die nach APISIX-Semantik entworfen wurden. Die Verwendung benutzerdefinierter Ressourcen erleichtert die Integration mit APISIX und ist nativ.
Unterstützung für Gateway API. Als nächste Generation des Ingress-Standards hat der APISIX Ingress Controller begonnen, die Gateway API (Beta-Phase) zu unterstützen. Da sich die Gateway API weiterentwickelt, wird sie wahrscheinlich direkt zu einer integrierten Ressource für K8s.

Der APISIX Ingress Controller hat gegenüber Ingress NGINX die folgenden Vorteile:

Architektonische Trennung. In APISIX Ingress sind die Architekturen der Datenebene und der Steuerungsebene getrennt. Wenn der Verkehrsverarbeitungsdruck hoch ist und Sie die Kapazität erweitern möchten, können Sie einfach die Datenebene erweitern, was es ermöglicht, mehr Datenebenen extern zu bedienen, ohne Anpassungen an der Steuerungsebene vornehmen zu müssen.
Hohe Skalierbarkeit und Unterstützung für benutzerdefinierte Plugins.
Als Wahl der Datenebene, mit hoher Leistung und vollständig dynamischen Funktionen. Dank der vollständig dynamischen Funktion von APISIX ist es möglich, den Geschäftsverkehr so weit wie möglich mit der Verwendung von APISIX Ingress zu schützen.

Derzeit wird der APISIX Ingress Controller von vielen Unternehmen weltweit verwendet, wie z.B. China Mobile Cloud Open Platform (ein Open-API- und Cloud-IDE-Produkt), Upyun und Copernicus (Teil von Europas Eyes on Earth).

Der APISIX Ingress Controller wird kontinuierlich weiterentwickelt, und wir planen, mehr Funktionen auf folgende Weise zu verbessern:

Vollständige Unterstützung der Gateway API, um mehr Szenariokonfigurationen zu ermöglichen.
Unterstützung für externen Dienstproxy.
Native Unterstützung für mehrere Registrierungen, um den APISIX Ingress Controller vielseitiger zu machen.
Architektonische Updates, um ein neues Architekturmodell zu schaffen;
Integration mit Argo CD/Flux und anderen GitOps-Tools, um ein reiches Ökosystem zu schaffen.

Wenn Sie an der APISIX Ingress-Lösung interessiert sind, folgen Sie bitte den Community-Updates für Produktiterationen und Community-Trends.

APISIX Service Mesh-Lösung

Derzeit wird neben der API-Gateway- und Ingress-Lösung auch die APISIX-basierte Service-Mesh-Lösung aktiv weiterentwickelt.

Die APISIX-basierte Service-Mesh-Lösung besteht aus zwei Hauptkomponenten, nämlich der Steuerungsebene und der Datenebene. Istio wurde für die Steuerungsebene gewählt, da es ein Branchenführer mit einer aktiven Community ist und von mehreren Anbietern unterstützt wird. APISIX wurde gewählt, um Envoy auf der Datenseite zu ersetzen, wodurch die hohe Leistung und Skalierbarkeit von APISIX zum Tragen kommt.

Das APISIX Service Mesh wird weiterhin aktiv verfolgt, mit nachfolgenden Iterationen in den folgenden Richtungen:

Durchführung von eBPF-Beschleunigung, um die Gesamteffektivität zu verbessern.
Integration von Plugin-Fähigkeiten, um eine bessere Nutzung der APISIX Ingress-Fähigkeiten innerhalb der Service-Mesh-Architektur zu ermöglichen.
Erstellung eines nahtlosen Migrationswerkzeugs, um einfachere Tools bereitzustellen und den Prozess für Benutzer zu vereinfachen.

Im Allgemeinen bringt uns die Evolution von Architektur und Technologie im Cloud-Native-Zeitalter sowohl Chancen als auch Herausforderungen. Apache APISIX als Cloud-Native-Gateway hat sich der Anpassung und Integration von mehr Technologien für den Cloud-Native-Trend verpflichtet. Verschiedene Lösungen basierend auf APISIX haben auch begonnen, Unternehmensbenutzern bei der digitalen Transformation zu helfen und Unternehmen den Übergang zur Cloud-Native-Spur zu erleichtern.