Optionale Features auf der Steuerungsebene im Cluster aktivieren

Auf dieser Seite wird beschrieben, wie Sie optionale Features auf einer Steuerungsebene im Cluster aktivieren Informationen zur verwalteten Steuerungsebene finden Sie unter Verwaltetes Anthos Service Mesh konfigurieren.

Wenn Sie Anthos Service Mesh installieren, unterscheiden sich die standardmäßig aktivierten Features je nach Plattform. Sie können optional Features aktivieren und dazu beim Installieren oder beim Upgrade von Anthos 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. Sie können die Standardkonfiguration überschreiben und ein optionales Feature aktivieren oder ein Standardfeature in einer Overlay-Datei deaktivieren. Geben Sie pro Overlay-Datei ein Feature an. Sie können mehr Overlays übereinander legen. Jede Overlay-Datei überschreibt die Konfiguration auf den vorherigen Ebenen.

Achtung: Mit asmcli install wird die vorhandene Konfiguration der Steuerungsebene überschrieben. Wenn Sie für eine vorhandene Installation optionale Features aktivieren, geben Sie alle Dateien an, die Sie in der ursprünglichen Konfiguration beibehalten möchten, sowie die Overlay-Dateien für die Features, die Sie aktivieren möchten. Wir empfehlen, die für die Installation verwendeten Overlay-Dateien in der Versionsverwaltung zu speichern, damit Sie bei Upgrades oder beim Aktivieren zusätzlicher optionaler Funktionen dieselben Konfigurationen auf Ihre Steuerungsebene anwenden können.

.

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 daran vornehmen.

Wenn Sie Anthos Service Mesh mit dem von Google bereitgestellten asmcli-Skript installieren, haben Sie die Möglichkeit, eine oder mehrere Overlay-Dateien mit der Option --option oder der Option --custom_overlay anzugeben. Wenn Sie keine Änderungen an den Dateien im anthos-service-mesh-Repository vornehmen müssen, können Sie --option verwenden. Das Skript ruft die Datei von GitHub ab. Sie können aber auch die Overlay-Datei ändern und die Änderungen mit der Option --custom_overlay an asmcli übergeben.

Wichtig: Gib in einer Overlay-Datei nicht mehr als eine IstioOperator-Antwortvorlage an, da istioctl install nur die erste in der Datei gefundene Antwortvorlage anwendet.

Fügen Sie nicht mehrere CRs in eine Overlay-Datei ein.	Separate Overlay-Dateien für jede CR erstellen

So aktivieren Sie optionale Features

Die folgenden Beispiele sind vereinfacht, damit nur die benutzerdefinierten Overlays zur Aktivierung optionaler Features angezeigt werden. Ersetzen Sie OTHER_FLAGS durch die anderen Befehlszeilenoptionen.

Wichtig: Die Reihenfolge der Dateien in der Befehlszeile spielt eine wichtige Rolle. Geben Sie unbedingt erst die für die Standardfunktionen erforderliche Konfiguration und danach die Overlay-Dateien an.

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. 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.

Proxy-Image löschen

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

Die folgende Konfiguration aktiviert Distributions-Images für das gesamte Anthos 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 zu versehen oder curl, ping oder andere Fehlerbehebungsfunktionen im Container zu verwenden. Wenn Sie versuchen, eine Shell auszufü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 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 Anthos 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 Anthos Service Mesh, die Sie in die benutzerdefinierte Container Registry spiegeln müssen:

• Install-cni - gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
• Verwaltete Datenebene - gcr.io/gke-release/asm/mdp:1.14.6-asm.16
• Pilot - gcr.io/gke-release/asm/pilot:1.14.6-asm.16
• Proxyv2 - gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16

Hinweis: Wenn Sie einen kanonischen Dienst verwenden, müssen Sie auch die benutzerdefinierten Container Registries gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 und gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16 spiegeln.

Images zu einer privaten Registry hinzufügen

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

Hinweis: Verwenden Sie einen Client, von dem Sie Daten aus gcr.io abrufen und in Ihre private Registry senden können.

