Istio Erklärt – Service Mesh Routing

Im ersten Teil unserer Beitragsreihe von Kubernest Consulting über ISTIO werden wir uns ansehen, was Istio genau ist. Zudem erfahren wir, wie Isito, das Open-Source-Projekt von Google, die Komplexität der Verwaltung von Netzwerken zur Verbindung von Microservices kontrolliert.

In den letzten Jahren sind wir in der DevOps-Beratung immer häufiger auf das Problem gestoßen, dass interne DevOps- oder Entwickler Schwierigkeiten haben, immer komplexere Kombinationen von Microservices effektiv zu verwalten. Dies ist besonders häufig bei Unternehmen der Fall, die in jüngster Vergangenheit dazu übergegangen sind, Anwendungen auf Basis einer Microservice- statt einer monolithischen Architektur zu entwickeln. Eines der wichtigsten Tools, das wir für die Verwaltung von Verbindungen zwischen Microservices einsetzen, ist Istio. Wir bieten Ihnen eine Schritt-für-Schritt-Anleitung, wie Sie Istio einrichten und wie Sie es für das Traffic-Routing, das Switching, die Aktivierung von Timeouts und Wiederholungen, das Mirroring und die Implementierung von Circuit Breakers verwenden

Microservices – Business und Technologie – Vor- und Nachteile

Microservices ermöglichen es, große, komplexe Anwendungen in unabhängige, containerbasierte Dienste zu zerlegen. Diese Container bilden dann Kubernetes-Cluster. Dies hat den Vorteil, dass die Kosten sinken, da die anfängliche Entwicklung vereinfacht und somit beschleunigt wird. Auch die Aktualisierung oder Skalierung bestehender Anwendungen wird vereinfacht, was sich positiv auf den Gewinn des Unternehmens auswirkt.

Die Entscheidung für eine Microservices-Architektur bringt jedoch neben den Vorteilen zwangsläufig auch einige Herausforderungen mit sich. Die Zerlegung von Anwendungen in unabhängige Prozesse bedeutet eine Zunahme der Anzahl von Komponenten, die miteinander verbunden und gesichert werden müssen. Die Verwaltung dieses Netzwerks unabhängiger Systeme, wie z. B. Verkehrsmanagement, Lastausgleich, Authentifizierung, Autorisierung usw., kann, insbesondere bei komplexen Anwendungen, äußerst kompliziert werden.

Der Begriff für den „Raum“ („space“), der zwischen Kubernetes-Containern in einem Cluster besteht, lautet „Service Mesh“. Istio ist ein Open-Source-Projekt, das von Google initiiert wurde, wobei auch IBM und das Ride-Sharing-Unternehmen Lyft daran mitwirken. Es handelt sich dabei um ein Tool zur Verwaltung des Service Mesh eines Kubernetes-Clusters. Es dient der Kontrolle, bevor es zu einer komplexen Chaoszone wird, die eine potenzielle Fehlerquelle darstellt.

Istio Service Mesh

Das Service Mesh ist die Architekturschicht, die für die zuverlässige Zustellung von Anfragen durch ein komplexes Netz von Microservices verantwortlich ist.

Wenn sich Ihre Anwendung von einer monolithischen zu einer Microservice-Architektur entwickelt, wird es immer schwieriger, sie täglich zu verwalten und zu überwachen. In diesem Fall müssen Sie zu Lösungen übergehen, die einige der mit Microservices verbundenen Probleme lösen:

• Load-Balancing innerhalb des Microservice-Grid
• Service Entdeckung
• Wiederherstellung bei Fehlern
• Metriken
• Überwachung

Außerdem lösen sie auch komplexere Probleme:

• A / B-Testing
• Rollouts („Canary Rollouts“)
• Zugangskontrolle
• Ende-zu-Ende-Authentifizierung

Wann Istio einsetzten?

An dieser Stelle kann Istio Abhilfe schaffen.

Hauptmerkmale von Istio:

• Traffic-Management: Timeouts, retries, load-Balancing
• Sicherheit: Authentifizierung und Autorisierung
• Beobachtbarkeit: Trace, Monitoring

Istio-Architektur

Istio Service Mesh wird logisch in eine Datenebene und eine Steuerungsebene unterteilt.

