Crea 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) aislado.

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

De forma predeterminada, los servicios y las cargas de trabajo de un proyecto están aislados de los servicios y las cargas de trabajo externos. Sin embargo, los servicios y las cargas de trabajo de diferentes espacios de nombres del proyecto y dentro 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 nivel global en todas las zonas. Para obtener más información sobre los recursos globales en un universo de GDC, consulta la descripción general de varias zonas.

Para aplicar el tráfico entre proyectos dentro de una sola zona, consulta Crea una política entre proyectos a nivel de la carga de trabajo para una sola zona.

Antes de comenzar

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

  • Los roles de identidad y acceso necesarios Para administrar las políticas de un proyecto específico, necesitas el rol de project-networkpolicy-admin. Para los entornos de varias zonas en los que necesitas administrar políticas que abarcan todas las zonas, necesitas el rol de global-project-networkpolicy-admin. Para obtener más información, consulta Cómo preparar roles y acceso predefinidos.
  • Un proyecto existente Para obtener más información, consulta Cómo crear un proyecto.
  • En el caso de las políticas de red de salida, también debes inhabilitar la protección contra el robo de datos para el proyecto.

Crea una política entre proyectos

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

Crea una política de entrada entre proyectos

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

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

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

Console

  1. En la consola de GDC del proyecto que estás configurando, ve a Networking > Firewall en el menú de navegación para abrir la página Firewall.
  2. Haz clic en Crear en la barra de acciones para comenzar a crear una nueva regla de firewall.

  3. En la página Detalles de la regla de firewall, completa la siguiente información:

    1. En el campo Nombre, ingresa un nombre válido para tu regla de firewall.
    2. En la sección Dirección del tráfico, selecciona Entrada para permitir el tráfico entrante de cargas de trabajo en otros proyectos.
    3. En la sección Objetivo, selecciona una de las siguientes opciones:
      • Todas las cargas de trabajo del usuario: Permite conexiones a las cargas de trabajo del proyecto que estás configurando.
      • Servicio: Indica que esta regla de firewall se dirige a un servicio específico dentro del proyecto que estás configurando.
    4. Si tu destino es un servicio del proyecto, selecciona el nombre del servicio en la lista de servicios disponibles en el menú desplegable Servicio.
    5. En la sección De, selecciona una de las siguientes dos opciones:
      • Todos los proyectos: Permite conexiones desde cargas de trabajo en todos los proyectos de la misma organización.
      • Otro proyecto y Todas las cargas de trabajo del usuario: Permiten conexiones desde cargas de trabajo en otro proyecto de la misma organización.
    6. Si solo quieres transferir cargas de trabajo desde otro proyecto, selecciona un proyecto al que puedas acceder desde la lista de proyectos en el menú desplegable ID del proyecto.
    7. Si tu objetivo son todas las cargas de trabajo del usuario, selecciona una de las siguientes opciones en la sección Protocolos y puertos:
      • Permitir todo: Permite conexiones con cualquier protocolo o puerto.
      • Protocolos y puertos especificados: Permiten conexiones solo con los protocolos y puertos que especificas en los campos correspondientes de la regla de firewall de entrada.

  4. En la página Detalles de la regla de firewall, haz clic en Crear.

Ahora permitiste las conexiones de otras cargas de trabajo del proyecto dentro de la misma organización. Después de crear la regla de firewall, esta se mostrará en una tabla en la página Firewall.

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

API

La siguiente política permite que las cargas de trabajo en el proyecto PROJECT_1 permitan conexiones de cargas de trabajo en el proyecto PROJECT_2, así como el tráfico de retorno para 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

Reemplaza GLOBAL_API_SERVER por la ruta de acceso del archivo kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Accede para obtener más detalles.

El comando anterior permite que PROJECT_2 vaya a PROJECT_1, pero no permite las conexiones iniciadas desde PROJECT_1 a PROJECT_2. En el segundo caso, 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.

Crea una política de salida entre proyectos

