Diese Seite wurde von der Cloud Translation API übersetzt.

Projektübergreifende Netzwerkrichtlinien erstellen

Auf dieser Seite finden Sie eine Anleitung zum Konfigurieren von netzwerkübergreifenden Traffic-Netzwerkrichtlinien in Google Distributed Cloud (GDC) mit Air Gap.

Projektübergreifender Traffic bezieht sich auf die Kommunikation zwischen Diensten und Arbeitslasten aus verschiedenen Projektnamespaces, aber innerhalb derselben Organisation.

Dienste und Arbeitslasten in einem Projekt sind standardmäßig von externen Diensten und Arbeitslasten isoliert. Dienste und Arbeitslasten aus verschiedenen Projektnamespaces innerhalb derselben Organisation können jedoch miteinander kommunizieren, indem Sie netzwerkübergreifende Netzwerkrichtlinien anwenden.

Standardmäßig gelten diese Richtlinien weltweit für alle Zonen. Weitere Informationen zu globalen Ressourcen in einem GDC-Universum finden Sie unter Übersicht über mehrere Zonen.

Informationen zum Erzwingen von projektübergreifendem Traffic innerhalb einer einzelnen Zone finden Sie unter Richtlinie für projektübergreifenden Traffic auf Arbeitslastebene für eine einzelne Zone erstellen.

Hinweise

Zum Konfigurieren von netzwerkübergreifenden Traffic-Richtlinien benötigen Sie Folgendes:

Die erforderlichen Identitäts- und Zugriffsrollen. Zum Verwalten von Richtlinien für ein bestimmtes Projekt benötigen Sie die Rolle project-networkpolicy-admin. In Umgebungen mit mehreren Zonen, in denen Sie Richtlinien verwalten müssen, die sich über alle Zonen erstrecken, benötigen Sie die Rolle global-project-networkpolicy-admin. Weitere Informationen finden Sie unter Vordefinierte Rollen und Zugriff vorbereiten.
Ein vorhandenes Projekt. Weitere Informationen finden Sie unter Projekt erstellen.
Bei Richtlinien für ausgehenden Netzwerkverkehr müssen Sie auch den Schutz vor Datenexfiltration für das Projekt deaktivieren.

Projektübergreifende Richtlinie erstellen

Sie können Richtlinien für projektübergreifenden Traffic für eingehenden oder ausgehenden Traffic definieren, um die Kommunikation zwischen Projekten zu verwalten.

Projektübergreifende Richtlinie für eingehenden Traffic erstellen

Wenn Sie Verbindungen zu den Arbeitslasten oder Diensten Ihres Projekts von Arbeitslasten in einem anderen Projekt in Ihrer Organisation zulassen möchten, müssen Sie eine Firewallregel für eingehenden Traffic konfigurieren.

Diese Richtlinie gilt für alle Zonen in Ihrer Organisation.

Führen Sie die folgenden Schritte aus, um eine neue Firewallregel zu erstellen und eingehenden Traffic von Arbeitslasten in einem anderen Projekt zuzulassen:

Console

Rufen Sie in der GDC Console des Projekts, das Sie konfigurieren, im Navigationsmenü Netzwerk > Firewall auf, um die Seite Firewall zu öffnen.
Klicken Sie in der Aktionsleiste auf Erstellen, um eine neue Firewallregel zu erstellen.
Geben Sie auf der Seite Details zur Firewallregel die folgenden Informationen an:
1. Geben Sie im Feld Name einen gültigen Namen für die Firewallregel ein.
2. Wählen Sie im Bereich Trafficrichtung die Option Eingehender Traffic aus, um eingehenden Traffic von Arbeitslasten in anderen Projekten zuzulassen.
3. Wählen Sie im Bereich Ziel eine der folgenden Optionen aus:
  - Alle Nutzerarbeitslasten:Verbindungen zu den Arbeitslasten des Projekts, das Sie konfigurieren, sind zulässig.
  - Dienst:Gibt an, dass diese Firewallregel auf einen bestimmten Dienst in dem Projekt ausgerichtet ist, das Sie konfigurieren.
