Firewallrichtlinien in GKE selektiv erzwingen

Auf dieser Seite wird gezeigt, wie Sie mithilfe von Tags Netzwerkfirewall-Richtlinien für Cloud Firewall Next Generation in Google Kubernetes Engine (GKE) selektiv erzwingen. Informationen zur Verwendung von Tags in GKE für andere Zwecke wie die Abrechnungsverwaltung oder bedingte IAM-Richtlinien finden Sie unter GKE-Ressourcen mit Tags verwalten.

Tags

Tags sind Schlüssel/Wert-Paare, mit denen Sie Google Cloud-Ressourcen auf Organisations- oder Projektebene annotieren und verwalten können. Mit Tags können Sie Ihre Ressourcen organisieren und Richtlinien wie Firewalls oder IAM-Richtlinien bedingt anwenden. Mit der IAM-Zugriffssteuerung können Sie festlegen, wer Tags anhängen, erstellen, aktualisieren oder löschen kann.

Weitere Informationen zu Tags finden Sie in der Resource Manager-Dokumentation unter Tags – Übersicht.

Tags verwenden, um Richtlinien für Netzwerkfirewalls zu erzwingen

Mit Tags können Sie globale oder regionale Netzwerk-Firewallrichtlinien bedingt auf Ihre GKE-Knoten anwenden. Sie müssen den Zweck GCE_FIREWALL für Tags festlegen, die Sie mit Netzwerk-Firewallrichtlinien verwenden möchten. Wenn Sie Tags für Firewallzwecke auf GKE-Cluster oder -Knotenpools anwenden, hängt GKE diese Tags automatisch an die entsprechenden virtuellen Compute Engine-Maschinen (VMs) an.

Durch Tags für Netzwerk-Firewallrichtlinien muss Netzwerk-Tag nicht mehr verwendet werden. Dies sind Metadaten, die jeder an die zugrunde liegenden Compute Engine-VMs für Durchsetzung von Virtual Private Cloud-Firewall-Regeln anhängen kann und die keine IAM-Zugriffssteuerung unterstützen. Wenn Sie derzeit Netzwerk-Tags mit VPC-Firewallregeln verwenden, empfehlen wir, zu Netzwerk-Firewallrichtlinien zu migrieren und sichere Firewall-Tags zu verwenden. Einen detaillierten Vergleich finden Sie in diesem Dokument unter Netzwerk-Tags mit Tags vergleichen.

Tags für Netzwerk-Firewallrichtlinien-Workflow

So verwenden Sie Tags mit Netzwerk-Firewallrichtlinien in GKE:

  1. Tag erstellen:

    1. Definieren Sie einen Tag-Schlüssel auf Organisations- oder Projektebene, z. B. env.
    2. Definieren Sie die möglichen Tag-Werte für den Schlüssel, z. B. dev, staging und prod.

    3. Legen Sie das Tag für die Verwendung von Netzwerk-Firewallrichtlinien fest.

  2. Gewähren Sie Nutzern Zugriff zur Interaktion mit dem Firewall-Tag.

  3. Tag-Schlüssel/Wert-Paare auf bestimmte GKE-Cluster oder Knotenpools anwenden. GKE hängt die Tags automatisch zur Durchsetzung der Firewallrichtlinien an die Compute Engine-VMs an.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Anforderungen und Einschränkungen

  • Tags für Netzwerk-Firewallrichtlinien werden in GKE-Version 1.28 und höher unterstützt. Wenn Sie eine GKE-Version vor 1.28 verwenden, verwenden Sie stattdessen Netzwerk-Tags mit VPC-Firewallregeln.
  • Der GKE-Cluster sollte ursprünglich mit der GKE-Version 1.28 oder höher erstellt worden sein. Durch das Upgrade eines Clusters von einer Version vor 1.28 auf Version 1.28 oder höher werden keine Tags aktiviert.
  • Der GKE-Cluster und das Tag müssen mit demselben VPC-Netzwerk verknüpft sein.
  • In Standardclustern unterstützt jeder Knotenpool bis zu fünf angehängte Firewall-Tags.
  • Autopilot-Cluster unterstützen bis zu fünf Firewall-Tags.
  • GKE lehnt Tag-Schlüssel ab, die das Präfix gke-managed verwenden.
  • Sie müssen die Tag-Schlüssel/Wert-Paare erstellen, bevor Sie sie an Cluster oder Knotenpools anhängen können.

