Crea un clúster privado

En esta página, se explica cómo crear un clúster privado en Google Kubernetes Engine (GKE). En un clúster privado, los nodos solo tienen direcciones IP internas RFC 1918, lo que garantiza que sus cargas de trabajo estén aisladas de la Internet pública. Para obtener más información sobre cómo funcionan los clústeres privados, consulta Clústeres privados.

Antes de comenzar

Familiarízate con los requisitos, las restricciones y las limitaciones antes de avanzar al siguiente paso.

Sigue estos pasos a fin de prepararte para esta tarea:

  • Asegúrate de que habilitaste la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Asegúrate de que instalaste el SDK de Cloud.
  • Establece tu ID del proyecto predeterminado:
    gcloud config set project [PROJECT_ID]
  • Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada:
    gcloud config set compute/zone [COMPUTE_ZONE]
  • Si trabajas con clústeres regionales, establece tu región de procesamiento predeterminada:
    gcloud config set compute/region [COMPUTE_REGION]
  • Actualiza gcloud a la versión más reciente:
    gcloud components update

Acceso a la instancia principal

En los clústeres privados, la instancia principal tiene un extremo público y uno privado. Existen tres combinaciones de configuración para controlar el acceso a los extremos del clúster.

  • Acceso al extremo público inhabilitado. Esto crea un clúster privado sin acceso del cliente al extremo público.
  • Acceso al extremo público habilitado, redes autorizadas de instancia principal habilitadas. Esto crea un clúster privado con acceso limitado al extremo público.
  • Acceso al extremo público habilitado, redes autorizadas de instancia principal inhabilitadas. Esto crea un clúster privado con acceso ilimitado al extremo público.

Consulta Acceso a los extremos del clúster para obtener una descripción general de las diferencias entre las opciones de configuración anteriores.

Crea un clúster privado sin acceso de clientes al extremo público

En esta sección, podrás crear un clúster privado con nodos privados y sin acceso al extremo público.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters create private-cluster-0 \
    --create-subnetwork name=my-subnet-0 \
    --enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --enable-private-endpoint \
    --master-ipv4-cidr 172.16.0.32/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

En el ejemplo anterior, se ilustra lo siguiente:

  • --enable-master-authorized-networks especifica que el acceso al extremo público está restringido a los rangos de direcciones IP que autorices.
  • --create-subnetwork name=my-subnet-0 hace que GKE cree de forma automática una subred llamada my-subnet-0.
  • --enable-ip-alias hace que el clúster sea nativo de la VPC.
  • --enable-private-nodes indica que los nodos del clúster no tienen direcciones IP externas.
  • --master-ipv4-cidr 172.16.0.32/28 especifica un rango RFC 1918 para la instancia principal. Esta configuración es permanente para este clúster.

Console

Completa los pasos siguientes:

  1. Visita el menú de GKE en Google Cloud Console.

    Visita el menú de GKE.

  2. Haz clic en Crear clúster.

  3. Elige la plantilla Clúster estándar o elige una plantilla adecuada para tu carga de trabajo.

  4. En Nombre, ingresa my-subnet-0.

  5. Haz clic en Disponibilidad, herramientas de redes, seguridad y características adicionales en la parte inferior del menú.

  6. En Nativo de la VPC, selecciona la casilla de verificación Habilitar nativo de la VPC (con IP de alias). Deja el menú desplegable Red configurado como default y el menú desplegable Subred de nodo configurado como default. Esto hace que GKE genere una subred para el clúster.

  7. En Seguridad de red, selecciona la casilla de verificación Clúster privado.

  8. Borra la casilla de verificación Acceder a la instancia principal mediante su dirección IP externa.

  9. Configura el rango de IP de instancia principal como 172.16.0.32/28.

  10. La casilla de verificación Habilitar redes autorizadas de instancia principal se selecciona de forma automática.

  11. Desmarca la casilla de verificación Habilitar panel de Kubernetes.

  12. Desmarca la casilla de verificación Emitir certificado de cliente.

  13. Haz clic en Crear.

API

Para crear un clúster con una instancia principal accesible de forma pública, especifica el campo enablePrivateEndpoint: true en el recurso privateClusterConfig.

En este punto, estas son las únicas direcciones IP que tienen acceso a la instancia principal del clúster:

  • El rango principal de my-subnet-0
  • El rango secundario que se usa para los pods

Por ejemplo, supongamos que creaste una VM en el rango primario de my-subnet-0. Luego, en esa VM, puedes configurar kubectl para usar la dirección IP interna de la instancia principal.

Si deseas acceder a la instancia principal del clúster fuera de my-subnet-0, debes autorizar al menos un rango de direcciones para que tenga acceso al extremo privado.