1. Rufen Sie die Anthos Service Mesh-Images ab:

   docker pull gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
   docker pull gcr.io/gke-release/asm/mdp:1.14.6-asm.16
   docker pull gcr.io/gke-release/asm/pilot:1.14.6-asm.16
   docker pull gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
   

2. 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.
3. Taggen Sie die Images mit Ihrer privaten Registry-URL:

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

4. Übertragen Sie die getaggten Images in Ihre private Registry:

   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.14.6-asm.16
   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.14.6-asm.16
   docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
   

5. (Optional) Wenn Sie einen kanonischen Dienst verwenden, fügen Sie die kanonischen Dienst-Images Ihrer privaten Registry hinzu.
   1. Rufen Sie die kanonischen Dienst-Images von Anthos Service Mesh ab:

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

   2. Taggen Sie die Images mit Ihrer privaten Registry-URL:

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

   3. Übertragen Sie die getaggten Images in Ihre private Registry:

              docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/kube-rbac-proxy:v0.5.0
              docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/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.

Envoy an stdout weiterleiten

---
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 Anthos Service Mesh-Installationen auf den folgenden Plattformen verfügbar:

• GKE in Google Cloud
• Lokale GKE Enterprise-Cluster, wenn Sie mit der Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) installieren

Ausführliche Preisinformationen finden Sie auf der Seite "Cloud Trace – Preise".

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

Die Standardabtastrate beträgt 1 %. Sie können den Standardwert aber durch Angabe eines tracing.sampling-Werts überschreiben. Der Wert muss zwischen 0,0 und 100,0 mit einer Genauigkeit von 0,01 liegen. Wenn Sie beispielsweise fünf Anfragen pro 10.000 Anfragen verfolgen möchten, verwenden Sie 0,05.

Das folgende Beispiel zeigt eine Abtastrate von 100 % (nur für Demozwecke oder zur Fehlerbehebung).

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100
  values:
    global:
      proxy:
        tracer: stackdriver

Beachten Sie, dass die Tracer-Konfiguration derzeit Teil der Proxy-Bootstrap-Konfiguration ist. Deshalb muss der Pod neu gestartet und wieder eingefügt werden, um die Tracer-Aktualisierung zu übernehmen. Sie können beispielsweise mit dem folgenden Befehl die Pods für ein Deployment neu starten:

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Weitergabe von Trace-Kontext

Auch wenn die Sidecar-Proxys automatisch Trace-Spans senden können, benötigen sie einige Hinweise, um den gesamten Trace zu verknüpfen. Anwendungen müssen die entsprechenden HTTP-Header weiterleiten, sodass die Spans einem einzigen Trace korrekt zugeordnet werden können, wenn die Proxys die Spaninformationen senden.

Dazu muss eine Anwendung die erforderlichen Header aus der eingehenden Anfrage erfassen und an alle ausgehenden Anfragen weiterleiten. Die Stackdriver-Tracing-Konfiguration von Anthos Service Mesh akzeptiert alle folgenden Headerformate und gibt alle folgende Formate weiter:

• B3 (x-b3-traceid, x-b3-spanid, x-b3parentspanid, x-b3-sampled, x-b3-flags)
• W3C TraceContext (traceparent)
• Google Cloud Trace (x-cloud-trace-context)
• gRPC TraceBin (grpc-trace-bin)

Dies bedeutet, dass Ihre Anwendungen ein beliebiges dieser Formate nutzen können, um Tracing-Kontext zu übertragen; die Traces werden generiert und korrekt auf Stackdriver eingestellt.

Beispiel

Hier ist ein Beispiel für eine HTTP-Get-Anfrage mit einem traceparent-Header in der ursprünglichen Anfrage. Beachten Sie die zusätzlichen Trace-Kontextheader, die vom Proxy hinzugefügt wurden.