IAM-Rollen und -Berechtigungen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zu gewähren, um die Berechtigungen zu erhalten, die Sie zum Verwenden von Tags für Firewallrichtlinien in GKE benötigen:

  • So erteilen Sie Nutzern und GKE-Dienst-Agents die erforderlichen Berechtigungen für Tags:
  • Zum Erstellen und Verwalten von Tags: Tag-Administrator (roles/resourcemanager.tagAdmin) für die Organisation oder das Projekt
  • Zum Anhängen von Tags an Ressourcen: Tag-Nutzer (roles/resourcemanager.tagUser) für das Projekt

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Tags erstellen

Tags müssen vorhanden sein, damit Sie sie an Cluster oder Knoten anhängen können. Informationen zum Erstellen eines Tags finden Sie in der Dokumentation zu Cloud NGFW unter Tags für Firewalls verwenden.

Führen Sie beispielsweise die folgenden Befehle aus, um ein projektbezogenes Firewall-Tag zu erstellen:

  1. Erstellen Sie den Tag-Schlüssel:

    gcloud resource-manager tags keys create TAG_KEY \
    --parent=projects/PROJECT_ID \
    --purpose=GCE_FIREWALL \
    --purpose-data=network=PROJECT_ID/NETWORK_NAME

    Ersetzen Sie Folgendes:

    • TAG_KEY: der Name des Tag-Schlüssels, z. B. env
    • PROJECT_ID: Ihre Google Cloud-Projekt-ID
    • NETWORK_NAME: der Name des VPC-Netzwerks, das Sie mit dem Tag verwenden möchten

  2. Rufen Sie die ID des Tag-Schlüssels ab:

    gcloud resource-manager tags keys describe PROJECT_ID/TAG_KEY \
    --format="value(name)"

    Die Ausgabe ist tagKeys/KEY_ID, wobei KEY_ID eine numerische ID für den Schlüssel ist. Notieren Sie sich diese ID für später.

  3. Fügen Sie dem Tag-Schlüssel einen Tag-Wert hinzu:

    gcloud resource-manager tags values create TAG_VALUE \
    --parent=tagKeys/KEY_ID

    Ersetzen Sie TAG_VALUE durch den Namen eines zulässigen Werts für diesen Tag-Schlüssel, z. B. dev.

Tag-Syntax in gcloud-Befehlen

Wenn Sie mit der gcloud CLI auf Tags verweisen, müssen Sie die Schlüssel/Wert-Paare mit einer der folgenden Syntaxen formatieren:

Tag-Syntax 

tagKeys/KEY_ID=tagValues/VALUE_ID

Ersetzen Sie Folgendes:

  • KEY_ID: die numerische Schlüssel-ID
  • VALUE_ID: die numerische Wert-ID

Beispiel: tagKeys/123456789=tagValues/987654321.

 

ORGANIZATION_ID/TAG_KEY=TAG_VALUE

Ersetzen Sie Folgendes:

  • ORGANIZATION_ID: Ihre numerische Google Cloud-Organisations-ID
  • TAG_KEY: der Name des Tag-Schlüssels, den Sie erstellt haben
  • TAG_VALUE: der Name des Tag-Werts, den Sie erstellt haben

Beispiel: 12345678901/env=dev.

 

PROJECT_ID/TAG_KEY=TAG_VALUE

