Anthos Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Optionale Features auf einer clusterinternen Steuerungsebene aktivieren

Auf dieser Seite wird beschrieben, wie Sie optionale Features in Cloud Service Mesh mit einer clusterinternen Steuerungsebene aktivieren.

Wenn Sie clusterinternes Cloud Service Mesh installieren, unterscheiden sich die standardmäßig aktivierten Funktionen je nach Plattform. Sie können die Standardkonfiguration überschreiben und ein optionales Feature aktivieren, indem Sie beim Installieren oder Upgraden von Cloud Service Mesh eine Overlay-Datei einfügen. Eine Overlay-Datei ist eine YAML-Datei, die eine benutzerdefinierte IstioOperator-Ressource (Custom Resource, CR) enthält, mit der Sie die Steuerungsebene konfigurieren. Geben Sie pro Overlay-Datei ein Feature an. Sie können weitere Overlays übereinander legen. Jede Overlay-Datei überschreibt die Konfiguration auf den vorherigen Ebenen.

Informationen zu Overlay-Dateien

Die Overlay-Dateien auf dieser Seite befinden sich im anthos-service-mesh-Paket in GitHub. Diese Dateien enthalten gängige Anpassungen der Standardkonfiguration. Sie können diese Dateien unverändert anwenden oder weitere Änderungen nach Bedarf daran vornehmen.

Wenn Sie Cloud Service Mesh mit dem asmcli-Skript installieren, können Sie mit der Option --option oder --custom_overlay eine oder mehrere Overlay-Dateien angeben. Wenn Sie keine Änderungen an den Dateien im anthos-service-mesh-Repository vornehmen müssen, können Sie --option verwenden. Das Skript ruft dann die Datei von GitHub ab. Andernfalls können Sie die Overlay-Datei ändern und sie mit der Option --custom_overlay an asmcli übergeben.

Nicht mehrere CRs in eine Overlay-Datei einfügen	Separate Overlay-Dateien für jede CR erstellen

So aktivieren Sie optionale Features

Die folgenden Beispiele sind vereinfacht, damit nur die Verwendung benutzerdefinierter Overlays zur Aktivierung optionaler Features dargestellt wird. Ersetzen Sie OTHER_FLAGS durch die erforderlichen Installationsflags.

Der Befehl asmcli install bietet zwei Möglichkeiten zum Aktivieren eines optionalen Features. Welche Methode Sie verwenden, hängt davon ab, ob Sie Änderungen an der Overlay-Datei vornehmen müssen.

Verwenden Sie --option, wenn Sie keine Änderungen an der Overlay-Datei vornehmen müssen. Mit --option ruft asmcli die Datei aus dem GitHub-Repository für Sie ab. Dazu benötigen Sie eine Internetverbindung.
```
./asmcli install \
  OTHER_FLAGS \
  --option OPTION_NAME
```
Ersetzen Sie OPTION_NAME durch die Option, die Sie aktivieren möchten. Lassen Sie die Erweiterung .yaml weg und geben Sie nur den Namen der Overlay-Datei an, z. B. iap-operator und attached-cluster. Eine Liste der Optionen finden Sie im Paket anthos-service-mesh.
Verwenden Sie --custom_overlay, wenn Sie die Overlay-Datei anpassen müssen.
```
./asmcli install \
  OTHER_FLAGS \
  --custom_overlay PATH_TO_FILE
```
Ersetzen Sie PATH_TO_FILE durch den Pfad zur Overlay-Datei, die Sie verwenden möchten.

YAML für optionale Features

Die folgenden Abschnitte enthalten die YAML-Datei, um optionale und unterstützte Funktionen zu aktivieren.

mTLS-`STRICT`-Modus

Die Konfiguration global.mtls.enabled wurde aus der IstioOperator-CR entfernt, um Probleme mit Upgrades zu vermeiden und eine flexiblere Installation zu ermöglichen. Konfigurieren Sie zum Aktivieren von STRICT mTLS stattdessen eine Peer-Authentifizierungsrichtlinie.

Distroless-Proxy-Image

