Teilen über

Migrationsleitfaden für OSM-Konfigurationen (Open Service Mesh) in Istio

  • Artikel

Wichtig

Dieser Artikel soll ein einfaches Verständnis dafür vermitteln, wie OSM-Konfigurationen identifiziert und in äquivalente Istio-Konfigurationen für die Migration von Workloads von OSM zu Istio übersetzt werden können. Hierbei handelt es sich keineswegs um eine ausführliche Anleitung.

Dieser Artikel enthält praktische Anleitungen für die Zuordnung von OSM-Richtlinien zu den Istio-Richtlinien, um Ihre von OSM verwalteten Bereitstellungen von Microservices so zu migrieren, um von Istio verwaltet zu werden. Die OSM Bookstore-Beispielanwendung wird als Basisreferenz für aktuelle OSM-Benutzer verwendet. Die folgende exemplarische Vorgehensweise stellt die Bookstore-Anwendung bereit. Es werden dieselben Schritte ausgeführt, und es wird erläutert, wie die OSM SMI-Datenverkehrsrichtlinien mithilfe des Istio-Äquivalents angewendet werden.

Wenn Sie OSM nicht verwenden und noch nicht mit Istio vertraut sind, beginnen Sie mit dem Istio-Leitfaden für erste Schritte, um zu erfahren, wie Sie das Istio-Dienstgitter für Ihre Anwendungen verwenden können. Wenn Sie derzeit OSM verwenden, stellen Sie sicher, dass Sie mit der exemplarischen Vorgehensweise zur OSM Bookstore-Beispielanwendung zum Konfigurieren von OMS-Datenverkehrsrichtlinien vertraut sind. Die folgende exemplarische Vorgehensweise ist kein Duplikat der aktuellen Dokumentation und verweist gegebenenfalls auf bestimmte Themen. Bevor Sie fortfahren, sollten Sie sich mit der Bookstore-Anwendungsarchitektur vertraut machen.

Voraussetzungen

  • Ein Azure-Abonnement. Falls Sie über kein Azure-Abonnement verfügen, können Sie ein kostenloses Konto erstellen.
  • Die Azure CLI muss installiert sein.
  • Das OSM AKS-Add-On wird im AKS-Cluster deinstalliert.
  • Alle vorhandenen OSM Bookstore-Anwendungen, einschließlich Namespaces, werden deinstalliert und aus dem Cluster gelöscht.
  • Installieren des Istio AKS Service Mesh-Add-On

Erforderliche Änderungen an der OSM Bookstore-Beispielanwendung

Damit Istio die OSM Bookstore-Anwendung verwalten kann, sind einige Änderungen an den vorhandenen Manifesten erforderlich. Diese Änderungen betreffen den Bookstore und die MySQL-Dienste.

Bookstore-Änderungen

In der exemplarischen Vorgehensweise für OSM Bookstore wird der Bookstore-Dienst zusammen mit einem anderen Bookstore-v2-Dienst bereitgestellt, um zu veranschaulichen, wie OSM das Verschieben des Datenverkehrs ermöglicht. Mit diesen bereitgestellten Diensten konnten der Clientdatenverkehr (bookbuyer) auf mehrere Dienstendpunkte aufgeteilt werden. Das erste neue Konzept beinhaltet, wie Istio mit dem umgeht, was als Verschieben des Datenverkehrs bezeichnet wird.

Die OSM-Implementierung für das Verschieben des Datenverkehrs basiert auf der Spezifikation für SMI-Datenverkehrsaufteilung. Die SMI-Datenverkehrsaufteilung erfordert das Vorhandensein mehrerer Dienste der obersten Ebene, die als Back-Ends mit der gewünschten Gewichtungsmetrik hinzugefügt werden, um Clientanforderungen von einem Dienst zu einem anderen zu verschieben. Istio führt das Verschieben des Datenverkehrs mithilfe einer Kombination aus einem virtuellen Dienst und einer Zielregel aus. Es wird dringend empfohlen, sich mit den Konzepten eines virtuellen Diensts und einer Zielregel vertraut zu machen.

