Aktivieren Sie Oracle Cloud Infrastructure Service Mesh in Ihren Kubernetes-Anwendungen
Kunden von Oracle Cloud Infrastructure (OCI) haben sich zunehmend zu einer Microservices-Architektur entwickelt, die zusammen mit ihren Vorteilen auch neue Herausforderungen mit sich bringt. In einer Microservices-Architektur werden monolithische Anwendungen in kleinere Microservices unterteilt, die über das Netzwerk über eine API kommunizieren. Dies führt zu einem Anstieg des Netzwerkverkehrs und erhöht die Komplexität und die allgemeine Angriffsfläche in der Architektur.
- Ermöglicht die Steuerung des Microservices-Trafficflusses.
- Bietet Einblick in Ihre Anwendungen.
- Ermöglicht die sichere Verbindung von Microservices ohne Änderungen am Anwendungscode.
Funktionen von OCI Service Mesh
- Durchsetzung von sicherheitsbezogenen Policys
OCI Service Mesh verwendet Zugriffs-Policys zur Definition von Zugriffsregeln. Zugriffs-Policys setzen die Kommunikation zwischen Microservices durch und lassen nur validierte Anforderungen zu, die innerhalb und außerhalb der Anwendung stammen. Zugriffs-Policys werden auch verwendet, um die zulässige Kommunikation mit externen Services zu definieren.
- Zero Trust
OCI Service Mesh implementiert automatisch eine Zero-Trust-Sicherheitsarchitektur für alle Microservices. Daten zwischen Microservices werden verschlüsselt. Zu Beginn der Kommunikation ist eine Microservice-zu-Microservice-Identifizierung erforderlich. Die beiden Parteien müssen Zugangsdaten mit ihren Identitätsinformationen austauschen. Auf diese Weise können sich die Services gegenseitig identifizieren, um festzustellen, ob sie zur Interaktion berechtigt sind. Dies wird mit gegenseitiger TLS mit automatisierter Zertifikat- und Schlüsselrotation mit dem Oracle Cloud Infrastructure Certificates-(OCI-Zertifikate-)Service und Oracle Key Management Cloud Service zur Verwaltung von Zertifikaten und Schlüsseln implementiert.
- Trafficverschiebung
Mit OCI Service Mesh können Sie Canary Deployments ausführen. Wenn Sie eine neue Version Ihres Codes in der Produktion veröffentlichen, lassen Sie nur einen Teil des Traffics zu. Mit dieser Funktion können Sie schnell bereitstellen und die Anwendung am wenigsten stören. Sie können Routingregeln definieren, die für die gesamte Kommunikation zwischen Microservices innerhalb des Meshs gelten. Sie können einen Teil des Datenverkehrs an eine bestimmte Version des Service weiterleiten.
- Überwachung und Logging
OCI Service Mesh ist einzigartig positioniert, um Telemetriedaten bereitzustellen, da die gesamte Kommunikation zwischen Microservices diese durchlaufen muss. Auf diese Weise kann das Service-Mesh Telemetriedaten wie Quelle, Ziel, Protokoll, URL, Dauer, Statuscode, Latenz, Logging und andere detaillierte Statistiken erfassen. Sie können Logginginformationen in den Oracle Cloud Infrastructure Logging-(OCI Logging-)Service exportieren. OCI Service Mesh stellt zwei Logtypen bereit: Fehlerlogs und Trafficlogs. Mit diesen Logs können Sie 404- oder 505-Probleme debuggen oder logbasierte Statistiken generieren. Metriken und Telemetriedaten können in Prometheus exportiert und mit Grafana visualisiert werden. Beide können direkt in einem OKE-Cluster bereitgestellt werden.
Architektur
Oracle Cloud Infrastructure Service Mesh (OCI Service Mesh) verwendet ein Sidecar-Modell. Diese Architektur kapselt den Code, der die Netzwerkfunktionalität implementiert, in einen Netzwerkproxy ein und verlässt sich dann auf den Traffic von und zu den Services, der in den Sidecar-Proxy umgeleitet werden soll. Es wird ein Sidecar genannt, weil an jeder Anwendung ein Proxy angebracht ist, ähnlich wie ein Sidecar, der an einem Motorrad befestigt ist. In OKE befindet sich der Anwendungscontainer neben dem Proxy-Sidecar-Container im selben Pod. Da sie sich im selben Pod befinden, verwenden sie denselben Netzwerk-Namespace und dieselbe IP-Adresse, sodass die Container über "localhost" kommunizieren können.
- Control Plane
Die OCI Service Mesh-Control Plane verwaltet und konfiguriert die gesamte Sammlung von Proxys, um Traffic weiterzuleiten. Es verarbeitet Weiterleitung, Integritätsprüfung, Load Balancing, Authentifizierung, Autorisierung und Aggregation von Telemetrie. Die Control Plane interagiert mit dem OCI-Zertifikatsservice und dem OCI-Schlüsselverwaltungsservice, um jedem Proxy sein Zertifikat bereitzustellen.
- Data Plane
Die Data Plane besteht aus der Sammlung von Sidecar-Proxies, die in der Umgebung eingesetzt werden, und ist für die Sicherheit, Netzwerkfunktionen und Beobachtbarkeit der Anwendung verantwortlich. Sie sammeln und melden auch Telemetrie über den gesamten Netzverkehr. Der Envoy-Proxy wird für die Data Plane von OCI Service Mesh verwendet.
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.
oci_service_mesh_oke_arch-oracle.zip
Diese Referenzarchitektur zeigt eine Anwendung, die in einem OKE-Cluster mit drei Services bereitgestellt ist. Der Namespace, in dem die Anwendung bereitgestellt wird, wurde "meshifiziert". Ein "meshified"-Namespace gibt an, dass die im Namespace bereitgestellten Services Teil eines Service-Meshs sind, und dass jeder neue bereitgestellte Pod mit einem Stellvertreter-Proxycontainer injiziert wird. Bei der Bereitstellung jedes Pods werden Konfigurationen und Zertifikate von der OCI Service Mesh-Control Plane an jeden der Proxycontainer gesendet. Die OCI Service Mesh-Control Plane kommuniziert mit dem OCI Certificates-Service und Oracle Key Management Cloud Service, um Zertifikate für jeden Proxy abzurufen.
Ein Ingress-Gateway wird bereitgestellt, um externen Zugriff auf die Anwendung zu ermöglichen. Das Ingress-Gateway ist Teil der OCI Service-Mesh-Data Plane und außerdem ein Stellvertreterproxy, der Konfiguration und Zertifikate von der OCI Service-Mesh-Control Plane empfängt.
Der Proxycontainer ist dafür verantwortlich, Service-Discovery, Trafficverschlüsselung und Authentifizierung mit dem Zielservice auszuführen. Die Proxycontainer wenden auch Netzwerkrichtlinien an, wie z. B. die Verteilung des Datenverkehrs zwischen verschiedenen Serviceversionen und die Durchsetzung von Zugriffsrichtlinien. Das Ingress-Gateway führt dieselbe Funktion für Traffic außerhalb des Service-Mesh aus.
Prometheus und Grafana werden im OKE-Cluster in einem separaten Namespace bereitgestellt, der nicht Teil des Service-Mesh ist. Die Service-Mesh-Data Plane sendet wichtige Betriebsstatistiken wie Latenz, Fehler, Anforderungen und Telemetrie an das Prometheus-Deployment. Grafana ruft Daten aus dem Prometheus-Deployment ab, mit dem Dashboards zur Visualisierung erstellt werden können.
OCI Service Mesh ist in den OCI Logging-Service integriert, und das Logging kann aktiviert werden, wenn das Service-Mesh erstellt wird. OCI Service Mesh stellt zwei Logtypen bereit: Fehlerlogs und Trafficlogs. Diese Logs können zum Debuggen von 404 oder 505 Problemen oder zum Generieren protokollbasierter Statistiken verwendet werden.
Diese Architektur verfügt über die folgenden OCI-Services:
- OCI Kubernetes Engine (OKE)
Bietet ein hochverfügbares, skalierbares, produktionsfähiges Kubernetes-Cluster für die Bereitstellung Ihrer containerisierten Anwendungen in der Cloud.
- Load Balancer
Bietet Zugriff auf das Ingress-Gateway im OKE-Cluster. Der Ingress leitet den Traffic an angeforderte Services im OKE-Cluster weiter.
- Certificate Authority
Verwaltet die TLS-Zertifikate für den OCI Service-Mesh-Service.
- Key Management
Verwaltet die vom Certificate Authority-Service verwendeten Schlüssel.
Die Architektur umfasst die folgenden Komponenten:
- Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domain bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).
- Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.
- Sicherheitsliste
Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der im Subnetz und aus dem Subnetz zugelassen werden muss.
OCI Service Mesh-Ressourcen
| Kubernetes-Ressourcen | Beschreibung |
| Mesh | Das Mesh auf der obersten Ebene ist der logische Container für alle Microservices in Ihrer Anwendung. |
| Virtueller Service | Ein virtueller Service ist eine logische Darstellung von Microservice in einem Service-Mesh. |
| Virtuelle Deployments | Ein virtuelles Deployment ist eine logische Darstellung eines Deployments, das in einem virtuellen Service gruppiert werden kann. Dadurch kann ein virtueller Service den Datenverkehr zwischen verschiedenen Versionen des Microservice verteilen. Ein Kubernetes-Microservice kann über mehrere Versionen verfügen, die separate Deployments im Cluster sind. |
| Virtual Deployment Bindings | Virtuelle Bindings werden verwendet, um eine Gruppe von Pods mit einem virtuellen Deployment zu verknüpfen. |
| Routentabellen von virtuellem Service | Eine virtuelle Routentabelle definiert, wie der Traffic basierend auf Protokoll und Pfad zwischen virtuellen Deployments in einem virtuellen Service verteilt wird. Jeder virtuelle Service verfügt über eine virtuelle Routentabelle. |
| Ingress-Gateway-Deployment | Ein Ingress-Gateway-Deployment erstellt Ingress-Pods, die als Load Balancer für eingehenden Traffic zum Mesh fungieren. |
| Ingress-Gateways | Ingress-Gateways verwalten Ingress-Traffic in das Mesh. Die Ingress-Gateways definieren eine Reihe von Regeln für die Kommunikation des externen Traffics mit dem Mesh, z.B. ob die Verschlüsselung für den gesamten eingehenden und ausgehenden Traffic erforderlich ist. Diese Regeln werden auf das Ingress-Gateway-Deployment angewendet. |
| Routentabellen von Ingress-Gateway | Routentabellen von Ingress-Gateway werden mit einem Ingress-Gateway-Deployment verknüpft. Die Routentabelle definiert, auf welche virtuellen Services im Mesh über das Ingress-Gateway-Deployment zugegriffen werden kann. |
| Zugriffs-Policys | Zugriffs-Policys sind festgelegte Regeln, mit denen die zulässige Kommunikation zwischen Microservices im Mesh und externen Anwendungen definiert wird. |
Das folgende Diagramm zeigt, wie die konfigurierten OCI-Service-Mesh-Ressourcen: Zugriffs-Policys, Ingress-Gateway, virtueller Service und virtuelles Deployment Ihren Anwendungsressourcen zugeordnet sind: K8s-Service, K8s-Service-Load Balancer, Deployments und Pods.
Empfehlungen
- VCN
Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich innerhalb des privaten IP-Standardadressraums befinden.
Wählen Sie CIDR-Blöcke aus, die sich nicht mit einem anderen Netzwerk (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, zu dem Sie private Verbindungen einrichten möchten.
Nachdem Sie ein VCN erstellt haben, können Sie die CIDR-Blöcke ändern, hinzufügen und entfernen.
Berücksichtigen Sie beim Entwerfen der Subnetze Ihren Trafficfluss und Ihre Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.
- Load-Balancer-Bandbreite
Beim Erstellen des Load Balancers können Sie entweder eine vordefinierte Ausprägung auswählen, die eine feste Bandbreite bereitstellt, oder eine benutzerdefinierte (flexible) Ausprägung angeben, in der Sie einen Bandbreitenbereich festlegen und den Service die Bandbreite automatisch basierend auf Trafficmustern skalieren lassen. Bei beiden Verfahren können Sie die Ausprägung nach dem Erstellen des Load Balancers jederzeit ändern.
Hinweise
Beachten Sie beim Deployment dieser Referenzarchitektur die folgenden Optionen.
- Kostenfaktor
Für die Control Plane von OCI Service Mesh im OKE-Cluster fallen keine Gebühren an. Kunden wird die Ressourcenauslastung der Proxycontainer für die Service-Mesh-Data Plane in Rechnung gestellt. In der Praxis zahlen Kunden jedoch bereits für die Ressourcen für den Knotenpool in einem OKE-Cluster. Wenn die Nutzung der Proxycontainer die Auslastung des Knotenpools nicht um mehr als 100 Prozent erhöht, fallen keine zusätzlichen Kosten für das Hinzufügen von OCI Service Mesh zu Ihrer Microservice-Architektur an.
- Verfügbarkeit
Die Control Plane des OCI Service Mesh wird immer mit High Availability bereitgestellt.