Cuando otorgas una política de tráfico de entrada entre proyectos para permitir que las cargas de trabajo de un proyecto permitan conexiones de cargas de trabajo en otro proyecto, esta acción también otorga el tráfico de retorno para 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 firewall nueva y permitir el tráfico saliente de las cargas de trabajo en un proyecto:

Console

  1. En la consola de GDC del proyecto que estás configurando, ve a Networking > Firewall en el menú de navegación para abrir la página Firewall.
  2. En la barra de acciones, haz clic en Crear para crear una regla de firewall nueva.

  3. En la página Detalles de la regla de firewall, completa la siguiente información:

    1. En el campo Nombre, ingresa un nombre válido para tu regla de firewall.
    2. En la sección Dirección del tráfico, selecciona Salida para indicar que esta regla de firewall controla el tráfico saliente.
    3. En la sección Objetivo, selecciona una de las siguientes opciones:
      • Todas las cargas de trabajo del usuario: Permite conexiones desde las cargas de trabajo del proyecto que estás configurando.
      • Servicio: Indica que esta regla de firewall se dirige a un servicio específico dentro del proyecto que estás configurando.
    4. Si tu destino es un servicio del proyecto, selecciona el nombre del servicio en la lista de servicios disponibles en el menú desplegable Servicio.
    5. En la sección Para, selecciona una de las siguientes dos opciones:
      • Todos los proyectos: Permite conexiones a cargas de trabajo en todos los proyectos de la misma organización.
      • Otro proyecto y Todas las cargas de trabajo del usuario: Permiten conexiones a cargas de trabajo en otro proyecto de la misma organización.
    6. Si deseas transferir cargas de trabajo solo a otro proyecto, selecciona un proyecto al que puedas acceder desde la lista de proyectos en el menú desplegable ID del proyecto.
    7. Si tu objetivo son todas las cargas de trabajo del usuario, selecciona una de las siguientes opciones en la sección Protocolos y puertos:
      • Permitir todo: Permite conexiones con cualquier protocolo o puerto.
      • Protocolos y puertos especificados: Permiten conexiones solo con los protocolos y puertos que especificas en los campos correspondientes de la regla de firewall de salida.

  4. En la página Detalles de la regla de firewall, haz clic en Crear.

Ahora permitiste las conexiones a otras cargas de trabajo del proyecto dentro de la misma organización. Después de crear la regla de firewall, esta se mostrará en una tabla en la página Firewall.

Para crear una política de salida recíproca en la otra dirección, visita 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 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

Reemplaza lo siguiente:

  • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
  • PROJECT_1: Es el nombre del proyecto que recibe el tráfico.
  • PROJECT_2: Es el nombre del proyecto desde el que proviene el tráfico.

El comando anterior permite conexiones salientes desde PROJECT_1 a PROJECT_2, pero no permite conexiones desde PROJECT_2 a PROJECT_1. En el segundo caso, 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

Crea una política entre proyectos a nivel de la carga de trabajo de salida

  • Para crear una política entre proyectos a nivel de la 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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • PROJECT_1: Es el nombre del proyecto que recibe el tráfico.
    • PROJECT_2: Es el nombre del proyecto desde el que proviene el tráfico.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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 envían el tráfico.
    • PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.

Crea una política entre proyectos a nivel de la carga de trabajo de una sola zona

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

Crea una política entre proyectos a nivel de la carga de trabajo de entrada de una sola zona

  1. Para crear una política entre proyectos a nivel de la 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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • PROJECT_1: Es el nombre del proyecto que recibe el tráfico.
    • PROJECT_2: Es el nombre del proyecto desde el que proviene el tráfico.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.
    • ZONE_SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar la zona del sujeto. Por ejemplo, zone o region. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • ZONE_SUBJECT_LABEL_VALUE: Es el valor asociado con el 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: Es la clave de la etiqueta que se usa para seleccionar la zona asociada con el par. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • ZONE_PEER_LABEL_VALUE: Es el valor asociado con el ZONE_PEER_LABEL_KEY.