Einfach ausgedrückt: Der virtuelle Dienst von Istio definiert Routingregeln für Clients, die den Host anfordern (Dienstname). Mit virtuellen Diensten können mehrere Versionen einer Bereitstellung einem Hostnamen des virtuellen Diensts zugeordnet werden, um Clients als Ziel zu verwenden. Für denselben Dienst können mehrere Bereitstellungen mit Bezeichnungen versehen werden, die verschiedene Versionen der Anwendung hinter demselben Hostnamen darstellen. Der virtuelle Dienst von Istio kann dann so konfiguriert werden, dass die Anforderung für eine bestimmte Version des Diensts gewichtet wird. Die verfügbaren Versionen des Diensts sind für die Verwendung des subsets-Attributs in einer Istio-Zielregel konfiguriert.

Durch die Änderung am Bookstore-Dienst und der Bereitstellung für Istio entfällt die Notwendigkeit, einen expliziten zweiten Dienst als Ziel zu verwenden, der für die SMI-Datenverkehrsaufteilung erforderlich ist. Es ist auch kein anderes Dienstkonto für den Bookstore v2-Dienst notwendig, da es unter dem Bookstore-Dienst konsolidiert werden soll. Die ursprüngliche Änderung des Manifests von OSM traffic-access-v1.yaml an Istio für den Bookstore v1 und v2 ist im nachstehenden Abschnitt Erstellen von Pods, Diensten und Dienstkonten aufgeführt. Es ist veranschaulicht, wie die Datenverkehrsaufteilung durchgeführt wird, die später in der exemplarischen Vorgehensweise als Verschieben des Datenverkehrs bezeichnet wird:

MySql-Änderungen

Änderungen am MySql-StatefulSet sind nur in der Dienstkonfiguration erforderlich. Gemäß der Dienstspezifikation benötigte OSM die targetPort- und appProtocol- Attribute. Diese Attribute sind für Istio nicht erforderlich. Der aktualisierte Dienst für MySqldb sieht wie folgt aus:

apiVersion: v1
kind: Service
metadata:
  name: mysqldb
  labels:
    app: mysqldb
    service: mysqldb
spec:
  ports:
    - port: 3306
      name: tcp
  selector:
    app: mysqldb

Bereitstellen der geänderten Bookstore-Anwendung

Ähnlich wie bei der exemplarischen Vorgehensweise für OSM Bookstore beginnen wir mit der neuen Installation der Bookstore-Anwendung.

Erstellen der Namespaces

kubectl create namespace bookstore
kubectl create namespace bookbuyer
kubectl create namespace bookthief
kubectl create namespace bookwarehouse

Hinzufügen einer Namespace-Bezeichnung für Istio Sidecar-Injection

Für OSM wurden mithilfe des Befehls osm namespace add <namespace> die erforderlichen Anmerkungen zum Namespace für den OSM-Controller erstellt, um die automatische Sidecar-Injection hinzuzufügen. Mit Istio müssen Sie nur einen Namespace bezeichnen, damit der Istio-Controller angewiesen wird, die Envoy-Sidecar-Proxys automatisch einzufügen.

kubectl label namespace bookstore istio-injection=enabled
kubectl label namespace bookbuyer istio-injection=enabled
kubectl label namespace bookthief istio-injection=enabled
kubectl label namespace bookwarehouse istio-injection=enabled

Bereitstellen des virtuellen Diensts und der Zielregel für Bookstore von Istio

Wie bereits im Abschnitt „Bookstore-Änderungen“ erwähnt, verarbeitet Istio das Verschieben des Datenverkehrs mithilfe eines VirtualService-Gewichtungsattributs, das später in der exemplarischen Vorgehensweise konfiguriert wird. Wir stellen den virtuellen Dienst und die Zielregel für den Bookstore-Dienst bereit. Wir stellen nur die Bookstore Version 1 bereit, obwohl die Bookstore Version 2 bereitgestellt wird. Der virtuelle Dienst von Istio stellt nur eine Route zur Version 1 von Bookstore bereit. Anders als beim Verschieben des Datenverkehrs (Datenverkehrsaufteilung) hat OSM für die Anwendung mit Bookstore Version 2 einen weiteren Dienst bereitgestellt. OSM musste den Datenverkehr so einrichten, dass er mithilfe eines TrafficSplit zwischen den Clientanforderungen aufgeteilt werden konnte. Bei Verwendung von Verschieben des Datenverkehrs mit Istio können wir auf das Verschieben des Datenverkehrs auf mehrere Kubernetes-Anwendungsbereitstellungen (Versionen) verweisen, die für denselben Dienst bezeichnet sind.

