Traffic Management in Istio – Ein ausführlicher Leitfaden

Worum geht es bei Traffic Management?

Traffic Management bezieht sich auf das Management des Verkehrs, der im Rahmen der Daten-/Browsing-Übertragung oder API-Aufrufe generiert wird.

Wenn wir eine Anwendung auf einem On-Premise-Server oder in der Cloud haben, wird Verkehr generiert, wenn diese Anwendung bestimmte API-Aufrufe versucht oder Anrufe an die Dienste anderer Drittanbieter oder Datenübertragungen über das Internet tätigt.

Daten sind ein entscheidender und anfälliger Aspekt jeder Anwendung, und die Infrastruktur ist die Grundlage des Setups. Es ist notwendig, den Verkehr über das Internet über die gesicherte Infrastruktur zu überwachen. Dies führt zu einer besseren Sicherheit und Verwaltung der Dienste auf derselben Plattform/Infrastruktur.

Im Folgenden werden wir uns Istio als Tool für das Traffic Management genauer ansehen.

Istio als Traffic Management Tool

Istio stellt uns das Traffic Management durch von ihm angebotene Verkehrslenkungsregeln vor. Die Anwendung wird widerstandsfähiger gegen Ausfälle, da der gesamte Verkehrsüberwachung, der über das Internet zur Anwendung gelangt, erfolgt.

Istio konfiguriert einen Envoy-Proxy als Sidecar für den Anwendungscontainer. Er überwacht den gesamten Verkehr, der zu und von der Anwendungspod für API-Aufrufe/Dienstleistungsengagements usw. geroutet wird.

Durch dies bleibt der zugrunde liegende Anwendungsdienst unberührt, und die gesamte Verkehrsüberwachung erfolgt über den Envoy-Sidecar für Widerstandsfähigkeit und Verkehrsmanagement.

1. Istio muss die Endpunkte einer Anwendung verstehen, um den Verkehr zu überwachen. Daher wird es intern mit dem Service-Entdeckungssystem verbunden, um die Dienste sowie die Endpunkte einer Anwendung zu erkennen.
2. Wenn also ein Netzwerkanruf die Anwendung trifft, wird er durch den Envoy-Proxy geroutet und schließlich zum Enddienst der Anwendung weitergeleitet. Der Sidecar rendert und überwacht somit vollständig den Verkehr der Anwendung.
3. Istio verwendet ein Round-Robin-Modell, um den Verkehr zu übertragen oder den Verkehr auf die in der Infrastruktur eingerichteten Lastenausgleichsgeräte zu verteilen.

Istio Traffic Management Ressourcen

Nachdem wir das Funktionieren von Istio als Tool für das Traffic Management verstanden haben, wollen wir nun die von Istio festgelegten Ressourcen erkunden.

1. Virtual Service

Mit einem Virtual Service können wir die Verkehrslenkungsregeln definieren, die helfen können, wenn die Anwendung den Lastenausgleich erreicht. Wir definieren Regeln und die entsprechenden übereinstimmenden Protokolle für den Enddienst. Wenn die Regel den Kriterien entspricht, wird der Verkehr zum Enddienst umgeleitet.

Ein Virtual Service ermöglicht es uns, den Verkehrsfluss einfach zu verwalten, indem wir die Dienstanfragen über die Verkehrslenkungsregeln entkoppeln. Wir können das Verhalten des Verkehrs für mehrere Hostnamen innerhalb derselben Virtual Service-Konfiguration spezifizieren und beibehalten.

Lassen Sie uns nun das folgende Beispiel einer Virtual Service-Konfiguration verstehen:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: demo-vs
spec:
  hosts:
  - demo.vs.com
  http:
  - match:
    - headers:
        end-user:
          exact: /api
    route:
    - destination:
        host: /

Erklärung

• Der Eintrag „hosts“ enthält die Domäne oder den CNAME der Anwendung.
• Wir gehen dann durch die HTTP-Routing-Struktur und konfigurieren den entsprechenden Backend-Dienst für einen bestimmten Host/Zielort.
• Unter dem Abschnitt „match“ kommt die Konfiguration des Backend-Dienstes, die aufgerufen wird, sobald der Host-Eintrag übereinstimmt.
• Der HTTP-Abschnitt enthält die Routing-Regeln, die zur Zieladresse umgeleitet werden.
• Sobald der Webverkehr/die Anforderung das Istio-Gateway erreicht, sucht es nach dem Eintrag seines CNAME/FQDN. Bei erfolgreicher Übereinstimmung leitet es den Verkehr dann zum Virtual Service weiter, der ihn zum bestimmten Ziel-K8-Dienst routet.

2. Gateway

Mit dem Gateway kommt die Flexibilität, den Ein- und Ausgangsverkehr auf globaler (Envoy) Ebene zu steuern und zu überwachen. Wir können die Art des Verkehrs (Protokoll/Regeln) festlegen, den wir in das Istio-Service-Mesh für die weitere Routenplanung zum Ziel zulassen möchten.

Also, sobald die Anwendungs-URL den Lastenausgleich erreicht, sucht sie nach einem entsprechenden Gateway. Sobald es den Eintrag findet, ermöglicht es dem Anwendungshost den Zugang zum Netzwerk.

Lassen Sie uns das Funktionsprinzip eines Gateways anhand des folgenden Beispiels verstehen:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: demo-gtwy
spec:
  selector:
    app: demo
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - demo.vs.com
    tls:
      mode: SIMPLE
      credentialName: demo-tls-cert

Erklärung:

• Sobald der Webverkehr den Lastenausgleich erreicht, wird er zum Istio-Gateway geroutet. Das Gateway ermöglicht es dem Verkehr, über den angegebenen Port (443 in diesem Fall) in das Service-Mesh einzutreten.
• Es erfolgt jedoch keine Verkehrsweiterleitung zum Backend-Dienst in diesem Stadium.
• Das Gateway sucht nach der Glaubwürdigkeit des CNAME durch das TLS-Geheimnis (Anmeldeinformation).
• Sobald das Gateway den Verkehr vom Host bestätigt und zulässt, übernimmt der Virtual Service die Führung und leitet den Verkehr zum Ziel-Dienst.

3. Sidecars

Mit Sidecars können wir den Verkehr begrenzen und verwalten, der die Envoy-Proxies erreicht. Auf generische Weise konfiguriert Istio einen Envoy-Proxy, der Verkehr auf den Ports akzeptiert, die mit der Workload der Anwendung verbunden sind. Das Hinzufügen eines Sidecars hat folgende Vorteile:

• Wir können Protokolle und Ports filtern und verwalten, die der Envoy akzeptieren sollte.
• Wir können auch den Envoy-Proxy filtern und einschränken, um Verkehr an bestimmte Dienste weiterzuleiten oder von ihnen zu blockieren.
• Es kann den Verkehr zu Diensten in verschiedenen Namensräumen erlauben/einschränken.

Lassen Sie uns nun das Konzept der Sidecars anhand des folgenden Beispiels verstehen:

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: default
spec:
  egress:
  - hosts:
    - "./*"
    - "bookinfo/*"

Erklärung

• Mit der obigen Konfiguration wird eine Sidecar-Konfiguration auf den Standard-Namensraum angewendet.
• Diese Konfiguration ermöglicht es, dass der externe/egress-Verkehr nur die Backend-Dienste der Namensräume „default“ und „bookinfo“ erreicht.
• Dadurch wird ein ausführlicher Verkehrsrouting/Zugriff auf andere Namensräume eingeschränkt.