Esta página se ha traducido con Cloud Translation API.

Configurar direcciones IP públicas usadas de forma privada en GKE

Autopilot Standard

En esta página se muestra cómo aplicar direcciones IP públicas usadas de forma privada (PUPI) a bloques de direcciones de pods de Google Kubernetes Engine (GKE).

Las direcciones IP públicas usadas de forma privada (PUPIs) son direcciones que puedes usar de forma privada en tu red de Google Cloud nube privada virtual (VPC). Google no es propietario de estas direcciones IP. No es necesario que seas el propietario de estas direcciones IP públicas para usarlas de forma privada.

Información general

Los clústeres de GKE requieren intervalos de direcciones IP dedicados para los nodos, los pods y los servicios. A medida que tu infraestructura crezca, es posible que te quedes sin espacio de direcciones IP internas estándar (RFC 1918). Una forma de mitigar el agotamiento de las direcciones RFC 1918 privadas es usar direcciones IP públicas usadas de forma privada (PUPI) para el bloque CIDR de pods de GKE. Los PUPIs proporcionan una alternativa para la red de pods de GKE, ya que reservan direcciones IP privadas para otros componentes del clúster.

Un solo clúster: si solo vas a crear un clúster de GKE, puedes habilitar las PUPIs habilitando los intervalos de direcciones IP externas usadas de forma privada.

Varios clústeres: si trabajas con varios clústeres de GKE conectados mediante el emparejamiento de VPC (un caso habitual para los proveedores de servicios), necesitarás una configuración más compleja. En el siguiente diagrama se muestra un ejemplo de cómo una empresa (productor) ofrece un servicio gestionado mediante PUPI con el peering de VPC a un cliente (consumidor).

Direcciones PUPI del bloque CIDR de pods de GKE.

En el diagrama anterior se tienen en cuenta los siguientes aspectos:

Bloque CIDR principal: bloque CIDR que no es PUPI y que se usa para nodos y balanceadores de carga internos (ILBs). No debe superponerse con otros bloques CIDR de VPCs.
Bloque CIDR secundario del productor: un bloque CIDR de PUPI que se usa para los pods (por ejemplo, 45.45.0.0/16).
Bloque CIDR secundario de consumidor: cualquier otro bloque CIDR de PUPI del lado del cliente (por ejemplo, 5.5.0.0/16).

Cómo se usan las PUPIs en un escenario de proveedor de servicios

El proveedor de servicios (productor) ejecuta su servicio gestionado en un clúster de GKE (gke-2) dentro de su VPC (vpc-producer). Este clúster usa el intervalo PUPI 45.0.0.0/8 para sus direcciones IP de pods.

El cliente (consumidor) también tiene un clúster de GKE (gke-1) en su propia VPC (vpc-consumer), que usa otro intervalo de PUPI, 5.0.0.0/8, para sus direcciones IP de pods.

Estas dos VPCs están conectadas mediante el peering de VPC, pero cada una sigue usando direcciones IP privadas estándar (RFC 1918) para nodos, servicios y balanceadores de carga internos.

Asegurar la comunicación entre VPCs

Consumidor a productor: de forma predeterminada, la VPC del consumidor comparte automáticamente sus rutas RFC 1918 (pero no las PUPIs) con el productor. De esta forma, los recursos de la VPC del consumidor pueden acceder a los servicios de la VPC del productor (normalmente, a través de balanceadores de carga internos).
Productor a consumidor: para que los pods del productor puedan acceder a los recursos de la VPC del consumidor, es necesario realizar una configuración explícita.
Sin solapamiento: el productor y el consumidor deben asegurarse de que el intervalo de PUPI del consumidor no entre en conflicto con ninguna dirección IP utilizada en la VPC del productor.
Exportar o importar: el productor debe habilitar la exportación de sus rutas de PUPI y el consumidor debe habilitar la importación de esas rutas a través de la conexión de emparejamiento.

Habilitar la comunicación cuando se solapen los intervalos de PUPI

Si la VPC del consumidor ya usa el mismo intervalo de PUPI que el productor, no es posible la comunicación directa desde los pods del productor. En su lugar, el productor puede habilitar el enmascaramiento de direcciones IP, donde las direcciones IP de los pods se ocultan tras las direcciones IP de los nodos del productor.

En la siguiente tabla se muestran los ajustes de importación y exportación predeterminados de cada VPC. Puedes modificar la configuración predeterminada de la interconexión de VPCs con el comando gcloud compute networks peerings update.