Als Best Practice sollten Sie den Inhalt einer Containerlaufzeit nur auf die erforderlichen Pakete beschränken. Dieser Ansatz verbessert die Sicherheit und das Signal-Rausch-Verhältnis von CVE-Scannern (Common Vulnerabilities and Exposures). Istio stellt Proxy-Images bereit, die auf Distroless-Basis-Images basieren.

Die folgende Konfiguration aktiviert Distroless-Images für das gesamte Cloud Service Mesh. Bei einer Änderung des Image-Typs muss jeder Pod neu gestartet und neu eingefügt werden, um wirksam zu werden.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      image:
        imageType: distroless

Das Distroless-Image enthält keine anderen Binärdateien als den Proxy. Daher ist es nicht möglich, eine Shell mit exec auszuführen oder curl, ping oder andere Fehlerbehebungsfunktionen im Container zu verwenden.

Wenn Sie einen Curl-Befehl ausführen, wird der folgende Fehler angezeigt:

error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec  "<container-id>"
OCI runtime exec failed: exec failed: unable to start container process: exec: "curl": executable file not found in $PATH: unknown

Wenn Sie einen Shell-Befehl ausführen, wird der folgende Fehler angezeigt:

error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "<container-id>"
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "sh": executable file not found in $PATH: unknown

Wenn Sie für bestimmte Pods Zugriff auf diese Tools benötigen, können Sie den imageType mit der folgenden Pod-Annotation überschreiben.

sidecar.istio.io/proxyImageType: debug

Nachdem Sie den Image-Typ einer Bereitstellung über die Annotation geändert haben, sollte die Bereitstellung neu gestartet werden.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Für die meisten Arten von Proxy-Debugging sollte istioctl proxy-cmd verwendet werden, für das kein Debug-Basis-Image erforderlich ist.

Benutzerdefiniertes Overlay für eine benutzerdefinierte Registry verwenden

Sie können ein benutzerdefiniertes Overlay für benutzerdefinierte Registries verwenden, z. B. wenn Sie Cloud Service Mesh aus einer benutzerdefinierten Container Registry installieren müssen. Beispiel:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  hub: {private_registry_url}

Im Folgenden finden Sie eine Liste von Images für Cloud Service Mesh, die Sie in die benutzerdefinierte Container Registry spiegeln müssen:

Install-cni – gke.gcr.io/asm/install-cni:1.25.5-asm.7
Managed Data Plane – gke.gcr.io/asm/mdp:1.25.5-asm.7
Pilot – gke.gcr.io/asm/pilot:1.25.5-asm.7
Proxyv2 – gke.gcr.io/asm/proxyv2:1.25.5-asm.7

Images zu einer privaten Registry hinzufügen

Führen Sie die folgenden Schritte aus, um Cloud Service Mesh-Images in eine private Registry zu übertragen.

Rufen Sie die Cloud Service Mesh-Images ab:

docker pull gke.gcr.io/asm/install-cni:1.25.5-asm.7
docker pull gke.gcr.io/asm/mdp:1.25.5-asm.7
docker pull gke.gcr.io/asm/pilot:1.25.5-asm.7
docker pull gke.gcr.io/asm/proxyv2:1.25.5-asm.7

Erstellen Sie eine Variable für Ihre private Registry-URL:
```
export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
```
Ersetzen Sie PRIVATE_REGISTRY_URL durch Ihre private Registry-URL.

Taggen Sie die Images mit Ihrer privaten Registry-URL:

docker tag gke.gcr.io/asm/install-cni:1.25.5-asm.7 \
 ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.25.5-asm.7
docker tag gke.gcr.io/asm/mdp:1.25.5-asm.7 \
 ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.25.5-asm.7
docker tag gke.gcr.io/asm/pilot:1.25.5-asm.7 \
 ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.25.5-asm.7
docker tag gke.gcr.io/asm/proxyv2:1.25.5-asm.7 \
 ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.25.5-asm.7

Übertragen Sie die getaggten Images in Ihre private Registry:

docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.25.5-asm.7
docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.25.5-asm.7
docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.25.5-asm.7
docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.25.5-asm.7

