Intra-Projekt-Netzwerkrichtlinien erstellen

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

In Projektnetzwerkrichtlinien werden Regeln für eingehenden oder ausgehenden Traffic definiert. Sie können Richtlinien definieren, die die Kommunikation innerhalb von Projekten, zwischen Projekten und mit externen IP-Adressen zulassen.

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.

Wenn die Durchsetzung des Intra-Project-Traffics in einer einzelnen Zone erforderlich ist, lesen Sie den Abschnitt Richtlinie auf Arbeitslast-Ebene für Intra-Project-Traffic in einer einzelnen Zone erstellen.

Hinweise

Zum Konfigurieren von Netzwerkrichtlinien für Intra-Projekt-Traffic 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.

Projektinterne Richtlinie erstellen

Für Traffic innerhalb eines Projekts wendet GDC standardmäßig eine vordefinierte Projektnetzwerkrichtlinie, die Intra-Project-Richtlinie, auf jedes Projekt an. Standardmäßig können Arbeitslasten in einem Projekt-Namespace miteinander kommunizieren, ohne etwas für externe Ressourcen freizugeben.

Standardmäßig gibt es keine Richtlinie für ausgehenden Traffic, sodass ausgehender Traffic für den gesamten Intra-Projekt-Traffic zulässig ist. Wenn Sie jedoch eine einzelne Richtlinie für ausgehenden Traffic festlegen, ist nur der Traffic zulässig, der in der Richtlinie angegeben ist.

Richtlinie für eingehenden Traffic innerhalb des Projekts erstellen

Wenn Sie ein Projekt erstellen, erstellen Sie implizit eine Standard-ProjectNetworkPolicy-Basisressource, die die Kommunikation innerhalb des Projekts ermöglicht. Diese Richtlinie lässt eingehenden Traffic von anderen Arbeitslasten im selben Projekt zu.

Sie können die Standardrichtlinie entfernen. Dadurch wird jedoch die projektinterne Kommunikation für alle Dienste und Arbeitslasten im Projekt verweigert. Verwenden Sie den Befehl kubectl delete, um die Richtlinie zu entfernen:

kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT

Sie können die Standardrichtlinie wieder hinzufügen, indem Sie das folgende Manifest anwenden:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: base-policy-allow-intra-project-traffic
spec:
  policyType: Ingress
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
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: Name Ihres Projekts

Richtlinie für ausgehenden Traffic innerhalb eines Projekts erstellen

Wenn Sie die Verhinderung von Datenexfiltration deaktivieren und eine ProjectNetworkPolicy-Richtlinie für das Projekt anwenden, z. B. um den Zugriff auf eine externe Ressource zu verhindern, verwenden Sie die folgende erforderliche Richtlinie, um ausgehenden Traffic innerhalb des Projekts zuzulassen:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-intra-project-outbound-traffic
spec:
  policyType: Egress
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
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: Name Ihres Projekts

Intra-Projekt-Richtlinie auf Arbeitslast-Ebene erstellen

Netzwerkrichtlinien auf Arbeitslastebene bieten eine detaillierte Steuerung der Kommunikation zwischen einzelnen Arbeitslasten innerhalb eines Projekts. Diese Granularität ermöglicht eine strengere Kontrolle des Netzwerkzugriffs und verbessert so die Sicherheit und Ressourcennutzung.

Richtlinie für eingehenden Traffic auf Arbeitslast- und Projektebene erstellen

Wenn Sie ein Projekt erstellen, erstellen Sie implizit eine standardmäßige ProjectNetworkPolicy-Basisressource, die die Kommunikation zwischen allen Arbeitslasten innerhalb des Projekts ermöglicht. Diese Richtlinie lässt eingehenden Traffic von anderen Arbeitslasten im selben Projekt zu.

Wenn Sie eine Intra-Projekt-Richtlinie auf Arbeitslastebene für eingehenden Traffic erstellen möchten, muss zuerst die Standardbasisrichtlinie gelöscht werden. Andernfalls kann es zu unerwartetem Verhalten kommen.

  1. Führen Sie den folgenden Befehl aus, um die Standardbasisrichtlinie zu löschen:

    kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT

  2. Wenn Sie eine Intra-Projekt-Richtlinie auf Arbeitslastebene für eingehenden Traffic 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
  name: allow-workload-level-intra-project-inbound-traffic
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - 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.
    • PROJECT: Name Ihres Projekts
    • 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.

Richtlinie für ausgehenden Traffic auf Arbeitslast- und Projektebene erstellen

  • Wenn Sie eine Richtlinie für ausgehenden Traffic auf Arbeitslastebene für ein Projekt 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
  name: allow-workload-level-intra-project-outbound-traffic
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - 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.
    • PROJECT: Name Ihres Projekts
    • 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.

Richtlinie auf Arbeitslast- und Projektebene für eine einzelne Zone 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.

Richtlinie auf Arbeitslastebene für eingehenden Traffic für ein einzelnes Projekt in einer einzelnen Zone erstellen

Wenn Sie ein Projekt erstellen, erstellen Sie implizit eine standardmäßige ProjectNetworkPolicy-Basisressource, die die Kommunikation zwischen allen Arbeitslasten innerhalb des Projekts ermöglicht. Diese Richtlinie lässt eingehenden Traffic von anderen Arbeitslasten im selben Projekt zu.

