Esta página se ha traducido con Cloud Translation API.

Crear políticas de red entre proyectos

En esta página se proporcionan instrucciones para configurar políticas de red de tráfico entre proyectos en Google Distributed Cloud (GDC) con air gap.

El tráfico entre proyectos hace referencia a la comunicación entre servicios y cargas de trabajo de diferentes espacios de nombres de proyectos, pero dentro de la misma organización.

Los servicios y las cargas de trabajo de un proyecto están aislados de los servicios y las cargas de trabajo externos de forma predeterminada. Sin embargo, los servicios y las cargas de trabajo de diferentes espacios de nombres de proyectos y de la misma organización pueden comunicarse entre sí aplicando políticas de red de tráfico entre proyectos.

De forma predeterminada, estas políticas se aplican a todas las zonas del mundo. Para obtener más información sobre los recursos globales en un universo de GDC, consulta el artículo Descripción general de multizona.

Para aplicar el tráfico entre proyectos en una sola zona, consulta Crear una política entre proyectos a nivel de carga de trabajo de una sola zona.

Antes de empezar

Para configurar políticas de red de tráfico entre proyectos, debes tener lo siguiente:

Los roles de identidad y acceso necesarios. Para gestionar las políticas de un proyecto específico, necesitas el rol project-networkpolicy-admin. En los entornos multizona en los que necesites gestionar políticas que abarquen todas las zonas, debes tener el rol global-project-networkpolicy-admin. Para obtener más información, consulta Preparar roles y acceso predefinidos.
Un proyecto que ya tengas. Para obtener más información, consulta Crear un proyecto.
En el caso de las políticas de red de salida, también debe inhabilitar la protección contra la filtración de datos del proyecto.

Crear una política entre proyectos

Puedes definir políticas de tráfico entre proyectos de entrada o de salida para gestionar la comunicación entre proyectos.

Crear una política de acceso multiproyecto

Para permitir las conexiones a las cargas de trabajo o los servicios de tu proyecto desde cargas de trabajo de otro proyecto de tu organización, debes configurar una regla de cortafuegos de entrada.

Esta política se aplica a todas las zonas de tu organización.

Sigue estos pasos para crear una regla de cortafuegos y permitir el tráfico entrante de cargas de trabajo de otro proyecto:

Consola

En la consola de GDC del proyecto que estés configurando, ve a Redes > Firewall en el menú de navegación para abrir la página Firewall.
Haga clic en Crear en la barra de acciones para empezar a crear una regla de cortafuegos.
En la página Detalles de regla de cortafuegos, rellena la siguiente información:
1. En el campo Nombre, introduce un nombre válido para la regla de cortafuegos.
2. En la sección Dirección del tráfico, selecciona Entrada para permitir el tráfico entrante de cargas de trabajo de otros proyectos.
3. En la sección Objetivo, seleccione una de las siguientes opciones:
  - Todas las cargas de trabajo de los usuarios: permite las conexiones a las cargas de trabajo del proyecto que estés configurando.
  - Servicio: indica que esta regla de cortafuegos está dirigida a un servicio específico del proyecto que estás configurando.
4. Si tu objetivo es un servicio de proyecto, selecciona el nombre del servicio en la lista de servicios disponibles del menú desplegable Servicio.
5. En la sección Desde, selecciona una de las dos opciones siguientes:
  - Todos los proyectos: permite las conexiones de las cargas de trabajo de todos los proyectos de la misma organización.
  - Otro proyecto y Todas las cargas de trabajo del usuario: permiten conexiones de cargas de trabajo de otro proyecto de la misma organización.
6. Si solo quieres transferir cargas de trabajo de otro proyecto, selecciona un proyecto al que tengas acceso en la lista del menú desplegable ID de proyecto.
7. Si tu objetivo son todas las cargas de trabajo de los usuarios, selecciona una de las siguientes opciones en la sección Protocolos y puertos:
  - Permitir todo: permite las conexiones mediante cualquier protocolo o puerto.
  - Protocolos y puertos especificados: permite las conexiones que usen solo los protocolos y puertos que especifiques en los campos correspondientes de la regla de cortafuegos de entrada.
En la página Detalles de la regla de cortafuegos, haz clic en Crear.

Ahora has permitido las conexiones de otras cargas de trabajo del proyecto dentro de la misma organización. Una vez creada la regla de cortafuegos, se mostrará en una tabla de la página Cortafuegos.