• Datenebene – besteht aus einer Reihe von intelligenten Proxys, die als Beiwagen eingesetzt werden. Diese Proxys stellen die gesamte Netzwerkkommunikation zwischen den Diensten zusammen mit dem Richtlinien- und Telemetriezentrum von Mixer bereit und steuern sie
• Control Plane – Konfiguriert die Proxies für das Routing des Datenverkehrs. Die Steuerungsebene konfiguriert auch den Mixer, um die Richtlinien und Telemetrie anzuwenden.

Istio Architecture (source)

Istio-Komponenten

• Envoy ist ein Hochleistungs-Proxy, der in C++ entwickelt wurde, um den gesamten ein- und ausgehenden Datenverkehr für alle Dienste zu übertragen
• Mixer – bietet Zugangskontrolle und Nutzungsrichtlinien für das Netz der Dienste und sammelt Telemetriedaten vom Envoy-Proxy-Server und anderen Diensten
• Pilot – ermöglicht die Erkennung von Diensten für den Envoy-Dienst, schafft Möglichkeiten für intelligentes Verkehrsrouting (z. B. A/B-Tests, Canary-deployment) und Fehlertoleranz (Timeouts, Retries, Circuit Breakers)
• Citadel – bietet eine zuverlässige Service-to-Service- und Endbenutzer-Authentifizierung
• Galley – ist eine Komponente zur Validierung der Istio-Konfiguration. Er ist verantwortlich für die Isolierung der übrigen Komponenten von Istio von der Benutzerkonfiguration der zugrunde liegenden Plattform

Routing und Traffic-Konfiguration in Istio

Das Istio-Verkehrsrouting- und Konfigurationsmodell verwendet die folgenden API-Ressourcen:

• Virtual Services – richtet Regeln für das Routing des Envoy-Traffics innerhalb unseres Service Mesh ein
• Destination rules – richtet Richtlinien für die Anwendung von Routing-Regeln auf virtuelle Dienste ein
• Gateways – zur Konfiguration der Envoy Load Balancing Methode (HTTP, TCP oder gRPC)
• Service entries – für die Konfiguration externer Netzabhängigkeiten

Sschritt-für-Schritt-Anleitung für die Installation und Konfiguration von Istio

Wir lassen istio auf der Google Kubernetes Engine (GKE) laufen. Erstellen Sie einen Cluster:

gcloud container clusters create <cluster-name> \
  --cluster-version latest \
  --num-nodes 4 \
  --zone <zone> \
  --project <project-id>

Wir erhalten Zugriffsschlüssel (hereinafter credentials):

gcloud container clusters get-credentials <cluster-name> \
--zone <zone> \
--project <project-id>

Wir geben unserem Benutzer Administratorrechte:

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole=cluster-admin \
    --user=$(gcloud config get-value core/account)

Nachdem wir den Cluster vorbereite haben, installieren wir die Istio-Komponente. Laden Sie die neuste Version herunter, zum Zeitpunkt der Erstellung dieses Artikels, Istio version 1.3.0:

curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.3.0 sh -

Wechseln Sie das Verzeichnis mit Istio:

cd istio-1.3.0

Installieren Sie Custom Resource Definitions (CRDs) für Istio mit kubectl

Install Custom Resource Definitions (CRDs) for Istio with kubectl

Nach der Installation des CRD, installieren Sie die Isito control plane mit TLS authentication:

kubectl apply -f install/kubernetes/istio-demo-auth.yaml

Kontrollieren Sie die services:

NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                                                                                                                                      AGE
grafana                  ClusterIP      10.43.242.92    <none>         3000/TCP                                                                                                                                     4m1s
istio-citadel            ClusterIP      10.43.252.216   <none>         8060/TCP,15014/TCP                                                                                                                           3m58s
istio-egressgateway      ClusterIP      10.43.254.22    <none>         80/TCP,443/TCP,15443/TCP                                                                                                                     4m2s
istio-galley             ClusterIP      10.43.244.7     <none>         443/TCP,15014/TCP,9901/TCP                                                                                                                   4m3s
istio-ingressgateway     LoadBalancer   10.43.253.1     34.69.43.198   15020:31384/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:30472/TCP,15030:32532/TCP,15031:30101/TCP,15032:30948/TCP,15443:30384/TCP   4m1s
istio-pilot              ClusterIP      10.43.250.244   <none>         15010/TCP,15011/TCP,8080/TCP,15014/TCP                                                                                                       3m59s
istio-policy             ClusterIP      10.43.242.33    <none>         9091/TCP,15004/TCP,15014/TCP                                                                                                                 4m
istio-sidecar-injector   ClusterIP      10.43.244.233   <none>         443/TCP,15014/TCP                                                                                                                            3m58s
istio-telemetry          ClusterIP      10.43.253.8     <none>         9091/TCP,15004/TCP,15014/TCP,42422/TCP                                                                                                       3m59s
jaeger-agent             ClusterIP      None            <none>         5775/UDP,6831/UDP,6832/UDP                                                                                                                   3m43s
jaeger-collector         ClusterIP      10.43.250.60    <none>         14267/TCP,14268/TCP                                                                                                                          3m43s
jaeger-query             ClusterIP      10.43.242.192   <none>         16686/TCP                                                                                                                                    3m43s
kiali                    ClusterIP      10.43.242.83    <none>         20001/TCP                                                                                                                                    4m
prometheus               ClusterIP      10.43.241.166   <none>         9090/TCP                                                                                                                                     3m59s
tracing                  ClusterIP      10.43.245.22    <none>         80/TCP                                                                                                                                       3m42s
zipkin                   ClusterIP      10.43.248.101   <none>         9411/TCP                                                                                                                                     3m42s

und pods:

NAME                                      READY   STATUS      RESTARTS   AGE
grafana-6fc987bd95-t4pwj                  1/1     Running     0          4m54s
istio-citadel-679b7c9b5b-tktt7            1/1     Running     0          4m48s
istio-cleanup-secrets-1.3.0-q9xrb         0/1     Completed   0          5m16s
istio-egressgateway-5db67796d5-pmcr2      1/1     Running     0          4m58s
istio-galley-7ff97f98b5-jn796             1/1     Running     0          4m59s
istio-grafana-post-install-1.3.0-blqtb    0/1     Completed   0          5m19s
istio-ingressgateway-859bb7b4-ms2zr       1/1     Running     0          4m56s
istio-pilot-9b9f7f5c8-7h4j7               2/2     Running     0          4m49s
istio-policy-754cbf67fb-5vk9f             2/2     Running     2          4m52s
istio-security-post-install-1.3.0-7wffc   0/1     Completed   0          5m15s
istio-sidecar-injector-68f4668959-ql975   1/1     Running     0          4m47s
istio-telemetry-7cf8dcfd54-crd9w          2/2     Running     2          4m50s
istio-tracing-669fd4b9f8-c8ptq            1/1     Running     0          4m46s
kiali-94f8cbd99-h4b5z                     1/1     Running     0          4m53s
prometheus-776fdf7479-krzqm               1/1     Running     0          4m48s

Start einer Anwendung

Wir verwenden die Lite-Version von bookinfo, die von K&C für den Test von Istio geschrieben wurde. Wir werden die UI noch nicht verwenden (sie funktioniert nicht gut genug für die Darstellung).

Anwendungsarchitektur:

• ui
• Gateway — API
• Books
• Ratings

Unterschiede zwischen den Anwendungsversionen:

books:

• v1 —  no description
• v2 — description

ratings:

• v1 — presentation «:-)»
• v2 — presentation «¯\\_(ツ)_/¯»

Erstellen Sie einen namespace für die Anwendung:

kubectl create ns mesh
kubectl label namespace mesh istio-injection=enabled

Erstellen Sie die books-deployment.yaml Datei mit den Inhalten.

Dies ist ein Paket von Standard api deployments und services zum deploying einer normalen Anwendung in Kubernetes. In diesem Beispiel verwenden wir eine Version von Gateway und 2 Versionen von books und ratings. Im service selector ist nur der Name der Anwendung und nicht die version registriert; wir werden das Routing zu einer bestimmten Version mit Istio konfigurieren:

# ===========
# = Gateway =
# ===========
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gw
  labels:
    app: gw
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gw
      version: v1
  template:
    metadata:
      labels:
        app: gw
        version: v1
    spec:
      containers:
      - name: gw
        image: kruschecompany/mesh:gateway
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: gw
spec:
  selector:
    app: gw
  ports:
    - name: http
      port: 8080
 
