Anthos Service Mesh 1.10 ist abgelaufen und wird nicht mehr unterstützt. Siehe Upgraden von früheren Versionen.

Lesen Sie die aktuelle Dokumentation oder wählen Sie eine andere verfügbare Version aus:

Verfügbare Versionen

1.20 (neueste Version)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Glossar

Diese Seite enthält kurze Definitionen und Links zu weiteren Informationen für die Begriffe, die in der Anthos Service Mesh-Dokumentation verwendet werden.

A

Anthos Workload Identity: Ein tuple aus trust domain, namespace und service account. Es hat ein SPIFFE-Identitätsformat von spiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount> in Anthos-x509-Zertifikaten. Für andere Arten von Anmeldedaten, z.B. OIDC-Tokens) kann das Format variieren.

C

Canary-Upgrade

Siehe Überarbeitungsbasiertes Upgrade.

Kanonischer Dienst

Ein Label, das auf Arbeitslasten in Anthos Service Mesh angewendet wird und es Ihnen ermöglicht, eine oder mehrere Arbeitslasten als logischer Dienst im Service Mesh zu gruppieren. Eine Arbeitslast gehört zu genau einem kanonischen Dienst, kann aber zu mehreren Kubernetes-Diensten gehören Ein kanonischer Dienst wird durch einen Namen und einen Namespace identifiziert und kann in eine oder mehrere kanonische Überarbeitungen unterteilt werden.

Steuerungsebene

Eine Steuerungsebene besteht aus einer Reihe von Systemdiensten, die das Mesh-Netzwerk oder eine Teilmenge des Mesh-Netzwerks konfigurieren, um die Kommunikation zwischen den Arbeitslastinstanzen zu verwalten. Anthos Service Mesh 1.9 und höher bietet zwei Steuerungsebenen:

Von Google verwaltete Steuerungsebene: Dies ist ein vollständig verwalteter Google Cloud-Dienst, den Sie nur konfigurieren müssen. Google sorgt für dessen Zuverlässigkeit, Upgrades, Skalierung und Sicherheit. Verwaltetes Anthos Service Mesh besteht aus der von Google verwalteten Steuerungsebene und der optionalen von Google verwalteten Datenebene, die sich in der Vorschau befindet.
Clusterinterne Steuerungsebene: Dies ist eine von Google unterstützte Verteilung von istiod, die Sie auf Ihrem Cluster installieren. Wenn Sie Anthos Service Mesh mit istiod installieren, sind Sie für die Aktualisierung sowie die Konfiguration der Sicherheit und Skalierung verantwortlich.

Obwohl die Steuerungsebene ihre Konfiguration an die Sidecar-Proxys verteilt, ist die Steuerungsebene nicht direkt an der Verarbeitung von Traffic für Arbeitslasten im Mesh-Netzwerk beteiligt.

D

Datenebene: Die Datenebene ist der Teil des Mesh-Netzwerks, mit dem die Kommunikation zwischen Arbeitslastinstanzen direkt gesteuert wird. Die Datenebene von Anthos Service Mesh verwendet Proxys, die als Sidecars bereitgestellt werden, um den gesamten von Ihren Mesh-Diensten gesendeten und empfangenen TCP-Traffic zu vermitteln und zu steuern. Managed Anthos Service Mesh bietet eine von Google verwaltete Datenebene, die sich in der Vorschau befindet.

E

Ausgangsgateway: Ein Ausgangsgateway ist ein Envoy-Proxy, mit dem Sie einen bestimmten Ausgangsknoten für den Traffic konfigurieren können, der das Mesh-Netzwerk verlässt. Zur Konfiguration des Proxys verwenden Sie die benutzerdefinierte Gateway-Ressource. Mit einem Ausgangsgateway können Sie einschränken, welche Dienste auf externe Netzwerke zugreifen können. Weitere Informationen finden Sie unter Gateways installieren und aktualisieren.

F

Flotte: Mit einer Flotte (früher als Environ bezeichnet) können Sie Cluster organisieren und so die Verwaltung mehrerer Cluster vereinfachen. Die Registrierung Ihrer Cluster in einer Flotte vereinfacht die Verwaltung eines Multi-Cluster-Mesh-Netzwerks, indem das Konzept der „Gleichheit“ für Identität, Namespaces und Dienste eingeführt wird. Wenn Sie Cluster in verschiedenen Projekten haben, müssen Sie die Cluster beim Flotten-Hostprojekt statt bei dem Projekt registrieren, in dem der Cluster erstellt wurde. Weitere Informationen zu Flotten finden Sie unter Einführung in Flotten.