In dieser exemplarischen Vorgehensweise werden beide Bookstore-Versionen (v1 und v2) gleichzeitig bereitgestellt. Nur die Version 1 ist aufgrund der Konfiguration des virtuellen Diensts erreichbar. Es ist nicht notwendig, einen weiteren Dienst für Bookstore Version 2 bereitzustellen. Wir aktivieren später eine Route zu Bookstore Version 2, wenn wir den virtuellen Dienst von Bookstore aktualisieren und das erforderliche Gewichtungsattribut für das Verschieben des Datenverkehrs bereitstellen.

kubectl apply -f - <<EOF
# Create bookstore virtual service
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookstore-virtualservice
  namespace: bookstore
spec:
  hosts:
  - bookstore
  http:
  - route:
    - destination:
        host: bookstore
        subset: v1
---
# Create bookstore destination rule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookstore-destination
  namespace: bookstore
spec:
  host: bookstore
  subsets:
  - name: v1
    labels:
      app: bookstore
      version: v1
  - name: v2
    labels:
      app: bookstore
      version: v2
EOF

Erstellen von Pods, Diensten und Dienstkonten

Wir verwenden eine einzelne Manifestdatei, die die zuvor in der exemplarische Vorgehensweise erläuterten Änderungen enthält, um die Anwendungen bookbuyer, bookthief, bookstore, bookwarehouse und mysql bereitzustellen.

kubectl apply -f - <<EOF
##################################################################################################
# bookbuyer service
##################################################################################################
---
# Create bookbuyer Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookbuyer
  namespace: bookbuyer
---
# Create bookbuyer Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookbuyer
  namespace: bookbuyer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookbuyer
      version: v1
  template:
    metadata:
      labels:
        app: bookbuyer
        version: v1
    spec:
      serviceAccountName: bookbuyer
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookbuyer
          image: openservicemesh/bookbuyer:latest-main
          imagePullPolicy: Always
          command: ["/bookbuyer"]
          env:
            - name: "BOOKSTORE_NAMESPACE"
              value: bookstore
            - name: "BOOKSTORE_SVC"
              value: bookstore
---
##################################################################################################
# bookthief service
##################################################################################################
---
# Create bookthief ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookthief
  namespace: bookthief
---
# Create bookthief Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookthief
  namespace: bookthief
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookthief
  template:
    metadata:
      labels:
        app: bookthief
        version: v1
    spec:
      serviceAccountName: bookthief
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookthief
          image: openservicemesh/bookthief:latest-main
          imagePullPolicy: Always
          command: ["/bookthief"]
          env:
            - name: "BOOKSTORE_NAMESPACE"
              value: bookstore
            - name: "BOOKSTORE_SVC"
              value: bookstore
            - name: "BOOKTHIEF_EXPECTED_RESPONSE_CODE"
              value: "503"
---
##################################################################################################
# bookstore service version 1 & 2
##################################################################################################
---
# Create bookstore Service
apiVersion: v1
kind: Service
metadata:
  name: bookstore
  namespace: bookstore
  labels:
    app: bookstore
spec:
  ports:
    - port: 14001
      name: bookstore-port
  selector:
    app: bookstore

---
# Create bookstore Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookstore
  namespace: bookstore

