Meistern Sie die Service Mesh Architektur mit Istio

1. Einführung

Entdecken Sie die Magie der Service Mesh Architektur und sehen Sie, wie sie Ihre verteilten Systeme auf das nächste Level bringt.

Tauchen Sie tief in Istio ein, den Superstar des Service Meshes, und lernen Sie, wie es Ihr Kubernetes-Cluster perfekt orchestriert.

2. Was ist ein Service Mesh?

Monolithische Anwendungen haben sich zu kleineren, unabhängigen Diensten entwickelt. Dieser Wandel hat durch Cloud-native Computing und Microservices-Architektur enorm an Popularität gewonnen. Tools wie Docker und Kubernetes beschleunigten diesen Trend.

Microservices auf Plattformen wie Kubernetes bieten zahlreiche Vorteile, bringen aber auch Komplexität mit sich. Die Verwaltung der Kommunikation zwischen diesen verteilten Diensten erfordert sorgfältige Überlegungen zu Discovery, Routing, Wiederholungen und Failover.

Weitere Herausforderungen sind Sicherheit und Beobachtbarkeit.

Diese Proxies bilden ein Mesh-Netzwerk für die Dienste, daher der Name. Das Service Mesh steuert jeden Aspekt der Kommunikation zwischen den Diensten und ermöglicht es, die acht Trugschlüsse der verteilten Systeme zu adressieren.

4. Istio Enthüllt

Istio, ein Open-Source-Service-Mesh, das von IBM, Google und Lyft entwickelt wurde, verbessert unsichtbar verteilte Anwendungen mit Verkehrsmanagement, Sicherheit und Leistungsüberwachung.

Es kann flexibel On-Premise, in der Cloud, innerhalb von Kubernetes oder auf virtuellen Maschinen bereitgestellt werden und glänzt besonders bei Microservices auf Kubernetes. Obwohl plattformunabhängig, passt es natürlich gut in containerisierte Umgebungen.

Im Kern setzt Istio Envoy-Proxies als Sidecars neben jedem Microservice ein:

Dieses Proxy-Netzwerk bildet die Datenebene von Istio, orchestriert von der Steuerungsebene:

Die Flexibilität von Istio zeigt sich in der nahtlosen Integration mit externen Logging-, Telemetrie- und Policysystemen.

5. Istios Bausteine Entwirrt

Die Architektur von Istio ist ein dynamisches Duo: die Datenebene und die Steuerungsebene. Gemeinsam orchestrieren sie die Magie hinter den Fähigkeiten von Istio. Lassen Sie uns in die Kernkomponenten eintauchen, die diese außergewöhnliche Plattform antreiben.

Machen Sie sich bereit, die detaillierten Feinheiten der Hauptkomponenten von Istio zu erkunden.

5.1. Die Datenebene: Das Epizentrum von Envoy

Die Datenebene von Istio ist im Wesentlichen eine verstärkte Version des Envoy-Proxies. Dieses Open-Source-Wunder bewältigt Netzwerkintrigen, sodass sich Anwendungen auf ihr Kerngeschäft konzentrieren können. Anwendungen interagieren nahtlos, ohne die komplexe Netzwerkinfrastruktur zu bemerken.

Im Kern ist Envoy ein Netzwerkwunder, das auf den Ebenen 3 und 4 des OSI-Modells arbeitet. Es verwaltet Verbindungen geschickt mit einer Kette anpassbarer Netzwerkfilter. Darüber hinaus befähigt der L7-Filter von Envoy es, den HTTP-Verkehr mit Finesse zu behandeln. Und das ist noch nicht alles - es ist ein Naturtalent mit den Protokollen HTTP/2 und gRPC.

Viele der herausragenden Funktionen von Istio sind tatsächlich Superkräfte, die von den eingebauten Fähigkeiten von Envoy geerbt wurden:

• Traffic-Kontrolle: Envoy verfügt über eine feinkörnige Kontrolle über HTTP-, gRPC-, WebSocket- und TCP-Traffic und leitet ihn präzise weiter.
• Netzwerkresilienz: Eingebaute automatische Wiederholungen, Circuit Breaking und Fehlerinjektion sorgen für unerschütterliche Netzwerksicherheit.
• Sicherheit: Schützen Sie Ihre Kommunikation mit robusten Sicherheitsrichtlinien, Zugriffskontrollen und Ratenbegrenzungen.