Supongamos que tienes una VM que está en la red predeterminada, en la misma región que tu clúster, pero no en my-subnet-0.

Por ejemplo:

  • my-subnet-0: 10.0.0.0/22
  • Rango secundario del pod: 10.52.0.0/14
  • Dirección de la VM: 10.128.0.3

Puedes autorizar a la VM el acceso a la instancia principal con este comando:

gcloud container clusters update private-cluster-0 \
    --enable-master-authorized-networks \
    --master-authorized-networks 10.128.0.3/32

Crea un clúster privado con acceso limitado al extremo público

Cuando creas un clúster privado con esta configuración, puedes optar por usar una subred generada automáticamente o una subred personalizada.

Usa una subred generada automáticamente

En esta sección, crearás un clúster privado en el que GKE generará automáticamente una subred para tus nodos de clúster. La subred tiene habilitado el acceso privado a Google. GKE crea automáticamente dos rangos secundarios en la subred: Uno para los pods y otro para los servicios.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters create private-cluster-1 \
    --create-subnetwork name=my-subnet-1 \
    --enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --master-ipv4-cidr 172.16.0.0/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

En el ejemplo anterior, se ilustra lo siguiente:

  • --enable-master-authorized-networks especifica que el acceso al extremo público está restringido a los rangos de direcciones IP que autorices.
  • --create-subnetwork name=my-subnet-1 hace que GKE cree de forma automática una subred llamada my-subnet-1.
  • --enable-ip-alias hace que el clúster sea nativo de la VPC.
  • --enable-private-nodes indica que los nodos del clúster no tienen direcciones IP externas.
  • --master-ipv4-cidr 172.16.0.0/28 especifica un rango RFC 1918 para la instancia principal. Esta configuración es permanente para este clúster.

Console

Completa los pasos siguientes:

  1. Visita el menú de GKE en Google Cloud Console.

    Visita el menú de GKE.

  2. Haz clic en Crear clúster.

  3. Elige la plantilla Clúster estándar o elige una plantilla adecuada para tu carga de trabajo.

  4. En Nombre, ingresa my-subnet-1.

  5. Haz clic en Disponibilidad, herramientas de redes, seguridad y características adicionales en la parte inferior del menú.

  6. En Nativo de la VPC, deja seleccionado Habilitar nativo de la VPC (con un alias de IP). Deja el menú desplegable Red configurado como default y el menú desplegable Subred de nodo configurado como default. Esto hace que GKE genere una subred para el clúster.

  7. En Seguridad de red, selecciona la casilla de verificación Clúster privado.

  8. Para crear una instancia principal a la que se pueda acceder desde los rangos de IP externa autorizados, deja seleccionada la casilla de verificación Acceder a la instancia principal mediante su dirección IP externa.

  9. Configura el rango de IP de instancia principal como 172.16.0.0/28.

  10. Deja seleccionada la casilla de verificación Habilitar redes autorizadas de instancia principal.

  11. Desmarca la casilla de verificación Habilitar panel de Kubernetes.

  12. Desmarca la casilla de verificación Emitir certificado de cliente.

  13. Haz clic en Crear.

API

Especifica el campo privateClusterConfig en el recurso de API Cluster:

{
  "name": "private-cluster-1",
  ...
  "ipAllocationPolicy": {
    "createSubnetwork": true,
  },
  ...
    "privateClusterConfig" {
      "enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
      "enablePrivateEndpoint": boolean # false creates a cluster master with a publicly-reachable endpoint
      "masterIpv4CidrBlock": string # CIDR block for the cluster master
      "privateEndpoint": string # Output only
      "publicEndpoint": string # Output only
  }
}

En este punto, estas son las únicas direcciones IP que tienen acceso a la instancia principal del clúster:

  • El rango principal de my-subnet-1
  • El rango secundario que se usa para los pods

Supongamos que tienes un grupo de máquinas fuera de tu red de VPC que tienen direcciones en el rango 203.0.113.0/29. Puedes autorizar a esas máquinas para que tengan acceso al extremo público si ingresas este comando:

gcloud container clusters update private-cluster-1 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

Ahora, estas son las únicas direcciones IP que tienen acceso a la instancia principal del clúster:

  • El rango principal de my-subnet-1
  • El rango secundario que se usa para los pods
  • Los rangos de direcciones autorizados, por ejemplo, 203.0.113.0/29

Usa una subred personalizada

En esta sección, debes crear un clúster privado llamado private-cluster-2. Debes crear una red, my-net-0. Debes crear una subred, my-subnet-2, con rango primario 192.168.0.0/20, para tus nodos de clúster. Tu subred tiene dos rangos de direcciones secundarios: my-pods-1 para las direcciones IP de pod y my-services-1 para las direcciones IP de servicio.

gcloud