Para crear una política de entrada recíproca en la otra dirección, ve a la consola de GDC del otro proyecto y repite el proceso.

API

La siguiente política permite que las cargas de trabajo del proyecto PROJECT_1 permitan conexiones de cargas de trabajo del proyecto PROJECT_2, así como el tráfico de retorno de los mismos flujos. Aplica la política:

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

Sustituye GLOBAL_API_SERVER por la ruta kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta la sección Iniciar sesión para obtener más información.

El comando anterior permite que PROJECT_2 vaya a PROJECT_1, pero no permite las conexiones iniciadas desde PROJECT_1 a PROJECT_2. Para este último, necesitas una política recíproca en el proyecto PROJECT_2. Aplica la política de reciprocidad:

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

Ahora se permiten las conexiones hacia y desde PROJECT_1 y PROJECT_2.

Crear una política de salida entre proyectos

Cuando concede una política de tráfico entre proyectos de entrada para permitir que las cargas de trabajo de un proyecto permitan conexiones de cargas de trabajo de otro proyecto, esta acción también concede el tráfico de retorno de los mismos flujos. Por lo tanto, no necesitas una política de red de tráfico entre proyectos de salida en el proyecto original.

Sigue estos pasos para crear una regla de cortafuegos y permitir el tráfico saliente de las cargas de trabajo de un proyecto:

Consola

En la consola de GDC del proyecto que estés configurando, ve a Redes > Firewall en el menú de navegación para abrir la página Firewall.
En la barra de acciones, haz clic en Crear para crear una regla de cortafuegos.
En la página Detalles de regla de cortafuegos, rellena la siguiente información:
1. En el campo Nombre, introduce un nombre válido para la regla de cortafuegos.
2. En la sección Dirección del tráfico, selecciona Salida para indicar que esta regla de cortafuegos controla el tráfico saliente.
3. En la sección Objetivo, seleccione una de las siguientes opciones:
  - Todas las cargas de trabajo de los usuarios: permite las conexiones de las cargas de trabajo del proyecto que estés configurando.
  - Servicio: indica que esta regla de cortafuegos está dirigida a un servicio específico del proyecto que estás configurando.
4. Si tu objetivo es un servicio de proyecto, selecciona el nombre del servicio en la lista de servicios disponibles del menú desplegable Servicio.
5. En la sección Para, selecciona una de las dos opciones siguientes:
  - Todos los proyectos: permite las conexiones a las cargas de trabajo de todos los proyectos de la misma organización.
  - Otro proyecto y Todas las cargas de trabajo del usuario: permiten conexiones a cargas de trabajo de otro proyecto de la misma organización.
6. Si solo quieres transferir cargas de trabajo a otro proyecto, selecciona un proyecto al que tengas acceso en la lista de proyectos del menú desplegable ID de proyecto.
7. Si tu objetivo son todas las cargas de trabajo de los usuarios, selecciona una de las siguientes opciones en la sección Protocolos y puertos:
  - Permitir todo: permite las conexiones mediante cualquier protocolo o puerto.
  - Protocolos y puertos especificados: permite las conexiones solo con los protocolos y puertos que especifiques en los campos correspondientes de la regla de cortafuegos de salida.
En la página Detalles de la regla de cortafuegos, haz clic en Crear.

Ahora has permitido las conexiones a otras cargas de trabajo del proyecto dentro de la misma organización. Una vez creada la regla de cortafuegos, se mostrará en una tabla de la página Cortafuegos.

Para crear una política de salida recíproca en la otra dirección, ve a la consola de GDC del otro proyecto y repite el proceso.

API

La siguiente política permite que las cargas de trabajo del proyecto PROJECT_1 se conecten a las cargas de trabajo del proyecto PROJECT_2. Aplica la política:

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

Haz los cambios siguientes:

GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
PROJECT_1: nombre del proyecto que recibe el tráfico.
PROJECT_2: nombre del proyecto del que procede el tráfico.
SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role.
SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend reciben el tráfico.
PEER_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del mismo nivel.
PEER_LABEL_VALUE: el valor asociado a PEER_LABEL_KEY.

El comando anterior permite las conexiones salientes de PROJECT_1 a PROJECT_2, pero no las conexiones de PROJECT_2 a PROJECT_1. Para esto último, necesitas una política recíproca en el proyecto PROJECT_2. Aplica la política de reciprocidad:

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

Crear una política multiproyecto a nivel de carga de trabajo de salida