4. Wenn Ihr Ziel ein Projektdienst ist, wählen Sie den Namen des Dienstes aus der Liste der verfügbaren Dienste im Drop-down-Menü Dienst aus.
5. Wählen Sie im Bereich Von eine der folgenden beiden Optionen aus:
  - Alle Projekte:Verbindungen von Arbeitslasten in allen Projekten derselben Organisation sind zulässig.
  - Anderes Projekt und Alle Nutzerarbeitslasten:Verbindungen von Arbeitslasten in einem anderen Projekt derselben Organisation sind zulässig.
6. Wenn Sie Arbeitslasten nur aus einem anderen Projekt übertragen möchten, wählen Sie in der Drop-down-Liste Projekt-ID ein Projekt aus, auf das Sie zugreifen können.
7. Wenn Ihr Ziel alle Nutzerarbeitslasten sind, wählen Sie im Bereich Protokolle und Ports eine der folgenden Optionen aus:
  - Alle zulassen:Verbindungen über ein beliebiges Protokoll oder einen beliebigen Port zulassen.
  - Angegebene Protokolle und Ports:Verbindungen sind nur über die Protokolle und Ports zulässig, die Sie in den entsprechenden Feldern für die Firewallregel für eingehenden Traffic angeben.
Klicken Sie auf der Seite Details zur Firewallregel auf Erstellen.

Sie haben jetzt Verbindungen von anderen Projektarbeitslasten innerhalb derselben Organisation zugelassen. Nachdem Sie die Firewallregel erstellt haben, wird sie in einer Tabelle auf der Seite Firewall angezeigt.

Wenn Sie eine gegenseitige Ingress-Richtlinie in der anderen Richtung erstellen möchten, rufen Sie die GDC-Konsole des anderen Projekts auf und wiederholen Sie den Vorgang.

API

Die folgende Richtlinie ermöglicht es Arbeitslasten im Projekt PROJECT_1, Verbindungen von Arbeitslasten im Projekt PROJECT_2 sowie den Rückgabe-Traffic für dieselben Flows zuzulassen. Wenden Sie die Richtlinie an:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-inbound-traffic-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
EOF

Ersetzen Sie GLOBAL_API_SERVER durch den kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.

Der vorherige Befehl erlaubt, dass PROJECT_2 zu PROJECT_1 wechselt, aber nicht, dass Verbindungen von PROJECT_1 zu PROJECT_2 initiiert werden. Für Letzteres benötigen Sie eine entsprechende Richtlinie im PROJECT_2-Projekt. Wenden Sie die Richtlinie für Gegenseitigkeit an:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-inbound-traffic-from-PROJECT_1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
EOF

Verbindungen zu und von PROJECT_1 und PROJECT_2 sind jetzt zulässig.

Projektübergreifende Richtlinie für ausgehenden Traffic erstellen

Wenn Sie eine projektübergreifende Ingress-Traffic-Richtlinie gewähren, damit Arbeitslasten in einem Projekt Verbindungen von Arbeitslasten in einem anderen Projekt zulassen, wird durch diese Aktion auch der Rückgabe-Traffic für dieselben Flows gewährt. Daher benötigen Sie im ursprünglichen Projekt keine Netzwerkrichtlinie für projektübergreifenden ausgehenden Traffic.

Führen Sie die folgenden Schritte aus, um eine neue Firewallregel zu erstellen und ausgehenden Traffic von Arbeitslasten in einem Projekt zuzulassen:

Console

Rufen Sie in der GDC Console des Projekts, das Sie konfigurieren, im Navigationsmenü Netzwerk > Firewall auf, um die Seite Firewall zu öffnen.
Klicken Sie in der Aktionsleiste auf Erstellen, um eine neue Firewallregel zu erstellen.
Geben Sie auf der Seite Details zur Firewallregel die folgenden Informationen an:
1. Geben Sie im Feld Name einen gültigen Namen für die Firewallregel ein.
2. Wählen Sie im Bereich Trafficrichtung die Option Ausgehender Traffic aus, um anzugeben, dass diese Firewallregel ausgehenden Traffic steuert.
3. Wählen Sie im Bereich Ziel eine der folgenden Optionen aus:
  - Alle Nutzerarbeitslasten:Verbindungen von den Arbeitslasten des Projekts, das Sie konfigurieren, zulassen.
  - Dienst:Gibt an, dass diese Firewallregel auf einen bestimmten Dienst in dem Projekt ausgerichtet ist, das Sie konfigurieren.