Crear una red

Primero, crea una red para el clúster. El siguiente comando crea una red, my-net-0:

gcloud compute networks create my-net-0 \
    --subnet-mode custom

Crea una subred y rangos secundarios

Luego, crea una subred, my-subnet-2, en la red my-net-0, con rangos secundarios my-pods-2 para pods y my-services-2 para servicios:

gcloud compute networks subnets create my-subnet-2 \
    --network my-net-0\
    --region us-central1 \
    --range 192.168.0.0/20 \
    --secondary-range my-pods-2=10.4.0.0/14,my-services-2=10.0.32.0/20 \
    --enable-private-ip-google-access

Crea un clúster privado

Ahora, crea un clúster privado, private-cluster-1, con la red, la subred y los rangos secundarios que creaste.

gcloud container clusters create private-cluster-1 \
    --zone us-central1-c \
    --enable-master-authorized-networks \
    --network my-net-0 \
    --subnetwork my-subnet-2 \
    --cluster-secondary-range-name my-pods-2 \
    --services-secondary-range-name my-services-2 \
    --enable-private-nodes \
    --enable-ip-alias \
    --master-ipv4-cidr 172.16.0.16/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

Console

Crea una red, subred y rangos secundarios

  1. Visita la página de redes de VPC en Cloud Console.

    Ir a la página Redes de VPC

  2. Haz clic en Crear red de VPC.

  3. Desde Nombre ingresa my-net-0.

  4. Asegúrate de que el Modo de creación de subred esté configurado en Personalizado.

  5. Desde Subred nueva, en Nombre, ingresa my-subnet-2.

  6. En el menú desplegable de Región, selecciona la región que desees.

  7. En Rango de direcciones IP, ingresa 192.168.0.0/20.

  8. Haz clic en Crear rango de IP secundario. En Nombre de rango de subred, ingresa my-services-1 y, en Rango de IP secundario , ingresa 10.0.32.0/20.

  9. Haz clic en Agregar rango de IP. En Nombre de rango de subred, ingresa my-pods-1 y, en Rango de IP secundario, ingresa 10.4.0.0/14.

  10. En Acceso privado a Google, haz clic en Activar.

  11. Haz clic en Listo.

  12. Haz clic en Crear.

Crear un clúster privado

Crea un clúster privado que use la subred:

  1. Visita el menú de GKE en Cloud Console.

    Visita el menú de GKE.

  2. Haz clic en Crear clúster.

  3. Elige la plantilla Clúster estándar o elige una plantilla adecuada para tu carga de trabajo.

  4. En Nombre, ingresa private-cluster-2.

  5. Haz clic en Disponibilidad, herramientas de redes, seguridad y características adicionales en la parte inferior del menú.

  6. En Nativo de la VPC, deja seleccionada la casilla de verificación Habilitar nativo de la VPC (con IP de alias).

  7. En el menú desplegable Red, selecciona my-net-1.

  8. En el menú desplegable de Subred del nodo, selecciona my-subnet-2.

  9. Desactiva la casilla de verificación Crear rangos secundarios automáticamente.

  10. En el menú desplegable de Rango de CIDR secundario de pods, selecciona my-pods-1.

  11. En el menú desplegable de Rango de CIDR secundario de servicios, selecciona my-services-1.

  12. En Seguridad de red, selecciona la casilla de verificación Clúster privado.

  13. Configura el rango de IP de instancia principal como 172.16.0.16/28.

  14. Deja seleccionada la casilla de verificación Habilitar redes autorizadas de instancia principal.

  15. Desmarca la casilla de verificación Habilitar panel de Kubernetes.

  16. Desmarca la casilla de verificación Emitir certificado de cliente.

  17. Haz clic en Crear.

En este punto, estas son las únicas direcciones IP que tienen acceso a la instancia principal del clúster:

  • El rango principal de my-subnet-2
  • El rango secundario de my-pods-1

Supongamos que tienes un grupo de máquinas fuera de my-net-1, que tienen direcciones en el rango 203.0.113.0/29. Puedes autorizar a esas máquinas para que tengan acceso al extremo público si ingresas este comando:

gcloud container clusters update private-cluster-1 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

En este punto, estas son las únicas direcciones IP que tienen acceso a la instancia principal del clúster:

  • El rango principal de my-subnet-2
  • El rango secundario de my-pods-1
  • Los rangos de direcciones autorizados, por ejemplo, 203.0.113.0/29

Usa Cloud Shell para acceder a un clúster privado

El clúster privado que creaste en el ejercicio anterior, private-cluster-1, cuenta con un extremo público y tiene habilitadas las redes autorizadas de instancia principal. Si deseas usar Cloud Shell para acceder al clúster, debes agregar la dirección IP pública de Cloud Shell a la lista de redes autorizadas de instancia principal del clúster.