---
# Create bookstore-v1 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookstore-v1
  namespace: bookstore
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookstore
      version: v1
  template:
    metadata:
      labels:
        app: bookstore
        version: v1
    spec:
      serviceAccountName: bookstore
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookstore
          image: openservicemesh/bookstore:latest-main
          imagePullPolicy: Always
          ports:
            - containerPort: 14001
              name: web
          command: ["/bookstore"]
          args: ["--port", "14001"]
          env:
            - name: BOOKWAREHOUSE_NAMESPACE
              value: bookwarehouse
            - name: IDENTITY
              value: bookstore-v1

---
# Create bookstore-v2 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookstore-v2
  namespace: bookstore
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookstore
      version: v2
  template:
    metadata:
      labels:
        app: bookstore
        version: v2
    spec:
      serviceAccountName: bookstore
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookstore
          image: openservicemesh/bookstore:latest-main
          imagePullPolicy: Always
          ports:
            - containerPort: 14001
              name: web
          command: ["/bookstore"]
          args: ["--port", "14001"]
          env:
            - name: BOOKWAREHOUSE_NAMESPACE
              value: bookwarehouse
            - name: IDENTITY
              value: bookstore-v2
---
##################################################################################################
# bookwarehouse service
##################################################################################################
---
# Create bookwarehouse Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
---
# Create bookwarehouse Service
apiVersion: v1
kind: Service
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
  labels:
    app: bookwarehouse
spec:
  ports:
  - port: 14001
    name: bookwarehouse-port
  selector:
    app: bookwarehouse
---
# Create bookwarehouse Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookwarehouse
  template:
    metadata:
      labels:
        app: bookwarehouse
        version: v1
    spec:
      serviceAccountName: bookwarehouse
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookwarehouse
          image: openservicemesh/bookwarehouse:latest-main
          imagePullPolicy: Always
          command: ["/bookwarehouse"]
##################################################################################################
# mysql service
##################################################################################################
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mysql
  namespace: bookwarehouse
---
apiVersion: v1
kind: Service
metadata:
  name: mysqldb
  labels:
    app: mysqldb
    service: mysqldb
spec:
  ports:
    - port: 3306
      name: tcp
  selector:
    app: mysqldb
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: bookwarehouse
spec:
  serviceName: mysql
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      serviceAccountName: mysql
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: mypassword
        - name: MYSQL_DATABASE
          value: booksdemo
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - mountPath: /mysql-data
          name: data
        readinessProbe:
          tcpSocket:
            port: 3306
          initialDelaySeconds: 15
          periodSeconds: 10
      volumes:
        - name: data
          emptyDir: {}
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 250M
EOF

Führen Sie die folgenden Befehle aus, um diese Ressourcen in Ihrem Cluster anzuzeigen:

kubectl get pods,deployments,serviceaccounts -n bookbuyer
kubectl get pods,deployments,serviceaccounts -n bookthief

kubectl get pods,deployments,serviceaccounts,services,endpoints -n bookstore
kubectl get pods,deployments,serviceaccounts,services,endpoints -n bookwarehouse

Anzeigen der Anwendungsbenutzeroberflächen

Ähnlich wie bei der ursprünglichen exemplarischen Vorgehensweise für OSM können Sie, wenn Sie das OSM-Repository geklont haben, die Portweiterleitungsskripts verwenden, um die Benutzeroberflächen jeder Anwendung hier anzuzeigen. Derzeit geht es nur darum, die Benutzeroberfläche bookbuyer und bookthief anzuzeigen.

cp .env.example .env
bash <<EOF
./scripts/port-forward-bookbuyer-ui.sh &
./scripts/port-forward-bookthief-ui.sh &
wait
EOF

Öffnen Sie in einem Browser die folgenden URLs:

http://localhost:8080 – Bookbuyer

http://localhost:8083 – Bookthief

Konfigurieren der Datenverkehrsrichtlinien von Istio

