Gestionar la NAT de salida predeterminada de un proyecto

En esta página se describe la configuración de NAT de salida predeterminada del proyecto, que ya no se usa y que se puede utilizar para permitir que las cargas de trabajo se conecten fuera de la organización. También se incluyen instrucciones sobre cómo migrar a la solución recomendada, Cloud NAT.

Información general

En esta página se describen las acciones de conectividad de salida que debes realizar en una máquina virtual o un pod de un proyecto para permitir que las cargas de trabajo salgan de la organización mediante la opción de configuración de NAT de salida predeterminada del proyecto (obsoleta).

La NAT de salida predeterminada del proyecto no es compatible con los clústeres estándar. Usa Cloud NAT si necesitas controlar la salida de los clústeres estándar.

En el procedimiento se muestra cómo añadir una etiqueta obligatoria a las implementaciones para habilitar explícitamente el tráfico saliente y permitir que las cargas de trabajo se comuniquen fuera de la organización.

De forma predeterminada, Google Distributed Cloud (GDC) air-gapped impide que las cargas de trabajo de un proyecto salgan de la organización. Las cargas de trabajo pueden salir de la organización si el administrador de la plataforma ha inhabilitado la protección contra la exfiltración de datos del proyecto. Los administradores de la plataforma pueden hacerlo añadiendo la etiqueta networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" a l proyecto. Además de inhabilitar la protección contra la exfiltración de datos, el operador de la aplicación debe añadir la etiqueta egress.networking.gke.io/enabled: true a la carga de trabajo del pod para habilitar la conectividad de salida de ese pod. Cuando asignas y usas una dirección IP conocida para el proyecto, se realiza una traducción de direcciones de red de origen (NAT) en el tráfico saliente de la organización.

Puedes gestionar la conectividad de salida de las cargas de trabajo en un pod o una máquina virtual.

Gestionar el tráfico saliente de las cargas de trabajo en un pod

Para configurar las cargas de trabajo en un pod para la conectividad de salida, primero debes asegurarte de que la protección contra la exfiltración de datos esté inhabilitada en el proyecto. A continuación, comprueba que se haya añadido la etiqueta egress.networking.gke.io/enabled: true al pod. Si usas una construcción de nivel superior, como Deployment o Daemonset, para gestionar conjuntos de pods, debes configurar la etiqueta del pod en esas especificaciones.

En el siguiente ejemplo se muestra cómo crear una Deployment a partir de su archivo de manifiesto. El archivo de ejemplo contiene el valor egress.networking.gke.io/enabled: true en el campo labels para habilitar explícitamente el tráfico saliente del proyecto. Esta etiqueta se añade a cada pod de la implementación y permite que las cargas de trabajo de los pods salgan de la organización.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  replicas: NUMBER_OF_REPLICAS
  selector:
    matchLabels:
      run: APP_NAME
  template:
    metadata:
      labels: # The labels given to each pod in the deployment, which are used
              # to manage all pods in the deployment.
        run: APP_NAME
        egress.networking.gke.io/enabled: true
    spec: # The pod specification, which defines how each pod runs in the deployment.
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
EOF

Haz los cambios siguientes:

  • USER_CLUSTER_KUBECONFIG: el archivo kubeconfig del clúster de usuario en el que vas a desplegar las cargas de trabajo de contenedor.

  • DEPLOYMENT_NAME: el archivo kubeconfig del clúster de usuario en el que vas a desplegar las cargas de trabajo de contenedor.

  • APP_NAME: el nombre de la aplicación que se va a ejecutar en la implementación.

  • NUMBER_OF_REPLICAS: el número de objetos Pod replicados que gestiona la implementación.

  • CONTAINER_NAME: el nombre del contenedor.

  • CONTAINER_IMAGE: el nombre de la imagen del contenedor. Debes incluir la ruta del registro de contenedores y la versión de la imagen, como REGISTRY_PATH/hello-app:1.0.

Por ejemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
        egress.networking.gke.io/enabled: true
    spec:
      containers:
      - name: hello-app
        image: REGISTRY_PATH/hello-app:1.0

Gestionar el tráfico saliente de las cargas de trabajo en una máquina virtual

Para configurar las cargas de trabajo en una máquina virtual para la conectividad de salida, puedes usar la consola de GDC para la configuración de la máquina virtual o crear un recurso VirtualMachineExternalAccess. Para obtener información sobre cómo habilitar una máquina virtual con acceso externo para la transferencia de datos, consulta la sección Habilitar el acceso externo en el artículo Conectarse a máquinas virtuales.

Migrar a Cloud NAT

Con la disponibilidad de Cloud NAT en la versión 1.15, la configuración de NAT de salida predeterminada del proyecto por proyecto queda obsoleta. Se recomienda que los usuarios migren sus configuraciones de salida de la configuración de NAT de salida predeterminada del proyecto a Cloud NAT.

La NAT de salida predeterminada del proyecto y Cloud NAT no son compatibles entre sí. Es decir, un punto de conexión de pod o de máquina virtual determinado solo puede usar una de las dos opciones. Para migrar puntos de conexión de una configuración a otra, debes inhabilitarlos en una y, a continuación, habilitarlos en la otra.

Para iniciar la migración, inhabilita la configuración anterior en los puntos de conexión que quieras migrar. Hay dos modos de hacerlo:

  • Inhabilitar la NAT de salida predeterminada del proyecto en todo el proyecto: inhabilita la NAT de salida predeterminada del proyecto en todos los puntos de conexión del proyecto asignando la etiqueta networking.gdc.goog/allocate-egress-ip: "false" al proyecto.
  • Inhabilitar la NAT de salida predeterminada del proyecto por punto de conexión: inhabilita la NAT de salida predeterminada del proyecto en un punto de conexión de pod o de máquina virtual concreto quitando la etiqueta egress.networking.gke.io/enabled:"true" del pod o de la máquina virtual.

Para continuar la migración, a medida que se quita cada punto de conexión de la NAT de salida predeterminada, se puede añadir a una pasarela de Cloud NAT añadiendo etiquetas al punto de conexión que coincidan con los selectores de etiquetas de la pasarela elegida.

Consulta el artículo Cloud NAT y las páginas siguientes para obtener instrucciones sobre cómo configurar Cloud NAT.

Monitorización de la IP de salida

Con la NAT de salida predeterminada, las IPs de salida que se usan para la NAT del tráfico de salida se incluyen en el estado del proyecto. Con Cloud NAT, el objeto del proyecto no contendrá ninguna IP de salida. En su lugar, el usuario podrá ver las IPs que usa la pasarela de Cloud NAT enumerando las subredes asignadas a la pasarela.