Para ello, sigue estos pasos:

  1. En la ventana de línea de comandos de Cloud Shell, usa dig para encontrar la dirección IP externa de tu Cloud Shell:

    dig +short myip.opendns.com @resolver1.opendns.com
    
  2. Agrega la dirección externa de Cloud Shell a la lista del clúster de redes autorizadas de instancia principal:

    gcloud container clusters update private-cluster-1 \
        --zone us-central1-c \
        --enable-master-authorized-networks \
        --master-authorized-networks [EXISTING_AUTH_NETS],[SHELL_IP]/32
    

    En el ejemplo anterior, se ilustra lo siguiente:

    • [EXISTING_AUTH_NETS] es la lista existente de redes autorizadas de instancia principal. Para encontrar las redes autorizadas de instancia principal, ve a la consola o ejecuta el siguiente comando: gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])".
    • [SHELL_IP] es la dirección IP externa de tu Cloud Shell.
  3. Obtén credenciales para que puedas usar kubectl a fin de acceder al clúster:

    gcloud container clusters get-credentials private-cluster-1 \
        --zone us-central1-a \
        --project [PROJECT_ID]
    

    en el que [PROJECT_ID] es el ID del proyecto.

Ahora puedes usar kubectl, en Cloud Shell, para acceder a tu clúster privado. Por ejemplo:

kubectl get nodes

Crea un clúster privado con acceso ilimitado al extremo público

En esta sección, crearás un clúster privado donde cualquier dirección IP pueda acceder a la instancia principal.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters create private-cluster-2 \
    --create-subnetwork name=my-subnet-3 \
    --no-enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --enable-private-endpoint \
    --master-ipv4-cidr 172.16.0.32/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

En el ejemplo anterior, se ilustra lo siguiente:

  • --enable-master-authorized-networks especifica que el acceso al extremo público está restringido a los rangos de direcciones IP que autorices.
  • --create-subnetwork name=my-subnet-3 hace que GKE cree de forma automática una subred llamada my-subnet-3.
  • --enable-ip-alias hace que el clúster sea nativo de la VPC.
  • --enable-private-nodes indica que los nodos del clúster no tienen direcciones IP externas.
  • --master-ipv4-cidr 172.16.0.32/28 especifica un rango RFC 1918 para la instancia principal. Esta configuración es permanente para este clúster.

Console

Completa los pasos siguientes:

  1. Visita el menú de GKE en Google Cloud Console.

    Visita el menú de GKE.

  2. Haz clic en Crear clúster.

  3. Elige la plantilla Clúster estándar o elige una plantilla adecuada para tu carga de trabajo.

  4. En Nombre, ingresa private-cluster-2.

  5. Haz clic en Disponibilidad, herramientas de redes, seguridad y características adicionales en la parte inferior del menú.

  6. En Nativo de la VPC, selecciona la casilla de verificación Habilitar nativo de la VPC (con IP de alias). Deja el menú desplegable Red configurado como default y el menú desplegable Subred de nodo configurado como default. Esto hace que GKE genere una subred para el clúster.

  7. En Seguridad de red, selecciona la casilla de verificación Clúster privado.

  8. Borra la casilla de verificación Acceder a la instancia principal mediante su dirección IP externa.

  9. Configura el rango de IP de instancia principal como 172.16.0.32/28.

  10. La casilla de verificación Habilitar redes autorizadas de la instancia principal se desmarca de forma automática.

  11. Desmarca la casilla de verificación Habilitar panel de Kubernetes.

  12. Desmarca la casilla de verificación Emitir certificado de cliente.

  13. Haz clic en Crear.

Otros parámetros de configuración del clúster privado

Además de los parámetros de configuración anteriores, puedes ejecutar clústeres privados con los siguientes parámetros.

Otorga acceso a Internet saliente a los nodos privados

Para proporcionar acceso a Internet saliente a tus nodos privados, puedes usar Cloud NAT o administrar tu propia puerta de enlace NAT.

Crea un clúster privado en una red de VPC compartida

Para obtener información sobre cómo crear un clúster privado en una red de VPC compartida, consulta la documentación de VPC compartida.

Enrutamiento entre VPC local y en clúster, y en clúster principal

Cuando creas un clúster privado de GKE con un extremo de instancia principal privada, la instancia principal del clúster es inaccesible desde la Internet pública, pero debe ser accesible para las herramientas del cliente, como kubectl. Para habilitar el tráfico entre la instancia principal del clúster y la red local, debe haber rutas entre la red local y la red de VPC de Google que aloja la instancia principal del clúster.