Ersetzen Sie Folgendes:

  • PROJECT_ID: Ihre Google Cloud-Projekt-ID
  • TAG_KEY: der Name des Tag-Schlüssels, den Sie erstellt haben
  • TAG_VALUE: der Name des Tag-Werts, den Sie erstellt haben

Beispiel: example-project/env=dev.

 

PROJECT_NUMBER/TAG_KEY=TAG_VALUE

Ersetzen Sie Folgendes:

  • PROJECT_ID: die numerische Kennung für Ihr Google Cloud-Projekt
  • TAG_KEY: der Name des Tag-Schlüssels, den Sie erstellt haben
  • TAG_VALUE: der Name des Tag-Werts, den Sie erstellt haben

Beispiel: 11223344556/env=dev.

Zieltags mit Firewallrichtlinien

Nachdem Sie Tags erstellt haben, können Sie in den Richtlinien der Firewall auf bestimmte Schlüssel/Wert-Paare verweisen. Eine Anleitung finden Sie unter Tags für Firewalls verwenden.

Dienst-Agents IAM-Berechtigungen erteilen

Damit GKE bei neuen Hochskalierungs-Tags automatisch neuen Knoten hinzufügt, müssen Sie den von Google verwalteten Dienstkonten, die auch als Dienst-Agents bezeichnet werden, die entsprechenden IAM-Rollen zuweisen.

  1. Weisen Sie dem Kubernetes Engine-Dienst-Agent die Rolle „Tag-Nutzer“ (roles/resourcemanager.tagUser) zu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

    Ersetzen Sie PROJECT_NUMBER durch die Google Cloud-Projektnummer des Clusters. Führen Sie den folgenden Befehl aus, um die Projektnummer zu ermitteln:

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

  2. Weisen Sie dem Kubernetes Engine Service Agent die Rolle „Tag-Hold-Administrator“ (roles/resourcemanager.tagHoldAdmin) für das Tag-Schlüssel/Wert-Paar zu:

    gcloud resource-manager tags values add-iam-policy-binding PROJECT_ID/TAG_KEY/TAG_VALUE \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagHoldAdmin

    Mit dieser Rolle kann der Dienst-Agent das Löschen von Tags verhindern, wenn das Schlüssel/Wert-Paar noch in GKE verwendet wird.

  3. Weisen Sie dem Google APIs-Dienst-Agent die Rolle „Tag-Nutzer“ (roles/resourcemanager.tagUser) zu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER@cloudservices.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

Zusätzliche IAM-Rollen für Tags außerhalb des Projekts zuweisen

Führen Sie folgende Schritte aus, um Tags zu verwenden, die einer Organisation oder einem anderen Projekt als dem Clusterprojekt gehören:

  1. Weisen Sie dem Kubernetes Engine Service Agent-Zugriff für die Tags in der übergeordneten Ressource die Rolle „Tag-Nutzer“ (roles/resourcemanager.tagUser) zu:

    gcloud resource-manager tags keys add-iam-policy-binding PARENT_RESOURCE/TAG_KEY \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

    Ersetzen Sie Folgendes:

    • PARENT_RESOURCE: die Projekt-ID oder die Organisations-ID der Ressource, zu der dieses Tag gehört
    • PROJECT_NUMBER: ist die Projektnummer des Cluster-Projekts.

  2. Weisen Sie dem Google APIs-Dienst-Agent für die Tags in der übergeordneten Ressource die Rolle „Tag-Nutzer“ (roles/resourcemanager.tagUser) zu:

    gcloud resource-manager tags keys add-iam-policy-binding PARENT_RESOURCE/TAG_KEY \
    --member=serviceAccount:PROJECT_NUMBER@cloudservices.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

  3. Weisen Sie dem Kubernetes Engine-Dienst-Agent für das Tag-Schlüssel/Wert-Paar die Rolle „Administrator für Tag-Holds“ (roles/resourcemanager.tagHoldAdmin) zu:

    gcloud resource-manager tags values add-iam-policy-binding PARENT_RESOURCE/TAG_KEY/TAG_VALUE \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagHoldAdmin

Firewalltags an Autopilot-Cluster anhängen

Sie hängen Firewall-Tags an Autopilot-Cluster auf Clusterebene an. GKE wendet diese Tags auf Clusterebene automatisch auf jeden Knoten an.

Tags beim Erstellen eines neuen Autopilot-Clusters anhängen

Führen Sie dazu diesen Befehl aus:

gcloud beta container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des neuen Clusters.
  • LOCATION: die Compute Engine-Region des Clusters.
  • TAG1,TAG2,...: ein durch Kommas getrennter Satz von Schlüssel/Wert-Paaren, die angehängt werden sollen. Für jedes Schlüssel/Wert-Paar muss eine unterstützte Syntax verwendet werden, wie im Abschnitt Tag-Syntax in Befehlen beschrieben. Beispiel: example-project/env=dev,1234567901/team=sre.

Tags an vorhandene Autopilot-Cluster anhängen

Führen Sie dazu diesen Befehl aus:

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

Wenn Sie die Tags in einem Cluster aktualisieren, überschreibt GKE alle vorhandenen Tags auf allen Knoten.

Firewall-Tags an Standardcluster und Knotenpools anhängen

Welche Methode Sie zum Anhängen von Tags verwenden, hängt davon ab, ob andere Knotenpools im Cluster die Tags übernehmen sollen:

Firewall-Tags für Standardcluster
--autoprovisioning-resource-manager-tags

Einstellung auf Clusterebene

GKE wendet die Tags auf alle neuen, automatisch bereitgestellten Knotenpools im Cluster an. Wenn Sie dieses Flag auf einem vorhandenen Cluster verwenden, behalten vorhandene Knotenpools alle Tags bei, die vor der Aktualisierung angewendet wurden.
--resource-manager-tags

Einstellung auf Knotenpoolebene

GKE wendet die Tags auf den angegebenen Knotenpool an. Wenn Sie dieses Flag während der Clustererstellung verwenden, wendet GKE die Tags auf den von GKE erstellten Standardknotenpool an. Wenn Sie dieses Flag für einen automatisch bereitgestellten Knotenpool verwenden, überschreibt GKE alle vorhandenen Tags im Knotenpool.

Firewall-Tags an Standardcluster anhängen

Sie können Tags an neue oder vorhandene Standardcluster anhängen. Wenn Sie Tags an einen gesamten Cluster anhängen, betrachtet GKE diese Tags als auf Clusterebene festgelegt.

Tags an einen neuen Standardcluster mit automatischer Knotenbereitstellung anhängen

GKE verwendet standardmäßig Tags auf Clusterebene für neue, automatisch bereitgestellte Knoten. Der Standard-Knotenpool, den GKE im Cluster erstellt, wird nicht automatisch bereitgestellt und erhält diese Tags nicht.

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,... \
    --enable-autoprovisioning \
    --max-cpu=MAX_CPU \
    --max-memory=MAX_MEMORY

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des neuen Clusters.
  • LOCATION ist die Compute Engine-Region oder -Zone für den neuen Cluster.
  • TAG1,TAG2,...: ein durch Kommas getrennter Satz von Schlüssel/Wert-Paaren, die angehängt werden sollen. Für jedes Schlüssel/Wert-Paar muss eine unterstützte Syntax verwendet werden, wie im Abschnitt Tag-Syntax in Befehlen beschrieben. Beispiel: example-project/env=dev,1234567901/team=sre.
  • MAX_CPU: die maximale Anzahl der Kerne für den Cluster
  • MAX_MEMORY: die maximale Speicherkapazität für den Cluster in Gigabyte

Tags anhängen, wenn Sie die automatische Knotenbereitstellung für einen vorhandenen Cluster aktivieren

