Se usó la API de Cloud Translation para traducir esta página.

Configura direcciones IP públicas usadas de forma privada para GKE

Autopilot Estándar

En este instructivo, se muestra cómo aplicar direcciones IP públicas de uso privado (PUPI) a los bloques de direcciones de Pods de Google Kubernetes Engine (GKE).

Las direcciones IP públicas de uso privado (PUPI) son direcciones que puedes usar de forma privada dentro de tu red de nube privada virtual (VPC) de Google Cloud. Estas direcciones IP no son propiedad de Google. No es necesario que seas propietario de estas direcciones IP públicas para usarlas de forma privada.

Descripción general

Los clústeres de GKE requieren rangos de direcciones IP dedicados para nodos, Pods y Services. A medida que tu infraestructura crece, es posible que te encuentres con el agotamiento del espacio de direcciones IP internas estándar (RFC 1918). Una forma de mitigar el agotamiento de direcciones privadas del RFC 1918 es usar direcciones IP públicas de uso privado (PUPI) para el bloque CIDR del Pod de GKE. Los PUPI proporcionan una alternativa para la red de tu Pod de GKE, ya que reservan direcciones IP privadas para otros componentes del clúster.

Clúster único: Si solo creas un clúster de GKE, puedes habilitar las PUPI habilitando los rangos de direcciones IP externas que se usan de forma privada.