H

Hydrierte Manifeste: Ein Manifest, das im Ziel bereitgestellt werden kann. Wenn Sie ein Manifest hydrieren möchten, verwenden Sie in der Regel ein Tool wie Helm, Kustomize oder kpt, um Werte für die Variablen im Manifest festzulegen.

I

identity

Identity ist ein grundlegendes Konzept der Sicherheitsinfrastruktur. Das Anthos Service Mesh-Identitätsmodell basiert auf einer Workload Identity der ersten Klasse. Am Anfang der Dienst-zu-Dienst-Kommunikation tauschen die beiden Parteien Anmeldedaten zur Identität zwecks gegenseitiger Authentifizierung aus.

Clients überprüfen die Identität des Servers im Hinblick auf deren sichere Namensinformationen, um festzustellen, ob der Server zur Ausführung des Dienstes autorisiert ist.

Server überprüfen die Identität des Clients, um festzustellen, auf welche Informationen der Client zugreifen kann. Server entscheiden, ob der Zugriff anhand der konfigurierten Autorisierungsrichtlinien zugelassen wird.

Mithilfe der Identität können Server prüfen, wann auf welche Informationen zugegriffen wurde und welche Informationen von einem bestimmten Client aufgerufen wurden. Sie können Clients auch basierend auf den von ihnen verwendeten Diensten Gebühren in Rechnung stellen und Clients, deren Rechnung nicht bezahlt wurde, den Zugriff auf Dienste verweigern.

Das Identitätsmodell von Anthos Service Mesh ist flexibel und detailliert genug, um einen Nutzer, einen einzelnen Dienst oder eine Gruppe von Diensten darzustellen. Auf Plattformen ohne erstklassige Dienstidentität kann Anthos Service Mesh andere Identitäten verwenden, die Dienstinstanzen wie etwa Dienstnamen gruppieren können.

Anthos Service Mesh unterstützt die folgenden Dienstidentitäten auf verschiedenen Plattformen:

Kubernetes: Kubernetes-Dienstkonto
Google Kubernetes Engine: Google Cloud-Dienstkonto
Google Cloud: Google Cloud-Dienstkonto

Ingress-Gateway

Ein Ingress-Gateway ist ein Envoy-Proxy, der als Load-Balancer für die Verarbeitung des von außerhalb des Mesh-Netzwerks eingehenden Traffics fungiert. Mit der benutzerdefinierten Gateway-Ressource konfigurieren Sie den Load-Balancer. Außerdem erstellen Sie virtuelle Dienste und Authentifizierungsrichtlinien, um zu steuern, wie eingehender Traffic gesichert und an Ihre Arbeitslasten weitergeleitet wird. Weitere Informationen finden Sie unter Gateways installieren und aktualisieren.

Injektion

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-Netzwerk-Dienste hinzuzufügen oder den Envoy-Proxy von Gateways zu konfigurieren.

Direktes Upgrade

Ein direktes Upgrade ersetzt die vorhandene Steuerungsebene durch eine neue Überarbeitung. Als Best Practice empfehlen wir Überarbeitungsupgrades.

istiod

istiod (das "d" steht für "Daemon") ist die konsolidierte monolithische Binärdatei, die Dienste der Steuerungsebene bereitstellt. Vor Anthos Service Mesh 1.5 wurden die Dienste der Steuerungsebene von den separaten Komponenten Pilot, Citadel, Mixer und Galley bereitgestellt.

IstioOperator

Eine benutzerdefinierte Ressource, mit der Sie die Steuerungsebene im Cluster konfigurieren. Weitere Informationen finden Sie unter Optionale Funktionen aktivieren.

$

Verwaltete Instanzgruppe (Managed Instance Group, MIG): Ermöglicht das Ausführen von Anwendungen auf mehreren identischen VMs, wobei mindestens eine MIG-Größe einer VM verwendet wird. Sie können Ihre Arbeitslasten skalierbar und hochverfügbar machen, indem Sie automatisierte MIG-Dienste nutzen, darunter Autoscaling, automatische Reparatur, regionale Bereitstellung (in mehreren Zonen) und automatische Aktualisierung. Weitere Informationen finden Sie unter Verwaltete Instanzgruppen (MIGs).