GKE wendet diese Tags nur auf neue automatisch bereitgestellte Knotenpools an. Vorhandene Knotenpools behalten alle Tags bei, die sie vor der Aktualisierung hatten.

  1. Hängen Sie Tags an den Cluster an:

    gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

  2. Aktivieren Sie die automatische Knotenbereitstellung auf dem Cluster:

    gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-autoprovisioning \
    --max-cpu=MAX_CPU \
    --max-memory=MAX_MEMORY

Firewall-Tags an Knotenpools anhängen

Sie können Tags an neue oder vorhandene Knotenpools anhängen, unabhängig davon, ob sie die automatische Knotenbereitstellung verwenden. GKE betrachtet diese Tags als Einstellung auf Knotenpoolebene.

Tags an den Standardknotenpool anhängen

GKE hängt die Tags an, die Sie mit dem Flag --resource-manager-tags angeben, wenn Sie einen Cluster beim Standardknotenpool erstellen, den GKE im Cluster erstellt.

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des neuen Clusters.
  • LOCATION ist die Compute Engine-Region oder -Zone für den neuen Cluster.
  • TAG1,TAG2,...: ein durch Kommas getrennter Satz von Schlüssel/Wert-Paaren, die angehängt werden sollen. Für jedes Schlüssel/Wert-Paar muss eine unterstützte Syntax verwendet werden, wie im Abschnitt Tag-Syntax in Befehlen beschrieben. Beispiel: example-project/env=dev,1234567901/team=sre.

Tags an einen neuen Knotenpool anhängen

Wenn Sie beim Erstellen des Knotenpools das Flag --resource-manager-tags verwenden, hängt GKE die von Ihnen angegebenen Tags an diesen Knotenpool an.

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME: Der Name des neuen Knotenpools.
  • CLUSTER_NAME ist der Name des Clusters.
  • LOCATION ist die Compute Engine-Region oder -Zone des Clusters.
  • TAG1,TAG2,...: ein durch Kommas getrennter Satz von Schlüssel/Wert-Paaren, die angehängt werden sollen. Für jedes Schlüssel/Wert-Paar muss eine unterstützte Syntax verwendet werden, wie im Abschnitt Tag-Syntax in Befehlen beschrieben. Beispiel: example-project/env=dev,1234567901/team=sre.

Tags an einen vorhandenen Knotenpool anhängen

Wenn Sie die Tags in einem vorhandenen Knotenpool mit dem Flag --resource-manager-tags aktualisieren, überschreibt GKE alle vorhandenen Tags in diesem Knotenpool. Mit diesem Befehl können Sie die Tags in automatisch bereitgestellten Knotenpools aktualisieren.

gcloud beta container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

Ersetzen Sie NODE_POOL_NAME durch den Namen des zu aktualisierenden Knotenpools.

Einstellungen für die automatische Bereitstellung in vorhandenen Clustern und Knotenpools umschalten

Wenn Sie Tags auf Clusterebene aktualisieren, wendet GKE diese neuen Tags auf alle neuen Knotenpools im Cluster an und behält die Tags bei, die an vorhandene Knotenpools angehängt wurden.

Wenn Sie vorhandene Knotenpools aktualisieren, um die automatische Knotenbereitstellung zu aktivieren oder zu deaktivieren, beachten Sie die folgenden Auswirkungen auf Tags:

  • Wenn Sie die automatische Knotenbereitstellung aktivieren oder deaktivieren, behält der Knotenpool alle vorhandenen Tags bei. GKE überschreibt diese Tags nicht mit Tags auf Clusterebene, auch nicht während der Neuerstellung des Knotens.
  • Wenn Sie die Tags für bestimmte Knotenpools manuell aktualisieren, überschreibt GKE die vorhandenen Tags mit den angegebenen Tags für diesen Knotenpool.

Firewall-Tags im Cluster prüfen

  • Listen Sie die Tags in Autopilot-Clustern auf:

    gcloud beta container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(nodePoolAutoConfig.resourceManagerTags)"

  • Listen Sie die Tags in bestimmten Knotenpools auf:

    gcloud beta container node-pools describe NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --location=LOCATION \
  --format="value(config.resourceManagerTags)"