# =========
# = Books = 
# =========
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: books-v1
  labels:
    app: books
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: books
      version: v1
  template:
    metadata:
      labels:
        app: books
        version: v1
    spec:
      containers:
      - name: books
        image: kruschecompany/mesh:books_v1
        ports:
        - containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: books-v2
  labels:
    app: books
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: books
      version: v2
  template:
    metadata:
      labels:
        app: books
        version: v2
    spec:
      containers:
      - name: books
        image: kruschecompany/mesh:books_v2
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: books
spec:
  selector:
    app: books
  ports:
    - name: http
      port: 80
      targetPort: 8080
 
 
# ===========
# = Ratings =
# ===========
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ratings-v1
  labels:
    app: ratings
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ratings
      version: v1
  template:
    metadata:
      labels:
        app: ratings
        version: v1
    spec:
      containers:
      - name: ratings
        image: kruschecompany/mesh:ratings_v1
        ports:
        - containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ratings-v2
  labels:
    app: ratings
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ratings
      version: v2
  template:
    metadata:
      labels:
        app: ratings
        version: v2
    spec:
      containers:
      - name: ratings
        image: kruschecompany/mesh:ratings_v2
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: ratings
spec:
  selector:
    app: ratings
  ports:
    - name: http
      port: 80
      targetPort: 8080

We apply:

kubectl -n mesh apply -f books-deployment.yaml

We check:

kubectl -n mesh get pod

NAME                          READY   STATUS    RESTARTS   AGE
books-v1-758875cb99-sj4wm     2/2     Running   0          26m
books-v2-64c4889569-jjpnt     2/2     Running   0          26m
gw-7488b5dcbd-2t9xr           2/2     Running   0          26m
ratings-v1-57f7d99c55-kxnm7   2/2     Running   0          26m
ratings-v2-5d856c95d5-dm2tk   2/2     Running   0          26m

Abschließend sehen wir, das in jedem Pod 2 containers laufen. Istio hat während des Deployments einen injection container mit Envoy erstellt, folglich wird der gesamte traffic über diese containers laufen.

Wir erstellen die Datei istio-gateway.yaml mit den Content. Istio erlaubt die Verwendung von Platzhaltern in VirtualService nicht, also ersetzen Sie ‘*’ durch die balancer ip:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: mesh
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: mesh-gw
spec:
  hosts:
  - "*" # <- replace on load balancer ip
  gateways:
  - mesh
  http:
  - match:
    - uri:
        exact: /gateway/books
    route:
    - destination:
        port:
          number: 8080
        host: gw

We apply:

kubectl -n mesh apply -f istio-gateway.yaml

Wir haben den Eingangspunkt zu unserer Anwendung festgelegt, der gesamte eingehende traffic von uri / gateway / books wird an den gateway service (aka gw) weitergeleitet.

Erstellen Sie nun die Datei istio-destinationrule.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: gw
spec:
  host: gw
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: books
spec:
  host: books
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ratings
spec:
  host: ratings
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

In we determined where to route traffic, for gw traffic will go to under c version 1, books and ratings for both versions in turn.

We apply:

kubectl -n mesh apply -f istio-destinationrule.yaml

Wir öffnen im Browser: http: // <load_balancer_ip> / gateway / books ist unsere API. Wir erhalten JSON mit books und deren Bewertung.

[
{
"id": 1,
"name": "War and Piece",
"rating": 455.45,
"presentation": ":-)",
"description": "Historical"
},
{
"id": 2,
"name": "Anna Karenina",
"rating": 666.4,
"presentation": ":-)",
"description": "Drama"
},
...
]

Laden Sie die Seite neu um diese zu aktualisieren – der Output wird verschieden sein, da die Anwendung jedes Mal auf andere services zugreift.

[
{
"id": 1,
"name": "War and Piece",
"rating": 455.45,
"presentation": "¯\\_(ツ)_/¯",
"description": "Historical"
},
{
"id": 2,
"name": "Anna Karenina",
"rating": 666.4,
"presentation": "¯\\_(ツ)_/¯",
"description": "Drama"
},
...
]

Und noch ein paar weitere Male:

[
{
"id": 1,
"name": "War and Piece",
"rating": 455.45,
"presentation": ":-)",
"description": null
},
{
"id": 2,
"name": "Anna Karenina",
"rating": 666.4,
"presentation": ":-)",
"description": null
},
...
]

Die application topology kann auch über Kiali eingesehen werden, das zusammen mit anderen Komponenten von Isio installiert wurde. Verwenden Sie dazu port-forward, um den service an unser System weiterzuleiten:

kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=kiali -o jsonpath='{.items[0].metadata.name}') 20001:20001

Kiali wird unter folgenden verfügbar sein: http: // localhost: 20001 admin / admin. Auf dem Graph tab sehen wir:

Traffic routing

Auf dem Bild ist alles super, aber in der Praxis muss der traffic zu bestimmten versions der services geleitet werden. Dazu erstellen wir eine weitere Datei: istio-virtual-service-all-v1.yaml, in der wir festlegen, dass alle Anfragen an die books und rating version 1 gehen:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: books
spec:
  hosts:
  - books
  http:
  - route:
    - destination:
        host: books
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1

And apply:

kubectl -n mesh apply -f istio-virtual-service-all-v1.yaml

Wir prüfen, ob der Browser den gleichen Output zeigt:

[
{
"id": 1,
"name": "War and Piece",
"rating": 455.45,
"presentation": ":-)",
"description": null
},
{
"id": 2,
"name": "Anna Karenina",
"rating": 666.4,
"presentation": ":-)",
"description": null
},
...
]

In diesem Beispiel haben wir in der Teilmenge nur v1 für books und ratings spezigiziert, und der gesamte traffic ging nur zur ersten version.

Traffic switching

Wir verwenden weight-based routing. Das bedeutet das wir Gewichte, weights auf services legen. Im Beispiel wird die first version mit 50 auf die service ratings und die second version mit demselben Wert versehen. Nun wird der gesamte traffic 50/50 zwischen den versions aufgeteilt. Wir können auch 10/90 angeben, in diesem Fall gehen 10% des traffic an die first version und 90% an die second version.

Create a virtual-service-ratings-50.yaml file:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
    - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
      weight: 50
    - destination:
        host: ratings
        subset: v2
      weight: 50

We apply:

kubectl -n mesh apply -f virtual-service-ratings-50.yaml

Check on browser:

[
{
"id": 1,
"name": "War and Piece",
"rating": 455.45,
"presentation": ":-)",
"description": null
},
{
"id": 2,
"name": "Anna Karenina",
"rating": 666.4,
"presentation": ":-)",
"description": null
},
...
]

Wir laden die Seite mehrmals neu (refresh the page a couple of times):

[
{
"id": 1,
"name": "War and Piece",
"rating": 455.45,
"presentation": "¯\\_(ツ)_/¯",
"description": null
},
{
"id": 2,
"name": "Anna Karenina",
"rating": 666.4,
"presentation": "¯\\_(ツ)_/¯",
"description": null
},
...
]

Clean and move on to the next example:

kubectl -n mesh apply -f istio-virtual-service-all-v1.yaml

Timeouts und Retries

Mit Istio können Sie Timeouts für services aktivieren, so dass Sie die langen Reaktionszeiten (response) von Microservices künstlich simulieren können.

Wir erstellen die Datei istio-delay.yaml, in der wir einen delay von 2 Sekunden für alle requests festlegen:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percent: 100
        fixedDelay: 2s
    route:
    - destination:
        host: ratings
        subset: v1

We apply:

kubectl -n mesh apply -f istio-delay.yaml

Wir prüfen im Browser – die Anwendung funktioniert, aber mit einem delay (Verzögerung). Erhöhen Sie den Timeout auf 5 Sekunden.

We apply and verify:

kubectl -n mesh apply -f istio-delay.yaml

Wir erhalten eine Fehlermeldung als Antwort und wissen nun, dass die Anwendung abstürzen wird, wenn einer der Microservices zu lange antwortet (responds for to long):

Sie können auch retries und ein timeout für die retry (Wiederholversuche) hinzufügen:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
    route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s

Clean and move on to the next example:

kubectl -n mesh apply -f istio-virtual-service-all-v1.yaml

Traffic mirroring

Manchmal müssen Sie die neue Version mit mehreren Benutzern testen, sie können diese aber nicht auf die prod ausrollen. Dazu verfügt Istio über eine Funktion zum traffic mirroring. Wir starten parallel eine neue Version des service und leiten den traffic dorthin, ohne die working version des service zu beeinträchtigen.

Tun Sie dies, ersellen Sie istio-mirroring.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
      weight: 100
    mirror:
      host: ratings
      subset: v2

We apply:

kubectl -n mesh apply -f istio-mirroring.yaml

We’re checking:

while true;do curl http://<load_balancer_ip>/gateway/books; sleep 2;done

Die Antwort erhalten wir aus den ratings der first version:

[
  {
    "id": 1,
    "name": "War and Piece",
    "rating": 455.45,
    "presentation": ":-)",
    "description": null
  },
  {
    "id": 2,
    "name": "Anna Karenina",
    "rating": 666.4,
    "presentation": ":-)",
    "description": null
  },
...
]

In den ratings container logs der second version, sehen wir, dass der traffic auf ihn gespiegelt (mirrored) wird:

2019-09-18 11:19:04.574  INFO 1 --- [nio-8080-exec-8] c.m.r.controller.BooksRatingsController  : [1, 2, 3, 4, 5, 6]
2019-09-18 11:19:06.686  INFO 1 --- [nio-8080-exec-9] c.m.r.controller.BooksRatingsController  : [1, 2, 3, 4, 5, 6]
2019-09-18 11:19:08.801  INFO 1 --- [io-8080-exec-10] c.m.r.controller.BooksRatingsController  : [1, 2, 3, 4, 5, 6]
2019-09-18 11:19:10.918  INFO 1 --- [nio-8080-exec-1] c.m.r.controller.BooksRatingsController  : [1, 2, 3, 4, 5, 6]
2019-09-18 11:19:13.065  INFO 1 --- [nio-8080-exec-2] c.m.r.controller.BooksRatingsController  : [1, 2, 3, 4, 5, 6]

Clean and move on to the next example:

kubectl -n mesh apply -f istio-virtual-service-all-v1.yaml

Circuit Breaker

Es ist sehr wichtig, dass unsere requests garantiert den Adressaten erreichen. Istio implementiert den Circuit-Breaking-Mechanismus. Proxies innerhalb des Clusters fragen services ab und schalten im Falle eines Ausfalls oder einer slow response die service instance (sub) vom network ab und leiten den load auf andere service replicas um.

For the books service, the following rules apply:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: books
spec:
  host: books
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

• maxConnections – Die maximale Anzahl von Verbindungen zum service. Jede überflüssige Verbindung wird in die queue aufgenommen.
• http1MaxPendingRequests – Die maximale Anzahl der pending service requests. Alle pending requests werden zurückgewiesen.
• maxRequestsPerConnection – Die maximale Anzahl von requests im Cluster.
• BaseEjectionTime – maximale extraction time für den hearth. Der under wird für 20 Sekunden entfernt.
• ConsecutiveErrors – Die Anzahl der Fehler, bevor die sub aus dem pool entfernt wird. Wenn Sie beispielsweise drei consecutive errors bei der Interaktion mit einem service haben, markiert Istio diesen als unhealthy.
• Interval – Zeitintervall für die outlier analysis. Zum Beispiel wird ein service alle 10 Sekunden überprüft.
• MaxEjectionPercent – der maximale Prozentsatz an hearths, die aus dem load balancing pool entnommen werden können. Wird dieses field beispielsweise auf 100 implies gesetzt, bedeutet dies, dass alle unhealthy hearths die konsistente errors produzieren, abgerufen werden können und die request an healthy hearths weitergeleitet wird.

Das war’s – eine schrittweise technische Anleitung zur Verwendung von Istio für das Routing in einer Microservices-basierten App-Umgebung.

K&C – IT Outsourcing You Can Trust

Wenn Ihr Unternehmen Unterstützung bei der Istio-Integration und -Einrichtung oder bei anderen Kubernetes- oder breiteren Webentwicklungsproblemen benötigt, würden wir uns freuen, von Ihnen zu hören.

Unsere Nearshore-Talentzentren in Kiew und Krakau, die von München aus geleitet werden, bieten Ihnen Zugang zu einigen der besten Entwickler, Softwaretester und IT-Berater Europas. Und das zu wettbewerbsfähigen Preisen, ohne Kompromisse bei der Qualität.

Unsere engagierten Teams, Teamerweiterungen und Berater können entweder vor Ort mit Ihnen zusammenarbeiten, egal wo Sie sich in Deutschland oder Europa befinden, oder remote von unseren K&C-Büros aus bzw. in einem Hybridmodell. Wir kümmern uns um Ihre Bedürfnisse, nehmen Sie Kontakt auf.