Manifest

Ein Kubernetes-Konfigurationsobjekt, mit dem Kubernetes-Ressourcen wie Pods, Deployments, Services oder Ingresses erstellt, geändert und gelöscht werden. In der Anthos Service Mesh-Dokumentation wird das Manifest, das Sie zum Konfigurieren der Steuerungsebene verwenden, als Overlay-Datei bezeichnet.

Manifeste haben einen von zwei Status: gerendert (auch als hydriert bezeichnet) oder nicht gerendert. Ein nicht gerendertes Manifest ist nicht für die Bereitstellung in einem Ziel bereit. Der Renderingprozess, der das Einfügen bestimmter Werte in das Manifest umfasst, wird häufig von Tools wie Helm, Kustomize und kpt ausgeführt.

Mesh CA: Der Name der von Google verwalteten Zertifizierungsstelle, die mTLS-Zertifikate verwaltet. Mesh CA ist standardmäßig aktiviert, wenn Sie Anthos Service Mesh in GKE-Clustern in Google Cloud installieren. Sie können Mesh CA optional aktivieren, wenn Sie Anthos Service Mesh 1.10 oder höher in GKE on VMware oder Bare Metal installieren.
Gegenseitiges TLS: Anthos Service Mesh nutzt gegenseitiges TLS (mTLS) für die Authentifizierung und Verschlüsselung zwischen Diensten im Mesh. Mit mTLS können Arbeitslasten die Identitäten untereinander prüfen und sich gegenseitig authentifizieren. Möglicherweise sind Sie mit einfachem TLS vertraut. Dies wird in HTTPS genutzt, um es Browsern zu ermöglichen, Webservern zu vertrauen und die ausgetauschten Daten zu verschlüsseln. Wenn einfaches TLS verwendet wird, stellt der Client fest, dass der Server als vertrauenswürdig eingestuft werden kann, indem er sein Zertifikat validiert. mTLS ist eine Implementierung von TLS, in der sowohl der Client als auch der Server Zertifikate bereitstellen und die Identität des jeweils anderen überprüft wird.

✘

network: Anthos Service Mesh verwendet eine vereinfachte Definition von Netzwerken auf der Grundlage allgemeiner Konnektivität. Arbeitslastinstanzen befinden sich im selben Netzwerk, wenn sie ohne Gateway direkt kommunizieren können.

O

Overlay-Datei: Eine YAML-Datei mit einer benutzerdefinierten Ressource vom Typ IstioOperator. Mit Overlay-Dateien lässt sich die Steuerungsebene konfigurieren. Sie können die Standardkonfiguration der Steuerungsebene überschreiben und die optional unterstützten Features in einer YAML-Datei aktivieren, die Sie an istioctl install oder an das Skript install_asm übergeben. Sie können mehr Overlays übereinander legen. Jede Overlay-Datei überschreibt die Konfiguration auf den vorherigen Ebenen. Unter Optionale Features aktivieren finden Sie Informationen zur YAML-Datei, die Sie für die Aktivierung von Features verwenden können, die nicht standardmäßig aktiviert werden.

P

Primärer Cluster: Ein primärer Cluster ist ein Cluster mit einer Steuerungsebene. Ein einzelnes Mesh-Netzwerk kann für eine hohe Verfügbarkeit und zur Reduzierung der Latenz mehr als einen primären Cluster haben. In der Dokumentation zu Istio 1.7 wird eine mehrfache Bereitstellung als replizierte Steuerungsebene bezeichnet.

R

Remote-Cluster: Ein Remote-Cluster ist ein Cluster, der eine Verbindung zu einer Steuerungsebene herstellt, die sich außerhalb des Clusters befindet. Ein Remote-Cluster kann eine Verbindung zu einer Steuerungsebene herstellen, die in einem primären Cluster oder einer externen Steuerungsebene ausgeführt wird.
Revision: Eine Überarbeitung stellt eine Snapshot-Version der Anwendung sowie einen Snapshot in einer bestimmten Zeit dar. Wenn Sie Anthos Service Mesh installieren oder aktualisieren, wird der Steuerungsebene ein Überarbeitungslabel hinzugefügt. Um die automatische Sidecar-Injektion zu aktivieren, fügen Sie das Überarbeitungslabel zu Ihren Namespaces hinzu und starten Ihre Pods neu. Das Überarbeitungslabel verknüpft die Pods in einem Namespace mit einer bestimmten Überarbeitung der Steuerungsebene.
Überarbeitungsbasiertes Upgrade: Migrationen von OSS Istio sowie Upgrades folgen einem revisionsbasierten Upgradevorgang. Dieser wird in der Istio-Dokumentation als „Canary-Upgrade“ bezeichnet. Bei einem Überarbeitungsupgrade wird die neue Überarbeitung der Steuerungsebene zusammen mit der vorhandenen Steuerungsebene installiert. Anschließend verschieben Sie einige Ihrer Arbeitslasten auf die neue Überarbeitung. Damit können Sie die Auswirkungen des Upgrades mit einem kleinen Prozentsatz der Arbeitslasten prüfen, bevor Sie den gesamten Traffic zur neuen Überarbeitung migrieren.

