Questa pagina è stata tradotta dall'API Cloud Translation.

Crea criteri di rete tra progetti

Questa pagina fornisce istruzioni per configurare i criteri di rete per il traffico tra progetti in Google Distributed Cloud (GDC) air-gapped.

Il traffico tra progetti si riferisce alla comunicazione tra servizi e carichi di lavoro di spazi dei nomi di progetti diversi, ma all'interno della stessa organizzazione.

Per impostazione predefinita, i servizi e i workload di un progetto sono isolati da servizi e workload esterni. Tuttavia, i servizi e i carichi di lavoro di spazi dei nomi di progetti diversi e all'interno della stessa organizzazione possono comunicare tra loro applicando criteri di rete per il traffico tra progetti.

Per impostazione predefinita, questi criteri si applicano a livello globale in tutte le zone. Per saperne di più sulle risorse globali in un universo GDC, consulta Panoramica multizona.

Per applicare il traffico tra progetti all'interno di una singola zona, consulta Creare una policy tra progetti a livello di workload per una singola zona.

Prima di iniziare

Per configurare le policy di rete per il traffico tra progetti, 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 policy che si estendono a tutte le zone, devi disporre del ruolo global-project-networkpolicy-admin. Per saperne di più, consulta Prepara ruoli e accesso predefiniti.
Un progetto esistente. Per saperne di più, consulta Creare un progetto.
Per i criteri di rete in uscita, devi anche disattivare la protezione dall'esfiltrazione di dati per il progetto.

Crea una policy tra progetti

Puoi definire policy di traffico in entrata o in uscita tra progetti per gestire la comunicazione tra i progetti.

Crea una policy in entrata tra progetti

Per consentire le connessioni ai servizi o ai carichi di lavoro del tuo progetto da carichi di lavoro in un altro progetto all'interno della tua organizzazione, devi configurare una regola firewall in entrata.

Questo criterio si applica a tutte le zone della tua organizzazione.

Segui questi passaggi per creare una nuova regola firewall e consentire il traffico in entrata dai carichi di lavoro in un altro progetto:

Console

Nella console GDC del progetto che stai configurando, vai a Networking > Firewall nel menu di navigazione per aprire la pagina Firewall.
Fai clic su Crea nella barra delle azioni per iniziare a creare una nuova regola firewall.
Nella pagina Dettagli regola firewall, compila le seguenti informazioni:
1. Nel campo Nome, inserisci un nome valido per la regola firewall.
2. Nella sezione Direzione del traffico, seleziona In entrata per consentire il traffico in entrata dai carichi di lavoro in altri progetti.
3. Nella sezione Target, seleziona una delle seguenti opzioni:
  - Tutti i workload utente: consentono le connessioni ai workload del progetto che stai configurando.
  - Servizio:indica che questa regola firewall ha come target un servizio specifico all'interno del progetto che stai configurando.
4. Se la destinazione è un servizio di progetto, seleziona il nome del servizio dall'elenco dei servizi disponibili nel menu a discesa Servizio.
5. Nella sezione Da, seleziona una delle seguenti due opzioni:
  - Tutti i progetti:consente le connessioni dai carichi di lavoro in tutti i progetti della stessa organizzazione.
  - Un altro progetto e Tutti i workload utente:consentono le connessioni dai workload in un altro progetto della stessa organizzazione.
6. Se vuoi trasferire i carichi di lavoro solo da un altro progetto, seleziona un progetto a cui puoi accedere dall'elenco dei progetti nel menu a discesa ID progetto.
7. Se la destinazione sono tutti i carichi di lavoro utente, seleziona una delle seguenti opzioni nella sezione Protocolli e porte:
  - Consenti tutto:consente le connessioni utilizzando qualsiasi protocollo o porta.
  - Protocolli e porte specificati:consentono le connessioni utilizzando solo i protocolli e le porte specificati nei campi corrispondenti per la regola firewall in entrata.
Nella pagina Dettagli regola firewall, fai clic su Crea.