4. Wenn Ihr Ziel ein Projektdienst ist, wählen Sie den Namen des Dienstes aus der Liste der verfügbaren Dienste im Drop-down-Menü Dienst aus.
5. Wählen Sie im Bereich An eine der folgenden Optionen aus:
  - Alle Projekte:Verbindungen zu Arbeitslasten in allen Projekten derselben Organisation zulassen.
  - Anderes Projekt und Alle Nutzerarbeitslasten:Ermöglichen Verbindungen zu Arbeitslasten in einem anderen Projekt derselben Organisation.
6. Wenn Sie Arbeitslasten nur in ein anderes Projekt übertragen möchten, wählen Sie in der Drop-down-Liste Projekt-ID ein Projekt aus, auf das Sie zugreifen können.
7. Wenn Ihr Ziel alle Nutzerarbeitslasten sind, wählen Sie im Bereich Protokolle und Ports eine der folgenden Optionen aus:
  - Alle zulassen:Verbindungen über ein beliebiges Protokoll oder einen beliebigen Port zulassen.
  - Angegebene Protokolle und Ports:Verbindungen sind nur über die Protokolle und Ports zulässig, die Sie in den entsprechenden Feldern für die Firewallregel für ausgehenden Traffic angeben.
Klicken Sie auf der Seite Details zur Firewallregel auf Erstellen.

Sie haben jetzt Verbindungen zu anderen Projektarbeitslasten innerhalb derselben Organisation zugelassen. Nachdem Sie die Firewallregel erstellt haben, wird sie in einer Tabelle auf der Seite Firewall angezeigt.

Wenn Sie eine entsprechende Egress-Richtlinie in der anderen Richtung erstellen möchten, rufen Sie die GDC-Konsole des anderen Projekts auf und wiederholen Sie den Vorgang.

API

Mit der folgenden Richtlinie können Arbeitslasten im Projekt PROJECT_1 Verbindungen zu Arbeitslasten im Projekt PROJECT_2 zulassen. Wenden Sie die Richtlinie an:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-outbound-traffic-to-PROJECT_2
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
EOF

Ersetzen Sie Folgendes:

GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, lesen Sie die Informationen unter Anmelden.
PROJECT_1: Der Name des Projekts, das den Traffic empfängt.
PROJECT_2: Der Name des Projekts, aus dem der Traffic stammt.
SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die betreffenden Arbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, wird der Traffic an Arbeitslasten mit dem Label app: backend weitergeleitet.
PEER_LABEL_KEY: Der Schlüssel des Labels, mit dem die Peer-Arbeitslasten ausgewählt werden.
PEER_LABEL_VALUE: Der Wert, der mit dem PEER_LABEL_KEY verknüpft ist.

Der vorherige Befehl erlaubt ausgehende Verbindungen von PROJECT_1 zu PROJECT_2, aber keine Verbindungen von PROJECT_2 zu PROJECT_1. Für Letzteres benötigen Sie eine entsprechende Richtlinie im Projekt PROJECT_2. Wenden Sie die Richtlinie für Gegenseitigkeit an:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-outbound-traffic-to-PROJECT_1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
EOF

Projektübergreifende Richtlinie für ausgehenden Traffic auf Arbeitslast-Ebene erstellen

Wenn Sie eine richtlinienübergreifende Richtlinie für ausgehenden Traffic auf Arbeitslastebene erstellen möchten, erstellen Sie die folgende benutzerdefinierte Ressource und wenden Sie sie an:
```
kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-cross-project-outbound-traffic-from-project-2-to-project-1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
EOF
```
Ersetzen Sie Folgendes:
- GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.
- PROJECT_1: Der Name des Projekts, das den Traffic empfängt.
- PROJECT_2: Der Name des Projekts, aus dem der Traffic stammt.
- SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die betreffenden Arbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
- SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, wird der Traffic von Arbeitslasten mit dem Label app: backend gesendet.
- PEER_LABEL_KEY: Der Schlüssel des Labels, mit dem die Peer-Arbeitslasten ausgewählt werden.
- PEER_LABEL_VALUE: Der Wert, der mit dem PEER_LABEL_KEY verknüpft ist.