S

Sichere Benennung: Serveridentitäten werden in Zertifikaten codiert. Dienstnamen werden jedoch über den Discovery-Dienst oder DNS abgerufen. Die sicheren Benennungsinformationen ordnen die Serveridentitäten den Dienstnamen zu. Die Zuordnung von Identität A zu Dienstname B bedeutet „A ist zur Ausführung von Dienst B berechtigt". Die Steuerungsebene beobachtet den apiserver, generiert die sicheren Namenszuordnungen und verteilt sie sicher an die Sidecar-Proxys.
Service Mesh: Ein Service Mesh oder ein einfaches Mesh-Netzwerk ist eine Infrastrukturebene, die eine verwaltete, beobachtbare und sichere Kommunikation zwischen Arbeitslastinstanzen ermöglicht.
Sidecar: Ein Muster zum Ausführen eines Dienstprogramms oder eines Hilfsprogramms mit einer Arbeitslast. Wenn Sie Kubernetes verwenden, werden Sidecars zusammen mit dem Arbeitslastcontainer in einem Pod ausgeführt. Beim Thema „Service Mesh“ wird der Begriff „Sidecar“ häufig verwendet, um auf den Proxy zu verweisen.

T

Trust-Domain

Trust-Domain ist eine vertrauenswürdige Domain und entspricht dem Root of Trust eines Systems. Sie ist Teil einer Workload Identity.

Anthos Service Mesh verwendet eine vertrauenswürdige Domain, um alle Identitäten in einem Mesh-Netzwerk zu erstellen. Beispiel: In der SPIFFE-ID spiffe://mytrustdomain.com/ns/default/sa/myname wird mit dem Teilstring mytrustdomain.com angegeben, dass die Arbeitslast von einer vertrauenswürdigen Domain mit dem Namen mytrustdomain.com stammt.

Bei Verwendung der Mesh-CA wird die vertrauenswürdige Domain automatisch von Anthos Service Mesh generiert. Sie basiert auf dem Arbeitslast-Pool des Clusters.

Sie können eine oder mehrere vertrauenswürdige Domains in einem Multi-Cluster-Mesh haben, sofern die Cluster über denselben Root of Trust verfügen.

W

Arbeitslast: Eine Arbeitslast ist eine containerisierte Anwendung, ein Dienst oder ein anderes Programm, z. B. ein Batchjob oder ein Daemon, der auf einer Plattform ausgeführt wird. Die Plattform kann ein Kubernetes-Cluster, eine virtuelle Maschine oder eine andere Umgebung wie Google Distributed Cloud Virtual for Bare Metal sein. Arbeitslasten haben Namen, Namespaces und eindeutige IDs. In Kubernetes entspricht eine Arbeitslast normalerweise einem Deployment. Es gibt aber auch andere Arten von Arbeitslasten, z. B. ein StatefulSet.
WorkloadEntry: Ermöglicht es Ihnen, Nicht-Kubernetes-Pod-Endpunkten zu beschreiben, die Teil des Mesh-Netzwerks sein sollen, und diese als Kubernetes-Pod zu behandeln. In unserem Fall wird jede VM als WorkloadEntry im Mesh-Netzwerk registriert. Weitere Informationen finden Sie unter https://istio.io/latest/blog/2020/workload-entry/
WorkloadGroup: Beschreibt eine Sammlung von Arbeitslastinstanzen. Siehe WorkloadGroup.
Workload Identity-Pool: Die Vertrauensgrenze, die auch als vertrauenswürdige Domain eines Anthos Service Mesh bezeichnet wird.