Red de VPC	Configuración de importación	Exportar ajustes	Notas
Productor	Comportamiento predeterminado (desactivado): no importa rutas de subred con direcciones IP públicas. Para activarlo: --import-subnet-routes-with-public-ip (a través del emparejamiento)	Comportamiento predeterminado (activado): exporta rutas de subred con direcciones IP públicas Para desactivarlo: --no-export-subnet-routes-with-public-ip (a través del emparejamiento)	Marcas controladas mediante redes de servicio.
Consumidor	Desactivado (predeterminado)	Activado (predeterminado)	Normalmente, lo gestiona el cliente y no es necesario modificarlo mediante la creación de redes de servicios.

Estos ajustes tienen los siguientes efectos:

La VPC de productor ve todas las rutas del cliente.
La VPC de consumidor no ve las rutas PUPI configuradas en la subred de pods de la VPC de productor.
El tráfico procedente de los pods del productor a la red vpc-consumer debe traducirse detrás de las direcciones de los nodos del clúster del productor.

Requisitos previos

Para establecer una comunicación correcta entre los pods de la VPC y otra VPC, asegúrate de que se cumplen los siguientes requisitos previos y configuraciones:

Tu clúster de GKE debe cumplir los siguientes requisitos de versión mínima:
- Clústeres de Autopilot: versión 1.22 de GKE o posterior
- Clústeres estándar: versión 1.14 de GKE o posterior
Selecciona un intervalo de PUPI que no sea accesible públicamente ni sea propiedad de Google.
Asegúrate de que las direcciones IP de los nodos y el intervalo de direcciones IP principal de ambas VPCs no se solapen.
Si necesitas una comunicación directa entre pods de la VPC del cliente y el servicio gestionado, sigue estos pasos:
- Clústeres de Autopilot: configura SNAT para PUPI para asegurar la comunicación entre pods. No necesitas ninguna configuración adicional.
- Clústeres estándar: traduce las direcciones IP de los pods a las direcciones IP de los nodos correspondientes mediante SNAT. Habilita SNAT para el tráfico de PUPI. Para obtener más información, consulta Habilitar intervalos de direcciones IP externas usadas de forma privada.

Configurar direcciones IP públicas usadas de forma privada para clústeres de GKE

Para configurar direcciones PUPI en clústeres de GKE, sigue estos pasos:

Configura dos redes de nube privada virtual.
Configura una subred en cada red de nube privada virtual.
Configura un intervalo de direcciones PUPI en un intervalo de direcciones secundario de cada subred.
Establece una relación de peering de nube privada virtual entre las dos redes de nube privada virtual con los ajustes de importación y exportación adecuados.
Inspecciona las rutas de cada nube privada virtual.

Costes

En este documento, se usan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

Usa solo clústeres nativos de VPC.
Configura las especificaciones de IPAM necesarias para el emparejamiento de VPC.

Configurar redes y clústeres

Crea redes de VPC:

Crea las dos redes de VPC siguientes con RFC-1918 como intervalos principales para los nodos e intervalos PUPI para los pods. Asigna intervalos de direcciones IP principales del espacio de direcciones privadas RFC 1918 (por ejemplo, 10.x.x.x, 172.16.x.x o 192.168.x.x) a ambas VPCs. Estos intervalos se suelen usar para los nodos de trabajador de los clústeres de GKE. Además de los intervalos de direcciones IP internas, designa intervalos independientes de direcciones IP públicas usadas de forma privada (PUPIs) para cada VPC. Estos intervalos de PUPI se usan exclusivamente para las direcciones IP de los pods de sus clústeres de GKE correspondientes.
- Red de VPC del consumidor: esta VPC aloja el clúster de GKE en el que se ejecutan las aplicaciones o las cargas de trabajo del consumidor. Puedes usar una configuración similar a la siguiente:
```
Network: consumer
Subnetwork: consumer-subnet
Primary range: 10.129.0.0/24
Service range name and cidr: consumer-services, 172.16.5.0/24
Pod range name and cidr: consumer-pods, 5.5.5.0/24
Cluster name: consumer-cluster
```
- Red de VPC del productor: esta VPC aloja el clúster de GKE responsable de proporcionar el servicio que usa el consumidor. Puedes usar una configuración similar a la siguiente:
```
Network: producer
Subnetwork: producer-subnet
Primary range: 10.128.0.0/24
Service range name and cidr: producer-services, 172.16.45.0/24
Pod range name and cidr: producer-pods, 45.45.45.0/24
Cluster name: producer-cluster
```
Para obtener más información sobre cómo crear redes de VPC, consulta Crear redes de VPC.
Con las redes de VPC y las subredes creadas con intervalos de PUPI en el paso anterior, puedes crear dos clústeres de GKE (producer y consumer).

