Google Distributed Cloud (GDC) aislado admite clústeres estándar, un clúster de Kubernetes de un solo proyecto y autoservicio gestionado por el grupo de operadores de aplicaciones que ofrece mayor flexibilidad para cargas de trabajo personalizadas. En esta página se explica cómo configurar Cloud NAT para clústeres estándar y se describen algunas restricciones y limitaciones de las configuraciones de NAT para este tipo de clúster.
Antes de empezar
Antes de configurar una pasarela, debes obtener los permisos de gestión de identidades y accesos (IAM) adecuados, asegurarte de que tu proyecto tiene una política de red adecuada y habilitar la salida.
Para obtener más información, consulta Antes de empezar a usar Cloud NAT.
La pasarela de Cloud NAT usa subredes leaf externas como entradas. Para obtener más información sobre cómo configurar subredes externas para Cloud NAT, consulta Crear subredes externas para Cloud NAT.
Información general
Las pasarelas Cloud NAT se pueden configurar para gestionar el tráfico de salida de las cargas de trabajo que se ejecutan en clústeres estándar de dos formas:
- Pasarela con ámbito de proyecto: una pasarela que se aplica a todo el tráfico de cargas de trabajo de los clústeres de un proyecto, incluidos todos los clústeres compartidos y estándar. Esta es la configuración descrita en Crear una puerta de enlace Cloud NAT.
- Pasarela con ámbito de clúster: pasarela que solo se aplica a las cargas de trabajo de un clúster estándar específico. Este es el tipo de pasarela que se muestra en esta página.
Estos dos métodos son exclusivos de las cargas de trabajo y no se aplican a los nodos que componen un clúster estándar. Para habilitar Cloud NAT en los nodos que forman un clúster estándar, añada la etiqueta cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true" al objeto del clúster estándar.
Crear la pasarela de Cloud NAT
El proceso para crear una pasarela para un clúster estándar sigue siendo el mismo que el de cualquier pasarela Cloud NAT con ámbito de proyecto.
En este caso, nos centramos en la función de filtrado de clústeres para Cloud NAT de clúster estándar y creamos una configuración similar a la del primer caso, pero especificando el nombre del clúster estándar user-vc-1 donde se encuentran los endpoints que enrutarán el tráfico a través de la pasarela. Como resultado, esta pasarela se limitará a este clúster específico.
apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
namespace: project-1
name: gateway-1
spec:
workloadSelector: # Immutable
labelSelector:
workloads:
matchLabels:
app: aa
clusters:
matchLabels:
kubernetes.io/metadata.name: user-vc-1
subnetRefs: # Mutable
- subnet-1
- subnet-2
Con esta configuración, se seleccionarán todas las cargas de trabajo con las etiquetas app: aa
en todos los espacios de nombres del clúster estándar user-vc-1.
Comprobar el estado de la pasarela
Comprueba el estado de las pasarelas ejecutando el siguiente comando de kubectl.
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
kubectl get cloudnatgateways gateway-1 -n project-1 --kubeconfig "${MGMT_KUBECONFIG:?}"
Si se ha configurado correctamente, el campo de estado del gateway de Cloud NAT debería mostrar la condición del tipo Ready definida como true y las subredes marcadas como OK, tal como se muestra en el siguiente ejemplo de salida:
apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
namespace: project-1
name: gateway-1
spec:
workloadSelector: # Immutable
labelSelector:
workloads:
matchLabels:
app: aa
clusters:
matchLabels:
kubernetes.io/metadata.name: user-vc-1
subnetRefs: # Mutable
- subnet-1
- subnet-2
status:
conditions:
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: Ready
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: SubnetsReady
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: PerimeterConfigurationReady
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: EgressRoutesReady
subnets:
- name: subnet-1
status: OK
- name: subnet-2
status: OK
Tráfico de prueba
Prueba el tráfico ejecutando un comando curl desde uno de los pods o las VMs asignados a la pasarela del clúster estándar hacia un endpoint externo. El endpoint receptor debería ver un paquete de una de las IPs de salida asociadas a la pasarela. Los endpoints de clústeres compartidos con las mismas etiquetas NO PUEDEN enviar tráfico saliente mediante esta pasarela.
Restricciones en las configuraciones de pasarela específicas de un clúster
Los matchers de etiquetas de cargas de trabajo (workloadSelector.labelSelector.workloads.matchLabels) de las pasarelas con ámbito de clúster NO DEBEN SOLAPARSE con los matchers de etiquetas de cargas de trabajo de otras pasarelas con ámbito de proyecto. Como se explica en Restricciones de la configuración de Cloud NAT, el workloadSelector.labelSelector.workloads.matchLabels no debe solaparse entre las pasarelas del mismo proyecto y zona.
Las demás restricciones que se indican en Restricciones de la configuración de Cloud NAT también se aplican a las configuraciones de gateway con ámbito de clúster.