Optional: Wenn Sie einen kanonischen Dienst verwenden, fügen Sie die Images des kanonischen Diensts Ihrer privaten Registry hinzu.

Rufen Sie die Images des kanonischen Diensts für Cloud Service Mesh ab:

        docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
        docker pull gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16

Taggen Sie die Images mit Ihrer privaten Registry-URL:

        docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 \
        ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
        docker tag gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16 \
        ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16

Übertragen Sie die getaggten Images in Ihre private Registry:

        docker push ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
        docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16

Wenn Sie die getaggten Images aus Ihrer privaten Registry abrufen können, war der Vorgang erfolgreich.

Dauer der Entladung nach Terminierung verlängern

Standardmäßig wartet Envoy fünf Sekunden (5s), bis bestehende Verbindungen abgeschlossen sind, wenn ein Pod terminiert wird.

Der Wert für Pod terminationGracePeriodSeconds muss größer sein als der Wert für terminationDrainDuration.

Weitere Informationen finden Sie unter Globale Mesh-Optionen.

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      terminationDrainDuration: 30s

Zugriffslogs aktivieren

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

Weitere Informationen finden Sie unter Zugriffs-Logging von Envoy aktivieren.

Cloud Trace

Cloud Trace ist mit Cloud Service Mesh-Installationen auf den folgenden Plattformen verfügbar:

GKE auf Google Cloud
Lokale GKE Enterprise-Cluster, wenn Sie sie mit der Cloud Service Mesh-Zertifizierungsstelle installieren

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
  values:
    global:
      proxy:
        tracer: stackdriver

Weitere Informationen finden Sie unter Auf Traces zugreifen.

Ausgehender Traffic über Egress-Gateways

Wir empfehlen, ein injiziertes Gateway zu installieren, wie unter Gateways installieren und upgraden beschrieben. Mit Injektion oder automatischer Injektion ist die Verwendung von mutierenden Webhooks zum Ändern von Pod-Spezifikationen bei der Erstellung gemeint. Sie verwenden Injektion, um die Envoy-Proxy-Sidecar-Konfiguration für Ihre Mesh-Dienste hinzuzufügen oder den Envoy-Proxy von Gateways zu konfigurieren.

Container-Netzwerkschnittstelle von Istio

Wie Sie die Container-Netzwerkschnittstelle (CNI) von Istio aktivieren, hängt von der Umgebung ab, in der Cloud Service Mesh installiert ist.

Netzwerkrichtlinie aktivieren
Wählen Sie die Overlay-Datei aus, die Ihrer Plattform entspricht.

CNI in der GKE aktivieren

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /home/kubernetes/bin
      excludeNamespaces:
        - istio-system
        - kube-system

CNI lokal aktivieren

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /opt/cni/bin
      excludeNamespaces:
        - istio-system
        - kube-system
        - gke-system

Traffic-Logs für Off-Google Cloudaktivieren

Die Installation von Cloud Service Mesh mit einer Istio-Zertifizierungsstelle außerhalb von Google Cloud meldet Messwerte standardmäßig an Prometheus. Verwenden Sie diese Option, um stattdessen das Melden von Traffic-Logs oder sowohl Prometheus als auch Stackdriver zu aktivieren, damit Sie die Cloud Service Mesh-Dashboards verwenden können.

Nur Stackdriver

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: false
        stackdriver:
          enabled: true

Stackdriver und Prometheus

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: true
        stackdriver:
          enabled: true

Internen Load-Balancer aktivieren

Wir empfehlen, ein injiziertes Gateway zu installieren, wie unter Gateways installieren und upgraden beschrieben, um einen internen Load-Balancer in der GKE einzurichten. Beim Konfigurieren des Gateway-Dienstes geben Sie die folgende Annotation an: networking.gke.io/load-balancer-type: "Internal"

Externe Zertifikatsverwaltung auf dem Ingress-Gateway

Informationen zum Aktivieren der externen Zertifikatsverwaltung auf dem Ingress-Gateway mit Envoy SDS finden Sie unter Sichere Gateways.