Kubernetes-Arbeitslasten einbinden

Hinweis: Dieser Leitfaden unterstützt nur Cloud Service Mesh mit Istio APIs und keine Google Cloud APIs. Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

Auf dieser Seite erfahren Sie, wie Sie Kubernetes-Arbeitslasten mit Cloud Service Mesh einrichten.

Kubernetes-Dienste bereitstellen

So stellen Sie Kubernetes-Dienste in Clustern mit Cloud Service Mesh bereit:

• Erstellen Sie Kubernetes-Dienste für alle Container. Allen Deployments sollte ein Kubernetes-Dienst zugeordnet sein.

• Geben Sie einen Namen für die Dienstports an. In GKE können Sie zwar unbenannte Dienstports definieren, in Cloud Service Mesh müssen Sie jedoch einen Namen für einen Port angeben, der mit dem Protokoll des Ports übereinstimmt.

• Kennzeichnen Sie Ihre Deployments mit Labels. So können Sie die Traffic-Management-Funktionen von Cloud Service Mesh nutzen, z. B. zum Aufteilen des Traffics zwischen Versionen desselben Dienstes.

Mit dem folgenden Beispiel-Deployment und -Dienst werden diese Anforderungen veranschaulicht:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloserver
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      containers:
      - image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always
        name: main
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer

Nachdem Sie Ihre Dienste in einem Cluster mit Cloud Service Mesh bereitgestellt haben, müssen Sie Sidecar-Proxys einfügen.

Beispiel: Online Boutique-Beispiel bereitstellen

Die Online Boutique-Beispielanwendung im anthos-service-mesh-packages-Repository wird aus dem ursprünglichen Satz von Manifesten im microservices-demo-Repository modifiziert. Gemäß den Best Practices wird jeder Dienst in einem separaten Namespace mit einem eigenen Dienstkonto bereitgestellt.

1. Erstellen Sie die Namespaces für die Anwendung:

   kubectl apply -f \
     DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces
   

   Erwartete Ausgabe:

   namespace/ad created
   namespace/cart created
   namespace/checkout created
   namespace/currency created
   namespace/email created
   namespace/frontend created
   namespace/loadgenerator created
   namespace/payment created
   namespace/product-catalog created
   namespace/recommendation created
   namespace/shipping created
   

2. Aktivieren Sie die Namespaces für die Injection: Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.

   Verwaltet (TD)

   Wenden Sie das Standard-Injektionslabel auf den Namespace an:

   for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
     kubectl label namespace $ns \
         istio.io/rev- istio-injection=enabled --overwrite
   done;
   

   Verwaltet (Istiod)

   Empfohlen:Führen Sie den folgenden Befehl aus, um das Standard-Injektionslabel auf den Namespace anzuwenden:

     for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
       kubectl label namespace $ns \
           istio.io/rev- istio-injection=enabled --overwrite
     done;
   

   Bereits bestehende Nutzer der verwalteten Istio-Steuerungsebene:Wir empfehlen die Standard-Injection, aber auch die revisionsbasierte Injection wird unterstützt. Gehen Sie dazu so vor:

   1. Führen Sie den folgenden Befehl aus, um die verfügbaren Release-Kanäle zu finden:

      kubectl -n istio-system get controlplanerevision
      

      Die Ausgabe sieht in etwa so aus:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      Hinweis :Wenn in der vorherigen Liste zwei Versionen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Steuerungsebenenkanäle im Cluster werden nicht unterstützt.

      In der Ausgabe ist der Wert in der NAME-Spalte das Überarbeitungslabel, das dem verfügbaren Release-Kanal für die Cloud Service Mesh-Version entspricht.

   2. Wenden Sie das Überarbeitungslabel auf den Namespace an.

      for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
        kubectl label namespace $ns \
            istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      done;
      

   Clusterintern

   Empfohlen:Führen Sie den folgenden Befehl aus, um das Standard-Injektionslabel auf den Namespace anzuwenden:

     for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
       kubectl label namespace $ns \
           istio.io/rev- istio-injection=enabled --overwrite
     done;
   

   Wir empfehlen die Verwendung der Standard-Injection, aber auch die revisionsbasierte Injection wird unterstützt: Folgen Sie dazu dieser Anleitung:

   1. Verwenden Sie den folgenden Befehl, um das Überarbeitungslabel für istiod zu finden:

      kubectl get deploy -n istio-system -l app=istiod -o \
         jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. Wenden Sie das Überarbeitungslabel auf den Namespace an. Im folgenden Befehl ist REVISION_LABEL der Wert des Überarbeitungslabels istiod, den Sie im vorherigen Schritt notiert haben.

      for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
        kubectl label namespace $ns \
            istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      done;
      