Um die Kontinuität mit der ursprünglichen exemplarischen Vorgehensweise für OSM Bookstore für die Übersetzung in Istio zu gewährleisten, wird der permissive Datenverkehrsrichtlinienmodus von OSM erläutert. Der permissive Datenverkehrsrichtlinienmodus von OSM war ein Konzept, das den Datenverkehr im Gittermodell zuließ oder verweigerte, ohne dass eine bestimmte Regel für SMI Datenverkehr-Zugriffssteuerung bereitgestellt wurde. Die Konfiguration des permissiven Datenverkehrsmodus diente dazu, Benutzern das Einbinden von Anwendungen in das Gittermodell zu ermöglichen und gleichzeitig eine mTLS-Verschlüsselung zu erreichen, ohne dass explizite Regeln für die Kommunikation von Anwendungen im Gittermodell erforderlich sind. Die Funktion „Permissiver Datenverkehrsmodus“ sollte verhindern, dass die Kommunikation Ihrer Anwendung unterbrochen wird, sobald OSM sie verwaltet hat, und Ihnen Zeit geben, Ihre Regeln zu definieren, während sichergestellt wird, dass die Anwendungskommunikation mTLS-verschlüsselt ist. Diese Einstellung kann auf true oder false über die MeshConfig von OSM festgelegt werden.

Istio behandelt die mTLS-Erzwingung anders. Anders als OSM konfiguriert der permissive Modus von Istio automatisch Sidecar-Proxys für die Verwendung von mTLS, ermöglicht es dem Dienst jedoch, sowohl Klartext- als auch MTLS-Datenverkehr zu akzeptieren. Das Äquivalent zur Konfiguration des permissiven Modus von OSM ist die Verwendung der PeerAuthentication-Einstellungen von Istio. PeerAuthentication kann im Namespace oder für das gesamte Gittermodell präzise ausgeführt werden. Weitere Informationen zur Erzwingung von mTLS durch Istio finden Sie im Artikel „Istio Mutual TLS Migration“.

Erzwingen des Strict-Modus von Istio für Bookstore-Namespaces

Es ist wichtig zu beachten, dass sich die PeerAuthentication-Konfiguration von Istio, genau wie der permissive Modus von OSM, nur auf die Verwendung der mTLS-Erzwingung bezieht. Tatsächliche Layer-7-Richtlinien, wie sie in den HTTPRouteGroups von OSM verwendet werden, werden mithilfe der AuthorizationPolicy-Konfigurationen von Istio verarbeitet, die später in der exemplarischen Vorgehensweise zu sehen sind.

Wir versetzen die Namespaces bookbuyer, bookthief, bookstore und bookwarehouse präzise in den mTLS-Strict-Modus von Istio.

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookbuyer
  namespace: bookbuyer
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookthief
  namespace: bookthief
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookstore
  namespace: bookstore
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
spec:
  mtls:
    mode: STRICT
EOF

Bereitstellen der Access Control-Richtlinien von Istio

Ähnlich wie die OSM-Ressourcen SMI Traffic Target und SMI Traffic Specs zur Definition von Zugriffssteuerungs- und Routingrichtlinien für die zu kommunizierenden Anwendungen erreicht Istio diese ähnlichen detaillierten Steuerelemente mithilfe der AuthorizationPolicy-Konfigurationen.

Lassen Sie uns die Übersetzung der TrafficTarget-Richtlinie von Bookstore durchgehen, die insbesondere bookbuyer die Kommunikation ermöglicht, und zwar nur mit bestimmten Layer-7-Pfaden, Headern und Methoden. Im Folgenden ist ein Teil des Manifests traffic-access-v1.yaml zu sehen.

kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha3
metadata:
  name: bookstore
  namespace: bookstore
spec:
  destination:
    kind: ServiceAccount
    name: bookstore
    namespace: bookstore
  rules:
    - kind: HTTPRouteGroup
      name: bookstore-service-routes
      matches:
        - buy-a-book
        - books-bought
  sources:
    - kind: ServiceAccount
      name: bookbuyer
      namespace: bookbuyer
---
apiVersion: specs.smi-spec.io/v1alpha4
kind: HTTPRouteGroup
metadata:
  name: bookstore-service-routes
  namespace: bookstore
spec:
  matches:
    - name: books-bought
      pathRegex: /books-bought
      methods:
        - GET
      headers:
        - "user-agent": ".*-http-client/*.*"
        - "client-app": "bookbuyer"
    - name: buy-a-book
      pathRegex: ".*a-book.*new"
      methods:
        - GET