Das wahre Potenzial von Envoy zeigt sich in der Zusammenarbeit mit Istio. Seine Erweiterbarkeit, die durch WebAssembly ermöglicht wird, ist ein Game-Changer für benutzerdefinierte Richtlinien und Telemetrie. Darüber hinaus eröffnet Istios Proxy-Wasm-Sandbox-API weitere Anpassungsmöglichkeiten für Envoy.

5.2. Die Steuerungsebene: Der Maestro von Istiod

Lernen Sie istiod kennen, den Dirigenten der Orchestrierungsebene von Istio. Dieser Maestro verwandelt hochrangige Routing-Regeln und Verkehrsmanagement-Richtlinien in Envoy-freundliche Konfigurationen und verteilt sie nahtlos an die Sidecars.

Erinnern Sie sich an die frühere Architektur von Istio mit ihren einzelnen Komponenten? Um die Dinge zu vereinfachen, wurden diese Komponenten zu einem einheitlichen istiod zusammengeführt. Aber keine Sorge, die Kernfunktionen bleiben intakt.

Im Kern nutzt istiod denselben Code und dieselben APIs wie seine Vorgänger. Pilot bleibt beispielsweise der Maestro der Service-Discovery und übersetzt plattformspezifische Details in eine universelle Sprache, die von Sidecars verstanden wird. Diese Flexibilität ermöglicht es Istio, sich nahtlos in verschiedene Umgebungen wie Kubernetes und virtuelle Maschinen zu integrieren.

Istiod übernimmt auch die Sicherheit, indem es robuste Service-to-Service- und Endbenutzerauthentifizierungen mit seinem integrierten Identitäts- und Berechtigungsmanagementsystem bereitstellt. Erzwingen Sie mit Leichtigkeit granulare Sicherheitsrichtlinien auf Basis der Service-Identität. Darüber hinaus fungiert istiod als vertrauenswürdige Zertifizierungsstelle (CA) und stellt Zertifikate aus, um die Kommunikation zwischen Diensten mittels mutual TLS (MTLS) zu sichern.

6. So funktioniert Istio

Wir haben die typischen Funktionen eines Service Meshes und die Architektur sowie die Kernkomponenten von Istio erforscht. Nun wollen wir herausfinden, wie Istio diese Funktionen mit seinen Kernkomponenten bereitstellt.

Wir werden die gleichen Funktionskategorien noch einmal durchgehen, die wir zuvor behandelt haben.

6.1. Verkehrsmanagement

Die Verkehrsmanagement-API von Istio bietet eine feinkörnige Kontrolle über den Service-Mesh-Traffic. Passen Sie Verkehrskonfigurationen mithilfe dieser APIs an und definieren Sie API-Ressourcen mit benutzerdefinierten Ressourcen-Definitionen (CRDs) von Kubernetes. Zu den wichtigsten API-Ressourcen für das Traffic-Routing gehören virtuelle Dienste und Zielregeln:

Ein virtueller Dienst bestimmt, wie Anfragen an einen Dienst innerhalb des Istio-Meshes weitergeleitet werden. Er besteht aus einer oder mehreren Routing-Regeln, die der Reihe nach ausgewertet werden. Nach dem Routing des virtuellen Dienstes werden Zielregeln angewendet, um den Verkehr zu einem Ziel zu steuern, z. B. durch die Gruppierung von Service-Instanzen nach Version.

6.2. Sicherheit

Die Sicherheitsgrundlage von Istio basiert auf starken Identitäten für jeden Dienst. Istio-Agenten neben jedem Envoy-Proxy arbeiten mit istiod zusammen, um die Rotation von Schlüsseln und Zertifikaten zu automatisieren:

Istio unterstützt zwei Authentifizierungstypen: Peer-Authentifizierung und Anforderungs-Authentifizierung. Die Peer-Authentifizierung sichert die Kommunikation zwischen Diensten mit der mutual TLS-Lösung von Istio. Die Anforderungs-Authentifizierung übernimmt die Endbenutzerauthentifizierung durch die Validierung von JSON Web Tokens (JWT) mithilfe eines benutzerdefinierten Authentifizierungsanbieters oder eines OpenID-Connect (OIDC)-Anbieters.

Istio erzwingt den Dienstzugriff durch die Anwendung von Autorisierungsrichtlinien. Diese Richtlinien regeln den eingehenden Traffic im Envoy-Proxy und ermöglichen die Zugriffskontrolle auf Mesh-, Namespace- und Dienstebene.

6.3. Beobachtbarkeit

Istio generiert umfassende Telemetrie, einschließlich Metriken, verteilter Traces und Zugriffslogs für alle Dienstkommunikationen innerhalb des Meshes. Diese Telemetrie umfasst Proxy-, Dienst- und Steuerungsebenen-Metriken.