Wenn Sie eine Intra-Project-Richtlinie auf Arbeitslastebene für eingehenden Traffic für eine einzelne Zone erstellen möchten, muss zuerst die Standardbasisrichtlinie gelöscht werden. Andernfalls kann es zu unerwartetem Verhalten kommen.

  1. Führen Sie den folgenden Befehl aus, um die Standardbasisrichtlinie zu löschen:

    kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT

  2. Wenn Sie eine Intra-Projekt-Traffic-Netzwerkrichtlinie auf Arbeitslastebene für Ingress mit 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
  name: allow-single-zone-intra-project-inbound-traffic
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
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
                ZONE_PEER_LABEL_KEY: ZONE_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: Name Ihres Projekts
    • 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. Wenn ZONE_SUBJECT_LABEL_KEY beispielsweise zone und ZONE_SUBJECT_LABEL_VALUE us-central1-a ist, wird der Traffic an Arbeitslasten mit dem Label zone: us-central1-a weitergeleitet.
    • 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.

Richtlinie auf Arbeitslastebene für ausgehenden Traffic für ein einzelnes Projekt erstellen

  • Wenn Sie eine Intra-Project-Richtlinie auf Arbeitslast- und Einzelzonenebene für den ausgehenden Traffic 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
  name: allow-single-zone-intra-project-outbound-traffic
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
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
                ZONE_PEER_LABEL_KEY: ZONE_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: Name Ihres Projekts
    • 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. Wenn ZONE_SUBJECT_LABEL_KEY beispielsweise zone und ZONE_SUBJECT_LABEL_VALUE us-central1-a ist, wird der Traffic an Arbeitslasten mit dem Label zone: us-central1-a weitergeleitet.
    • 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.

Projektinterne Richtlinie für Standardcluster erstellen

Standardcluster sind Kubernetes-Cluster auf Projektebene, die mehr Kontrolle, Flexibilität und Clusteradministratorberechtigungen bieten. Wenn Sie eine richtlinieninterne Richtlinie erstellen, wird sie standardmäßig von Standardclustern übernommen. Diese Richtlinie erlaubt die gesamte Kommunikation innerhalb der Standardcluster, die sich im selben Projekt befinden.

Richtlinie für eingehenden Intra-Projekt-Traffic für Standardcluster erstellen

Wenn Sie ein Projekt erstellen, erstellen Sie implizit eine standardmäßige ProjectNetworkPolicy-Basisressource, die die Kommunikation zwischen allen Arbeitslasten innerhalb des Projekts ermöglicht. Diese Richtlinie lässt eingehenden Traffic von anderen Arbeitslasten im selben Projekt sowie die Intra-Cluster-Kommunikation zwischen allen Arbeitslasten in den Standardclustern innerhalb des Projekts zu.

Wenn Sie eine Ingress-Richtlinie für das Projekt für Standardcluster erstellen möchten, muss zuerst die Standardbasisrichtlinie gelöscht werden. Andernfalls kann es zu unerwartetem Verhalten kommen.

  1. Führen Sie den folgenden Befehl aus, um die Standardbasisrichtlinie zu löschen:

    kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT

    Sie können die Standardrichtlinie wieder hinzufügen, indem Sie das folgende Manifest anwenden:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: base-policy-allow-intra-project-traffic
spec:
  policyType: Ingress
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
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: Name Ihres Projekts

  2. Wenn Sie eine Ingress-Richtlinie für die Kommunikation zwischen Pods innerhalb eines Clusters in 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_PROJECT
  name: allow-ingress-from-intra-cluster-traffic
spec:
  policyType: Ingress
  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
  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, finden Sie weitere Informationen unter Anmelden.
    • STANDARD_CLUSTER_PROJECT: der Name des Standardclusterprojekts.
    • STANDARD_CLUSTER_NAME: Der Name des Standardclusters.
    • 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.

  3. Wenn Sie eine Ingress-Richtlinie für die Kommunikation zwischen Knoten und Pods innerhalb des Clusters in 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_PROJECT
  name: allow-ingress-from-node-to-pod-traffic
spec:
  policyType: Ingress
  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
  ingress:
  - from:
    - ipBlocks:
      - cidr: NODE_IP
    ports:
    - protocol: TCP
      port: PORT
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.
    • STANDARD_CLUSTER_NAME: Der Name des Standardclusters.
    • 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.
    • NODE_IP: die IP-Adresse des Knotens.
    • PORT: Der Port der betreffenden Arbeitslast, auf dem Traffic zulässig ist.

Richtlinie für ausgehenden Intra-Projekt-Traffic für Standardcluster erstellen

  1. Wenn Sie eine Richtlinie für den Intra-Cluster-Pod-zu-Pod-Ausgang in 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_PROJECT
  name: allow-egress-to-intra-cluster-traffic
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:
          - 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, finden Sie weitere Informationen unter Anmelden.
    • STANDARD_CLUSTER_PROJECT: der Name des Standardclusterprojekts.
    • STANDARD_CLUSTER_NAME: Der Name des Standardclusters.
    • 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.
    1. Wenn Sie eine Richtlinie für den Intra-Cluster-Pod-zu-Knoten-Ausgang in 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_PROJECT
  name: allow-egress-from-pod-to-node-traffic
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:
    - ipBlocks:
      - cidr: NODE_IP
    ports:
    - protocol: TCP
      port: PORT
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.
    • STANDARD_CLUSTER_NAME: Der Name des Standardclusters.
    • 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.
    • NODE_IP: die IP-Adresse des Knotens.
    • PORT: Der Port auf der Knoten-IP, für den Traffic zulässig ist.