Nota: Los intervalos de PUPI solo se admiten como intervalos de direcciones IP secundarias para la red de pods en GKE y no se pueden usar para el intervalo de direcciones IP principal (que usan los nodos y los servicios).
1. Crea clústeres producer con la red y la subred del productor de la siguiente manera:
```
gcloud container clusters create PRODUCER_CLUSTER_NAME \
    --location=PRODUCER_CONTROL_PLANE_LOCATION \
    --enable-ip-alias \
    --network=PRODUCER_NETWORK_NAME \
    --subnetwork=PRODUCER_SUBNETWORK_NAME \
    --cluster-secondary-range-name=PRODUCER_PODS \
    --services-secondary-range-name=PRODUCER_SERVICES \
    --num-nodes=1 \
    --project=PRODUCER_PROJECT_ID
```
  Haz los cambios siguientes:
  - PRODUCER_CLUSTER_NAME: el nombre del clúster de productor de GKE.
  - PRODUCER_CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster de productor. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.
  - PRODUCER_NETWORK_NAME: el nombre de una red de VPC de productor.
  - PRODUCER_SUBNETWORK_NAME: el nombre de una subred. El intervalo de direcciones IP principal de la subred se usa para los nodos. La subred debe existir en la misma región que la que usa el clúster. Si se omite, GKE intentará usar una subred de la default VPC de la región del clúster.
  - Si GKE gestiona el método de asignación de intervalos secundarios:
    - POD_IP_RANGE: un intervalo de direcciones IP en notación CIDR, como 10.0.0.0/14, o el tamaño de una máscara de subred de bloque CIDR, como /14. Se usa para crear el intervalo de direcciones IP secundarias de la subred para los pods. Si omites la opción --cluster-ipv4-cidr, GKE elige un intervalo /14 (2¹⁸ direcciones) automáticamente. El intervalo elegido automáticamente se selecciona al azar entre 10.0.0.0/8 (un intervalo de 2²⁴ direcciones).
    - SERVICES_IP_RANGE: un intervalo de direcciones IP en notación CIDR (por ejemplo, 10.4.0.0/19) o el tamaño de una máscara de subred de bloque CIDR (por ejemplo, /19). Se usa para crear el intervalo de direcciones IP secundarias de la subred para los servicios.
  - Si el método de asignación de intervalo secundario es gestionado por el usuario:
    - SECONDARY_RANGE_PODS: el nombre de un intervalo de direcciones IP secundarias ya creado en el SUBNET_NAME especificado. GKE usa todo el intervalo de direcciones IP secundarias de la subred para los pods del clúster.
    - SECONDARY_RANGE_SERVICES: el nombre de un intervalo de direcciones IP secundarias ya creado en el especificado.
  - PRODUCER_PROJECT_ID: el ID del proyecto productor.
2. Crea clústeres consumer con la red y la subred del consumidor de la siguiente manera:
```
gcloud container clusters create CONSUMER_CLUSTER_NAME \
    --location=CONSUMER_CONTROL_PLANE_LOCATION \
    --enable-ip-alias \
    --network=CONSUMER_NETWORK_NAME \
    --subnetwork=CONSUMER_SUBNETWORK_NAME \
    --cluster-secondary-range-name=CONSUMER_PODS \
    --services-secondary-range-name=CONSUMER_SERVICES \
    --num-nodes=1 \
    --project=CONSUMER_PROJECT_ID
```
  Haz los cambios siguientes:
  - CONSUMER_CLUSTER_NAME: el nombre del clúster de consumidor de GKE.
  - CONSUMER_CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster de consumidor. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.
  - PRODUCER_NETWORK_NAME: el nombre de una red VPC de consumidor.
  - CONSUMER_SUBNETWORK_NAME: el nombre de una subred. El intervalo de direcciones IP principal de la subred se usa para los nodos. La subred debe existir en la misma región que la que usa el clúster. Si se omite, GKE intentará usar una subred de la default VPC de la región del clúster.
  - Si el método de asignación de intervalos secundarios es gestionado por GKE:
    - POD_IP_RANGE: un intervalo de direcciones IP en notación CIDR, como 10.0.0.0/14, o el tamaño de una máscara de subred de bloque CIDR, como /14. Se usa para crear el intervalo de direcciones IP secundarias de la subred para los pods. Si omites la opción --cluster-ipv4-cidr, GKE elige un intervalo /14 (2¹⁸ direcciones) automáticamente. El intervalo elegido automáticamente se selecciona aleatoriamente entre 10.0.0.0/8 (un intervalo de 2²⁴ direcciones) y no incluirá intervalos de direcciones IP asignados a máquinas virtuales, rutas ni intervalos asignados a otros clústeres. El intervalo elegido automáticamente puede entrar en conflicto con direcciones IP reservadas, rutas dinámicas o rutas de VPCs que estén emparejadas con este clúster. Si usas alguno de estos, debes especificar --cluster-ipv4-cidr para evitar conflictos.
    - SERVICES_IP_RANGE: un intervalo de direcciones IP en notación CIDR (por ejemplo, 10.4.0.0/19) o el tamaño de una máscara de subred de bloque CIDR (por ejemplo, /19). Se usa para crear el intervalo de direcciones IP secundarias de la subred para los servicios.
  - Si el método de asignación de intervalo secundario es gestionado por el usuario:
    - SECONDARY_RANGE_PODS: el nombre de un intervalo de direcciones IP secundarias ya creado en el SUBNET_NAME especificado. GKE usa todo el intervalo de direcciones IP secundarias de la subred para los pods del clúster.
    - SECONDARY_RANGE_SERVICES: el nombre de un intervalo de direcciones IP secundarias ya creado en el especificado.
  - CONSUMER_PROJECT_ID: el ID del proyecto de consumidor.