Projektübergreifende Richtlinie auf Arbeitslast- und Zonenebene erstellen

Netzwerkrichtlinien auf Arbeitslastebene können PNP in einer einzelnen Zone erzwingen. Arbeitslasten in einer einzelnen Zone können bestimmte Labels hinzugefügt werden. So können Sie die Kommunikation zwischen einzelnen Arbeitslasten innerhalb eines Projekts oder in verschiedenen Projekten für diese Zone steuern.

Projektübergreifende Richtlinie auf Arbeitslastebene für eingehenden Traffic für eine einzelne Zone erstellen

Wenn Sie eine richtlinienübergreifende Richtlinie auf Arbeitslast- und Projektebene für den Ingress in einer einzelnen Zone erstellen möchten, erstellen und wenden Sie die folgende benutzerdefinierte Ressource an:
```
kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-single-zone-cross-project-inbound-traffic-from-project-2-to-project-1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
            ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
                ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
EOF
```
Hinweis :Ressourcen müssen genau übereinstimmende Labels haben. Damit diese Richtlinie in einer einzelnen Zone durchgesetzt wird, müssen die Arbeitslasten des Subjekts und des Peers dasselbe Zonenlabel haben.

Ersetzen Sie Folgendes:
- GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.
- PROJECT_1: Der Name des Projekts, das den Traffic empfängt.
- PROJECT_2: Der Name des Projekts, aus dem der Traffic stammt.
- SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die betreffenden Arbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
- SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, wird der Traffic an Arbeitslasten mit dem Label app: backend weitergeleitet.
- PEER_LABEL_KEY: Der Schlüssel des Labels, mit dem die Peer-Arbeitslasten ausgewählt werden.
- PEER_LABEL_VALUE: Der Wert, der mit dem PEER_LABEL_KEY verknüpft ist.
- ZONE_SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die Subjektzone ausgewählt wird. Beispiel: zone oder region.
- ZONE_SUBJECT_LABEL_VALUE: Der Wert, der mit dem ZONE_SUBJECT_LABEL_KEY verknüpft ist. Gibt an, welche Zone den Traffic empfängt. Wenn ZONE_SUBJECT_LABEL_KEY beispielsweise zone und ZONE_SUBJECT_LABEL_VALUE us-central1-a ist, erhalten Arbeitslasten mit dem Label zone: us-central1-a den Traffic.
- ZONE_PEER_LABEL_KEY: Der Schlüssel des Labels, mit dem die dem Peer zugeordnete Zone ausgewählt wird.
- ZONE_PEER_LABEL_VALUE: Der Wert, der mit dem ZONE_PEER_LABEL_KEY verknüpft ist.

Projektübergreifende Richtlinie auf Arbeitslastebene für ausgehenden Traffic für eine einzelne Zone erstellen

Wenn Sie eine richtlinienübergreifende Richtlinie auf Arbeitslast- und Projektebene für ausgehenden Traffic für eine einzelne Zone erstellen möchten, erstellen Sie die folgende benutzerdefinierte Ressource und wenden Sie sie an:
```
kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-single-zone-cross-project-outbound-traffic-from-project-2-to-project-1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
            ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
                ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
EOF
```
Hinweis :Ressourcen müssen genau übereinstimmende Labels haben. Damit diese Richtlinie in einer einzelnen Zone durchgesetzt wird, müssen die Arbeitslasten des Subjekts und des Peers dasselbe Zonenlabel haben.

Ersetzen Sie Folgendes:
- GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.
- PROJECT_1: Der Name des Projekts, das den Traffic empfängt.
- PROJECT_2: Der Name des Projekts, aus dem der Traffic stammt.
- SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die betreffenden Arbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
- SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, wird der Traffic von Arbeitslasten mit dem Label app: backend gesendet.
- PEER_LABEL_KEY: Der Schlüssel des Labels, mit dem die Peer-Arbeitslasten ausgewählt werden.
- PEER_LABEL_VALUE: Der Wert, der mit dem PEER_LABEL_KEY verknüpft ist.
- ZONE_SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die Subjektzone ausgewählt wird. Beispiel: zone oder region.
- ZONE_SUBJECT_LABEL_VALUE: Der Wert, der mit dem ZONE_SUBJECT_LABEL_KEY verknüpft ist. Wenn ZONE_SUBJECT_LABEL_KEY beispielsweise zone und ZONE_SUBJECT_LABEL_VALUE us-central1-a ist, wird der Traffic von Arbeitslasten mit dem Label zone: us-central1-a gesendet.
- ZONE_PEER_LABEL_KEY: Der Schlüssel des Labels, mit dem die dem Peer zugeordnete Zone ausgewählt wird.
- ZONE_PEER_LABEL_VALUE: Der Wert, der mit dem ZONE_PEER_LABEL_KEY verknüpft ist.

