En esta página, se explica cómo crear un clúster privado de Google Kubernetes Engine (GKE), que es un tipo de clúster nativo de la VPC. En un clúster privado, los nodos solo tienen direcciones IP internas, lo que significa que los nodos y los Pods están aislados de la Internet de forma predeterminada.
Las direcciones IP internas de los nodos provienen del rango de direcciones IP principal de la subred que eliges para el clúster. Las direcciones IP de los Pods y de los servicios provienen de dos rangos de direcciones IP secundarios de esa misma subred. Si deseas obtener más información, consulta Rangos de IP para clústeres nativos de la VPC.
La versión 1.14.2 y posteriores de GKE admiten cualquier rango de direcciones IP internas, incluidos los rangos privados (RFC 1918 y otros rangos privados) y los rangos de direcciones IP públicas utilizados de forma privada. Consulta la documentación de VPC para obtener una lista de los rangos de direcciones IP internas válidos.
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.
Antes de comenzar, asegúrate de haber realizado las siguientes tareas:
- Habilita la API de Kubernetes Engine de Google. Habilitar la API de Kubernetes Engine de Google
- 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.
Asegúrate de tener el permiso correcto para crear clústeres. Como mínimo, debes ser un administrador de clústeres de Kubernetes Engine.
Asegúrate de tener una ruta a la puerta de enlace predeterminada de Internet.
Crea un clúster privado sin acceso de clientes al extremo público
En esta sección, crearás los siguientes recursos:
- Un clúster privado llamado
private-cluster-0
que tiene nodos privados y que no tiene acceso de clientes al extremo público. - Una red llamada
my-net-0
. - Una subred llamada
my-subnet-0
.
Console
Crea una red y una subred
Ve a la página Redes de VPC en la consola de Google Cloud.
Haga clic en add_box Crear red de VPC.
En Nombre, ingresa
my-net-0
.En Modo de creación de subred, selecciona Personalizado.
Dentro de la sección Subred nueva, en Nombre, ingresa
my-subnet-0
.En la lista Región, selecciona la región que deseas.
En Rango de direcciones IP, ingresa
10.2.204.0/22
.Configura el Acceso privado a Google como Activado.
Haga clic en Listo.
Haz clic en Crear.
Cree un clúster privado
Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
Haz clic en
Crear y, luego, en la sección Standard o Autopilot, haz clic en Configurar.En Nombre, especifica
private-cluster-0
.En el panel de navegación, haga clic en Herramientas de redes.
En la lista Red, selecciona my-net-0.
En la lista Subred del nodo, selecciona my-subnet-0.
Selecciona el botón de selección Clúster privado.
Desmarca la casilla de verificación Permitir el acceso al plano de control mediante su dirección IP externa.
(Opcional para Autopilot): Configura el Rango de IP del plano de control como
172.16.0.32/28
.Haz clic en Crear.
gcloud
Para los clústeres Autopilot, ejecuta el siguiente comando:
gcloud container clusters create-auto private-cluster-0 \ --create-subnetwork name=my-subnet-0 \ --enable-master-authorized-networks \ --enable-private-nodes \ --enable-private-endpoint
Para los clústeres estándar, 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
Donde:
--create-subnetwork name=my-subnet-0
hace que GKE cree de forma automática una subred llamadamy-subnet-0
.--enable-master-authorized-networks
especifica que el acceso al extremo público está restringido a los rangos de direcciones IP que autorices.
--enable-ip-alias
hace que el clúster sea nativo de VPC (no es necesario para Autopilot).
--enable-private-nodes
indica que los nodos del clúster no tienen direcciones IP externas.--enable-private-endpoint
indica que el clúster se administra mediante la dirección IP interna del extremo de la API del plano de control.
--master-ipv4-cidr 172.16.0.32/28
especifica un rango de direcciones IP internas para el plano de control (opcional para Autopilot). Esta configuración es permanente para este clúster y debe ser única dentro de la VPC. Se admite el uso de direcciones IP internas que no sean RFC 1918.
API
Para crear un clúster con un plano de control 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 al plano de control:
- 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 del plano de control.
Si deseas acceder al plano de control desde 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
Si deseas autorizar a la VM para que acceda al plano de control, ejecuta el siguiente 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 llamado private-cluster-1
en el que GKE generará de forma automática una subred para los 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.
Puedes usar Google Cloud CLI o la API de GKE.
gcloud
Para los clústeres Autopilot, ejecuta el siguiente comando:
gcloud container clusters create-auto private-cluster-1 \ --create-subnetwork name=my-subnet-1 \ --enable-master-authorized-networks \ --enable-private-nodes
Para los clústeres estándar, 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
Donde:
--create-subnetwork name=my-subnet-1
hace que GKE cree de forma automática una subred llamadamy-subnet-1
.--enable-master-authorized-networks
especifica que el acceso al extremo público está restringido a los rangos de direcciones IP que autorices.
--enable-ip-alias
hace que el clúster sea nativo de VPC (no es necesario para Autopilot).
--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 de direcciones IP internas para el plano de control (opcional para Autopilot). Esta configuración es permanente para este clúster y debe ser única dentro de la VPC. Se admite el uso de direcciones IP internas que no sean RFC 1918.
API
Especifica el campo privateClusterConfig
en el recurso de la API de Cluster
:
{
"name": "private-cluster-1",
...
"ipAllocationPolicy": {
"createSubnetwork": true,
},
...
"privateClusterConfig" {
"enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
"enablePrivateEndpoint": boolean # false creates a cluster control plane with a publicly-reachable endpoint
"masterIpv4CidrBlock": string # CIDR block for the cluster control plane
"privateEndpoint": string # Output only
"publicEndpoint": string # Output only
}
}
En este punto, estas son las únicas direcciones IP que tienen acceso al plano de control 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
. Si deseas autorizar a esas máquinas a que accedan al extremo público, ejecuta 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 al plano de control:
- 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, crearás los siguientes recursos:
- Un clúster privado llamado
private-cluster-2
. - Una red llamada
my-net-2
. - Una subred llamada
my-subnet-2
, con rango primario192.168.0.0/20
, para tus nodos de clúster. Tu subred tiene los siguientes rangos de direcciones secundarios:my-pods
para las direcciones IP del pod.my-services
para las direcciones IP de servicio.
Console
Crea una red, una subred y rangos secundarios
Ve a la página Redes de VPC en la consola de Google Cloud.
Haga clic en add_box Crear red de VPC.
En Nombre, ingresa
my-net-2
.En Modo de creación de subred, selecciona Personalizado.
Dentro de la sección Subred nueva, en Nombre, ingresa
my-subnet-2
.En la lista Región, selecciona la región que deseas.
En Rango de direcciones IP, ingresa
192.168.0.0/20
.Haz clic en Crear rango de IP secundario. En Nombre de rango de subred, ingresa
my-services
y, en Rango de IP secundario , ingresa10.0.32.0/20
.Haz clic en Agregar rango de IP. En Nombre de rango de subred, ingresa
my-pods
y, en Rango de IP secundario, ingresa10.4.0.0/14
.Configura el Acceso privado a Google como Activado.
Haga clic en Listo.
Haz clic en Crear.
Cree un clúster privado
Crea un clúster privado que use tu subred:
Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
Haz clic en
Crear y, luego, en la sección Standard o Autopilot, haz clic en Configurar.En Nombre, ingresa
private-cluster-2
.En el panel de navegación, haz clic en Herramientas de redes.
Selecciona el botón de selección Clúster privado.
Para crear un plano de control accesible desde los rangos de IP externos autorizados, mantén seleccionada la casilla de verificación Permitir el acceso al plano con su dirección IP externa.
(Opcional para Autopilot): Configura el Rango de IP del plano de control como
172.16.0.16/28
.En la lista Red, selecciona my-net-2.
En la lista Subred del nodo, selecciona my-subnet-2.
Desmarca la casilla de verificación Crear rangos secundarios automáticamente.
En la lista Rango de CIDR secundario del pod, selecciona my-pods.
En la lista Rango de CIDR secundario de Services, selecciona my-services.
Selecciona la casilla de verificación Habilitar redes autorizadas del plano de control.
Haz clic en Crear.
gcloud
Crea una red
Primero, crea una red para el clúster. El siguiente comando crea una red, my-net-2
:
gcloud compute networks create my-net-2 \
--subnet-mode custom
Crea una subred y rangos secundarios
Luego, crea una subred, my-subnet-2
, en la red my-net-2
, con rangos secundarios my-pods
para pods y my-services
para servicios:
gcloud compute networks subnets create my-subnet-2 \
--network my-net-2 \
--range 192.168.0.0/20 \
--secondary-range my-pods=10.4.0.0/14,my-services=10.0.32.0/20 \
--enable-private-ip-google-access
Cree un clúster privado
Ahora, crea un clúster privado, private-cluster-2
, con la red, la subred y los rangos secundarios que creaste.
Para los clústeres Autopilot, ejecuta el siguiente comando:
gcloud container clusters create-auto private-cluster-2 \ --enable-master-authorized-networks \ --network my-net-2 \ --subnetwork my-subnet-2 \ --cluster-secondary-range-name my-pods \ --services-secondary-range-name my-services \ --enable-private-nodes
Para los clústeres estándar, ejecuta el siguiente comando:
gcloud container clusters create private-cluster-2 \ --enable-master-authorized-networks \ --network my-net-2 \ --subnetwork my-subnet-2 \ --cluster-secondary-range-name my-pods \ --services-secondary-range-name my-services \ --enable-private-nodes \ --enable-ip-alias \ --master-ipv4-cidr 172.16.0.16/28 \ --no-enable-basic-auth \ --no-issue-client-certificate
En este punto, estas son las únicas direcciones IP que tienen acceso al plano de control:
- El rango principal de
my-subnet-2
- El rango secundario de
my-pods
Supongamos que tienes un grupo de máquinas fuera de my-net-2
, que tienen direcciones en el rango 203.0.113.0/29
. Si deseas autorizar a esas máquinas a que accedan al extremo público, ejecuta este comando:
gcloud container clusters update private-cluster-2 \
--enable-master-authorized-networks \
--master-authorized-networks 203.0.113.0/29
En este punto, estas son las únicas direcciones IP que tienen acceso al plano de control:
- El rango principal de
my-subnet-2
- El rango secundario de
my-pods
- 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 la sección Usa una subred generada de forma automática, private-cluster-1
, tiene un extremo público y tiene habilitadas las redes autorizadas. Si deseas usar Cloud Shell para acceder al clúster, debes agregar la dirección IP externa de Cloud Shell a la lista de redes autorizadas del clúster.
Para ello, siga estos pasos:
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
Agrega la dirección externa de Cloud Shell a la lista de redes autorizadas del clúster:
gcloud container clusters update private-cluster-1 \ --enable-master-authorized-networks \ --master-authorized-networks EXISTING_AUTH_NETS,SHELL_IP/32
Reemplaza lo siguiente:
EXISTING_AUTH_NETS
: Son las direcciones IP de tu lista existente de redes autorizadas. Puedes encontrar las redes autorizadas en Console o mediante la ejecución del 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.
Obtén credenciales de modo que puedas usar
kubectl
para acceder al clúster:gcloud container clusters get-credentials private-cluster-1 \ --project=PROJECT_ID \ --internal-ip
Reemplaza
PROJECT_ID
con el ID del proyecto.Usa
kubectl
en Cloud Shell para acceder al clúster privado:kubectl get nodes
El resultado es similar a este:
NAME STATUS ROLES AGE VERSION gke-private-cluster-1-default-pool-7d914212-18jv Ready <none> 104m v1.21.5-gke.1302 gke-private-cluster-1-default-pool-7d914212-3d9p Ready <none> 104m v1.21.5-gke.1302 gke-private-cluster-1-default-pool-7d914212-wgqf Ready <none> 104m v1.21.5-gke.1302
Crea un clúster privado con acceso ilimitado al extremo público
En esta sección, crearás un clúster privado en el que cualquier dirección IP pueda acceder al plano de control.
Console
Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
Haz clic en
Crear y, luego, en la sección Standard o Autopilot, haz clic en Configurar.En Nombre, ingresa
private-cluster-3
.En el panel de navegación, haga clic en Herramientas de redes.
Selecciona la opción Clúster privado.
Deja seleccionada la casilla de verificación Permitir el acceso al plano de control mediante su dirección IP externa.
(Opcional para Autopilot): Configura el Rango de IP del plano de control como
172.16.0.32/28
.Deja la Red y la Subred del nodo establecidas en
default
. Esto hace que GKE genere una subred para el clúster.Desmarca la casilla de verificación Habilitar redes autorizadas del plano de control.
Haz clic en Crear.
gcloud
Para los clústeres Autopilot, ejecuta el siguiente comando:
gcloud container clusters create-auto private-cluster-3 \ --create-subnetwork name=my-subnet-3 \ --no-enable-master-authorized-networks \ --enable-private-nodes
Para los clústeres estándar, ejecuta el siguiente comando:
gcloud container clusters create private-cluster-3 \ --create-subnetwork name=my-subnet-3 \ --no-enable-master-authorized-networks \ --enable-ip-alias \ --enable-private-nodes \ --master-ipv4-cidr 172.16.0.32/28
Donde:
--create-subnetwork name=my-subnet-3
hace que GKE cree de forma automática una subred llamadamy-subnet-3
.--no-enable-master-authorized-networks
inhabilita las redes autorizadas para el clúster.
--enable-ip-alias
hace que el clúster sea nativo de VPC (no es necesario para Autopilot).
--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 de direcciones IP internas para el plano de control (opcional para Autopilot). Esta configuración es permanente para este clúster y debe ser única dentro de la VPC. Se admite el uso de direcciones IP internas que no sean RFC 1918.
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
Si deseas proporcionar acceso a Internet saliente a los nodos privados, como para extraer imágenes de un registro externo, usa Cloud NAT para crear y configurar un Cloud Router. Cloud NAT permite que los clústeres privados establezcan conexiones salientes a través de Internet para enviar y recibir paquetes.
El Cloud Router permite que todos los nodos de la región usen Cloud NAT para todos los rangos de IP de alias y principales. También asigna de forma automática las direcciones IP externas de la puerta de enlace NAT.
Para obtener instrucciones sobre cómo crear y configurar un Cloud Router, consulta Crea una configuración de Cloud NAT con Cloud Router en la documentación de Cloud NAT.
Crea un clúster privado en una red de VPC compartida
Para aprender a crear un clúster privado en una red de VPC compartida, consulta Crea un clúster privado en una VPC compartida.
Implementa una aplicación de contenedor de Windows Server en un clúster privado
Para obtener información sobre cómo implementar una aplicación de contenedor de Windows Server en un clúster privado, consulta la documentación del grupo de nodos de Windows.
Accede al extremo privado del plano de control de forma global
El balanceador de cargas de red de transferencia interno implementa el extremo privado del plano de control en la red de VPC del plano de control. Los clientes internos o conectados mediante túneles de Cloud VPN y adjuntos de VLAN de Cloud Interconnect pueden acceder a los balanceadores de cargas de red de transferencia internos.
De forma predeterminada, estos clientes deben estar ubicados en la misma región que el balanceador de cargas.
Cuando habilitas el acceso global del plano de control, se puede acceder al balanceador de cargas de red de transferencia interno de forma global: las VM del cliente y los sistemas locales pueden conectarse al extremo privado del plano de control, sujetos a la configuración de las redes autorizadas de cualquier región.
Para obtener más información sobre los balanceadores de cargas de red de transferencia internos y el acceso global, consulta Balanceadores de cargas internos y redes conectadas.
Habilita el acceso global al extremo privado del plano de control
De forma predeterminada, el acceso global no está habilitado para el extremo privado del plano de control cuando creas un clúster privado. Para habilitar el acceso global al plano de control, usa las siguientes herramientas según el modo del clúster:
- Para los clústeres Standard, puedes usar
Google Cloud CLI
o la consola de Google Cloud.
- Para los clústeres de Autopilot, puedes usar el recurso
google_container_cluster
de Terraform.
Console
Para crear un clúster privado nuevo con el acceso global al plano de control habilitado, sigue estos pasos:
Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
Haz clic en
Crear y, luego, en la sección Standard o Autopilot, haz clic en Configurar.Escribe un Nombre.
En el panel de navegación, haga clic en Herramientas de redes.
Selecciona Clúster privado.
Selecciona la casilla de verificación Habilitar el acceso global al plano de control.
Configura otros campos como desees.
Haz clic en Crear.
Para habilitar el acceso global al plano de control de un clúster privado existente, sigue estos pasos:
Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
Junto al clúster que deseas editar, haz clic en more_vert Acciones y, luego, en edit Editar.
En la sección Herramientas de redes, junto a Acceso global al plano de control, haz clic en edit Editar.
En el cuadro de diálogo Editar el acceso global al plano de control, selecciona la casilla de verificación Habilitar el acceso global al plano de control.
Haz clic en Guardar cambios.
gcloud
Agrega la marca --enable-master-global-access
para crear un clúster privado con acceso global al extremo privado habilitado del plano de control:
gcloud container clusters create CLUSTER_NAME \
--enable-private-nodes \
--enable-master-global-access
También puedes habilitar el acceso global al extremo privado del plano de control para un clúster privado existente:
gcloud container clusters update CLUSTER_NAME \
--enable-master-global-access
Verifica el acceso global al extremo del plano de control
Para verificar que el acceso global al extremo privado del plano de control esté habilitado, ejecuta el siguiente comando y observa su resultado.
gcloud container clusters describe CLUSTER_NAME
En el resultado, se incluye una sección privateClusterConfig
en la que puedes ver el estado de masterGlobalAccessConfig
.
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
masterGlobalAccessConfig:
enabled: true
Accede al extremo privado del plano de control desde otras redes
Cuando creas un clúster privado de GKE e inhabilitas el extremo público del plano de control, debes administrar el clúster con herramientas como kubectl
mediante el extremo privado del plano de control. Puedes acceder al extremo privado del plano de control del clúster desde otra red, incluidas las siguientes opciones:
- Una red local que está conectada a la red de VPC del clúster mediante túneles de Cloud VPN o adjuntos de VLAN de Cloud Interconnect
- Otra red de VPC que esté conectada a la red de VPC del clúster mediante túneles de Cloud VPN
En el siguiente diagrama, se muestra el enrutamiento entre los nodos de una red local y del plano de control de GKE:
Para permitir que los sistemas de otra red se conecten al extremo privado del plano de control de un clúster, completa los siguientes requisitos:
Identifica y registra la información de red relevante para el clúster y el extremo privado del plano de control.
gcloud container clusters describe CLUSTER_NAME \ --location=COMPUTE_LOCATION \ --format="yaml(network, privateClusterConfig)"
Reemplaza lo siguiente:
CLUSTER_NAME
: el nombre del clúster.COMPUTE_LOCATION
: la ubicación de Compute Engine del clúster
En el resultado del comando, identifica y registra la siguiente información para usarla en los siguientes pasos:
network
: es el nombre o el URI de la red de VPC del clúster.privateEndpoint
: es la dirección IPv4 del extremo privado del plano de control o el rango de CIDR de IPv4 adjunto (masterIpv4CidrBlock
).peeringName
: es el nombre de la conexión de intercambio de tráfico entre redes de VPC que se usa para conectar la red de VPC del clúster a la red de VPC del plano de control.
El resultado es similar a este:
network: cluster-network privateClusterConfig: enablePrivateNodes: true masterGlobalAccessConfig: enabled: true masterIpv4CidrBlock: 172.16.1.0/28 peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer privateEndpoint: 172.16.1.2 publicEndpoint: 34.68.128.12
Considera habilitar el acceso global del extremo privado del plano de control para permitir que los paquetes ingresen desde cualquier región en la red de VPC del clúster. Habilitar el acceso global al extremo del plano de control te permite conectarte al extremo privado mediante túneles de Cloud VPN o adjuntos de VLAN de Cloud Interconnect ubicados en cualquier región, no solo en la región del clúster.
Crea una ruta para la dirección IP
privateEndpoint
o el rango de direcciones IPmasterIpv4CidrBlock
en la otra red. Debido a que la dirección IP del extremo privado del plano de control siempre se ajusta al rango de direcciones IPv4masterIpv4CidrBlock
, lo que crea una ruta para la dirección IPprivateEndpoint
o su rango delimitador proporciona una ruta para los paquetes desde la otra red al extremo privado del plano de control si se cumplen las siguientes condiciones:La otra red se conecta a la red de VPC del clúster mediante los adjuntos de VLAN de Cloud Interconnect o los túneles de Cloud VPN que usan rutas dinámicas (BGP): Usa un anuncio de ruta personalizado de Cloud Router. Para obtener más información, consulta Cómo anunciar rangos de IP personalizados en la documentación de Cloud Router.
La otra red se conecta a la red de VPC del clúster mediante túneles de VPN clásica que no usan rutas dinámicas: debes configurar una ruta estática en la otra red.
Configura la red de VPC del clúster para exportar sus rutas personalizadas en la relación de intercambio de tráfico a la red de VPC del plano de control. Google Cloud siempre configura la red de VPC del plano de control para importar rutas personalizadas desde la red de VPC del clúster. En este paso, se proporciona una ruta para los paquetes desde el extremo privado del plano de control a la otra red.
Para habilitar la exportación de rutas personalizadas desde la red de VPC de tu clúster, usa el siguiente comando:
gcloud compute networks peerings update PEERING_NAME \ --network=CLUSTER_VPC_NETWORK \ --export-custom-routes
Reemplaza lo siguiente:
PEERING_NAME
: es el nombre del intercambio de tráfico que conecta la red de VPC del clúster a la red de VPC del plano de controlCLUSTER_VPC_NETWORK
: es el nombre o URI de la red de VPC del clúster
Para obtener más detalles sobre cómo actualizar el intercambio de rutas para conexiones de intercambio de tráfico entre redes de VPC existentes, consulta Actualiza la conexión de intercambio de tráfico.
Las rutas personalizadas en la red de VPC del clúster incluyen rutas cuyos destinos son rangos de direcciones IP en otras redes, por ejemplo, una red local. Para garantizar que estas rutas sean efectivas como rutas personalizadas de intercambio de tráfico en la red de VPC del plano de control, consulta Destinos admitidos desde la otra red.
Destinos admitidos de la otra red
Los rangos de direcciones que la otra red envía a los Cloud Routers en la red de VPC del clúster deben cumplir con las siguientes condiciones:
Mientras que la VPC del clúster puede aceptar una ruta predeterminada (
0.0.0.0/0
), la red de VPC del plano de control siempre rechaza las rutas predeterminadas porque ya tiene una ruta predeterminada local. Si la otra red envía una ruta predeterminada a la red de VPC, la otra red también debe enviar los destinos específicos de los sistemas que necesitan conectarse al extremo privado del plano de control. Para obtener más detalles, consulta Orden de enrutamiento.Si la red de VPC del plano de control acepta rutas que reemplazan de manera eficaz una ruta predeterminada, esas rutas interrumpen la conectividad a las APIs y los servicios de Google Cloud, lo que interrumpe el plano de control del clúster. Como ejemplo representativo, la otra red no debe anunciar rutas con los destinos
0.0.0.0/1
y128.0.0.0/1
. Consulta el punto anterior para ver una alternativa.
Supervisa los límites de Cloud Router, en especial, la cantidad máxima de destinos únicos para las rutas aprendidas.
Verifica que los nodos no tengan direcciones IP externas
Después de crear un clúster privado, verifica que los nodos del clúster no tengan direcciones IP externas.
Console
Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
En la lista de clústeres, haz clic en el nombre del clúster.
Para los clústeres de Autopilot, en la sección Conceptos básicos del clúster, marca el campo Extremo externo. El valor es Inhabilitado.
Para los clústeres de Standard, haz lo siguiente:
- En la página Clústeres, haz clic en la pestaña Nodos.
- En Grupos de nodos, haz clic en el nombre del grupo de nodos.
- En la página de detalles del grupo de nodos, en Grupos de instancias, haz clic en el nombre de tu grupo de instancias. Por ejemplo, gke-private-cluster-0-default-pool-5c5add1f-grp`.
- En la lista de instancias, verifica que las instancias no tengan direcciones IP externas.
gcloud
Ejecuta el siguiente comando:
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
Ready v1.8.7-gke.1 Container-Optimized OS
Ready v1.8.7-gke.1 Container-Optimized OS
Visualiza 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.
Console
Ve a la página Redes de VPC en la consola de Google Cloud.
Haz clic en el nombre de la subred. Por ejemplo,
gke-private-cluster-0-subnet-163e3c97
.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.
En Rangos de IP secundarios, podrás ver el rango de direcciones IP para los pods y servicios.
gcloud
Muestra todas las subredes
Ejecuta el siguiente comando para ver la lista de subredes de la red del clúster:
gcloud compute networks subnets list \
--network NETWORK_NAME
Reemplaza NETWORK_NAME
por 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
Reemplaza SUBNET_NAME
por 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 para 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
...
Cómo ver los extremos del clúster privado
Puedes ver los extremos del clúster privado con la CLI de gcloud o la consola de Google Cloud.
Console
Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
En la lista de clústeres, haz clic en el nombre.
En la pestaña Detalles, en Conceptos básicos del clúster, busca el campo Extremo.
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
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 Artifact 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 de forma predeterminada no pueden comunicarse con servicios fuera de la red de Google Cloud.
Los nodos de un clúster privado pueden comunicarse con los servicios de Google Cloud, como Artifact Registry, si se encuentran en una subred que tenga habilitado el Acceso privado a Google.
Mediante los siguientes comandos, se crea un Deployment que extrae una imagen de muestra de un repositorio de Artifact Registry:
kubectl run hello-deployment --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.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 el plano de control del clúster para iniciar solo 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.
Entre las funciones de Kubernetes que requieren reglas de firewall adicionales, se incluyen las siguientes:
- Webhooks de admisión
- Servidores de API agregados
- Conversión de webhooks
- Configuración de auditoría dinámica
- Por lo general, cualquier API que tenga un campo ServiceReference requiere reglas de firewall adicionales
Agregar una regla de firewall permite el tráfico del plano de control del clúster a todos los siguientes puertos:
- 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 más información, 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 registrar el bloque CIDR del plano de control del clúster y el destino que se usó. Después de grabar esto, puedes crear la regla.
Paso 1. Visualiza el bloque CIDR del plano de control
El bloque CIDR del plano de control del clúster es necesario para agregar una regla de firewall.
Console
Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
En la lista de clústeres, haz clic en el nombre.
En la pestaña Detalles, en Herramientas de redes, anota el valor en el campo Rango de direcciones del plano de control.
gcloud
Ejecuta el siguiente comando:
gcloud container clusters describe CLUSTER_NAME
Reemplaza CLUSTER_NAME
por el nombre de tu clúster privado.
En el resultado del comando, anota el valor en el campo masterIpv4CidrBlock.
Paso 2: Cómo ver 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.
Console
Ve a la página de políticas de firewall en la consola de Google Cloud.
En Tabla de filtro, en Reglas de firewall de VPC, ingresa
gke-CLUSTER_NAME
.
En los resultados, anota el valor en el campo Destinos.
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.
Paso 3: Agrega una regla de firewall
Console
Ve a la página de políticas de firewall en la consola de Google Cloud.
Haga clic en add_box Crear regla de firewall.
En Nombre, ingresa el nombre de la regla de firewall.
En la lista Red, selecciona la red que corresponda.
En Dirección del tráfico, haz clic en Ingress.
En Acción en caso de coincidencia, haz clic en Permitir.
En la lista Destinos, selecciona Etiquetas de destino especificadas.
En Etiquetas de destino, ingresa el valor de destino que anotaste antes.
En la lista Filtro de fuente, selecciona Rangos de IPv4.
En Rangos de IPv4 de origen, ingresa el bloque CIDR del plano de control del clúster.
En Protocolos y puertos, haz clic en Protocolos y puertos especificados, selecciona la casilla de verificación para el protocolo relevante (tcp oudp ) y, luego, ingresa el número de puerto en el campo del protocolo.
Haz clic en Crear.
gcloud
Ejecuta el siguiente comando:
gcloud compute firewall-rules create FIREWALL_RULE_NAME \
--action ALLOW \
--direction INGRESS \
--source-ranges CONTROL_PLANE_RANGE \
--rules PROTOCOL:PORT \
--target-tags TARGET
Reemplaza lo siguiente:
FIREWALL_RULE_NAME
: Es el nombre que elegiste para la regla de firewall.CONTROL_PLANE_RANGE
: Es el rango de direcciones IP del plano de control del clúster (masterIpv4CidrBlock
) que obtuviste en el paso anterior.PROTOCOL:PORT
: Es el puerto y su protocolo,tcp
oudp
.TARGET
: Es el valor de destino (Targets
) que recopilaste antes.
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 Configuración y detalles del perímetro de servicio.
Si usas Artifact Registry con tu clúster privado de GKE en un perímetro de servicio de los Controles del servicio de VPC, debes configurar el enrutamiento a la IP virtual restringida para evitar el robo de datos.
Reutilización del intercambio de tráfico entre VPC
Todos los clústeres privados que crees después del 15 de enero de 2020 vuelven a usar las conexiones del intercambio de tráfico entre redes de VPC.
Todos los clústeres privados que creaste antes del 15 de enero de 2020 usan una única conexión de intercambio de tráfico entre redes de VPC. Cada red de VPC puede intercambiarse con hasta 25 redes de VPC, lo que significa que hay un límite máximo de 25 clústeres privados por red (si es que los intercambios de tráfico no se usan para otros fines).
Esta característica no se encuentra en versiones anteriores. Para habilitar la reutilización del intercambio de tráfico de red de VPC en clústeres privados más antiguos, puedes borrar el clúster y volver a crearlo. La actualización del clúster no hace que este vuelva a usar una conexión de intercambio de tráfico de red de VPC existente.
Cada ubicación puede admitir un máximo de 75 clústeres privados si estos tienen habilitada la reutilización del intercambio de tráfico entre redes de VPC. Las zonas y las regiones se tratan como ubicaciones separadas.
Por ejemplo, puedes crear hasta 75 clústeres zonales privados en us-east1-a
y otros 75 clústeres regionales privados en us-east1
. Esto también se aplica si usas clústeres privados en una red de VPC compartida. La cantidad máxima de conexiones a una sola red de VPC es 25, lo que significa que solo puedes crear clústeres privados con 25 ubicaciones únicas.
La reutilización del intercambio de tráfico entre redes de VPC solo se aplica a los clústeres en la misma ubicación, por ejemplo, clústeres regionales en la misma región o clústeres zonales en la misma zona. Como máximo, puedes tener cuatro intercambios de tráfico entre redes de VPC por región si creas clústeres regionales y clústeres zonales en todas las zonas de esa región.
Puedes comprobar si tu clúster privado vuelve a usar las conexiones de intercambio de tráfico de red de VPC mediante la CLI de gcloud o la consola de Google Cloud.
Console
Verifica la fila del intercambio de tráfico de VPC en la página de detalles del clúster. Si tu clúster vuelve a usar conexiones de intercambio de tráfico de VPC, el resultado comenzará con gke-n
.
Por ejemplo, gke-n34a117b968dee3b2221-93c6-40af-peer
.
gcloud
gcloud container clusters describe CLUSTER_NAME \
--format="value(privateClusterConfig.peeringName)"
Si tu clúster vuelve a usar conexiones de intercambio de tráfico de VPC, el resultado comenzará con gke-n
. Por ejemplo, gke-n34a117b968dee3b2221-93c6-40af-peer
Realice una limpieza
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:
Borra los clústeres
Console
Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
Selecciona cada clúster.
Haz clic en delete Borrar.
gcloud
gcloud container clusters delete -q private-cluster-0 private-cluster-1 private-cluster-2 private-cluster-3
Borra la red
Console
Ve a la página Redes de VPC en la consola de Google Cloud.
En la lista de redes, haz clic en
my-net-0
.En la página de detalles de la red de VCP, haz clic en delete Borrar red de VPC.
En el diálogo Borrar una red, haz clic en Borrar.
gcloud
gcloud compute networks delete my-net-0
Requisitos, restricciones y limitaciones
Los clústeres privados tienen los siguientes requisitos:
- Los clústeres privados deben ser clústeres nativos de la VPC. Los clústeres nativos de la VPC no son compatibles con las redes heredadas.
Los clústeres privados tienen las siguientes restricciones:
- No puedes convertir un clúster público existente en un clúster privado.
- Cuando usas
172.17.0.0/16
para el rango de IP del plano de control, no puedes usar este rango para direcciones IP de nodos, Pods o servicios. - Un clúster privado deja de funcionar si se borra el intercambio de tráfico de VPC entre el plano de control y los nodos del clúster, las reglas de firewall que permiten el tráfico de entrada del plano de control del clúster a los nodos en el puerto 10250 o la ruta predeterminada a la puerta de enlace predeterminada de Internet. Si borras la ruta predeterminada, debes asegurarte de que se enrute el tráfico a los servicios de Google Cloud necesarios. Para obtener más información, consulta Enrutamiento personalizado.
- Cuando se habilita la exportación de rutas personalizadas para la VPC, la creación de rutas que se superpongan con los rangos de IP de Google Cloud podría interrumpir el clúster.
- Puedes agregar hasta 50 redes autorizadas (bloques CIDR permitidos) 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:
- El tamaño del bloque RFC 1918 del plano de control de clústeres debe ser de
/28
. - Si bien GKE puede detectar la superposición con el bloque de direcciones del plano de control, no puede detectar la superposición dentro de una red de VPC compartida.
- Todos los nodos de un clúster privado se crean sin una IP pública. Tienen acceso limitado a los servicios y a las APIs de Google Cloud. Si deseas proporcionar acceso saliente a Internet a tus nodos privados, puedes usar Cloud NAT.
- El acceso privado a Google se habilita de forma automática cuando creas un clúster privado, a menos que uses una VPC compartida. No debes inhabilitar el Acceso privado a Google, a menos que uses NAT para acceder a Internet.
- Todos los clústeres privados que creaste antes del 15 de enero de 2020 tienen un límite máximo de 25 clústeres privados por red (si es que el intercambio de tráfico no se usa para otros fines). Consulta Reutilización del intercambio de tráfico entre VPC para obtener más información.
- Cada clúster privado requiere una ruta de intercambio de tráfico entre las VPC, pero solo puede ocurrir una operación de intercambio de tráfico a la vez. Si intentas crear varios clústeres privados al mismo tiempo, es posible que se agote el tiempo de espera de creación del clúster. Para evitar esto, crea clústeres privados nuevos de manera serial para que las rutas de intercambio de tráfico entre VPC ya existan en cada clúster privado posterior. Si intentas crear un único clúster privado, es posible que también se agote el tiempo de espera si hay operaciones en ejecución en la VPC.
- Si expandes el rango de IP principal de una subred para admitir nodos adicionales, debes agregar el rango de direcciones IP principal de la subred expandida a la lista de redes autorizadas para tu clúster. Si no lo haces, las reglas de firewall de entrada permitida que son relevantes para el plano de control no se actualizan, y los nodos nuevos creados en el espacio de direcciones IP expandido no podrán registrarse con el plano de control. Esto puede provocar una interrupción en la que los nodos nuevos se borren y se reemplacen de forma continua. Este tipo de interrupción puede ocurrir cuando se realizan actualizaciones de grupos de nodos o cuando los nodos se reemplazan de manera automática debido a fallas de sondeo de estado en funcionamiento.
- No crees reglas de firewall ni reglas de política de firewall jerárquicas que tengan una prioridad más alta que la reglas de firewall creadas automáticamente.
Soluciona problemas
En las siguientes secciones, se explica cómo resolver problemas habituales relacionados con los clústeres privados.
Se borra accidentalmente la conexión de intercambio de tráfico de red de VPC en el clúster privado
- Síntomas
Cuando borras una conexión de intercambio de tráfico entre redes de VPC por accidente, el clúster entra en un estado de reparación y todos los nodos muestran un estado
UNKNOWN
. No podrás realizar ninguna operación en el clúster porque la accesibilidad del plano de control está desconectada. Cuando inspecciones el plano de control, los registros mostrarán un error similar al siguiente:error checking if node NODE_NAME is shutdown: unimplemented
- Causas posibles
Borraste accidentalmente la conexión de intercambio de tráfico de red de VPC.
- Solución
Lleva a cabo los pasos siguientes:
Crea un nuevo clúster temporal de intercambio de tráfico entre redes de VPC. La creación de clústeres provoca que se vuelvan a crear intercambios de tráfico de red de VPC y el clúster anterior se restablece a su funcionamiento normal.
Borra el clúster de intercambio de tráfico entre redes de VPC creado temporalmente después de que el clúster anterior se restablezca a su funcionamiento normal.
El clúster se superpone con el intercambio de tráfico
- Síntomas
Si intentas crear un clúster privado, se muestra un error similar al siguiente:
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 del plano de control superpuesto.
- Solución
Borra y vuelve a crear el clúster mediante otro CIDR del plano de control.
No se puede acceder al plano de control de un clúster privado
Aumenta la probabilidad de que se pueda acceder al plano de control del clúster mediante la implementación de cualquiera de las opciones de configuración de acceso del extremo del clúster. Si deseas obtener más información, consulta el acceso a los extremos del 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 similar a uno de los siguientes:Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out.
Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
- Causas posibles
kubectl
no puede comunicarse con el plano de control del clúster.- Solución
Verifica que las credenciales del clúster se hayan generado para kubeconfig o que se haya activado el contexto correcto. Para obtener más información sobre cómo configurar las credenciales del clúster, consulta Genera una entrada de kubeconfig.
Verifica que se permita el acceso al plano de control mediante su dirección IP externa. La inhabilitación del acceso externo al plano de control del clúster aísla el clúster de Internet. Esta configuración es inmutable después de la creación del clúster. Con esta configuración, solo los rangos de CIDR de red interna autorizados o la red reservada tienen acceso al plano de control.
Verifica que la dirección IP de origen esté autorizada para acceder al plano de control:
gcloud container clusters describe CLUSTER_NAME \ --format="value(masterAuthorizedNetworksConfig)"\ --location=COMPUTE_LOCATION
Reemplaza lo siguiente:
CLUSTER_NAME
: es el nombre de tu clúster.COMPUTE_LOCATION
: la ubicación de Compute Engine para el clúster.
Si la dirección IP de origen no está autorizada, el resultado que se muestra puede estar vacío (solo aparecen llaves) o contener rangos CIDR que no incluyen la dirección IP de origen.
cidrBlocks: cidrBlock: 10.XXX.X.XX/32 displayName: jumphost cidrBlock: 35.XXX.XXX.XX/32 displayName: cloud shell enabled: true
Agrega redes autorizadas al plano de control de acceso.
Si ejecutas el comando
kubectl
desde un entorno local o una región diferente a la ubicación del clúster, asegúrate de que esté habilitado el acceso global del extremo privado del plano de control. Para obtener más información, consulta Accede al extremo privado del plano de control de forma global.Describe el clúster para ver la respuesta de la configuración de acceso de control:
gcloud container clusters describe CLUSTER_NAME \ --location=COMPUTE_LOCATION \ --flatten "privateClusterConfig.masterGlobalAccessConfig"
Reemplaza lo siguiente:
CLUSTER_NAME
: es el nombre de tu clúster.COMPUTE_LOCATION
: la ubicación de Compute Engine para el clúster.
Un resultado correcto es similar al siguiente:
enabled: true
Si se muestra
null
, habilita el acceso global al plano de control.
No se puede crear el clúster debido a la superposición del bloque CIDR de IPv4
- Síntomas
gcloud container clusters create
muestra un error similar al siguiente: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 del plano de control que se superpone con una subred existente en tu VPC.
- Solución
Especifica un bloque CIDR para
--master-ipv4-cidr
que no se superponga con una subred existente.
No se puede crear el clúster debido a que otro clúster ya usa el rango de servicios
- Síntomas
Si intentas crear un clúster privado, se muestra un error similar al siguiente:
Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork [SUBNET_NAME] is already used by another cluster.
- Causas posibles
Cualquiera de las siguientes opciones:
- Elegiste un rango de servicios que aún está en uso por otro clúster o el clúster no se borró.
- Hubo un clúster con ese rango de servicios que se borró, pero los metadatos de rangos secundarios no se borraron de forma correcta. Los rangos secundarios de un clúster de GKE se guardan en los metadatos de Compute Engine y deben quitarse una vez que se borra el clúster. Incluso cuando un clúster se borra de forma correcta, es posible que los metadatos no se quiten.
- Solución
Lleva a cabo los pasos siguientes:
- Comprueba si un clúster existente está usando el rango de servicios. Puedes usar el comando
gcloud container clusters list
con la marcafilter
para buscar el clúster. Si hay un clúster existente que usa los rangos de servicios, debes borrar ese clúster o crear un rango de servicios nuevo. - Si un clúster existente no usa el rango de servicios, quita manualmente la entrada de metadatos que coincida con el rango de servicios que deseas usar.
- Comprueba si un clúster existente está usando el rango de servicios. Puedes usar el comando
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 CIDR del plano de control que especificaste se superpone con otro rango de IP en el clúster. Esto también puede ocurrir si borraste un clúster privado hace poco y ahora intentas crear uno nuevo con el mismo CIDR del plano de control.
- Solució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
: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 direcciones IP externas, por lo que no cumplen con los requisitos de acceso a Internet. Sin embargo, los nodos pueden acceder a los servicios y las APIs de Google, incluido Artifact Registry, si habilitaste el Acceso privado a Google y cumpliste con los requisitos de la red.
- Solución
Utiliza una de las siguientes soluciones:
Copia las imágenes de tu clúster privado de Docker Hub a Artifact Registry. Consulta la página sobre cómo migrar contenedores desde un registro de terceros para obtener más información.
GKE busca de forma automática
mirror.gcr.io
para las copias almacenadas en caché de las imágenes de Docker Hub a las que se accede con frecuencia.Si necesitas extraer imágenes de Docker Hub o de otro repositorio público, usa Cloud NAT o un proxy basado en instancias que sea el objetivo de una ruta estática
0.0.0.0/0
.
Solicitud a la API que activa el agotamiento del tiempo de espera del webhook de admisión
- Síntomas
Se agota el tiempo de espera de una solicitud a la API que activa un webhook de admisión configurado para usar un servicio con un targetPort distinto a 443, lo que hace que la solicitud falle:
Error from server (Timeout): request did not complete within requested timeout 30s
- Causas posibles
De forma predeterminada, el firewall no permite conexiones TCP a los nodos, excepto en los puertos 443 (HTTPS) y 10250 (kubelet). Un webhook de admisión que intenta comunicarse con un Pod en un puerto distinto a 443 fallará si no hay una regla de firewall personalizada que permita el tráfico.
- Solución
Agrega una regla de firewall para tu caso de uso específico.
No se puede crear el clúster porque falla la verificación de estado
- Síntomas
Después de crear un clúster privado, se atasca en el paso de verificación de estado e informa un error similar al siguiente:
All cluster resources were brought up, but only 0 of 2 have registered.
All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
- Causas posibles
Cualquiera de los siguientes:
- Los nodos del clúster no pueden descargar objetos binarios obligatorios de la API de Cloud Storage (
storage.googleapis.com
). - Reglas de firewall que restringen el tráfico de salida.
- Los permisos de IAM de VPC compartida son incorrectos.
- El acceso privado a Google requiere que configures el DNS para
*.gcr.io
.
- Los nodos del clúster no pueden descargar objetos binarios obligatorios de la API de Cloud Storage (
- Solución
Utiliza una de las siguientes soluciones:
Habilita el Acceso privado a Google en la subred para el acceso de la red del nodo a
storage.googleapis.com
o habilita Cloud NAT a fin de permitir que los nodos se comuniquen constorage.googleapis.com
. extremos. Para obtener más información, consulta Cómo solucionar problemas de creación de clústeres privados de GKE.Para el acceso de lectura del nodo a
storage.googleapis.com
, confirma que la cuenta de servicio asignada al nodo del clúster tenga acceso de lectura de almacenamiento.Asegúrate de tener una regla de firewall de Google Cloud a fin de permitir todo el tráfico de salida o configura una regla de firewall para permitir el tráfico de salida de los nodos al plano de control del clúster y
*.googleapis.com
.Crea la configuración de DNS para
*.gcr.io
.Si tienes una configuración de firewall o de ruta no predeterminada, configura el Acceso privado a Google.
Si usas los Controles del servicio de VPC, configura Container Registry o Artifact Registry para los clústeres privados de GKE.
Asegúrate de no haber borrado o modificado las reglas de firewall creadas automáticamente para la entrada.
Si usas una VPC compartida, asegúrate de haber configurado los permisos de IAM necesarios.
kubelet no pudo crear una zona de pruebas de Pod
- Síntomas
Después de crear un clúster privado, se informa un error similar a uno de los siguientes:
Warning FailedCreatePodSandBox 12s (x9 over 4m) kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://registry.k8s.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
- Causas posibles
El Pod
calico-node
onetd
no puede alcanzar*.gcr.io
.- Solución
Utiliza una de las siguientes soluciones:
- Asegúrate de que completaste la configuración requerida para Container Registry o Artifact Registry.
Nodos de clúster privado que se crearon, pero no se unieron al clúster
A menudo, cuando se usan rutas personalizadas y dispositivos de red de terceros en la VPC que usa el clúster privado, la ruta predeterminada (0.0.0.0/0
) se redirecciona al dispositivo, en lugar de la puerta de enlace de Internet predeterminada. Además de la conectividad del plano de control, debes asegurarte de que sea posible acceder a los siguientes destinos:
- *.googleapis.com
- *.gcr.io
- gcr.io
Configura el Acceso privado a Google en los tres dominios. Con esta práctica recomendada, se permite que los nodos nuevos se inicien y se unan al clúster, y se mantiene restringido el tráfico vinculado a Internet.
Las cargas de trabajo de clústeres de GKE privados no pueden acceder a Internet
Los Pods en clústeres de GKE privados no pueden acceder a Internet. Por ejemplo, después de ejecutar el comando apt update
desde el Pod exec shell
, se informa un error similar al siguiente:
0% [Connecting to deb.debian.org (199.232.98.132)] [Connecting to security.debian.org (151.101.130.132)]
Si el rango de direcciones IP secundario de la subred que se usa para los Pods en el clúster no está configurado en la puerta de enlace de Cloud NAT, los Pods no pueden conectarse a Internet, ya que no tienen configurada una dirección IP externa para la puerta de enlace de Cloud NAT.
Asegúrate de configurar la puerta de enlace de Cloud NAT a fin de aplicar al menos los siguientes rangos de direcciones IP de subred para la subred que usa tu clúster:
- Rango de direcciones IP principal de la subred (para los nodos)
- Rango de direcciones IP secundario de la subred utilizado para los Pods del clúster
- Rango de direcciones IP secundario de la subred utilizado para los servicios del clúster
Si quieres obtener más información, consulta cómo agregar un rango de IP de subred secundario usado para los Pods.
¿Qué sigue?
- Lee la descripción general de redes de GKE.
- Obtén información para crear clústeres nativos de VPC.
- Obtén más información sobre el intercambio de tráfico entre redes de VPC.