Varios clústeres: Si trabajas con varios clústeres de GKE conectados a través del intercambio de tráfico entre VPC (una situación común 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 administrado a un cliente (consumidor) mediante PUPI con el emparejamiento de VPC.

Direcciones PUPI para el bloque CIDR del Pod de GKE.

En el diagrama anterior, se incluyen las siguientes consideraciones:

Bloque CIDR principal: Un bloque CIDR que no es de PUPI que se usa para nodos y balanceador de cargas interno (ILB), y no debe superponerse en las VPC.
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 del consumidor: cualquier otro bloque CIDR de PUPI del lado del cliente (por ejemplo, 5.5.0.0/16).

Cómo se usan las PUPI en una situación de proveedor de servicios

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

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

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

Garantiza la comunicación entre las VPC

De consumidor a productor: De forma predeterminada, la VPC del consumidor comparte de forma automática sus rutas RFC 1918 (pero no las PUPI) con el productor. Esto permite que los recursos de la VPC del consumidor accedan a los servicios en la VPC del productor (por lo general, a través de balanceadores de cargas internos).
Del productor a consumidor: Para que los Pods del productor lleguen a los recursos en la VPC del consumidor, se necesita una configuración explícita.
Sin superposición: El productor y el consumidor deben asegurarse de que el rango de PUPI del consumidor no entre en conflicto con ninguna dirección IP que se use en la VPC del productor.
Exportar/importar: El productor debe habilitar la exportación de sus rutas PUPI y el consumidor debe habilitar la importación de esas rutas a través de la conexión de intercambio de tráfico.

Habilita la comunicación cuando los rangos de PUPI se superponen

Si la VPC del consumidor ya usa el mismo rango 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, en el que las direcciones IP del Pod están ocultas detrás de las direcciones IP del nodo del productor.

En la siguiente tabla, se muestra la configuración predeterminada de importación y exportación para cada VPC. Puedes modificar la configuración predeterminada del intercambio de tráfico de VPC mediante el comando gcloud compute networks peerings update.

Red de VPC	Importar la configuración	Exportar configuración	Notas
Productor	Comportamiento predeterminado (desactivado): No importa rutas de subredes con direcciones IP públicas Para activar: --import-subnet-routes-with-public-ip (mediante el intercambio de tráfico)	Comportamiento predeterminado (activado): Exporta rutas de subredes con direcciones IP públicas Para desactivar: --no-export-subnet-routes-with-public-ip (mediante el intercambio de tráfico)	Marcas controladas a través de las herramientas de redes de servicios
Consumidor	Desactivado (predeterminado)	Activado (predeterminado)	Por lo general, administra el cliente y no es necesario modificarlo mediante las redes de servicio.

Esta configuración da como resultado lo siguiente:

La VPC del productor ve todas las rutas de clientes.
La VPC del consumidor no ve las rutas de PUPI configuradas en la subred del Pod en la VPC del productor.
El tráfico que se origina de los Pods del productor a la red vpc-consumer debe traducirse detrás de las direcciones de nodo en el clúster del productor.

Requisitos previos

Para establecer una comunicación exitosa entre los Pods de VPC y otra VPC, asegúrate de que se cumplan los siguientes requisitos y configuraciones:

Tu clúster de GKE debe cumplir con los siguientes requisitos mínimos de versión:
- Clústeres de Autopilot: GKE versión 1.22 o posterior
- Clústeres de Linux: GKE versión 1.14 o posterior
Selecciona un rango de PUPI que no se pueda enrutar públicamente ni que sea propiedad de Google.
Asegúrate de que las direcciones IP del nodo y el rango de direcciones IP principal de ambas VPC no se superpongan.
Si necesitas una comunicación directa de Pod a Pod entre la VPC del cliente y el servicio administrado, sigue estos pasos:
- Clústeres de Autopilot: Configura SNAT para PUPI a fin de garantizar la comunicación de Pod a Pod. No necesitas configuración adicional.
- Clústeres estándar: Convierte las direcciones IP de Pod a sus direcciones IP de nodo correspondientes con SNAT. Habilita la SNAT para el tráfico PUPI. Para obtener más información, consulta Habilita los rangos de direcciones IP externas utilizados de forma privada.

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

Para configurar direcciones PUPI para clústeres de GKE, haz lo siguiente:

Configura dos redes de nube privada virtual.
Configura una subred dentro de cada red de nube privada virtual.
Configurar un rango de direcciones PUPI en un rango de direcciones secundario en cada subred
Establecer una relación de intercambio de tráfico de nube privada virtual entre las dos redes de nube privada virtual con la configuración adecuada de importación y exportación.
Inspecciona las rutas dentro de cada nube privada virtual.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la CLI de gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Usa solo clústeres nativos de la VPC.
Configura las especificaciones de IPAM necesarias para el intercambio de tráfico de VPC.

Configura redes y clústeres

Crea redes de VPC:

Crea las siguientes dos redes de VPC con RFC-1918 como rangos principales para nodos y rangos de PUPI para Pods. Asigna rangos 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 VPC. Por lo general, estos rangos se usan para los nodos trabajadores dentro de tus clústeres de GKE. Además de los rangos de direcciones IP internas, designa rangos separados de direcciones IP públicas de uso privado (PUPI) para cada VPC. Estos rangos de PUPI se usan exclusivamente para las direcciones IP de Pods dentro 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 cargas de trabajo del consumidor. Puedes usar una configuración similar a la que se muestra a continuación:
```
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 que se muestra a continuación:
```
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 la creación de redes de VPC, consulta Crea redes de VPC.
Con las redes y subredes de VPC que creaste con los rangos de PUPI en el paso anterior, puedes crear dos clústeres de GKE (producer y consumer).

Nota: Los rangos de PUPI solo son compatibles como rangos de direcciones IP secundarios para la red de Pods en GKE y no se pueden usar en el rango de direcciones IP principal (que usa nodos y objetos Service).
1. Crea clústeres producer con la red y la subred de productor de la siguiente manera:
```
gcloud container clusters create PRODUCER_CLUSTER_NAME \
    --enable-ip-alias \
    --network=NETWORK_NAME \
    --subnetwork=SUBNETWORK_NAME \
    --cluster-secondary-range-name=PRODUCER_PODS \
    --services-secondary-range-name=PRODUCER_SERVICES \
    --num-nodes=1 \
    --zone=PRODUCER_ZONE_NAME \
    --project=PRODUCER_PROJECT_NAME
```
  Reemplaza lo siguiente:
  - PRODUCER_CLUSTER_NAME: Es el nombre del clúster del productor de GKE.
  - COMPUTE_LOCATION: la ubicación de Compute Engine para el clúster.
  - PRODUCER_SUBNET_NAME: Es el nombre de una subred existente. El rango de direcciones IP principal de la subred se usa para los nodos. La subred debe existir en la misma región que usa el clúster. Si se omite, GKE intenta usar una subred en la red de VPC default en la región del clúster.
  - Si el método de asignación del rango secundario es administrado por GKE:
    - POD_IP_RANGE: Un rango de direcciones IP en notación de CIDR, como 10.0.0.0/14, o el tamaño de la máscara de subred de un bloque CIDR, como /14. Esto se usa con el fin de crear el rango de direcciones IP secundario de la subred para los pods. Si omites la opción --cluster-ipv4-cidr, GKE elige un rango /14 (2¹⁸ direcciones) de forma automática. Este rango se selecciona de forma aleatoria a partir de 10.0.0.0/8 (un rango de 2²⁴ direcciones).
    - SERVICES_IP_RANGE: un rango de direcciones IP en una notación de CIDR (por ejemplo, 10.4.0.0/19) o el tamaño de la máscara de subred de un bloque de CIDR (por ejemplo, /19). Se usa con el fin de crear el rango de direcciones IP secundarias de la subred para los servicios.
  - Si el método de asignación del rango secundario es administrado por el usuario:
    - SECONDARY_RANGE_PODS es el nombre de un rango de direcciones IP secundario existente en el SUBNET_NAME especificado. GKE usa todo el rango de direcciones IP secundario de la subred para los Pods del clúster.
    - SECONDARY_RANGE_SERVICES es el nombre de un rango de direcciones IP secundario existente en el especificado.
2. Crea clústeres consumer con la red y la subred de productor de la siguiente manera:
```
gcloud container clusters create CONSUMER_CLUSTER_NAME \
    --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 \
    --zone=CONSUMER_ZONE \
    --project=CONSUMER_PROJECT
```
  Reemplaza lo siguiente:
  - CONSUMER_CLUSTER_NAME: Es el nombre del clúster de consumidor de GKE.
  - COMPUTE_LOCATION: la ubicación de Compute Engine para el clúster.
  - CONSUMER_SUBNET_NAME: Es el nombre de una subred existente. El rango de direcciones IP principal de la subred se usa para los nodos. La subred debe existir en la misma región que usa el clúster. Si se omite, GKE intenta usar una subred en la red de VPC default en la región del clúster.
  - Si el método de asignación del rango secundario es administrado por GKE:
    - POD_IP_RANGE: Un rango de direcciones IP en notación de CIDR, como 10.0.0.0/14, o el tamaño de la máscara de subred de un bloque CIDR, como /14. Esto se usa con el fin de crear el rango de direcciones IP secundario de la subred para los pods. Si omites la opción --cluster-ipv4-cidr, GKE elige un rango /14 (2¹⁸ direcciones) de forma automática. Este rango se selecciona de forma aleatoria a partir de 10.0.0.0/8 (un rango de 2²⁴ direcciones) y no incluirá los rangos de direcciones IP asignados a las VMs, rutas existentes o rangos asignados a otros clústeres. El rango elegido de forma automática podría entrar en conflicto con direcciones IP reservadas, rutas dinámicas o rutas dentro de VPC que intercambian el tráfico con este clúster. Si usas alguna de estas opciones, debes especificar --cluster-ipv4-cidr para evitar conflictos.
    - SERVICES_IP_RANGE: un rango de direcciones IP en una notación de CIDR (por ejemplo, 10.4.0.0/19) o el tamaño de la máscara de subred de un bloque de CIDR (por ejemplo, /19). Se usa con el fin de crear el rango de direcciones IP secundarias de la subred para los servicios.
  - Si el método de asignación del rango secundario es administrado por el usuario:
    - SECONDARY_RANGE_PODS es el nombre de un rango de direcciones IP secundario existente en el SUBNET_NAME especificado. GKE usa todo el rango de direcciones IP secundario de la subred para los Pods del clúster.
    - SECONDARY_RANGE_SERVICES es el nombre de un rango de direcciones IP secundario existente en el especificado.
Para obtener más información sobre la creación de clústeres, consulta Crea clústeres.
Establece la relación de intercambio de tráfico de VPC entre la red de VPC del consumidor y la red de VPC del productor de la siguiente manera:
- Para conectar la red consumer al productor, ejecuta el siguiente comando:
```
gcloud compute networks peerings create PEERING_NAME \
    --project=consumer_project \
    --network=consumer \
    --peer-network=producer
```
- Para conectar la red producer al consumidor, ejecuta el siguiente comando:
```
gcloud compute networks peerings create PEERING_NAME \
    --project=producer_project \
    --network=producer \
    --peer-network=consumer \
    --no-export-subnet-routes-with-public-ip \
    --import-subnet-routes-with-public-ip
```
Reemplaza lo siguiente:
- PEERING_NAME: Es el nombre del clúster de consumidor de GKE.
- CONSUMER_CLUSTER_NAME: Es el nombre del clúster de consumidor de GKE.
De forma predeterminada, la VPC del consumidor exporta las direcciones PUPI. Cuando creas la VPC del productor, usas los siguientes argumentos para configurar la VPC a fin de importar direcciones PUPI, pero no exportarlas:
```
--no-export-subnet-routes-with-public-ip
--import-subnet-routes-with-public-ip
```

Verifica las redes y las subredes

Verifica la red del productor:

gcloud compute networks describe producer \
    --project=producer_project

El resultado es similar a este:

...
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-subnet \
    --project=producer_project\
    --region=producer_region

El resultado es similar a este:

...
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 subnets describe consumer-subnet \
    --project=consumer_project \
    --region=consumer_region

El resultado es similar a este:

...
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 de consumidor:

gcloud compute networks describe consumer \
--project=consumer_project

El resultado es similar a este:

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

Verifica el clúster de GKE y sus recursos

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

gcloud container clusters get-credentials consumer-cluster \
    --project=consumer_project \
    --zone=consumer_zone

El resultado es similar a este:

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

Instala y verifica helloapp.

Como alternativa, 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 es similar a este:

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

Verifica la solución

Verifica que creaste el intercambio de tráfico de VPC de forma correcta:

gcloud compute networks peerings list

El resultado es similar al siguiente, que muestra los intercambios de tráfico llamados consumidor y productor:

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 del consumidor exporte rutas PUPI:

gcloud compute networks peerings list-routes consumer-peer-producer \
    --direction=OUTGOING \
    --network=consumer \
    --region=<consumer_region>

El resultado es similar al siguiente, que muestra los tres bloques CIDR del 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 PUPI que importó la VPC del productor:

gcloud compute networks peerings list-routes producer-peer-consumer \
    --direction=INCOMING \
    --network=producer \
    --region=<producer_region>

El resultado es similar al siguiente, que muestra los tres bloques CIDR del 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 se encuentran dentro del rango 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>

¿Qué sigue?

Lee la guía Configura el acceso privado a los servicios.
Lee la guía Comienza a usar la API de Herramientas de redes de servicios.
Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.