3. Stellen Sie die Beispielanwendung im Cluster bereit:

   1. Erstellen Sie die Dienstkonten und Deployments:

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments
      

      Erwartete Ausgabe:

      serviceaccount/ad created
      deployment.apps/adservice created
      serviceaccount/cart created
      deployment.apps/cartservice created
      serviceaccount/checkout created
      deployment.apps/checkoutservice created
      serviceaccount/currency created
      deployment.apps/currencyservice created
      serviceaccount/email created
      deployment.apps/emailservice created
      serviceaccount/frontend created
      deployment.apps/frontend created
      serviceaccount/loadgenerator created
      deployment.apps/loadgenerator created
      serviceaccount/payment created
      deployment.apps/paymentservice created
      serviceaccount/product-catalog created
      deployment.apps/productcatalogservice created
      serviceaccount/recommendation created
      deployment.apps/recommendationservice created
      serviceaccount/shipping created
      deployment.apps/shippingservice created
      

   2. Erstellen Sie die Dienste:

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/kubernetes-manifests/services
      

      Erwartete Ausgabe:

      service/adservice created
      service/cartservice created
      service/checkoutservice created
      service/currencyservice created
      service/emailservice created
      service/frontend created
      service/frontend-external created
      service/paymentservice created
      service/productcatalogservice created
      service/recommendationservice created
      service/shippingservice created
      

   3. Erstellen Sie die Diensteinträge:

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml
      

      Erwartete Ausgabe:

      serviceentry.networking.istio.io/allow-egress-googleapis created
      serviceentry.networking.istio.io/allow-egress-google-metadata created
      

Dienstports benennen

Um in Cloud Service Mesh aufgenommen zu werden, müssen die Dienstports benannt werden und der Name muss das Protokoll des Ports enthalten. Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 9080
    name: http

Der Portname des Diensts kann ein Suffix in der Syntax name: protocol[-suffix] enthalten, wobei mit den eckigen Klammern ein optionales Suffix angegeben wird, das mit einem Bindestrich beginnen muss. Beispiel:

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 3306
    name: mysql
  - number: 80
    name: http-web

Damit die Messwerte in der Google Cloud Console angezeigt werden, müssen die Dienstports mit einem der folgenden Protokolle benannt werden: http, http2 oder grpc. Dienstports mit dem https-Protokoll im Namen werden als tcp behandelt. Für diese Dienste werden keine Messwerte angezeigt.

Sidecar-Proxys einfügen

In diesem Abschnitt wird beschrieben, wie Sie die Sidecar-Proxy-Injektion mit Cloud Service Mesh konfigurieren, um die Netzwerksicherheit, Zuverlässigkeit und Beobachtbarkeit zu verbessern. Diese Funktionen werden vom primären Container der Anwendung abstrahiert und in einem gemeinsamen Out-of-Process-Proxy (Sidecar) implementiert. Dieser wird als separater Container im selben Pod bereitgestellt. Sie können die Features von Cloud Service Mesh verwenden, ohne Ihre Produktionsanwendungen neu gestalten zu müssen, um an einem Service Mesh teilzunehmen.

Die automatische Sidecar-Proxy-Einfügung (automatische Einfügung) tritt auf, wenn Cloud Service Mesh ein Namespace-Label erkennt, das Sie für den Pod der Arbeitslast konfigurieren. Der Proxy fängt den gesamten eingehenden und ausgehenden Traffic an die Arbeitslasten ab und kommuniziert mit Cloud Service Mesh.

Für diese Aufgaben erforderliche Berechtigungen

Zum Ausführen der Aufgaben auf dieser Seite benötigen Sie die Rolle roles/container.clusterAdmin oder eine höhere Rolle. Weitere Informationen zu den in dieser Rolle enthaltenen Berechtigungen finden Sie unter Google Kubernetes Engine-Rollen.

