Crea criteri di rete intraprogetto

Questa pagina fornisce istruzioni per configurare i criteri di rete per il traffico intraprogetto in Google Distributed Cloud (GDC) con air gap.

I criteri di rete del progetto definiscono regole in entrata o in uscita. Puoi definire criteri che consentono la comunicazione all'interno dei progetti, tra progetti e con indirizzi IP esterni.

Per impostazione predefinita, queste norme si applicano a livello globale in tutte le zone. Per saperne di più sulle risorse globali in un universo GDC, consulta la panoramica multizona.

Se è necessaria l'applicazione del traffico intra-progetto all'interno di una singola zona, consulta Creare una policy intra-progetto a livello di workload per una singola zona.

Prima di iniziare

Per configurare i criteri di rete per il traffico intra-progetto, devi disporre di quanto segue:

  • I ruoli di identità e accesso necessari. Per gestire le policy per un progetto specifico, devi disporre del ruolo project-networkpolicy-admin. Per gli ambienti multizona in cui devi gestire criteri che si estendono a tutte le zone, devi disporre del ruolo global-project-networkpolicy-admin. Per saperne di più, consulta Preparare ruoli e accesso predefiniti.
  • Un progetto esistente. Per saperne di più, consulta Creare un progetto.

Crea una policy intraprogetto

Per il traffico all'interno di un progetto, GDC applica una policy di rete del progetto predefinita, la policy intra-progetto, a ogni progetto per impostazione predefinita. Per impostazione predefinita, i workload in uno spazio dei nomi del progetto possono comunicare tra loro senza esporre nulla a risorse esterne.

Per impostazione predefinita, non esiste alcun criterio di uscita, pertanto il traffico in uscita è consentito per tutto il traffico all'interno del progetto. Tuttavia, quando imposti un'unica policy di uscita, viene consentito solo il traffico specificato dalla policy.

Crea una policy in entrata intraprogetto

Quando crei un progetto, crei implicitamente una risorsa di base ProjectNetworkPolicy predefinita che consente la comunicazione all'interno del progetto. Questa policy consente il traffico in entrata da altri workload nello stesso progetto.

Puoi rimuovere il criterio predefinito, ma tieni presente che questa rimozione comporta il rifiuto della comunicazione intraprogetto per tutti i servizi e i workload all'interno del progetto. Per rimuovere la policy, utilizza il comando kubectl delete:

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

Puoi aggiungere nuovamente le norme predefinite applicando il seguente manifest:

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

Sostituisci quanto segue:

  • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
  • PROJECT: il nome del progetto.

Crea una policy in uscita intraprogetto

Quando disattivi la prevenzione esfiltrazione di dati e applichi al progetto una policy di uscita ProjectNetworkPolicy, ad esempio impedendo l'accesso a una risorsa esterna, utilizza la seguente policy obbligatoria per consentire il traffico in uscita intraprogetto:

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

Sostituisci quanto segue:

  • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
  • PROJECT: il nome del progetto.

Crea un criterio intraprogetto a livello di workload

I criteri di rete a livello di workload offrono un controllo granulare sulla comunicazione tra i singoli workload all'interno di un progetto. Questa granularità consente un controllo più rigoroso dell'accesso alla rete, migliorando la sicurezza e l'utilizzo delle risorse.

Crea un criterio intraprogetto a livello di workload in entrata

Quando crei un progetto, crei implicitamente una risorsa di base ProjectNetworkPolicy predefinita che consente la comunicazione intra-progetto tra tutti i carichi di lavoro. Questa policy consente il traffico in entrata da altri workload nello stesso progetto.

Per creare una policy intra-progetto a livello di workload in entrata, devi prima eliminare la policy di base predefinita. In caso contrario, potrebbero verificarsi comportamenti imprevisti.

  1. Per eliminare la policy di base predefinita, esegui questo comando:

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

  2. Per creare una policy intra-progetto a livello di workload in entrata, crea e applica la seguente risorsa personalizzata:

    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • PROJECT: il nome del progetto.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro del soggetto. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend ricevono il traffico.
    • PEER_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro peer.
    • PEER_LABEL_VALUE: il valore associato a PEER_LABEL_KEY.

Crea una policy intraprogetto a livello di carico di lavoro in uscita

  • Per creare una policy intra-progetto a livello di workload in uscita, crea e applica la seguente risorsa personalizzata:

    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • PROJECT: il nome del progetto.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro del soggetto. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend inviano il traffico.
    • PEER_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro peer.
    • PEER_LABEL_VALUE: il valore associato a PEER_LABEL_KEY.

Crea un criterio intraprogetto a livello di workload per una singola zona

I criteri di rete a livello di workload possono applicare PNP lungo una singola zona. È possibile aggiungere etichette specifiche ai carichi di lavoro all'interno di una singola zona, consentendoti di controllare la comunicazione tra singoli carichi di lavoro all'interno di un progetto o in progetti diversi per quella zona.

Crea un criterio intraprogetto a livello di workload in entrata per una singola zona

Quando crei un progetto, crei implicitamente una risorsa di base ProjectNetworkPolicy predefinita che consente la comunicazione intra-progetto tra tutti i carichi di lavoro. Questa policy consente il traffico in entrata da altri workload nello stesso progetto.