Para crear una política entre proyectos a nivel de carga de trabajo de salida, crea y aplica el siguiente recurso personalizado:
```
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
```
Haz los cambios siguientes:
- GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
- PROJECT_1: nombre del proyecto que recibe el tráfico.
- PROJECT_2: nombre del proyecto del que procede el tráfico.
- SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role.
- SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend están enviando el tráfico.
- PEER_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del mismo nivel.
- PEER_LABEL_VALUE: el valor asociado a PEER_LABEL_KEY.

Crear una política multiproyecto a nivel de carga de trabajo de una sola zona

Las políticas de red a nivel de carga de trabajo pueden aplicar PNP en una sola zona. Se pueden añadir etiquetas específicas a las cargas de trabajo de una sola zona, lo que te permite controlar la comunicación entre cargas de trabajo individuales de un proyecto o de diferentes proyectos de esa zona.

Crear una política multiproyecto a nivel de carga de trabajo de entrada de una sola zona

Para crear una política multiproyecto a nivel de carga de trabajo de entrada de una sola zona, crea y aplica el siguiente recurso personalizado:
```
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: Los recursos deben tener etiquetas que coincidan exactamente. Para asegurarte de que esta política se aplique en una sola zona, las cargas de trabajo de asunto y de mismo nivel deben tener la misma etiqueta de zona.

Haz los cambios siguientes:
- GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
- PROJECT_1: nombre del proyecto que recibe el tráfico.
- PROJECT_2: nombre del proyecto del que procede el tráfico.
- SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role.
- SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend reciben el tráfico.
- PEER_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del mismo nivel.
- PEER_LABEL_VALUE: el valor asociado a PEER_LABEL_KEY.
- ZONE_SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar la zona del sujeto. Por ejemplo, zone o region.
- ZONE_SUBJECT_LABEL_VALUE: el valor asociado a ZONE_SUBJECT_LABEL_KEY. Especifica qué zona recibe el tráfico. Por ejemplo, si ZONE_SUBJECT_LABEL_KEY es zone y ZONE_SUBJECT_LABEL_VALUE es us-central1-a, las cargas de trabajo con la etiqueta zone: us-central1-a reciben el tráfico.
- ZONE_PEER_LABEL_KEY: la clave de la etiqueta usada para seleccionar la zona asociada al elemento del mismo nivel.
- ZONE_PEER_LABEL_VALUE: el valor asociado a ZONE_PEER_LABEL_KEY.

Crear una política multiproyecto a nivel de carga de trabajo de salida de una sola zona

Para crear una política de salida de un solo proyecto a nivel de carga de trabajo de una sola zona, crea y aplica el siguiente recurso personalizado:
```
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: Los recursos deben tener etiquetas que coincidan exactamente. Para asegurarte de que esta política se aplique en una sola zona, las cargas de trabajo del asunto y del mismo nivel deben tener la misma etiqueta de zona.

Haz los cambios siguientes:
- GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
- PROJECT_1: nombre del proyecto que recibe el tráfico.
- PROJECT_2: nombre del proyecto del que procede el tráfico.
- SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role.
- SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend están enviando el tráfico.
- PEER_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del mismo nivel.
- PEER_LABEL_VALUE: el valor asociado a PEER_LABEL_KEY.
- ZONE_SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar la zona del sujeto. Por ejemplo, zone o region.
- ZONE_SUBJECT_LABEL_VALUE: el valor asociado a ZONE_SUBJECT_LABEL_KEY. Por ejemplo, si ZONE_SUBJECT_LABEL_KEY es zone y ZONE_SUBJECT_LABEL_VALUE es us-central1-a, las cargas de trabajo con la etiqueta zone: us-central1-a están enviando el tráfico.
- ZONE_PEER_LABEL_KEY: la clave de la etiqueta usada para seleccionar la zona asociada al elemento del mismo nivel.
- ZONE_PEER_LABEL_VALUE: el valor asociado a ZONE_PEER_LABEL_KEY.

Crear una política entre proyectos para clústeres estándar

Los clústeres estándar son clústeres de Kubernetes con ámbito de proyecto que ofrecen más control, flexibilidad y permisos de administrador de clústeres.

Crear una política de acceso multiproyecto para clústeres estándar

Para crear una política de acceso entre clústeres en clústeres estándar, crea y aplica el siguiente recurso personalizado:

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

Haz los cambios siguientes:

GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
STANDARD_CLUSTER_1_PROJECT: el nombre del proyecto de clúster estándar que recibe el tráfico.
STANDARD_CLUSTER_2_PROJECT: el nombre del proyecto de clúster estándar del que procede el tráfico.
STANDARD_CLUSTER_1_NAME: el nombre del clúster estándar que recibe el tráfico.
STANDARD_CLUSTER_2_NAME: el nombre del clúster estándar del que procede el tráfico.
SUBJECT_NAMESPACE: el espacio de nombres del asunto en el clúster estándar.
PEER_NAMESPACE: el espacio de nombres del mismo nivel en el clúster estándar.
SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role.
SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend reciben el tráfico.
PEER_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del mismo nivel.
PEER_LABEL_VALUE: el valor asociado a PEER_LABEL_KEY.

Para crear una política de acceso entre clústeres entre clústeres estándar y compartidos, crea y aplica el siguiente recurso personalizado:

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

Haz los cambios siguientes:

GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
STANDARD_CLUSTER_PROJECT: el nombre del proyecto del clúster estándar.
SHARED_CLUSTER_PROJECT: el nombre del proyecto de clúster compartido.
STANDARD_CLUSTER_NAME: el nombre del clúster estándar.
PEER_NAMESPACE: el espacio de nombres del mismo nivel en el clúster estándar.
SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role.
SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend reciben el tráfico.
PEER_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del mismo nivel.
PEER_LABEL_VALUE: el valor asociado a PEER_LABEL_KEY.

Crear una política de salida entre proyectos para clústeres estándar

Para crear una política de salida entre clústeres estándar, crea y aplica el siguiente recurso personalizado:

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

Haz los cambios siguientes:

GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
STANDARD_CLUSTER_1_PROJECT: el nombre del proyecto de clúster estándar que recibe el tráfico.
STANDARD_CLUSTER_2_PROJECT: el nombre del proyecto de clúster estándar del que procede el tráfico.
STANDARD_CLUSTER_1_NAME: el nombre del clúster estándar que recibe el tráfico.
STANDARD_CLUSTER_2_NAME: el nombre del clúster estándar del que procede el tráfico.
SUBJECT_NAMESPACE: el espacio de nombres del asunto en el clúster estándar.
PEER_NAMESPACE: el espacio de nombres del mismo nivel en el clúster estándar.
SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role.
SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend están enviando el tráfico.
PEER_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del mismo nivel.
PEER_LABEL_VALUE: el valor asociado a PEER_LABEL_KEY.

Para crear una política de salida entre clústeres estándar y compartidos, crea y aplica el siguiente recurso personalizado:
```
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
```
Haz los cambios siguientes:
- GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de APIs globales y zonales. Si aún no has generado un archivo kubeconfig para el servidor de la API, consulta Iniciar sesión para obtener más información.
- STANDARD_CLUSTER_PROJECT: el nombre del proyecto del clúster estándar.
- SHARED_CLUSTER_PROJECT: el nombre del proyecto de clúster compartido.
- STANDARD_CLUSTER_NAME: el nombre del clúster estándar.
- SUBJECT_NAMESPACE: el espacio de nombres del asunto en el clúster estándar.
- SUBJECT_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role.
- SUBJECT_LABEL_VALUE: el valor asociado a SUBJECT_LABEL_KEY. Por ejemplo, si SUBJECT_LABEL_KEY es app y SUBJECT_LABEL_VALUE es backend, las cargas de trabajo con la etiqueta app: backend están enviando el tráfico.
- PEER_LABEL_KEY: la clave de la etiqueta usada para seleccionar las cargas de trabajo del mismo nivel.
- PEER_LABEL_VALUE: el valor asociado a PEER_LABEL_KEY.

Crear políticas de red entre proyectos Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Antes de empezar

Crear una política entre proyectos

Crear una política de acceso multiproyecto

Consola

API

Crear una política de salida entre proyectos

Consola

API

Crear una política multiproyecto a nivel de carga de trabajo de salida

Crear una política multiproyecto a nivel de carga de trabajo de una sola zona

Crear una política multiproyecto a nivel de carga de trabajo de entrada de una sola zona

Crear una política multiproyecto a nivel de carga de trabajo de salida de una sola zona

Crear una política entre proyectos para clústeres estándar

Crear una política de acceso multiproyecto para clústeres estándar

Crear una política de salida entre proyectos para clústeres estándar

Crear políticas de red entre proyectos