Projektübergreifende Richtlinie für Standardcluster erstellen

Standardcluster sind Kubernetes-Cluster auf Projektebene, die mehr Kontrolle, Flexibilität und Clusteradministratorberechtigungen bieten.

Projektübergreifende Richtlinie für eingehenden Traffic für Standardcluster erstellen

Wenn Sie eine Ingress-Richtlinie für Cluster zwischen Standardclustern erstellen möchten, erstellen und wenden Sie die folgende benutzerdefinierte Ressource an:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: STANDARD_CLUSTER_1_PROJECT
  name: allow-ingress-from-standard-cluster-2-to-standard-cluster-1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: STANDARD_CLUSTER_1_NAME
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: SUBJECT_NAMESPACE
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - STANDARD_CLUSTER_2_PROJECT
        workloadSelector:
          labelSelector:
            clusters:
              matchLabels:
                kubernetes.io/metadata.name: STANDARD_CLUSTER_2_NAME
            namespaces:
              matchLabels:
                kubernetes.io/metadata.name: PEER_NAMESPACE
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
EOF

Ersetzen Sie Folgendes:

GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, lesen Sie die Informationen unter Anmelden.
STANDARD_CLUSTER_1_PROJECT: der Name des Standardclusterprojekts, das den Traffic empfängt.
STANDARD_CLUSTER_2_PROJECT: Der Name des Standardclusterprojekts, aus dem der Traffic stammt.
STANDARD_CLUSTER_1_NAME: Der Name des Standardclusters, der den Traffic empfängt.
STANDARD_CLUSTER_2_NAME: Der Name des Standardclusters, aus dem der Traffic stammt.
SUBJECT_NAMESPACE: Der Betreff-Namespace im Standardcluster.
PEER_NAMESPACE: Der Peer-Namespace im Standardcluster.
SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die betreffenden Arbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, wird der Traffic an Arbeitslasten mit dem Label app: backend weitergeleitet.
PEER_LABEL_KEY: Der Schlüssel des Labels, mit dem die Peer-Arbeitslasten ausgewählt werden.
PEER_LABEL_VALUE: Der Wert, der mit dem PEER_LABEL_KEY verknüpft ist.

Wenn Sie eine Ingress-Richtlinie zwischen Standard- und freigegebenen Clustern erstellen möchten, erstellen und wenden Sie die folgende benutzerdefinierte Ressource an:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: SHARED_CLUSTER_PROJECT
  name: allow-ingress-from-standard-cluster-to-shared-cluster
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - STANDARD_CLUSTER_PROJECT
        workloadSelector:
          labelSelector:
            clusters:
              matchLabels:
                kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
            namespaces:
              matchLabels:
                kubernetes.io/metadata.name: PEER_NAMESPACE
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
EOF

Ersetzen Sie Folgendes:

GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, lesen Sie die Informationen unter Anmelden.
STANDARD_CLUSTER_PROJECT: Der Name des Standardclusterprojekts.
SHARED_CLUSTER_PROJECT: der Name des freigegebenen Clusterprojekts.
STANDARD_CLUSTER_NAME: Der Name des Standardclusters.
PEER_NAMESPACE: Der Peer-Namespace im Standardcluster.
SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die betreffenden Arbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, wird der Traffic an Arbeitslasten mit dem Label app: backend weitergeleitet.
PEER_LABEL_KEY: Der Schlüssel des Labels, mit dem die Peer-Arbeitslasten ausgewählt werden.
PEER_LABEL_VALUE: Der Wert, der mit dem PEER_LABEL_KEY verknüpft ist.