Laut TrafficTarget-Richtlinie können Sie in der Spezifikation explizit definieren, welcher Quelldienst mit einem Zieldienst kommunizieren kann. Wie lassen also zu, dass die Quelle bookbuyer für die Kommunikation mit dem Ziel-Bookstore autorisiert wird. Wenn wir die Dienst-zu-Dienst-Autorisierung von einer OSM TrafficTarget-Konfiguration in ein Istio AuthorizationPolicy übersetzen, sieht dies wie folgt aus:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: bookstore
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer"]

Im AuthorizationPolicy von Istio ist zu sehen, wie der OSM TrafficTarget-Richtlinien-Zieldienst der Übereinstimmung der Selektorbezeichnung und dem Namespace, in dem sich der Dienst befindet, zugeordnet ist. Der Quelldienst wird im Abschnitt „Regeln“ dargestellt, in dem ein Quell-/Prinzipien-Attribut vorhanden ist, das dem Dienstkontonamen für den bookbuyer-Dienst zugeordnet ist.

Zusätzlich zur reinen Quell-/Zielkonfiguration in der OSM-TrafficTarget-Ressource bindet OSM die Verwendung von HTTPRouteGroup, um die Autorisierung in Schicht 7 weiter zu definieren, auf die die Quelle Zugriff hat. Wir können nur den Teil der HTTPRouteGroup unten sehen. Für den zulässigen Quelldienst gibt es zwei matches.

apiVersion: specs.smi-spec.io/v1alpha4
kind: HTTPRouteGroup
metadata:
  name: bookstore-service-routes
  namespace: bookstore
spec:
  matches:
    - name: books-bought
      pathRegex: /books-bought
      methods:
        - GET
      headers:
        - "user-agent": ".*-http-client/*.*"
        - "client-app": "bookbuyer"
    - name: buy-a-book
      pathRegex: ".*a-book.*new"
      methods:
        - GET

Es gibt einen match mit dem Namen books-bought, der der Quelle den Zugriff auf den Pfad /books-bought mithilfe einer GET-Methode mit Benutzer-Agent- und Client-App-Informationen des Hostheaders ermöglicht, und eine buy-a-book-Übereinstimmung, die einen regex express für einen Pfad mit .*a-book.*new mithilfe einer GET-Methode verwendet.