Para obtener más información sobre cómo crear clústeres, consulta Crear clústeres.
Establece la relación de emparejamiento entre redes de VPC entre la red de VPC de consumidor y la red de VPC de productor de la siguiente manera:
- Para conectar la red consumer al productor, ejecuta el siguiente comando:
```
gcloud compute networks peerings create CONSUMER_PEERING_NAME \
    --project=CONSUMER_PROJECT_ID \
    --network=CONSUMER_NETWORK_NAME \
    --peer-network=PRODUCER_NETWORK_NAME
```
  Sustituye CONSUMER_PEERING_NAME por el nombre del peering que se va a añadir a la red del consumidor.
- Para conectar la red producer al consumidor, ejecuta el siguiente comando:
```
gcloud compute networks peerings create PRODUCER_PEERING_NAME \
    --project=PRODUCER_PROJECT_ID \
    --network=PRODUCER_NETWORK_NAME \
    --peer-network=CONSUMER_NETWORK_NAME \
    --no-export-subnet-routes-with-public-ip \
    --import-subnet-routes-with-public-ip
```
  Sustituye PRODUCER_PEERING_NAME por el nombre del emparejamiento que se va a añadir a la red del productor.
De forma predeterminada, la VPC de consumidor exporta las direcciones PUPI. Cuando creas la VPC de productor, usas los siguientes argumentos para configurar la VPC de forma que importe direcciones PUPI, pero no las exporte:
```
--no-export-subnet-routes-with-public-ip
--import-subnet-routes-with-public-ip
```

Verificar las redes y las subredes

Verifica la red del productor:

gcloud compute networks describe PRODUCER_NETWORK_NAME \
    --project=PRODUCER_PROJECT_ID

El resultado debería ser similar al siguiente:

...
kind: compute#network
name: producer
peerings:
- autoCreateRoutes: true
  exchangeSubnetRoutes: true
  exportCustomRoutes: false
  exportSubnetRoutesWithPublicIp: false
  importCustomRoutes: false
  importSubnetRoutesWithPublicIp: true
  name: producer-peer-consumer
…

Verifica la subred del productor:

gcloud compute networks subnets describe PRODUCER_SUBNETWORK_NAME \
    --project=PRODUCER_PROJECT_ID\
    --region=PRODUCER_CONTROL_PLANE_LOCATION

El resultado debería ser similar al siguiente:

...
ipCidrRange: 10.128.0.0/24
kind: compute#subnetwork
name: producer-subnet
…
secondaryIpRanges:
- ipCidrRange: 172.16.45.0/24
  rangeName: producer-services
- ipCidrRange: 45.45.45.0/24
  rangeName: producer-pods
…

Verifica la red del consumidor:

gcloud compute networks describe CONSUMER_NETWORK_NAME \
    --project=CONSUMER_PROJECT_ID

El resultado debería ser similar al siguiente:

...
kind: compute#network
name: consumer
peerings:
- autoCreateRoutes: true
  exchangeSubnetRoutes: true
  exportCustomRoutes: false
  exportSubnetRoutesWithPublicIp: true
  importCustomRoutes: false
  importSubnetRoutesWithPublicIp: false
  name: consumer-peer-producer
...

Verifica la subred del consumidor:

gcloud compute networks subnets describe CONSUMER_SUBNETWORK_NAME \
    --project=CONSUMER_PROJECT_ID\
    --region=CONSUMER_CONTROL_PLANE_LOCATION

El resultado debería ser similar al siguiente:

...
ipCidrRange: 10.129.0.0/24
kind: compute#subnetwork
name: consumer-subnet
...
secondaryIpRanges:
- ipCidrRange: 172.16.5.0/24
  rangeName: consumer-services
- ipCidrRange: 5.5.5.0/24
  rangeName: consumer-pods
...

Verificar el clúster de GKE y sus recursos

Obtén las credenciales del clúster de consumidor:

gcloud container clusters get-credentials CONSUMER_CLUSTER_NAME \
    --project=CONSUMER_PROJECT_ID \
    --location=CONSUMER_CONTROL_PLANE_LOCATION

El resultado debería ser similar al siguiente:

...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for consumer-cluster.
...

Instala y verifica la aplicación helloapp.

También puedes guardar el siguiente manifiesto como deployment.yaml:

kubectl apply -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 200m
EOF

Aplica el archivo deployment.yaml:
```
kubectl apply -f
```

Verifica la implementación de helloweb:

kubectl get deployment helloweb

El resultado debería ser similar al siguiente:

...
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
helloweb   1/1     1            1           10s
...

Verificar la solución

Valida que has creado correctamente el peering de VPC:

gcloud compute networks peerings list

La salida es similar a la siguiente, que muestra las conexiones del mismo nivel denominadas consumer y producer:

NAME                                     NETWORK    PEER_PROJECT                PEER_NETWORK                            STACK_TYPE  PEER_MTU  IMPORT_CUSTOM_ROUTES  EXPORT_CUSTOM_ROUTES  STATE   STATE_DETAILS
consumer-peer-producer                   consumer   <project_name>             producer                                IPV4_ONLY   1460      False                 False                 ACTIVE  [2023-08-07T13:14:57.178-07:00]: Connected.
producer-peer-consumer                   producer   <project_name>             consumer                                IPV4_ONLY   1460      False                 False                 ACTIVE  [2023-08-07T13:14:57.178-07:00]: Connected.

Valida que la VPC de consumidor exporta rutas de PUPI:

gcloud compute networks peerings list-routes CONSUMER_PEERING_NAME \
    --direction=OUTGOING \
    --network=CONSUMER_NETWORK_NAME \
    --region=CONSUMER_CONTROL_PLANE_LOCATION

El resultado es similar al siguiente, que muestra los tres bloques CIDR de consumidor:

DEST_RANGE     TYPE                  NEXT_HOP_REGION  PRIORITY  STATUS
10.129.0.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer
172.16.5.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer
5.5.5.0/24     SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer

Valida las rutas de PUPI que ha importado la VPC de productor:

gcloud compute networks peerings list-routes PRODUCER_PEERING_NAME \
    --direction=INCOMING \
    --network=PRODUCER_NETWORK_NAME \
    --region=PRODUCER_CONTROL_PLANE_LOCATION

El resultado es similar al siguiente, que muestra los tres bloques CIDR de consumidor:

DEST_RANGE     TYPE                  NEXT_HOP_REGION  PRIORITY  STATUS
10.129.0.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted
172.16.5.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted
5.5.5.0/24     SUBNET_PEERING_ROUTE  us-central1      0         accepted

Valida que los pods de GKE tengan una dirección PUPI:

kubectl get pod -o wide

El resultado es similar al siguiente, que muestra que las direcciones IP de los pods están dentro del intervalo 5.5.5/24.

NAME                        READY   STATUS    RESTARTS   AGE   IP         NODE                                              NOMINATED NODE   READINESS GATES
helloweb-575d78464d-xfklj   1/1     Running   0          28m   5.5.5.16   gke-consumer-cluster-default-pool-e62b6542-dp5f   <none>           <none>

Siguientes pasos

Consulta la guía Configurar acceso privado a servicios.
Consulta la guía Primeros pasos con la API Service Networking.
Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobreGoogle Cloud. Consulta nuestro Centro de arquitectura de Cloud.

Configurar direcciones IP públicas usadas de forma privada en GKE Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Información general

Requisitos previos

Configurar direcciones IP públicas usadas de forma privada para clústeres de GKE

Costes

Antes de empezar

Configurar redes y clústeres

Verificar las redes y las subredes

Verificar el clúster de GKE y sus recursos

Verificar la solución

Siguientes pasos

Configurar direcciones IP públicas usadas de forma privada en GKE