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.

Las políticas de red de un proyecto definen reglas de entrada o de salida. Puede definir políticas que permitan la comunicación dentro de los proyectos, entre proyectos y con direcciones IP externas.

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 las multizonas.

Si necesitas aplicar la política de tráfico entre proyectos en una sola zona, consulta el artículo 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 dentro de un proyecto, 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.

Crear una política de intraproyecto

En el caso del tráfico de un proyecto, GDC aplica de forma predeterminada una política de red de proyecto predefinida, la política intraproyecto, a cada proyecto. De forma predeterminada, las cargas de trabajo de un espacio de nombres de un proyecto pueden comunicarse entre sí sin exponer nada a recursos externos.

De forma predeterminada, no hay ninguna política de salida, por lo que se permite el tráfico saliente para todo el tráfico dentro del proyecto. Sin embargo, cuando se define una sola política de salida, solo se permite el tráfico que especifica la política.

Crear una política de entrada entre proyectos

Cuando creas un proyecto, se crea implícitamente un recurso base ProjectNetworkPolicy predeterminado que permite la comunicación entre proyectos. Esta política permite el tráfico entrante de otras cargas de trabajo del mismo proyecto.

Puedes quitar la política predeterminada, pero ten en cuenta que, si lo haces, se denegará la comunicación entre proyectos para todos los servicios y cargas de trabajo del proyecto. Para quitar la política, usa el comando kubectl delete:

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

Para volver a añadir la política predeterminada, aplica el siguiente manifiesto:

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

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: el nombre de tu proyecto.

Crear una política de salida entre proyectos

Cuando inhabilita la prevención de la exfiltración de datos y aplica una política de salida ProjectNetworkPolicy al proyecto, como impedir el acceso a un recurso externo, utilice la siguiente política obligatoria para permitir el tráfico saliente dentro del proyecto:

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

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: el nombre de tu proyecto.

Crear una política intraproyecto a nivel de carga de trabajo

Las políticas de red a nivel de carga de trabajo ofrecen un control granular sobre la comunicación entre cargas de trabajo individuales de un proyecto. Esta granularidad permite un control más estricto del acceso a la red, lo que mejora la seguridad y el uso de los recursos.

Crear una política de entrada a nivel de carga de trabajo dentro de un proyecto

Cuando creas un proyecto, se crea implícitamente un recurso base ProjectNetworkPolicy predeterminado que permite la comunicación entre todas las cargas de trabajo del proyecto. Esta política permite el tráfico entrante de otras cargas de trabajo del mismo proyecto.

Para crear una política de nivel de carga de trabajo de entrada entre proyectos, primero se debe eliminar la política base predeterminada. De lo contrario, puede producirse un comportamiento inesperado.

  1. Para eliminar la política básica predeterminada, ejecuta el siguiente comando:

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

  2. Para crear una política de nivel de carga de trabajo de entrada entre proyectos, 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
  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

    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: el nombre de tu proyecto.
    • 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 a nivel de carga de trabajo dentro de un proyecto

  • Para crear una política de salida a nivel de carga de trabajo dentro de un proyecto, 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
  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

    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: el nombre de tu proyecto.
    • 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 intraproyecto 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 intraproyecto a nivel de carga de trabajo de entrada de una sola zona

Cuando creas un proyecto, se crea implícitamente un recurso base ProjectNetworkPolicy predeterminado que permite la comunicación entre todas las cargas de trabajo del proyecto. Esta política permite el tráfico entrante de otras cargas de trabajo del mismo proyecto.

Para crear una política de nivel de carga de trabajo de entrada de una sola zona en un proyecto, primero debes eliminar la política base predeterminada. De lo contrario, puede producirse un comportamiento inesperado.

  1. Para eliminar la política básica predeterminada, ejecuta el siguiente comando:

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

  2. Para crear una política de red de tráfico entre proyectos 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
  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

    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: el nombre de tu proyecto.
    • 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 asunto. 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 reciben el tráfico.
    • ZONE_PEER_LABEL_KEY: 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 de salida de nivel de carga de trabajo intraproyecto de una sola zona

  • Para crear una política de salida de una sola zona a nivel de carga de trabajo dentro de un proyecto, 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
  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

    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: el nombre de tu proyecto.
    • 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 asunto. 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 reciben el tráfico.
    • ZONE_PEER_LABEL_KEY: 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 intraproyecto 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. Cuando creas una política intraproyecto, los clústeres estándar la heredan de forma predeterminada. Esta política permite toda la comunicación dentro de los clústeres estándar que residen en el mismo proyecto.

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

Cuando creas un proyecto, se crea implícitamente un recurso base ProjectNetworkPolicy predeterminado que permite la comunicación entre todas las cargas de trabajo del proyecto. Esta política permite el tráfico entrante de otras cargas de trabajo del mismo proyecto, así como la comunicación entre todas las cargas de trabajo de los clústeres estándar del proyecto.

Para crear una política de acceso intraproyecto para clústeres estándar, primero se debe eliminar la política base predeterminada. De lo contrario, puede producirse un comportamiento inesperado.

  1. Para eliminar la política básica predeterminada, ejecuta el siguiente comando:

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

    Para volver a añadir la política predeterminada, aplica el siguiente manifiesto:

    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

    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: el nombre de tu proyecto.

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

    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.
    • STANDARD_CLUSTER_NAME: el nombre del clúster estándar.
    • 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.

  3. Para crear una política de nodo a pod de entrada 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_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

    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.
    • STANDARD_CLUSTER_NAME: el nombre del 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.
    • NODE_IP: la dirección IP del nodo.
    • PORT: el puerto de la carga de trabajo en cuestión en el que se permite el tráfico.

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

  1. Para crear una política de pod a pod de salida dentro de un clúster 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_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

    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.
    • STANDARD_CLUSTER_NAME: el nombre del clúster estándar.
    • 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.
    1. Para crear una política de pod a nodo de salida dentro del clúster 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_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

    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.
    • STANDARD_CLUSTER_NAME: el nombre del 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.
    • NODE_IP: la dirección IP del nodo.
    • PORT: el puerto de la IP del nodo al que se permite el tráfico.