$ kubectl exec -it sleep-557747455f-n6flv -- curl "httpbin:8000/anything?freeform=" -H "accept: application/json" -H "Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01" -vv
*   Trying 10.12.3.52:8000...
* Connected to httpbin (10.12.3.52) port 8000 (#0)
> GET /anything?freeform= HTTP/1.1
> Host: httpbin:8000
> User-Agent: curl/7.80.0-DEV
> accept: application/json
> Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: envoy
< date: Wed, 10 Nov 2021 20:36:04 GMT
< content-type: application/json
< content-length: 1032
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 5
<
{
  "args": {
    "freeform": ""
  },
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "application/json",
    "Grpc-Trace-Bin": "AAB1Q9FeCeXWGAHU90zeEmm4AaDHmGRtdM7wAgE",
    "Host": "httpbin:8000",
    "Traceparent": "00-7543d15e09e5d61801d4f74cde1269b8-a0c798646d74cef0-01",
    "User-Agent": "curl/7.80.0-DEV",
    "X-B3-Sampled": "1",
    "X-B3-Spanid": "a0c798646d74cef0",
    "X-B3-Traceid": "7543d15e09e5d61801d4f74cde1269b8",
    "X-Cloud-Trace-Context": "7543d15e09e5d61801d4f74cde1269b8/11585396123534413552;o=1",
    "X-Envoy-Attempt-Count": "1",
    "X-Forwarded-Client-Cert": "<REDACTED>"
  },
  "json": null,
  "method": "GET",
  "origin": "127.0.0.6",
  "url": "http://httpbin:8000/anything?freeform="
}

Beachten Sie, dass der vollständige Satz an Trace-Kontext-Headern im zurückgegebenen Satz an Anfrageheadern vorhanden ist.

Weitere Beispiele für die Weitergabe der Header finden Sie unter Weitergabe von Trace-Kontext.

Trace von einem Client mit benutzerdefinierter ID erstellen

Verwenden Sie zum Erstellen eines Trace von einem Client mit einer benutzerdefinierten ID den Befehl curl, um eine Anfrage mit einem externen Client zu erstellen und die Anzeige eines Trace zu erzwingen. Beispiel:

curl $URL --header "x-client-trace-id: 105445aa7843bc8bf206b12000100000"

Weitere Informationen zu x-client-trace-id finden Sie in der Envoy-Dokumentation.

Hinweis: Wenn Sie die Anthos Service Mesh-Sidecar-Container testen, die Cloud Trace-Daten mithilfe der Mikrodienst-Demo von Google senden, müssen Sie die integrierte Cloud Trace-Funktion deaktivieren. Die Mikrodienst-Demo kann Cloud Trace-Daten ohne Istio senden. Wenn Sie diese Funktion nicht deaktivieren, werden doppelte Traces erzeugt, da sowohl der Anwendungscontainer als auch der Sidecar-Container Traces senden. In der Mikrodienst-Demo-Release-Datei sind mehrere DISABLE_TRACING-Variablen zu konfigurieren.

Ausgehender Traffic über Egress-Gateways

Wir empfehlen, ein injiziertes Gateway zu installieren, wie unter Gateways installieren und aktualisieren beschrieben.

Container-Netzwerkschnittstelle von Istio

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

1. Netzwerkrichtlinien aktivieren

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

CNI in 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

Google Cloud-Beobachtbarkeit für Standorte außerhalb von Google Cloud aktivieren

Die Installation von Anthos Service Mesh mit Istio-Zertifizierungsstelle außerhalb von Google Cloud meldet Messwerte standardmäßig an Prometheus. Verwenden Sie diese Option, um Messwerte für die Berichterstellung stattdessen für Google Cloud Observability oder sowohl für Prometheus als auch für Stackdriver zu aktivieren, damit Sie die Anthos 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 aktualisierenbeschrieben, um einen internen Load-Balancer in GKE einzurichten. Beim Konfigurieren des Gateway-Dienstes geben Sie die Annotation networking.gke.io/load-balancer-type: "Internal" an.

Externe Zertifikatsverwaltung auf dem Ingress-Gateway

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