Ora hai consentito le connessioni da altri workload del progetto all'interno della stessa organizzazione. Dopo aver creato la regola firewall, questa è visibile in una tabella nella pagina Firewall.

Per creare un criterio di ingresso reciproco nell'altra direzione, visita la console GDC dell'altro progetto e ripeti la procedura.

API

La seguente policy consente ai carichi di lavoro nel progetto PROJECT_1 di consentire le connessioni dai carichi di lavoro nel progetto PROJECT_2, nonché il traffico di ritorno per gli stessi flussi. Applica la policy:

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

Sostituisci GLOBAL_API_SERVER con 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 i dettagli.

Il comando precedente consente a PROJECT_2 di andare a PROJECT_1, ma non consente le connessioni avviate da PROJECT_1 a PROJECT_2. Per quest'ultimo, è necessaria una policy reciproca nel progetto PROJECT_2. Applica la norma di reciprocità:

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

Ora le connessioni sono consentite da e verso PROJECT_1 e PROJECT_2.

Crea un criterio in uscita tra progetti

Quando concedi una policy di traffico in entrata tra progetti per consentire ai carichi di lavoro in un progetto di accettare connessioni da carichi di lavoro in un altro progetto, questa azione concede anche il traffico di ritorno per gli stessi flussi. Pertanto, non hai bisogno di una policy di rete per il traffico in uscita tra progetti nel progetto originale.

Segui questi passaggi per creare una nuova regola firewall e consentire il traffico in uscita dai carichi di lavoro in un progetto:

Console

Nella console GDC del progetto che stai configurando, vai a Networking > Firewall nel menu di navigazione per aprire la pagina Firewall.
Nella barra delle azioni, fai clic su Crea per creare una nuova regola firewall.
Nella pagina Dettagli regola firewall, compila le seguenti informazioni:
1. Nel campo Nome, inserisci un nome valido per la regola firewall.
2. Nella sezione Direzione del traffico, seleziona In uscita per indicare che questa regola del firewall controlla il traffico in uscita.
3. Nella sezione Target, seleziona una delle seguenti opzioni:
  - Tutti i carichi di lavoro utente: consente le connessioni dai carichi di lavoro del progetto che stai configurando.
  - Servizio:indica che questa regola firewall ha come target un servizio specifico all'interno del progetto che stai configurando.
4. Se la destinazione è un servizio di progetto, seleziona il nome del servizio dall'elenco dei servizi disponibili nel menu a discesa Servizio.
5. Nella sezione A, seleziona una delle seguenti due opzioni:
  - Tutti i progetti:consente le connessioni ai carichi di lavoro in tutti i progetti della stessa organizzazione.
  - Un altro progetto e Tutti i workload utente:consentono le connessioni ai workload in un altro progetto della stessa organizzazione.
6. Se vuoi trasferire i carichi di lavoro solo a un altro progetto, seleziona un progetto a cui puoi accedere dall'elenco dei progetti nel menu a discesa ID progetto.
7. Se la destinazione sono tutti i carichi di lavoro utente, seleziona una delle seguenti opzioni nella sezione Protocolli e porte:
  - Consenti tutto:consente le connessioni utilizzando qualsiasi protocollo o porta.
  - Protocolli e porte specificati:consentono le connessioni utilizzando solo i protocolli e le porte specificati nei campi corrispondenti per la regola firewall in uscita.
Nella pagina Dettagli regola firewall, fai clic su Crea.

Ora hai consentito le connessioni ad altri workload del progetto all'interno della stessa organizzazione. Dopo aver creato la regola firewall, questa è visibile in una tabella nella pagina Firewall.

Per creare una policy di uscita reciproca nell'altra direzione, visita la console GDC dell'altro progetto e ripeti la procedura.

API

La seguente policy consente ai workload nel progetto PROJECT_1 di consentire le connessioni ai workload nel progetto PROJECT_2. Applica la policy:

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

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_1: il nome del progetto che riceve il traffico.
PROJECT_2: il nome del progetto da cui proviene il traffico.
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.