La VPC de Google exporta de forma automática la ruta al CIDR de la instancia principal a tu VPC, conectada a tu red local, mediante Cloud VPN o Cloud Interconnect. Sin embargo, la ruta a tu entorno local también debe exportarse desde tu VPC a la VPC de Google.

Para compartir las rutas, habilita la marca --export-custom-routes en el intercambio de tráfico entre tu VPC y la VPC de Google.

  1. Identifica el intercambio de tráfico entre la VPC de tu clúster y la VPC de Google:

    gcloud beta container clusters describe [CLUSTER-NAME]
    

    El resultado de este comando incluye el campo privateClusterConfig.peeringName del clúster. Este es el nombre del intercambio de tráfico entre tu clúster y la VPC de Google. Por ejemplo:

    privateClusterConfig:
    enablePrivateNodes: true
    masterIpv4CidrBlock: 172.16.1.0/28
    peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
    privateEndpoint: 172.16.1.2
    publicEndpoint: 34.68.128.12
    
  2. Habilita --export-custom-routes en el intercambio de tráfico:

    gcloud beta compute networks peerings update [PEERING] --network [NETWORK] \
       --export-custom-routes
    

    En el ejemplo anterior, [PEERING] es el valor de privateClusterConfig.peeringName, que se identifica en el paso anterior, y [NETWORK] es el nombre de tu VPC.

    Esta marca hace que [NETWORK] anuncie sus rutas a la VPC de Google donde se encuentra la instancia principal del clúster. En el paso siguiente, se explica cómo anunciar la ruta desde tu VPC a la VPC de Google a tu entorno local.

  3. De manera opcional, para habilitar la conectividad bidireccional, también se debe anunciar la ruta al CIDR de la instancia principal del clúster desde tu VPC al entorno local. Puedes hacerlo de dos maneras:

    • Técnica recomendada: Anuncia la ruta a la subred de la instancia principal como una ruta personalizada a través de eBGP desde Cloud Router. Consulta la página sobre cómo anunciar rangos de IP personalizados para obtener más información. Se recomienda esta técnica, porque las rutas anunciadas se retiran si eBGP no está disponible, lo que ayuda al tráfico de agujeros negros.

    • Aprovisiona una ruta estática en el enrutador local o el dispositivo perimetral hacia Google Cloud.

Verifica que la exportación de la ruta personalizada esté habilitada

Usa este comando para verificar que la opción --export-custom-routes esté habilitada en el intercambio de tráfico entre tu VPC y la VPC de Google:

gcloud beta compute networks peerings list

El resultado de este comando muestra una lista de los intercambios de tráfico de la red de Compute Engine. Busca el intercambio de tráfico (cuyo nombre descubriste en el paso uno del procedimiento anterior) y verifica que tu columna EXPORT_CUSTOM_ROUTES sea True y que la columna STATE sea ACTIVE.

Inhabilita la exportación de rutas personalizadas

Para inhabilitar la exportación de rutas personalizadas desde tu VPC, haz lo siguiente:

gcloud beta compute networks peerings update [PEERING] --network [NETWORK] --no-export-custom-routes

en el que [PEERING] es el valor de privateClusterConfig.peeringName, y [NETWORK] es el nombre de tu VPC. Para buscar el peeringName, consulta el primer paso de las instrucciones anteriores a fin de habilitar la exportación de rutas personalizadas.

Verifica que los nodos no tengan IP externas

Después de crear un clúster privado, verifica que los nodos del clúster no tengan direcciones IP externas.

gcloud

Ejecuta el siguiente comando para verificar que los nodos del clúster no tengan direcciones IP externas:

kubectl get nodes --output wide

La columna EXTERNAL-IP del resultado está vacía:

STATUS ... VERSION   EXTERNAL-IP  OS-IMAGE ...
Ready      v.8.7-gke.1                 Container-Optimized OS from Google
Ready      v1.8.7-gke.1                Container-Optimized OS from Google
Ready      v1.8.7-gke.1                Container-Optimized OS from Google

Console

Sigue estos pasos para verificar que los nodos del clúster no tengan direcciones IP externas:

  1. Visita el menú de GKE en Cloud Console.

    Visitar el menú de GKE.

  2. En la lista de clústeres, haz clic en el clúster que desees.

  3. En Grupo de nodos, haz clic en el nombre del grupo de instancias. Por ejemplo, gke-private-cluster-0-default-pool-5c5add1f-grp.

  4. En la lista de instancias, verifica que las instancias no tengan direcciones IP externas.

Cómo ver la subred y los rangos de direcciones secundarios del clúster

Después de crear el clúster privado, podrás ver la subred y los rangos de direcciones secundarios que tú o GKE aprovisionaron para el clúster.

gcloud

Agrega todas las subredes a la lista

Ejecuta el siguiente comando para agregar las subredes de la red del clúster a la lista:

