Zusammenfassung: Im September dieses Jahres kündigte die Istio-Community die Open Source von Ambient Mesh an, was bei vielen Entwicklern im In- und Ausland heftige Diskussionen auslöste.
Dieser Artikel wurde von der HUAWEI CLOUD Community „ Deep Analysis! Ambient Mesh, ein neuer Modus von Istio Shared Proxy , vom HUAWEI CLOUD Cloud Native Team.
Im September dieses Jahres kündigte die Istio-Community die Open Source von Ambient Mesh an, was bei vielen Entwicklern im In- und Ausland heftige Diskussionen auslöste. Tatsächlich haben wir durch die Kommunikation mit dem Istio TOC-Mitglied linsun ( https://github.com/linsun ) erfahren, dass http://Solo.io bereits 2021 begonnen hat, auch die Forschung und das Design des Agenten zu teilen Im Jahr 2021 untersucht Google auch intern das Shared-Proxy-Modell. Daher verstanden sich die beiden Unternehmen gut und begannen von April bis Mai dieses Jahres, die Entwicklung des gemeinsamen Agenturmodells durch gemeinsame Entwicklung zu beschleunigen.
Derzeit hat Ambient Mesh eine Preview-Version veröffentlicht, die interessierte Leser auf Abruf erleben können. Aus Platzgründen stellt dieser Artikel hauptsächlich eine eingehende Analyse der Ambient Mesh-Architektur und des vierschichtigen Traffic-Management-Prozesses dar. Für eine detaillierte Erläuterung des siebenschichtigen Traffic-Managements beachten Sie bitte die Folgeartikel.
1. Was ist Ambient Mesh?
Einfach ausgedrückt ist Ambient Mesh ein neuer Modus für gemeinsam genutzten Proxy für Istio Service Mesh . Es handelt sich um ein neues Datenebenenschema , das gemeinsam von Google und http://Solo.io entwickelt wurde , um den Betrieb zu vereinfachen, die Anwendungskompatibilität zu verbessern und die Infrastrukturkosten zu senken. Der Umgebungsmodus behält die Kernfunktionen von Istio wie Zero-Trust-Sicherheit, Datenverkehrsverwaltung und Telemetrie ohne die Einführung von Sidecar bei.
2. Analyse der Ambient-Mesh-Architektur
Bevor wir mit der Architektur von Ambient beginnen, sehen wir uns kurz die Architektur von Istio an. Es besteht hauptsächlich aus zwei Teilen, nämlich der Steuerebene und der Datenebene. Die Steuerungsebene Istiod führt die grundlegende Konfigurationsgenerierung und den Push durch und verwaltet alle Datenebenen; der Sidecar-Proxy wird in die Datenebene eingeführt, um den ein- und ausgehenden Datenverkehr der Anwendung zu übernehmen.
Abbildung 1 Istio-Architektur
Im Vergleich zu Sidecar bietet Ambient Mesh eine weniger aufdringliche Option mit einfacherem Upgrade-Management. Ambient unterteilt die Funktionalität von Istio in zwei unterschiedliche Ebenen, eine Sicherheitsüberlagerung (vier Governance-Ebenen) und eine Verarbeitungsebene mit sieben Ebenen (sieben Governance-Ebenen):
Abbildung 2 Ambient Mesh ist in eine Schicht unterteilt
• Sicherheitsüberlagerungsschicht: Verarbeitung von TCP-Routing, Überwachungsindikatoren, Zugriffsprotokolle, mTLS -Tunnel, einfache Autorisierung •Siebenschichtige Verarbeitungsschicht: Zusätzlich zu den Funktionen der Sicherheitsüberlagerungsschicht bietet sie HTTP-Protokollrouting, Überwachung, Zugriffsprotokolle, Anruf Chain, Load Traffic-Management-Funktionen wie Balancing, Fusing, Current Limiting und Retry, sowie umfassende siebenschichtige Autorisierungsrichtlinien
Lasten unter Ambient Mesh können nahtlos mit Lasten im Sidecar-Modus zusammenarbeiten, sodass Benutzer die beiden Modi entsprechend ihren Anforderungen mischen und anpassen können.
• Vierstufige Governance-Architektur: Im Sidecar-Modus implementiert Istio das Abfangen des Datenverkehrs über InitContainer oder Istio-CNI. Istio-CNI stellt eine erforderliche Komponente unter Ambient Mesh dar. Die folgende Abbildung zeigt die grundlegende vierschichtige Governance-Struktur von Ambient Mesh:
Abbildung 3 Ambient-Mesh-Vierschicht-Governance-Architektur
In Istio-CNI wird ein neues Verarbeitungsmodul für Ambient hinzugefügt , das Änderungen in Namespace und Pod überwacht und Routing- und iptables-Regeln für Anwendungen auf dem Knoten festlegt:
• Routing: Richten Sie die Routing-Tabelle so ein, dass der von der Anwendung dieses Knotens gesendete Datenverkehr an ztunnel und der von diesem Knoten empfangene Datenverkehr an ztunnel geleitet wird.
• iptables: Legen Sie iptables-Regeln im ztunnel-Container fest, um Datenverkehr zum Port, der ztunnel entspricht, transparent abzufangen.
ztunnel ist eine neu eingeführte Komponente von Ambient, die auf jedem Knoten in Form von Daemonset bereitgestellt wird. ztunnel bietet mTLS, Telemetrie, Authentifizierung und L4-Autorisierung für die Anwendungskommunikation im Mesh und führt keine Verarbeitung im Zusammenhang mit dem Layer-7-Protokoll durch. Die Steuerungsebene stellt einem Ztunnel nur dann ein Workload-Zertifikat aus, wenn es auf einem Knoten mit derselben Workload ausgeführt wird. Wenn ztunnel angegriffen wird, kann daher nur das Zertifikat der Last gestohlen werden, die auf dem Knoten ausgeführt wird, und das Sicherheitsrisiko ist relativ kontrollierbar, ähnlich wie bei anderen gut implementierten Infrastrukturen zur gemeinsamen Nutzung von Knoten.
• Siebenschichtige Traffic-Governance-Architektur: Derzeit muss Ambient Mesh die siebenschichtige Verarbeitung für einen Dienst explizit aktivieren, indem eine Gateway-API-Ressource definiert wird. Die folgende Abbildung zeigt die Architektur der siebenschichtigen Governance von Ambient:
Abbildung 4 Ambient-Mesh-Governance-Architektur mit sieben Ebenen
Im Vergleich zur vierschichtigen Governance von Ambient wurde der siebenschichtigen Governance-Architektur eine Wegpunktkomponente hinzugefügt. Pilot wird ein neues Wegpunkt -Verarbeitungsmodul hinzugefügt , das die Änderungen von ServiceAccount-, Deployment- und Gateway-API-Objekten überwacht und dann die zugehörigen Wegpunkt-Objekte koordiniert:
• Wenn sich das ServiceAccount ändert, versucht Pilot, alle Wegpunkte im aktuellen Namensraum zu aktualisieren
• Wenn sich die Bereitstellung ändert, löst es die Wartung des Wegpunkts durch das Gateway-Objekt aus, das seiner OwnerReference zugeordnet ist
• Wenn sich das Gateway ändert, wird der zugeordnete Wegpunkt Proxy wird aktualisiert.
Derzeit muss sich Ambient auf Gateway-API-Ressourcen wie die folgenden verlassen, um einen Wegpunkt-Proxy zu erstellen:
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
name: productpage
annotations:
istio.io/service-account: bookinfo-productpage
spec:
gatewayClassName: istio-meshDer GatewayClassName-Wert muss auf istio-mesh gesetzt werden, andernfalls kann er ignoriert werden. Jeder ServiceAccount hat seinen eigenen dedizierten Wegpunkt-Proxy, ähnlich wie das Sidecar-Modell. Es wird empfohlen, dass jeder Dienst seine eigene separate Identität verwendet, um zusätzliche Sicherheitsrisiken zu vermeiden.
Pilot aktualisiert die Layer 7- und Layer 7-Verkehrsregeln für den Wegpunkt-Proxy über xDS, um Layer 7-bezogene Traffic-Governance-Funktionen zu implementieren. Es ist nicht unbedingt garantiert, dass sich der Wegpunkt-Proxy auf demselben Knoten befindet wie die Arbeitslast, die er bedient, was anscheinend zu bestimmten Leistungsproblemen führt. Bei Istio ist die Verzögerung jedoch eher auf die komplexe siebenschichtige Verarbeitung zurückzuführen, und es wird erwartet, dass die siebenschichtige Governance-Verzögerung des endgültigen Ambient-Modus nahe an der des Sidecar-Modus liegt. Der Wegpunkt-Agent wird über ein separates Deployment bereitgestellt, sodass er individuell mit der erforderlichen CPU und dem erforderlichen Speicher konfiguriert werden kann, die entsprechende HPA-elastische Skalierungsstrategie festlegen, nicht mehr mit der Anwendung gekoppelt ist, eine flexiblere Skalierbarkeit bieten und die Ressourcennutzung verbessern kann ein gewisses Maß Rate.
3. Ambient Mesh Vier-Layer-Traffic-Management
Wir wissen, dass ztunnel nur vierschichtiges Verkehrsmanagement, vierschichtigen Lastausgleich, TLS-Verkehrsverschlüsselung, grundlegende Authentifizierung und Authentifizierung usw. durchführen kann, aber kein fortgeschritteneres siebenschichtiges Routing und Authentifizierung durchführen kann. Hier verwenden wir das Beispiel des Zugriffs auf bookinfo über die Sleep-Anwendung, um ein tiefes Verständnis dafür zu erlangen, wie der vierschichtige Datenverkehr von Ambient Mesh geroutet wird. Der eigentliche Umgebungshintergrund dieses Beispiels ist wie folgt: Die Anwendungen sleep und productpage laufen auf zwei verschiedenen Knoten.
Abbildung 5 Ambient-Mesh-Traffic-Proxy-Prozess mit vier Schichten
• Um auf den Produktseitendienst im Sleep-Container zuzugreifen, wird die Anfrage zuerst an den Ztunnel desselben Knotens abgefangen, und der Ztunnel führt einen grundlegenden Lastenausgleich auf vier Ebenen sowie eine TLS-Verschlüsselung und -Entschlüsselung durch und wählt schließlich eine Zielinstanz (die IP von den Produktseiten-Container), um die Anfrage weiterzuleiten. .
• Wenn diese Anfrage den Knoten erreicht, auf dem sich der Produktseiten-Container befindet, wird sie zuerst von ztunnel abgefangen, der für die Entschlüsselung des TLS-Verkehrs verantwortlich ist, dann die vom Benutzer angegebene Authentifizierungsrichtlinie ausführt und die Anfrage schließlich an den Produktseiten-Container sendet.
Das Obige stellt einen grundlegenden Prozess der Ambient-Mesh-Verkehrsweiterleitung dar. Lassen Sie uns den vollständigen Kommunikationsprozess in Kombination mit der spezifischen xDS-Konfiguration genauer verstehen.
3.1 Verkehrsverarbeitung auf der Sendeseite von sleep
(1) Der Datenverkehr vom Ruhezustand zum Zugriff auf die Produktseite wird abgefangen und vom Tunnel desselben Knotens im TPROXY-Modus (transparenter Proxy) an ztunnel (Überwachung 127.0.0.1:15001) weitergeleitet.Der Vorteil der Verwendung von TPROXY besteht darin, dass das ursprüngliche Ziel beibehalten wird -Adresse, und ztunnel muss sich bei der Weiterleitung darauf verlassen.
-A PREROUTING -i pistioout -p tcp -j TPROXY --on-port 15001 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff(2) ztunnel überwacht Port 15001 über den Listener „ztunnel_outbound“. Der ztunnel_outbound-Listener unterscheidet sich vollständig vom Listener im Istio-Sidecar-Modus, er enthält eine Filterkette von allen Diensten auf diesem Knoten zu anderen Diensten im gesamten Mesh.
Abbildung 6 ztunnel_outbound-Listener
Es ist ersichtlich, dass für alle Filterketten keine Übereinstimmungsbedingungen festgelegt sind (standardmäßig alle Übereinstimmungen). Wie wählt ztunnel also die Zielfilterkette gemäß den Verkehrseigenschaften aus? Es stellt sich heraus, dass es auch eine Möglichkeit gibt, die Filterabgleichbedingungen auf dem Listener-Stamm festzulegen: Durch den folgenden Abgleich lautet die Quelladresse 10.244.1.4, die Zieladresse 10.96.179.71 und der Zielport 9080. Der Datenverkehr wird an die Filterverarbeitung "spiffe://cluster. local/ns/default/sa/sleep_to_http_productpage.default.svc.cluster.local_outbound_internal" übergeben,
Abbildung 7 Filterkettenabgleich ztunnel_outbound
(3) Der Filter „spiffe://cluster.local/ns/default/sa/sleep_to_http_productpage.default.svc.cluster.local_outbound_internal“ ist dem gleichnamigen Cluster zugeordnet. Der Cluster enthält insgesamt zwei Endpoint-Instanzen. Ein Endpoint wird nach dem Load-Balancing-Algorithmus ausgewählt, und das Wichtigste ist, die Metadaten (Ziel und Adresse des Tunnels) an den Namen „outbound_tunnel_lis_spiffe://cluster.local“ zu übergeben /ns/default/sa" Listener-Behandlung für /bookinfo-productpage".
Abbildung 8 outbound_internal interne Clusterkonfiguration
Abbildung 9 outbound_internal interner Cluster-Endpunkt
(4) Der Listener „outbound_tunnel_lis_spiffe://cluster.local/ns/default/sa/sleep“ verwendet den Filter „set_dst_address“, um die Zieladresse der Daten gemäß den Metadaten des im vorherigen Schritt ausgewählten Endpunkts festzulegen. Wenn der vorherige outbound_internal-Cluster den Endpunkt 10.244.2.8:9080 ausgewählt hat, dann setzt der Tunnel-Listener hier 10.244.2.8:15008 als Zieladresse. Außerdem hat der Listener nur einen TcpProxy, der dem Cluster mit dem Namen "outbound_tunnel_clus_spiffe://cluster.local/ns/default/sa/sleep" zugeordnet ist, dann wird der Datenverkehr natürlich an den Cluster übergeben. Ein HTTP Connect-Tunnel (der den an 10.244.2.8:9080 gesendeten Datenverkehr transportiert) wird ebenfalls im TCP-Filter zur Verwendung durch den ztunnel des Knotens festgelegt, auf dem sich die Produktseite befindet. HTTP-Tunneling ist das Trägerprotokoll für die sichere Kommunikation zwischen Ambient Mesh-Komponenten.
Abbildung 10 Konfiguration des Listeners „outbound_tunnel“.
Der Typ des outbound_tunnel-Clusters ist „ORIGINAL_DST“, und er ist mit UpstreamTlsContext konfiguriert, sodass er für die TLS-Verschlüsselung des Datenverkehrs verantwortlich ist und dann direkt an die Zieladresse gesendet wird, die 10.244.2.8:15008 lautet.
Abbildung 11: Konfiguration des Clusters „outbound_tunnel“.
3.2 Verarbeitung des Datenverkehrs auf der Empfangsseite der Produktseite
(1) Der Datenverkehr von Sleep, der auf die Produktseite zugreift (Zieladresse ist „10.244.2.8:15008“), erreicht den Knoten, auf dem sich die Produktseite befindet, und wird von TPROXY (transparenter Proxy) an ztunnel (Überwachung 127.0.0.1:15008) abgefangen Vorteile der Verwendung von TPROXY Es behält die ursprüngliche Zieladresse, und ztunnel muss sich beim Weiterleiten auf die ursprüngliche Zieladresse verlassen.
10.244.2.8 via 192.168.126.2 dev istioin table 100 src 10.244.2.1
-A PREROUTING -i pistioin -p tcp -m tcp --dport 15008 -j TPROXY --on-port 15008 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff(2) Der „ztunnel_inbound“-Listener auf ztunnel lauscht auf Port 15008, sodass der Datenverkehr zuerst vom ztunnel_inbound-Listener verarbeitet wird. TLS wird auf dem ztunnel_inbound-Listener festgelegt, und TLS-Handshake wird mit dem Downstream entsprechend seiner Konfiguration durchgeführt, sodass alle ztunnels basierend auf gegenseitiger TLS-Verschlüsselung kommunizieren. Außerdem wurde, wie Sie der nachstehenden Konfiguration entnehmen können, das CONNECT-Upgrade eingerichtet, sodass Envoy HTTP Connect-Anforderungen als Proxy weiterleitet. Außerdem wird in RouteMatch der ConnectMatcher gesetzt, wodurch der HTTP-Connect-Request an den „virtual_inbound“-Cluster zur Verarbeitung übergeben wird.
Abbildung 12 ztunnel_inbound Listener-Konfiguration
(3) Der virtual_inbound-Clustertyp ist ORIGINAL_DST, und der x-envoy-original-dst-host- HTTP-Header ist so eingestellt, dass er die ursprüngliche Zieladresse neu schreibt, und dieser Header wird von der sendenden Seite genau definiert „outbound_tunnel_lis_spiffe://cluster.local /ns/default/sa/sleep“ Listener-Einstellung mit einem Wert von 10.244.2.8:9080. Daher wird diese Anforderung schließlich erfolgreich über virtual_inbound an den Produktseitencontainer gesendet.
Abbildung 13 virtual_inbound-Clusterkonfiguration
3.3 Zusammenfassung des Ambient Mesh-Datenverkehrsmanagements auf vier Ebenen
Abbildung 14 Vollständiger Dienstzugriff Vierschicht-Proxy
Im Falle des Ruhezustandszugriffs auf die Produktseite ist der Proxy aus Sicht aller Ambient-Komponenten TCP-Datenverkehr, obwohl wir das HTTP-Protokoll verwenden. Zuvor haben wir das Arbeitsprinzip jedes Listeners und jedes Clusters in ztunnel eingehend analysiert, was kompliziert erscheinen mag. Daher hier eine kurze Zusammenfassung durch Abbildung 14. Wir stellen fest, dass es im Kommunikationsprozess nicht viele Module gibt, die tatsächlich an der Arbeit teilnehmen:
- Routing und iptables auf der Sendeseite: Verkehr an Port 15001 von ztunnel abfangen
- Sendeseite ztunnel: zwei Listener und zwei entsprechende Cluster
- Routing und iptables auf der Empfangsseite: Verkehr an Port 15008 von ztunnel abfangen
- Ztunnel empfangen: virtual_inbound Listener und zugehöriger Cluster
4. Zukunftsausblick
Sidecar ist eine Funktion von Istio. Mit Sidecar können Sie die Vorteile von Service Mesh nutzen und den Arbeits- und Wartungsaufwand reduzieren, indem Sie sehr kleine Änderungen an der Anwendung vornehmen. Der Sidecar-Modus weist jedoch auch einige Einschränkungen auf:
- Aufdringlich: Der Sidecar-Container wird im Wege des Admission Webhook injiziert und gehört zum selben Pod wie der Anwendungscontainer. Daher muss das Upgrade des Sidecars von der Rekonstruktion des Business-Containers begleitet werden. Kann die Anwendungslast stören (z. B. können fortlaufende Upgrades in langen Verbindungsszenarien Überspannungen verursachen).
- Niedrige Ressourcenauslastung: Sidecars entsprechen Anwendungen eins zu eins, und es muss ausreichend CPU und Arbeitsspeicher reserviert werden, was zu einer geringen Ressourcenauslastung des gesamten Clusters führen kann; elastische Skalierung kann nur für die gesamte Arbeitslast durchgeführt werden und kann nicht durchgeführt werden allein bei Beiwagen.
- Verkehrsunterbrechung: Die Erfassung des Datenverkehrs und die HTTP-Verarbeitung erfolgt durch Sidecar, was teuer ist und einige inkompatible HTTP-Implementierungen beschädigen kann.
Gegenwärtig hat Ambient Mesh das Problem der Bereitstellungsabhängigkeit von Anwendungen und Sidecars im Sidecar-Modus gut gelöst und muss keine Sidecars mehr einfügen; die Funktionen von Service Mesh werden über Ztunnel und Waypoint Proxy sowie die Bereitstellung und Aktualisierung von Anwendungen und Mesh bereitgestellt Komponenten ist nicht einfach wieder voneinander abhängig.
Darüber hinaus kann der Ambient-Sharing-Modus den Ressourcen-Overhead der Grid-Komponente selbst stark reduzieren, was ein großer Vorteil für ressourcenbewusste Benutzer ist.
Ambient befindet sich noch in der Vorschau, viele Funktionen befinden sich noch in der Entwicklung und viele Einschränkungen wurden in der offiziellen Dokumentation aufgeführt . Darüber hinaus haben Community-Benutzer auch neue Entdeckungen während der Verwendung gemacht:
• IPV6 wird nicht unterstützt
• Nicht kompatibel mit Calico CNI, da von Ambient erstellte iptables mit Calico in Konflikt stehen.
Gleichzeitig kann der aktuelle Envoy-basierte ztunnel Leistungsprobleme in Bezug auf xDS-Effizienz, Mandantenfähigkeit und Telemetrie haben.In der Zukunft könnte ein leichterer und leistungsfähigerer ztunnel basierend auf Rost umgeschrieben werden.
Langfristig wird das Sidecar-Modell das Mainstream-Modell für Istio bleiben. Das Ambient-Sharing-Modell hat der Istio-Community oder der Service-Mesh-Branche genug Impulse gebracht. Es wird davon ausgegangen, dass das Ambient-Sharing-Modell aufgrund der gemeinsamen Bemühungen aller Entwickler in der Community zur zweiten Wahl von Istio werden wird.