Diese OSM-HTTPRouteGroup-Konfigurationen können im Abschnitt „Regeln“ des unten gezeigten Istio AuthorizationPolicy definiert werden:

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "bookstore"
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer"]
        - source:
            namespaces: ["bookbuyer"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["*/books-bought", "*/buy-a-book/new"]
    - when:
        - key: request.headers[User-Agent]
          values: ["*-http-client/*"]
        - key: request.headers[Client-App]
          values: ["bookbuyer"]

Wir können jetzt das von OSM migrierte Manifest traffic-access-v1.yaml so bereitstellen, wie es von Istio unten verstanden wird. Es gibt kein AuthorizationPolicy für die Bookthief, daher sollte die Bookthief-Benutzeroberfläche das Inkrementieren von Büchern aus Bookstore v1 beenden:

kubectl apply -f - <<EOF
##################################################################################################
# bookstore policy
##################################################################################################
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "bookstore"
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer"]
        - source:
            namespaces: ["bookbuyer"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["*/books-bought", "*/buy-a-book/new"]
    - when:
        - key: request.headers[User-Agent]
          values: ["*-http-client/*"]
        - key: request.headers[Client-App]
          values: ["bookbuyer"]
---
##################################################################################################
# bookwarehouse policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "bookwarehouse"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: bookwarehouse
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookstore/sa/bookstore"]
        - source:
            namespaces: ["bookstore"]
      to:
        - operation:
            methods: ["POST"]
---
##################################################################################################
# mysql policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "mysql"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: mysql
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookwarehouse/sa/bookwarehouse"]
        - source:
            namespaces: ["bookwarehouse"]
      to:
         - operation:
            ports: ["3306"]
EOF

Bookthief-Anwendung kann auf Bookstore zugreifen

Derzeit gibt es keine AuthorizationPolicy, die es dem Bookthief ermöglicht, mit Bookstore zu kommunizieren. Wir können folgende AuthorizationPolicy bereitstellen, damit der Bookthief mit Bookstore kommunizieren kann. Sie sehen den Zusatz für die Regel für die Bookstore-Richtlinie, die die Bookthief-Autorisierung zulässt.

kubectl apply -f - <<EOF
##################################################################################################
# bookstore policy
##################################################################################################
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "bookstore"
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer", "cluster.local/ns/bookthief/sa/bookthief"]
        - source:
            namespaces: ["bookbuyer", "bookthief"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["*/books-bought", "*/buy-a-book/new"]
    - when:
        - key: request.headers[User-Agent]
          values: ["*-http-client/*"]
        - key: request.headers[Client-App]
          values: ["bookbuyer"]
---
##################################################################################################
# bookwarehouse policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "bookwarehouse"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: bookwarehouse
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookstore/sa/bookstore"]
        - source:
            namespaces: ["bookstore"]
      to:
        - operation:
            methods: ["POST"]
---
##################################################################################################
# mysql policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "mysql"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: mysql
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookwarehouse/sa/bookwarehouse"]
        - source:
            namespaces: ["bookwarehouse"]
      to:
         - operation:
            ports: ["3306"]
EOF

Die Bookthief-Benutzeroberfläche sollte jetzt Bücher aus Bookstore v1 inkrementieren.

Konfigurieren des Verschiebens des Datenverkehrs zwischen zwei Dienstversionen

Um zu veranschaulichen, wie Datenverkehr zwischen zwei Versionen eines Kubernetes-Diensts ausgeglichen wird, was in Istio als Verschieben des Datenverkehrs bezeichnet wird. Wie Sie sich in einem vorherigen Abschnitt beschrieben, stützte sich die OSM-Implementierung für das Verschieben des Datenverkehrs darauf, dass zwei verschiedene Dienste bereitgestellt und diese Dienstnamen zur Back-End-Konfiguration der TrafficTarget-Richtlinie hinzugefügt wurden. Diese Bereitstellungsarchitektur ist für die Implementierung für das Verschieben von Datenverkehr durch Istio nicht erforderlich. Mit Istio können mehrere Bereitstellungen erstellt werden, die jede Version der Dienstanwendung darstellen, und Datenverkehr über die virtualservice-Konfiguration von Istio an diese spezifischen Versionen verschieben.

Die derzeit bereitgestellte virtualservice verfügt nur über eine Routenregel für die unten dargestellte v1-Version von Bookstore:

spec:
  hosts:
    - bookstore
  http:
    - route:
        - destination:
            host: bookstore
            subset: v1

Wir aktualisieren virtualservice, um 100 % der Gewichtung auf die v2-Version von Bookstore zu verschieben.

kubectl apply -f - <<EOF
# Create bookstore virtual service
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookstore-virtualservice
  namespace: bookstore
spec:
  hosts:
  - bookstore
  http:
  - route:
    - destination:
        host: bookstore
        subset: v1
      weight: 0
    - destination:
        host: bookstore
        subset: v2
      weight: 100
EOF

Jetzt sollten Sie sehen, dass sowohl die Benutzerfläche bookbuyer als auch bookthief nur für den bookstore v2-Dienst inkrementiert werden. Sie können weiter experimentieren, indem Sie das weigth-Attribut ändern, um den Datenverkehr zwischen den beiden bookstore-Versionen zu verschieben.

Zusammenfassung

Wir hoffen, dass wir Ihnen mit dieser exemplarischen Vorgehensweise zeigen konnten, wie Sie Ihre aktuellen OSM-Richtlinien zu Istio-Richtlinien migrieren können. Lesen Sie sorgfältig die Konzepte von Istio, und sehen Sie sich den Istio-Leitfaden für erste Schritte an, um zu erfahren, wie Sie das Dienst-Gittermodel von Istio für die Verwaltung Ihrer Anwendungen verwenden können.