Crea una política entre proyectos a nivel de la carga de trabajo de salida de una sola zona

  • Para crear una política entre proyectos a nivel de la carga de trabajo de salida 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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • PROJECT_1: Es el nombre del proyecto que recibe el tráfico.
    • PROJECT_2: Es el nombre del proyecto desde el que proviene el tráfico.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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 envían el tráfico.
    • PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.
    • ZONE_SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar la zona del sujeto. Por ejemplo, zone o region. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • ZONE_SUBJECT_LABEL_VALUE: Es el valor asociado con el 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 envían el tráfico.
    • ZONE_PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar la zona asociada con el par. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • ZONE_PEER_LABEL_VALUE: Es el valor asociado con el ZONE_PEER_LABEL_KEY.

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

Los clústeres estándar son clústeres de Kubernetes con alcance a nivel del proyecto que proporcionan mayor control, flexibilidad y permisos de administrador del clúster.

Crea una política de entrada entre proyectos para clústeres estándar

  1. Para crear una política de entrada 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_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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • STANDARD_CLUSTER_1_PROJECT: Es el nombre del proyecto del clúster estándar que recibe el tráfico.
    • STANDARD_CLUSTER_2_PROJECT: Es el nombre del proyecto del clúster estándar desde el que proviene el tráfico.
    • STANDARD_CLUSTER_1_NAME: Es el nombre del clúster estándar que recibe el tráfico.
    • STANDARD_CLUSTER_2_NAME: Es el nombre del clúster estándar desde el que proviene el tráfico.
    • SUBJECT_NAMESPACE: Es el espacio de nombres del sujeto en el clúster estándar.
    • PEER_NAMESPACE: Es el espacio de nombres del par en el clúster estándar.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.

  2. Para crear una política de ingreso 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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • STANDARD_CLUSTER_PROJECT: Es el nombre del proyecto del clúster estándar.
    • SHARED_CLUSTER_PROJECT: Es el nombre del proyecto del clúster compartido.
    • STANDARD_CLUSTER_NAME: Es el nombre del clúster estándar.
    • PEER_NAMESPACE: Es el espacio de nombres del par en el clúster estándar.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.

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

  1. 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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • STANDARD_CLUSTER_1_PROJECT: Es el nombre del proyecto del clúster estándar que recibe el tráfico.
    • STANDARD_CLUSTER_2_PROJECT: Es el nombre del proyecto del clúster estándar desde el que proviene el tráfico.
    • STANDARD_CLUSTER_1_NAME: Es el nombre del clúster estándar que recibe el tráfico.
    • STANDARD_CLUSTER_2_NAME: Es el nombre del clúster estándar desde el que proviene el tráfico.
    • SUBJECT_NAMESPACE: Es el espacio de nombres del sujeto en el clúster estándar.
    • PEER_NAMESPACE: Es el espacio de nombres del par en el clúster estándar.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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 envían el tráfico.
    • PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.

  2. Para crear una política de salida entre clústeres compartidos y 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_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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API global. Para obtener más información, consulta Servidores de API globales y zonales. Si aún no generaste un archivo kubeconfig para el servidor de la API, consulta Acceder para obtener más detalles.
    • STANDARD_CLUSTER_PROJECT: Es el nombre del proyecto del clúster estándar.
    • SHARED_CLUSTER_PROJECT: Es el nombre del proyecto del clúster compartido.
    • STANDARD_CLUSTER_NAME: Es el nombre del clúster estándar.
    • SUBJECT_NAMESPACE: Es el espacio de nombres del sujeto en el clúster estándar.
    • SUBJECT_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo del asunto. Por ejemplo, app, tier o role. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • SUBJECT_LABEL_VALUE: Es el valor asociado con el 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 envían el tráfico.
    • PEER_LABEL_KEY: Es la clave de la etiqueta que se usa para seleccionar las cargas de trabajo de los pares. Si haces referencia a etiquetas de VM, debes agregar un prefijo a esta clave. Consulta la advertencia que sigue a esta lista.
    • PEER_LABEL_VALUE: Es el valor asociado con el PEER_LABEL_KEY.