Firewall-Tags von Clustern und Knotenpools trennen

Wenn Sie Firewall-Tags aus Clustern und Knotenpools entfernen möchten, aktualisieren Sie die Ressource mit einem leeren Wert für die Tags.

Tags von Autopilot-Clustern trennen

Führen Sie dazu diesen Befehl aus:

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=

Tags von Knotenpools trennen

  1. Trennen Sie die Tags für die automatische Knotenbereitstellung auf Clusterebene:

    gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=

    GKE hängt keine Tags an neue automatisch bereitgestellte Knotenpools an.

  2. Trennen Sie Knotenpool-Tags:

    gcloud beta container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=

    GKE entfernt vorhandene Tags aus diesem Knotenpool.

Tag-Schlüssel und -Werte löschen

Achten Sie beim Löschen eines Tag-Schlüssels oder -Werts darauf, dass das Tag von allen Ressourcen getrennt ist. Anschließend finden Sie in der Resource Manager-Dokumentation unter Tags löschen weitere Informationen.

Netzwerktags mit Tags vergleichen

Die Verwendung von Tags für die Erzwingung von Firewallrichtlinien bietet im Vergleich zu Netzwerktags erhebliche Vorteile in Bezug auf Sicherheit und Nutzerfreundlichkeit. Ebenso verbessern Netzwerk-Firewall-Richtlinien die Funktionen von VPC-Firewallregeln, indem die Durchsetzung von Firewallregeln für ganze Organisationen, Ordner, Projekte oder Netzwerke erleichtert wird.

Die Verwendung von Tags mit Netzwerk-Firewallrichtlinien ist eine sicherere und skalierbare Möglichkeit, den Zugriff auf Ihre GKE-Umgebungen in Ihrer Organisation zu verwalten. Sie können Netzwerktags im selben Cluster wie Tags verwenden. Sie können jedoch keine Netzwerktags verwenden, um Netzwerkfirewallrichtlinien zu erzwingen.

Einen detaillierten Vergleich zwischen Tags und Netzwerktags finden Sie in der Dokumentation zu Cloud NGFW unter Vergleich von Tags und Netzwerktags.

Funktionale Unterschiede bei automatisch bereitgestellten Knotenpools

In Autopilot-Clustern und Standardknotenpools, die keine automatische Knotenbereitstellung verwenden, verhalten sich Netzwerktags und Tags ähnlich. Die folgende Tabelle zeigt die funktionalen Unterschiede zwischen Netzwerktags und Tags in automatisch bereitgestellten Knotenpools in Standardclustern:

Aktion Verhalten von Netzwerktags Tag-Verhalten
GKE stellt automatisch einen Knotenpool bereit GKE wendet die Netzwerk-Tags auf Clusterebene an GKE wendet die Tags auf Clusterebene an
Sie aktualisieren Tags oder Netzwerk-Tags in einem automatisch bereitgestellten Knotenpool.
  • Wenn Netzwerk-Tags auf Clusterebene vorhanden sind, schlägt der Aktualisierungsvorgang fehl.
  • Wenn keine Netzwerk-Tags auf Clusterebene vorhanden sind, überschreibt GKE die vorhandenen Netzwerk-Tags für den Knotenpool
 GKE überschreibt vorhandene Tags für den Knotenpool, unabhängig davon, ob Tags auf Clusterebene vorhanden sind
Sie aktualisieren Tags oder Netzwerk-Tags für den gesamten Cluster. GKE überschreibt die Netzwerktags für neue und vorhandene automatisch bereitgestellte Knotenpools im Cluster. GKE wendet die neuen Tags auf Clusterebene auf neue automatisch bereitgestellte Knotenpools an. Vorhandene automatisch bereitgestellte Knotenpools behalten die Tags bei, die sie vor der Aktualisierung hatten.

Nächste Schritte