Projektübergreifende Richtlinie für ausgehenden Traffic für Standardcluster erstellen

Wenn Sie eine Richtlinie für ausgehenden Traffic zwischen Standardclustern erstellen möchten, erstellen Sie die folgende benutzerdefinierte Ressource und wenden Sie sie an:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: STANDARD_CLUSTER_2_PROJECT
  name: allow-egress-from-standard-cluster-2-to-standard-cluster-1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: STANDARD_CLUSTER_2_NAME
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: SUBJECT_NAMESPACE
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - STANDARD_CLUSTER_1_PROJECT
        workloadSelector:
          labelSelector:
            clusters:
              matchLabels:
                kubernetes.io/metadata.name: STANDARD_CLUSTER_1_NAME
            namespaces:
              matchLabels:
                kubernetes.io/metadata.name: PEER_NAMESPACE
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
EOF

Ersetzen Sie Folgendes:

GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.
STANDARD_CLUSTER_1_PROJECT: der Name des Standardclusterprojekts, das den Traffic empfängt.
STANDARD_CLUSTER_2_PROJECT: Der Name des Standardclusterprojekts, aus dem der Traffic stammt.
STANDARD_CLUSTER_1_NAME: Der Name des Standardclusters, der den Traffic empfängt.
STANDARD_CLUSTER_2_NAME: Der Name des Standardclusters, aus dem der Traffic stammt.
SUBJECT_NAMESPACE: Der Betreff-Namespace im Standardcluster.
PEER_NAMESPACE: Der Peer-Namespace im Standardcluster.
SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die betreffenden Arbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, wird der Traffic von Arbeitslasten mit dem Label app: backend gesendet.
PEER_LABEL_KEY: Der Schlüssel des Labels, mit dem die Peer-Arbeitslasten ausgewählt werden.
PEER_LABEL_VALUE: Der Wert, der mit dem PEER_LABEL_KEY verknüpft ist.

Wenn Sie eine Intercluster-Richtlinie für ausgehenden Traffic zwischen Standard- und freigegebenen Clustern erstellen möchten, erstellen und wenden Sie die folgende benutzerdefinierte Ressource an:
```
kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: STANDARD_CLUSTER_PROJECT
  name: allow-egress-from-standard-cluster-to-shared-cluster
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: SUBJECT_NAMESPACE
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - SHARED_CLUSTER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
EOF
```
Ersetzen Sie Folgendes:
- GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.
- STANDARD_CLUSTER_PROJECT: Der Name des Standardclusterprojekts.
- SHARED_CLUSTER_PROJECT: der Name des freigegebenen Clusterprojekts.
- STANDARD_CLUSTER_NAME: Der Name des Standardclusters.
- SUBJECT_NAMESPACE: Der Betreff-Namespace im Standardcluster.
- SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die betreffenden Arbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
- SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, wird der Traffic von Arbeitslasten mit dem Label app: backend gesendet.
- PEER_LABEL_KEY: Der Schlüssel des Labels, mit dem die Peer-Arbeitslasten ausgewählt werden.
- PEER_LABEL_VALUE: Der Wert, der mit dem PEER_LABEL_KEY verknüpft ist.

Projektübergreifende Netzwerkrichtlinien erstellen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweise

Projektübergreifende Richtlinie erstellen

Projektübergreifende Richtlinie für eingehenden Traffic erstellen

Console

API

Projektübergreifende Richtlinie für ausgehenden Traffic erstellen

Console

API

Projektübergreifende Richtlinie für ausgehenden Traffic auf Arbeitslast-Ebene erstellen

Projektübergreifende Richtlinie auf Arbeitslast- und Zonenebene erstellen

Projektübergreifende Richtlinie auf Arbeitslastebene für eingehenden Traffic für eine einzelne Zone erstellen

Projektübergreifende Richtlinie auf Arbeitslastebene für ausgehenden Traffic für eine einzelne Zone erstellen

Projektübergreifende Richtlinie für Standardcluster erstellen

Projektübergreifende Richtlinie für eingehenden Traffic für Standardcluster erstellen

Projektübergreifende Richtlinie für ausgehenden Traffic für Standardcluster erstellen

Projektübergreifende Netzwerkrichtlinien erstellen