gcloud compute networks subnets list --network [NETWORK]

en el que [NETWORK] es la red del clúster privado. Si creaste el clúster con una subred creada de forma automática, usa default.

En el resultado del comando, busca el nombre de la subred del clúster.

Visualiza la subred del clúster

Obtén información sobre la subred creada automáticamente:

gcloud compute networks subnets describe [SUBNET_NAME]

en el que [SUBNET_NAME] es el nombre de la subred.

En el resultado, se muestra el rango de direcciones principal para los nodos (el primer campo ipCidrRange) y los rangos secundarios destinados a pods y servicios (en secondaryIpRanges):

...
ipCidrRange: 10.0.0.0/22
kind: compute#subnetwork
name: gke-private-cluster-1-subnet-163e3c97
...
privateIpGoogleAccess: true
...
secondaryIpRanges:
- ipCidrRange: 10.40.0.0/14
  rangeName: gke-private-cluster-1-pods-163e3c97
- ipCidrRange: 10.0.16.0/20
  rangeName: gke-private-cluster-1-services-163e3c97
...

Console

  1. Visita la página de redes de VPC en Cloud Console.

    Ir a la página Redes de VPC

  2. Haz clic en el nombre de la subred. Por ejemplo, gke-private-cluster-0-subnet-163e3c97.

  3. En el Rango de direcciones IP, podrás ver el rango de direcciones principal de la subred. Este es el rango que se usa para los nodos.

  4. En Rangos de IP secundarios, podrás ver el rango de direcciones IP para los pods y servicios.

Visualiza los extremos del clúster privado

Puedes ver los extremos del clúster privado con la herramienta de línea de comandos de gcloud o Cloud Console.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters describe [CLUSTER_NAME]

En el resultado, se muestran los extremos privados y públicos:

...
privateClusterConfig:
enablePrivateEndpoint: true
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.0.32/28
privateEndpoint: 172.16.0.34
publicEndpoint: 35.239.154.67

Console

Completa los pasos siguientes:

  1. Visita el menú de GKE en Cloud Console.

    Visitar el menú de GKE.

  2. En la lista, haz clic en el clúster que desees.

  3. En la pestaña Detalles, en Clúster, busca el campo Extremo.

Extrae imágenes de contenedor desde un registro de imágenes

En un clúster privado, el entorno de ejecución del contenedor puede extraer imágenes de contenedor de Container Registry, pero no puede extraer imágenes de ningún otro registro de imágenes de contenedor en la Internet. Esto se debe a que los nodos de un clúster privado no tienen direcciones IP externas, por lo que no pueden comunicarse con servicios fuera de la red de Google, según la configuración predeterminada.

Los nodos de un clúster privado pueden comunicarse con los servicios de Google, como Container Registry, si se encuentran en una subred que tenga habilitado el Acceso privado a Google.

Los siguientes comandos crean una implementación que extrae una imagen de muestra de un repositorio de Container Registry que es propiedad de Google:

kubectl run hello-deployment --image gcr.io/google-samples/hello-app:2.0

Agrega reglas de firewall para casos prácticos específicos

En esta sección, se explica cómo agregar una regla de firewall a un clúster privado. De forma predeterminada, las reglas de firewall restringen la instancia principal del clúster para iniciar únicamente conexiones TCP a los nodos en los puertos 443 (HTTPS) y 10250 (kubelet). Para algunas características de Kubernetes, es posible que debas agregar reglas de firewall a fin de permitir el acceso a puertos adicionales. Por ejemplo, en Kubernetes 1.9 y versiones anteriores, kubectl top accede a heapster, que necesita una regla de firewall para permitir conexiones TCP en el puerto 8080. Para otorgar este acceso, puedes agregar reglas de firewall.

Agregar una regla de firewall permite el tráfico de la instancia principal del clúster a todos los puertos siguientes:

  • El puerto especificado de cada nodo (hostPort).
  • El puerto especificado de cada pod que se ejecuta en estos nodos.
  • El puerto especificado de cada servicio que se ejecuta en estos nodos

Para obtener información sobre las reglas de firewall, consulta Reglas de firewall en la documentación de Cloud Load Balancing.

Si deseas agregar una regla de firewall a un clúster privado, debes grabar el bloque CIDR de la instancia principal del clúster y el destino utilizado. Después de grabar esto, puedes crear la regla.

Paso 1. Visualiza el bloque CIDR de la instancia principal del clúster

El bloque CIDR de la instancia principal del clúster es necesario para agregar una regla de firewall.

gcloud

Ejecuta el siguiente comando:

gcloud container clusters describe [CLUSTER_NAME]

En el resultado del comando, toma nota del valor en el campo masterIpv4CidrBlock.