Automatische Sidecar-Einfügung aktivieren

1. Aktivieren Sie den Namespace für die Injection: Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.

   Verwaltet (TD)

   1. Wenden Sie das Standard-Injektionslabel auf den Namespace an:

   kubectl label namespace NAMESPACE
       istio.io/rev- istio-injection=enabled --overwrite
   

   Verwaltet (Istiod)

   Empfohlen:Führen Sie den folgenden Befehl aus, um das Standard-Injektionslabel auf den Namespace anzuwenden:

     kubectl label namespace NAMESPACE \
         istio.io/rev- istio-injection=enabled --overwrite
   

   Bereits bestehende Nutzer der verwalteten Istio-Steuerungsebene:Wir empfehlen die Standard-Injection, aber auch die revisionsbasierte Injection wird unterstützt. Gehen Sie dazu so vor:

   1. Führen Sie den folgenden Befehl aus, um die verfügbaren Release-Kanäle zu finden:

      kubectl -n istio-system get controlplanerevision
      

      Die Ausgabe sieht in etwa so aus:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      HINWEIS: Wenn in der Liste oben zwei Überarbeitungen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Steuerungsebenenkanäle im Cluster werden nicht unterstützt.

      In der Ausgabe ist der Wert in der NAME-Spalte das Überarbeitungslabel, das dem verfügbaren Release-Kanal für die Cloud Service Mesh-Version entspricht.

   2. Wenden Sie das Überarbeitungslabel auf den Namespace an.

      kubectl label namespace NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

   Clusterintern

   Empfohlen:Führen Sie den folgenden Befehl aus, um das Standard-Injektionslabel auf den Namespace anzuwenden:

     kubectl label namespace NAMESPACE \
         istio.io/rev- istio-injection=enabled --overwrite
   

   Wir empfehlen die Verwendung der Standard-Injection, aber auch die revisionsbasierte Injection wird unterstützt: Folgen Sie dazu dieser Anleitung:

   1. Verwenden Sie den folgenden Befehl, um das Überarbeitungslabel für istiod zu finden:

      kubectl get deploy -n istio-system -l app=istiod -o \
         jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. Wenden Sie das Überarbeitungslabel auf den Namespace an. Im folgenden Befehl ist REVISION_LABEL der Wert des Überarbeitungslabels istiod, den Sie im vorherigen Schritt notiert haben.

      kubectl label namespace NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

2. Starten Sie die betroffenen Pods neu. Führen Sie dazu die Schritte im nächsten Abschnitt aus.

3. Annotieren Sie den demo-Namespace so:

   kubectl annotate --overwrite namespace NAMESPACE \
   mesh.cloud.google.com/proxy='{"managed":"true"}'
   

Pods neu starten, um Sidecar-Proxys zu aktualisieren

Warnung: Wenn Sie für Blau/Grün-Bereitstellungen keinen Load-Balancer oder Router eingerichtet haben, testen Sie den Neustart von Pods in einer Staging-Umgebung, um sicherzustellen, dass Ihre Dienste auf mögliche Trafficunterbrechungen reagieren können.

Mit der automatischen Sidecar-Einfügung können Sie die Sidecar-Proxys für vorhandene Pods mit einem Pod-Neustart aktualisieren.

Wie Sie Pods neu starten, hängt davon ab, ob sie als Teil einer Bereitstellung erstellt wurden.

1. Starten Sie die Bereitstellung neu, wenn Sie eine Bereitstellung verwendet haben. Dadurch werden alle Pods mit Sidecar-Dateien neu gestartet:

   kubectl rollout restart deployment -n NAMESPACE

   Wenn Sie keine Bereitstellung verwendet haben, löschen Sie die Pods, und sie werden automatisch mit Sidecar-Dateien neu erstellt:

   kubectl delete pod -n NAMESPACE --all

2. Prüfen Sie, ob alle Pods im Namespace Sidecar-Dateien eingefügt haben:

   kubectl get pod -n NAMESPACE

   In der folgenden Beispielausgabe des vorherigen Befehls sehen Sie, dass die Spalte READY zwei Container für jede Ihrer Arbeitslasten enthält: den primären Container und den Container für den Sidecar-Proxy.

   NAME                    READY   STATUS    RESTARTS   AGE
   WORKLOAD           2/2     Running   0          20s
   ...