Per creare una policy intra-progetto a livello di workload in entrata a zona singola, devi prima eliminare la policy di base predefinita. In caso contrario, potrebbero verificarsi comportamenti imprevisti.

  1. Per eliminare la policy di base predefinita, esegui questo comando:

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

  2. Per creare un criterio di rete per il traffico intraprogetto a livello di workload Ingress a zona singola, crea e applica la seguente risorsa personalizzata:

    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • PROJECT: il nome del progetto.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro del soggetto. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend ricevono il traffico.
    • PEER_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro peer.
    • PEER_LABEL_VALUE: il valore associato a PEER_LABEL_KEY.
    • ZONE_SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare la zona soggetta. Ad esempio, zone o region.
    • ZONE_SUBJECT_LABEL_VALUE: il valore associato a ZONE_SUBJECT_LABEL_KEY. Ad esempio, se ZONE_SUBJECT_LABEL_KEY è zone e ZONE_SUBJECT_LABEL_VALUE è us-central1-a, i carichi di lavoro con l'etichetta zone: us-central1-a ricevono il traffico.
    • ZONE_PEER_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare la zona associata al peer.
    • ZONE_PEER_LABEL_VALUE: il valore associato a ZONE_PEER_LABEL_KEY.

Crea un criterio intraprogetto a livello di workload in uscita per una singola zona

  • Per creare una policy intraprogetto a livello di workload in uscita per una singola zona, crea e applica la seguente risorsa personalizzata:

    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • PROJECT: il nome del progetto.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro del soggetto. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend ricevono il traffico.
    • PEER_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro peer.
    • PEER_LABEL_VALUE: il valore associato a PEER_LABEL_KEY.
    • ZONE_SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare la zona soggetta. Ad esempio, zone o region.
    • ZONE_SUBJECT_LABEL_VALUE: il valore associato a ZONE_SUBJECT_LABEL_KEY. Ad esempio, se ZONE_SUBJECT_LABEL_KEY è zone e ZONE_SUBJECT_LABEL_VALUE è us-central1-a, i carichi di lavoro con l'etichetta zone: us-central1-a ricevono il traffico.
    • ZONE_PEER_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare la zona associata al peer.
    • ZONE_PEER_LABEL_VALUE: il valore associato a ZONE_PEER_LABEL_KEY.

Crea un criterio intraprogetto per i cluster standard

I cluster standard sono cluster Kubernetes con ambito di progetto che offrono maggiore controllo, flessibilità e autorizzazioni di amministratore del cluster. Quando crei una policy intraprogetto, questa viene ereditata dai cluster standard per impostazione predefinita. Questo criterio consente tutte le comunicazioni all'interno dei cluster standard che si trovano nello stesso progetto.

Crea un criterio in entrata intraprogetto per i cluster standard

Quando crei un progetto, crei implicitamente una risorsa di base ProjectNetworkPolicy predefinita che consente la comunicazione intra-progetto tra tutti i carichi di lavoro. Questa policy consente il traffico in entrata da altri workload nello stesso progetto e anche la comunicazione intracluster tra tutti i workload nei cluster standard all'interno del progetto.

Per creare un criterio di ingresso intra-progetto per i cluster standard, è necessario eliminare prima il criterio di base predefinito. In caso contrario, potrebbero verificarsi comportamenti imprevisti.

  1. Per eliminare la policy di base predefinita, esegui questo comando:

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

    Puoi aggiungere nuovamente le norme predefinite applicando il seguente manifest:

    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • PROJECT: il nome del progetto.

  2. Per creare un criterio di ingresso da pod a pod intra-cluster nei cluster standard, crea e applica la seguente risorsa personalizzata

    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • STANDARD_CLUSTER_PROJECT: il nome del progetto del cluster standard.
    • STANDARD_CLUSTER_NAME: il nome del cluster standard.
    • SUBJECT_NAMESPACE: lo spazio dei nomi del soggetto nel cluster standard.
    • PEER_NAMESPACE: lo spazio dei nomi peer nel cluster standard.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro del soggetto. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend ricevono il traffico.
    • PEER_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro peer.
    • PEER_LABEL_VALUE: il valore associato a PEER_LABEL_KEY.

  3. Per creare una policy di Ingress da nodo a pod intra-cluster nei cluster standard, crea e applica la seguente risorsa personalizzata:

    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • STANDARD_CLUSTER_PROJECT: il nome del progetto del cluster standard.
    • STANDARD_CLUSTER_NAME: il nome del cluster standard.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro del soggetto. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend ricevono il traffico.
    • NODE_IP: l'indirizzo IP del nodo.
    • PORT: la porta sul workload soggetto in cui è consentito il traffico.

Crea un criterio in uscita intraprogetto per i cluster standard

  1. Per creare una policy di uscita da pod a pod intra-cluster nei cluster standard, crea e applica la seguente risorsa personalizzata

    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • STANDARD_CLUSTER_PROJECT: il nome del progetto del cluster standard.
    • STANDARD_CLUSTER_NAME: il nome del cluster standard.
    • SUBJECT_NAMESPACE: lo spazio dei nomi del soggetto nel cluster standard.
    • PEER_NAMESPACE: lo spazio dei nomi peer nel cluster standard.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro del soggetto. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend inviano il traffico.
    • PEER_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro peer.
    • PEER_LABEL_VALUE: il valore associato a PEER_LABEL_KEY.
    1. Per creare una policy di uscita da pod a nodo intra-cluster nei cluster standard, crea e applica la seguente risorsa personalizzata:
    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

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • STANDARD_CLUSTER_PROJECT: il nome del progetto del cluster standard.
    • STANDARD_CLUSTER_NAME: il nome del cluster standard.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro del soggetto. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend inviano il traffico.
    • NODE_IP: l'indirizzo IP del nodo.
    • PORT: la porta sull'IP del nodo a cui è consentito il traffico.