Console

  1. Visita el menú de GKE en Cloud Console.

    Visitar el menú de GKE.

  2. Selecciona el clúster que desees.

En la pestaña Detalles, en Clúster, anota el valor en el campo Rango de direcciones de la instancia principal.

Paso 2. Visualiza las reglas de firewall existentes

Debes especificar el destino (en este caso, los nodos de destino) que usan las reglas de firewall existentes del clúster.

gcloud

Ejecuta el siguiente comando:

gcloud compute firewall-rules list \
    --filter 'name~^gke-[CLUSTER_NAME]' \
    --format 'table(
        name,
        network,
        direction,
        sourceRanges.list():label=SRC_RANGES,
        allowed[].map().firewall_rule().list():label=ALLOW,
        targetTags.list():label=TARGET_TAGS
    )'

En el resultado del comando, anota el valor en el campo Destinos.

Console

Completa los pasos siguientes:

  1. Visita el menú de Reglas de firewall en Cloud Console.

    Visitar el menú de Reglas de firewall.

  2. Llena el cuadro Filtrar recursos con gke-[CLUSTER_NAME]

En los resultados, anota el valor en el campo Destinos.

Paso 3. Agrega una regla de firewall

gcloud

Ejecuta el siguiente comando:

gcloud compute firewall-rules create [FIREWALL_RULE_NAME] \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges [MASTER_CIDR_BLOCK] \
    --rules [PROTOCOL]:[PORT] \
    --target-tags [TARGET]

Donde:

  • [FIREWALL_RULE_NAME] es el nombre que eliges para la regla de firewall.
  • [MASTER_CIDR_BLOCK] es el bloque CIDR de la instancia principal del clúster que recopilaste antes.
  • [PROTOCOL]:[PORT] es el puerto deseado y su protocolo, tcp o udp.
  • [TARGET] es el valor de destino que recopilaste antes.

Console

Completa los pasos siguientes:

  1. Visita el menú de Reglas de firewall en Cloud Console.

    Visitar el menú Reglas de firewall.

  2. Haz clic en Crear regla de firewall.

  3. Llena el cuadro Nombre con el nombre que desees para la regla de firewall.

  4. En el menú desplegable de Red, selecciona la red correspondiente.

  5. En Dirección del tráfico, haz clic en Ingress.

  6. En Acción en caso de coincidencia, haz clic en Permitir.

  7. En el menú desplegable de Destinos, selecciona Etiquetas de destino especificadas.

  8. Llena el cuadro Etiquetas de destino con el valor del destino que recopilaste anteriormente.

  9. En el menú desplegable de Filtro de fuente, selecciona rangos de IP.

  10. Llena el cuadro rangos de IP fuente con el bloque CIDR de la instancia principal del clúster que recopilaste anteriormente.

  11. En Protocolos y puertos, haz clic en Protocolos y puertos especificados, marca la casilla del protocolo correspondiente (TCP o UDP) y llena el cuadro con el puerto deseado.

  12. Haz clic en Crear.

Protege un clúster privado con los Controles del servicio de VPC

Para proteger aún más tus clústeres privados de GKE, puedes usar los Controles del servicio de VPC.

Los Controles del servicio de VPC brindan seguridad adicional para tus clústeres privados de GKE a fin de mitigar el riesgo de robo de datos. Con los Controles del servicio de VPC, puedes agregar proyectos a perímetros de servicio que protejan los recursos y servicios de las solicitudes que se originan fuera del perímetro.

Para obtener más información sobre los perímetros de servicio, consulta la página de configuración del perímetro de servicio de la documentación de Controles del servicio de VPC.

Si usas Container Registry con tu clúster privado de GKE, se requieren pasos adicionales para usar ese clúster privado con los Controles del servicio de VPC. Si deseas obtener más información, consulta la página sobre cómo configurar Container Registry para clústeres privados de GKE.

Limpia

Después de completar las tareas de esta página, sigue estos pasos para quitar los recursos a continuación y evitar que se hagan cargos no deseados a tu cuenta:

Borrar los clústeres

gcloud

gcloud container clusters delete -q private-cluster-0 private-cluster-1

Console

  1. Visita el menú de GKE en Cloud Console.

    Visitar el menú de GKE.

  2. Selecciona cada clúster.

  3. Haz clic en Borrar.

Borrar la red

gcloud

gcloud compute networks delete net-0

Console

  1. Ve a la página de redes de VPC en Cloud Console.

    Ir a la página Redes de VPC

  2. En la lista de redes, en net-0, haz clic en el ícono de la papelera.

  3. Junto a cada subred, haz clic en el ícono de la papelera.

Requisitos, restricciones y limitaciones

Los clústeres privados tienen los siguientes requisitos:

Los clústeres privados tienen las siguientes restricciones:

  • No puedes convertir un clúster público existente en un clúster privado.
  • No puedes usar un rango de IP de instancia principal del clúster, nodo, pod o servicio que se superponga con 172.17.0.0/16 si ejecutas un clúster con una versión inferior a 1.14.4.
  • Un clúster privado deja de funcionar si se borran el intercambio de tráfico de VPC entre la instancia principal y los nodos del clúster, las reglas de firewall que permiten la entrada de tráfico desde la instancia principal del clúster hasta los nodos en el puerto 10250 o la ruta predeterminada a la puerta de enlace predeterminada de Internet. Para que un clúster privado vuelva a funcionar después de borrar la ruta predeterminada, debes aprovisionar el VIP restringido de manera estática.
  • Puedes agregar hasta 50 redes autorizadas (bloques CIDR incluidos en la lista blanca) a un proyecto. Para obtener más información, consulta Agrega una red autorizada a un clúster existente.

Los clústeres privados tienen las siguientes limitaciones:

  • Cada clúster privado que creas usa un intercambio de tráfico entre redes de VPC exclusivo. Cada red de VPC puede intercambiar tráfico con otras 25 redes de VPC.
  • El tamaño del bloque RFC 1918 de la instancia principal del clúster debe ser de /28.
  • Si bien GKE puede detectar la superposición con el bloque de direcciones de instancia principal del clúster, no puede detectar la superposición dentro de una red de VPC compartida.
  • Los nodos de un clúster privado no tienen acceso saliente a la Internet pública y tienen acceso limitado a los servicios y las API de Google.
  • Solo se puede acceder a la dirección IP privada de la instancia principal en un clúster regional desde subredes dentro de la misma región o desde entornos locales conectados a la misma región.

Soluciona problemas

En las siguientes secciones, se explica cómo resolver problemas comunes relacionados con los clústeres privados.

El clúster se superpone con el intercambio de tráfico

Síntomas
Si intentas crear un clúster privado, se muestra un error, como Google Compute Engine: An IP range in the peer network overlaps with an IP range in an active peer of the local network..
Causas posibles
Elegiste un CIDR de instancia principal superpuesto.
Resolución
Borra y vuelve a crear el clúster con otro CIDR de instancia principal.

No se puede acceder al clúster

Síntomas
Después de crear un clúster privado, si se intenta ejecutar los comandos kubectl en el clúster, se muestra un error, como Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out o Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Causas posibles
kubectl no puede comunicarse con la instancia principal del clúster.
Resolución
Debes agregar redes autorizadas para que el clúster incluya en la lista blanca las direcciones IP de tu red.

No se puede crear el clúster debido a una marca omitida

Síntomas
gcloud container clusters create muestra un error, como Cannot specify --enable-private-endpoint without --enable-private-nodes.
Causas posibles
No especificaste una marca necesaria.
Resolución
Asegúrate de que especificaste las marcas necesarias. No puedes habilitar un extremo privado para la instancia principal del clúster sin habilitar los nodos privados.

No se puede crear el clúster debido a la superposición del bloque CIDR de IPv4 de la instancia principal

Síntomas
gcloud container clusters create muestra un error, como The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network 10.128.0.0/20.
Causas posibles
Especificaste un bloque CIDR de instancia principal que se superpone con una subred existente en tu VPC.
Resolución
Especifica un bloque CIDR para que --master-ipv4-cidr no se superponga con una subred existente.

No se puede crear la subred

Síntomas
Cuando intentas crear un clúster privado con una subred automática o crear una subred personalizada, puedes encontrar el siguiente error: An IP range in the peer network overlaps with an IP range in one of the active peers of the local network.
Causas posibles
El rango de CIDR de instancia principal que especificaste se superpone con otro rango de IP en el clúster. Esto también puede ocurrir si borraste hace poco un clúster privado y ahora intentas crear uno nuevo con el mismo CIDR de instancia principal.
Resolución
Usa otro rango de CIDR.

No se puede extraer la imagen de Docker Hub público

Síntomas
Un pod que se ejecuta en tu clúster muestra una advertencia en kubectl describe, como Failed to pull image: rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Causas posibles
Los nodos de un clúster privado no tienen acceso saliente a la Internet pública. Tienen acceso limitado a los servicios y API de Google, incluido Container Registry.
Solución
No puedes recuperar imágenes directamente desde Docker Hub. En su lugar, utiliza imágenes alojadas en Container Registry. Ten en cuenta que, aunque se puede acceder a la duplicación de Docker Hub de Container Registry desde un clúster privado, no se debe depender exclusivamente de ella. La duplicación es solo una caché, por lo que las imágenes se quitan periódicamente y un clúster privado no puede recurrir a Docker Hub.

Próximos pasos