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 Cloud Service Mesh konfigurieren.
Wenn Sie Cloud Service Mesh im Cluster installieren, unterscheiden sich die standardmäßig aktivierten Features 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 mehrere Overlays ebenenweise platzieren. 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 daran vornehmen.
Wenn Sie Cloud 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.
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 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
ruftasmcli
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 Dateiendung „.yaml“ weg und geben Sie nur den Namen der Overlay-Datei an, z. B.iap-operator
undattached-cluster
. Eine Liste der Optionen finden Sie im Paketanthos-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 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
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 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.23.3-asm.2
- Verwaltete Datenebene -
gke.gcr.io/asm/mdp:1.23.3-asm.2
- Pilot -
gke.gcr.io/asm/pilot:1.23.3-asm.2
- Proxyv2 -
gke.gcr.io/asm/proxyv2:1.23.3-asm.2
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.23.3-asm.2 docker pull gke.gcr.io/asm/mdp:1.23.3-asm.2 docker pull gke.gcr.io/asm/pilot:1.23.3-asm.2 docker pull gke.gcr.io/asm/proxyv2:1.23.3-asm.2
-
Erstellen Sie eine Variable für Ihre private Registry-URL:
Ersetzen Sieexport PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
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.23.3-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.3-asm.2 docker tag gke.gcr.io/asm/mdp:1.23.3-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.3-asm.2 docker tag gke.gcr.io/asm/pilot:1.23.3-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.3-asm.2 docker tag gke.gcr.io/asm/proxyv2:1.23.3-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.3-asm.2
- Übertragen Sie die getaggten Images in Ihre private Registry:
docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.3-asm.2 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.3-asm.2 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.3-asm.2 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.3-asm.2
- Optional: Wenn Sie einen kanonischen Dienst verwenden, fügen Sie die Images des kanonischen Dienstes Ihrer privaten Registry hinzu.
- Rufen Sie die kanonischen Dienst-Images von 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}/gke.gcr.io/asm/kube-rbac-proxy:v0.13.1 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
- Rufen Sie die kanonischen Dienst-Images von Cloud Service Mesh ab:
Wenn Sie die getaggten Images aus Ihrer privaten Registry abrufen können, war der Vorgang erfolgreich.
Dauer der Akkuentladung bei Beendigung erhöhen
Standardmäßig wartet Envoy fünf Sekunden (5s
), bis bestehende Verbindungen beendet sind, wenn ein Pod beendet wird.
Pod terminationGracePeriodSeconds
muss größer als der Wert terminationDrainDuration
sein.
Weitere Informationen finden Sie unter Globale Mesh-Optionen.
---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
defaultConfig:
terminationDrainDuration: 30s
Zugriffslogs aktivieren
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 in Google Cloud
- GKE Enterprise-Cluster lokal, wenn Sie mit der Cloud Service Mesh-Zertifizierungsstelle installieren
Weitere Informationen finden Sie unter Auf Protokolle zugreifen.
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 Cloud Service Mesh installiert ist.
Wählen Sie die Overlay-Datei aus, die Ihrer Plattform entspricht.
CNI in GKE aktivieren
CNI lokal aktivieren
Traffic-Logs für externe Google Cloud aktivieren
Die Installation von Cloud Service Mesh mit Istio-Zertifizierungsstelle außerhalb von Google Cloud meldet Messwerte standardmäßig an Prometheus. Verwenden Sie diese Option, um stattdessen Traffic-Logs oder sowohl Prometheus als auch Stackdriver zu aktivieren, sodass Sie die Cloud Service Mesh-Dashboards verwenden können.
Nur Stackdriver
Stackdriver und Prometheus
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.