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 ahora está obsoleta y que se puede usar para permitir que las cargas de trabajo se conecten fuera de la organización. En esta página 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 llevar a cabo en una máquina virtual (VM) 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).

Nota: Esta opción de configuración y la solución recomendada, Cloud NAT, son incompatibles. Solo puedes usar una de estas opciones para un endpoint determinado.

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) con air gap 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 tu administrador de plataforma ha inhabilitado la protección contra la exfiltración de datos del proyecto. Para ello, los administradores de la cuenta pueden adjuntar la etiqueta networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" al 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 (NAT) de origen en el tráfico saliente de la organización.

Puedes gestionar la conectividad de salida de las cargas de trabajo de un pod o una VM.

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

Para configurar 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, asegúrate de que se haya añadido la etiqueta egress.networking.gke.io/enabled: true en el pod. Si usas una estructura de nivel superior, como Deployment o Daemonset, para gestionar conjuntos de pods, debes configurar la etiqueta de pod en esas especificaciones.

En el siguiente ejemplo se muestra cómo crear un 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 implementar cargas de trabajo de contenedor.

• DEPLOYMENT_NAME: el archivo kubeconfig del clúster de usuario en el que vas a implementar cargas de trabajo de contenedores.

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

• NUMBER_OF_REPLICAS: 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 de una VM

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

Migrar a Cloud NAT

Con la disponibilidad de Cloud NAT en la versión 1.15, la configuración predeterminada de NAT de salida por proyecto se ha quedado obsoleta. Recomendamos que los usuarios migren sus configuraciones de salida de la configuración de NAT de salida del proyecto predeterminado a Cloud NAT.

El NAT de salida del proyecto predeterminado y Cloud NAT no son compatibles entre sí. Es decir, un endpoint de un pod o una VM solo puede usar uno de los dos. Para migrar endpoints de una configuración a otra, debes inhabilitarlos en una y habilitarlos en la otra.

Para iniciar la migración, inhabilita la configuración anterior en los endpoints 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 endpoints del proyecto asignando la etiqueta networking.gdc.goog/allocate-egress-ip: "false" al proyecto.
• Inhabilitar la NAT de salida predeterminada del proyecto por endpoint: inhabilita la NAT de salida predeterminada del proyecto para un endpoint de pod o de VM concreto quitando la etiqueta egress.networking.gke.io/enabled:"true" del pod o de la VM.

Para continuar con la migración, a medida que se elimina cada endpoint de la NAT de salida predeterminada, se puede añadir a una puerta de enlace de Cloud NAT añadiendo etiquetas al endpoint que coincidan con los selectores de etiquetas de la puerta de enlace elegida.

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

Monitorización de IPs 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 Project no contendrá ninguna IP de salida. En su lugar, el usuario podrá enumerar las IPs que utiliza la pasarela de Cloud NAT enumerando las subredes asignadas a la pasarela.