Il comando precedente consente le connessioni in uscita da PROJECT_1 a PROJECT_2, ma non consente le connessioni da PROJECT_2 a PROJECT_1. Per quest'ultimo, è necessaria una norma reciproca nel progetto PROJECT_2. Applica la norma di reciprocità:

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

Crea un criterio tra progetti a livello di carico di lavoro in uscita

Per creare una policy interprogetto 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_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
```
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_1: il nome del progetto che riceve il traffico.
- PROJECT_2: il nome del progetto da cui proviene il traffico.
- 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 tra progetti 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 workload all'interno di una singola zona, consentendoti di controllare la comunicazione tra singoli workload all'interno di un progetto o in progetti diversi per quella zona.

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

Per creare una policy cross-project a livello di workload Ingress 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_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
```
Nota :le risorse devono avere etichette di corrispondenza esatta. Per garantire l'applicazione di questo criterio all'interno di una singola zona, i carichi di lavoro soggetto e peer devono avere la stessa etichetta di zona.

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_1: il nome del progetto che riceve il traffico.
- PROJECT_2: il nome del progetto da cui proviene il traffico.
- 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. Specifica quale zona riceve il traffico. 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 tra progetti a livello di workload in uscita per una singola zona

Per creare una policy cross-project 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_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
```
Nota :le risorse devono avere etichette di corrispondenza esatta. Per garantire l'applicazione di questo criterio all'interno di una singola zona, i carichi di lavoro soggetto e peer devono avere la stessa etichetta di zona.

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_1: il nome del progetto che riceve il traffico.
- PROJECT_2: il nome del progetto da cui proviene il traffico.
- 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.
- 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 inviano 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 tra progetti 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.

Crea un criterio in entrata tra progetti per i cluster standard

Per creare una policy intercluster in entrata tra 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_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

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_1_PROJECT: il nome del progetto del cluster standard che riceve il traffico.
STANDARD_CLUSTER_2_PROJECT: il nome del progetto del cluster standard da cui proviene il traffico.
STANDARD_CLUSTER_1_NAME: il nome del cluster standard che riceve il traffico.
STANDARD_CLUSTER_2_NAME: il nome del cluster standard da cui proviene il traffico.
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.

Per creare una policy intercluster Ingress tra cluster standard e condivisi, 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: 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

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.
SHARED_CLUSTER_PROJECT: il nome del progetto del cluster condiviso.
STANDARD_CLUSTER_NAME: il nome del 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.

Crea un criterio in uscita tra progetti per i cluster standard

Per creare una policy intercluster in uscita tra 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_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

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_1_PROJECT: il nome del progetto del cluster standard che riceve il traffico.
STANDARD_CLUSTER_2_PROJECT: il nome del progetto del cluster standard da cui proviene il traffico.
STANDARD_CLUSTER_1_NAME: il nome del cluster standard che riceve il traffico.
STANDARD_CLUSTER_2_NAME: il nome del cluster standard da cui proviene il traffico.
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.

Per creare una policy intercluster in uscita tra cluster standard e condivisi, 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-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

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.
SHARED_CLUSTER_PROJECT: il nome del progetto del cluster condiviso.
STANDARD_CLUSTER_NAME: il nome del cluster standard.
SUBJECT_NAMESPACE: lo spazio dei nomi del soggetto 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.

Crea criteri di rete tra progetti Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Prima di iniziare

Crea una policy tra progetti

Crea una policy in entrata tra progetti

Console

API

Crea un criterio in uscita tra progetti

Console

API

Crea un criterio tra progetti a livello di carico di lavoro in uscita

Crea un criterio tra progetti a livello di workload per una singola zona

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

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

Crea un criterio tra progetti per i cluster standard

Crea un criterio in entrata tra progetti per i cluster standard

Crea un criterio in uscita tra progetti per i cluster standard

Crea criteri di rete tra progetti