Früher war Mixer die zentrale Komponente in Istios Telemetriearchitektur. Telemetrie v2 ersetzt jedoch die Funktionen von Mixer durch Envoy-Proxy-Plugins:

Istio erstellt verteilte Traces über Envoy-Proxies und unterstützt verschiedene Tracing-Backends wie Zipkin, Jaeger, Lightstep und Datadog. Die Sampling-Rate der Trace-Erstellung ist konfigurierbar. Außerdem generiert Istio Zugriffslogs für den Service-Traffic in anpassbaren Formaten.

7. Tauchen Sie ein in Istio

Genug Hintergrundwissen, sehen wir uns Istio in Aktion an! Wir installieren Istio auf einem Kubernetes-Cluster und verwenden eine einfache Microservices-App, um seine Leistungsfähigkeit zu demonstrieren.

7.1 Installation

Istio kann auf verschiedene Arten installiert werden, aber das Herunterladen und Entpacken der neuesten Version für Ihr Betriebssystem (z. B. Windows) ist am einfachsten. Das entpackte Paket enthält den istioctl-Client im bin-Verzeichnis. Verwenden Sie istioctl, um Istio auf Ihrem Kubernetes-Cluster zu installieren:

istioctl install --set profile=demo -y

kubectl label namespace default istio-injection=enabled

Wir verwenden hier kubectl und gehen davon aus, dass Sie ein Kubernetes-Cluster (wie Minikube) und die Kubernetes-CLI kubectl eingerichtet haben.

7.2 Beispielanwendung

Stellen Sie sich für diese Demo eine einfache Online-Bestell-App vor. Sie besteht aus drei Microservices, die zusammenarbeiten, um Bestellungen zu erfüllen:

Wir werden nicht in die Details der Microservices eintauchen, aber sie lassen sich leicht mit Spring Boot und REST-APIs erstellen. Wesentlich ist es, Docker-Images für diese Microservices zu erstellen, um sie auf Kubernetes bereitzustellen.

7.3 Bereitstellung

Das Bereitstellen containerisierter Workloads auf Kubernetes-Clustern wie Minikube ist einfach. Verwenden Sie Deployment- und Service-Ressourcen, um die Workload zu deklarieren und darauf zuzugreifen. Definieren Sie diese typischerweise in einer YAML-Datei:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

Da wir die automatische Injektion von Envoy-Sidecar-Proxies für den Standard-Namespace aktiviert haben, wird alles automatisch gehandhabt. Alternativ können Sie die Envoy-Sidecar-Proxies manuell mithilfe des kube-inject-Befehls von istioctl injizieren.

7.4 Zugriff auf die Anwendung

Istio verwaltet hauptsächlich Mesh-Traffic. Standardmäßig wird der Verkehr von oder zu außerhalb des Meshes blockiert. Istio verwendet Gateways, um eingehenden und ausgehenden Mesh-Traffic zu verwalten, sodass Sie genau steuern können, was in das oder aus dem Mesh gelangt. Istio bietet vorkonfigurierte Gateway-Proxy-Bereitstellungen: istio-ingressgateway und istio-egressgateway.

Erstellen Sie ein Gateway und einen virtuellen Dienst für Ihre Anwendung:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

8 Häufige Anwendungsfälle von Istio

Wir haben eine einfache App auf Kubernetes mit Istio bereitgestellt. Lassen Sie uns die leistungsstarken Funktionen von Istio erkunden und sehen, wie sie unsere Anwendung verbessern können.

8.1 Anfragerouting

Stellen Sie sich vor, Sie haben mehrere Versionen eines Microservices wie dem Versandservice bereitgestellt. Sie möchten neue Funktionen schrittweise einführen, ohne alle Benutzer zu beeinträchtigen. Mit dem Anfragerouting können Sie dies tun, indem Sie einen Teil des Traffics auf die neueste Version lenken.

Verwenden Sie virtuelle Dienst-Routing-Regeln, um dies zu erreichen.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Routing-Regeln können auch den Traffic basierend auf Headern oder anderen Attributen filtern. Das Zielfeld gibt den Zielservice für übereinstimmende Anfragen an.

8.2 Circuit Breaking

Verhindern Sie kaskadierende Ausfälle mit Circuit Breakern. Dieses Muster erkennt Fehler und stoppt den Traffic vorübergehend zu fehlgeschlagenen Diensten, um die Gesundheit Ihrer Anwendung insgesamt zu schützen.

Mit der DestinationRule von Istio können Sie das Verhalten des Circuit Breakings für Dienste wie den Lagerdienst konfigurieren.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

Indem Sie maximale Verbindungen, ausstehende Anfragen und Anfragen pro Verbindung begrenzen, können Sie den Traffic effektiv steuern und Überlastungen verhindern.

8.3 Aktivierung von mutual TLS

Mutual TLS sorgt für sichere Kommunikation zwischen Diensten, indem beide Parteien authentifiziert werden. Istio aktiviert automatisch mutual TLS für Dienste, die seine Proxies verwenden.

Während Istio mutual TLS zwischen proxied Diensten durchsetzt, kann unverschlüsselter Verkehr weiterhin Dienste ohne Proxies erreichen. Verwenden Sie PeerAuthentication-Richtlinien, um mutual TLS im gesamten Mesh durchzusetzen.

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

Sie können mutual TLS auf Mesh-, Namespace- oder Dienstebene anwenden. Dienstspezifische Richtlinien überschreiben Namespace-weite Einstellungen.

8.4 Zugriffskontrolle mit JWT

JSON Web Tokens (JWT) sind ein Standard für die sichere Übertragung von Benutzerinformationen. Sie werden häufig für die Authentifizierung und Autorisierung verwendet.

Mit der AuthorizationPolicy von Istio können Sie den Zugriff auf Dienste wie den Buchungsservice basierend auf JWT-Ansprüchen steuern.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["[email protected]/[email protected]"]

Fordern Sie gültige JWTs mit bestimmten Ansprüchen für den autorisierten Zugriff an. Istio erstellt ein requestPrincipal-Attribut aus den 'issuer'- und 'subject'-Ansprüchen des JWT.

9. Abschließende Gedanken

Istio vereinfacht das Management häufiger Herausforderungen in verteilten Microservice-Architekturen. Allerdings kann seine Komplexität auch zusätzliche Belastungen für Bereitstellungen bedeuten. Wie bei jedem Werkzeug ist Istio keine magische Lösung und erfordert eine sorgfältige Abwägung.

9.1. Ist ein Service Mesh immer notwendig?

Obwohl Service Meshes Vorteile bieten, sollten diese Nachteile berücksichtigt werden:

Service Meshes bieten Vorteile, aber eine sorgfältige Bewertung der Komplexität Ihrer Anwendung ist entscheidend. Wiegen Sie die Vorteile gegen die zusätzliche Komplexität ab.

9.2. Alternativen zu Istio

Istio ist ein beliebtes Service Mesh, das von Branchenführern unterstützt wird, aber es ist nicht die einzige Option. Hier ist ein kurzer Überblick über Linkerd und Consul.

Linkerd ist ein Kubernetes-natives, Open-Source-Service-Mesh, das zunehmend an Beliebtheit gewinnt. Es ist ein CNCF-Inkubationsprojekt und funktioniert ähnlich wie Istio, indem es TCP-Proxies verwendet. Der auf Rust basierende Mikro-Proxy von Linkerd heißt Linkerd-proxy.

Linkerd ist im Allgemeinen einfacher als Istio, da es sich auf Kubernetes konzentriert. Allerdings ähnelt sein Funktionsumfang dem von Istio und seine Kernarchitektur ist ähnlich. Linkerd besteht aus einer Benutzeroberfläche, einer Datenebene und einer Steuerungsebene.

Consul ist ein Open-Source-Service-Mesh von HashiCorp, das sich in andere HashiCorp-Infrastrukturtools integriert. Die Datenebene von Consul unterstützt sowohl Proxy- als auch native Integrationsmodelle. Es bietet einen integrierten Proxy, kann aber auch mit Envoy arbeiten.

Consul funktioniert auch außerhalb von Kubernetes und unterstützt Plattformen wie Nomad. Es verwendet Agents auf jedem Knoten für Gesundheitschecks und kommuniziert mit Consul-Servern für Datenspeicherung und Replikation. Obwohl es Standardfunktionen eines Service Meshes bietet, ist Consul komplexer zu implementieren und zu verwalten.

10. Fazit

In diesem Tutorial haben wir die Grundlagen der Service-Mesh-Architektur und die leistungsstarken Funktionen von Istio untersucht. Wir haben die Kernstruktur, Komponenten und praktischen Anwendungen von Istio eingehend betrachtet. Am Ende sollten Sie ein solides Verständnis dafür haben, wie Istio für häufige Szenarien installiert und genutzt werden kann.