Configurar clústeres con VPC compartida

En esta guía se muestra cómo crear dos clústeres de Google Kubernetes Engine (GKE) en proyectos distintos que usen una VPC compartida. Para obtener información general sobre las redes de GKE, consulta la descripción general de la red.

En los ejemplos de esta guía se configura la infraestructura de una aplicación web de dos niveles, tal como se describe en la descripción general de la VPC compartida.

Por qué usar VPC compartida con GKE

Con la VPC compartida, designas un proyecto como proyecto host y puedes vincular otros proyectos, denominados proyectos de servicio, al proyecto host. Creas redes, subredes, intervalos de direcciones secundarias, reglas de cortafuegos y otros recursos de red en el proyecto del host. Después, comparte las subredes seleccionadas, incluidos los intervalos secundarios, con los proyectos de servicio. Los componentes que se ejecutan en un proyecto de servicio pueden usar la VPC compartida para comunicarse con los componentes que se ejecutan en otros proyectos de servicio.

Puedes usar una VPC compartida con clústeres Autopilot y con clústeres estándar zonales y regionales.

Los clústeres estándar que usan VPC compartida no pueden usar redes antiguas y deben tener habilitado el enrutamiento del tráfico nativo de VPC. Los clústeres de Autopilot siempre habilitan el enrutamiento del tráfico nativo de VPC.

Puedes configurar la VPC compartida al crear un clúster. GKE no admite la conversión de clústeres en el modelo de VPC compartida.

Con la VPC compartida, se aplican determinadas cuotas y límites. Por ejemplo, hay una cuota para el número de redes de un proyecto y un límite en el número de proyectos del servicio que se pueden vincular a un proyecto del host. Para obtener más información, consulta Cuotas y límites.

Antes de empezar

Antes de empezar a configurar un clúster con VPC compartida, debes hacer lo siguiente:

Antes de hacer los ejercicios de esta guía:

  • Elige uno de tus proyectos para que sea el proyecto host.
  • Elige dos de tus proyectos para que sean proyectos de servicio.

Cada proyecto tiene un nombre, un ID y un número. En algunos casos, el nombre y el ID son iguales. En esta guía se usan los siguientes nombres descriptivos y marcadores de posición para hacer referencia a tus proyectos:

Nombre descriptivo Marcador de posición del ID de proyecto
Marcador de posición del número de proyecto
Tu proyecto del host HOST_PROJECT_ID HOST_PROJECT_NUM
Tu primer proyecto de servicio SERVICE_PROJECT_1_ID SERVICE_PROJECT_1_NUM
Tu segundo proyecto de servicio SERVICE_PROJECT_2_ID SERVICE_PROJECT_2_NUM

Consultar los IDs y números de tus proyectos

Puedes encontrar el ID y los números de tu proyecto con la gcloud CLI o la Trusted Cloud consola.

Consola

  1. Ve a la página Principal de la Trusted Cloud consola.

    Ir a la página principal

  2. En el selector de proyectos, elige el proyecto que hayas seleccionado como proyecto host.

  3. En Información del proyecto, puede ver el nombre, el ID y el número del proyecto. Anota el ID y el número para más adelante.

  4. Haz lo mismo con cada uno de los proyectos que hayas elegido como proyectos de servicio.

gcloud

Consulta tus proyectos con el siguiente comando:

gcloud projects list

En el resultado se muestran los nombres, los IDs y los números de tus proyectos. Anota el ID y el número para más adelante:

PROJECT_ID        NAME        PROJECT_NUMBER
host-123          host        1027xxxxxxxx
srv-1-456         srv-1       4964xxxxxxxx
srv-2-789         srv-2       4559xxxxxxxx

Habilitar la API de GKE en tus proyectos

Antes de continuar con los ejercicios de esta guía, asegúrate de que la API de GKE esté habilitada en los tres proyectos. Al habilitar la API en un proyecto, se crea una cuenta de servicio de GKE para el proyecto. Para realizar las tareas restantes de esta guía, cada uno de tus proyectos debe tener una cuenta de servicio de GKE.

Puedes habilitar la API de GKE mediante la Trusted Cloud consola o la CLI de Google Cloud.

Consola

  1. Ve a la página APIs y servicios de la Trusted Cloud consola.

    Ir a APIs y servicios

  2. En el selector de proyectos, elige el proyecto que hayas seleccionado como proyecto host.

  3. Si Kubernetes Engine API aparece en la lista de APIs, ya está habilitada y no tienes que hacer nada. Si no aparece en la lista, haz clic en Habilitar APIs y servicios. Buscar Kubernetes Engine API. Haz clic en la tarjeta API de Kubernetes Engine y, a continuación, en Habilitar.

  4. Repite estos pasos con cada proyecto que hayas elegido como proyecto de servicio. Cada operación puede tardar un tiempo en completarse.

gcloud

Habilita la API de GKE en los tres proyectos. Cada operación puede tardar un tiempo en completarse:

gcloud services enable container.googleapis.com --project HOST_PROJECT_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_1_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_2_ID

Crear una red y dos subredes

En esta sección, realizarás las siguientes tareas:

  1. En el proyecto host, crea una red llamada shared-net.
  2. Crea dos subredes llamadas tier-1 y tier-2.
  3. Crea dos intervalos de direcciones secundarias para cada subred: uno para los servicios y otro para los pods.

Consola

  1. Ve a la página Redes de VPC de la consola de Trusted Cloud .

    Ir a redes de VPC

  2. En el selector de proyectos, selecciona el proyecto host.

  3. Haz clic en Crear red VPC.

  4. En Nombre, escribe shared-net.

  5. En Modo de creación de subred, selecciona Personalizado.

  6. En el cuadro Nueva subred, en Nombre, introduce tier-1.

  7. En Región, selecciona una región.

  8. En Tipo de pila de IP, selecciona IPv4 (pila única).

  9. En Intervalo de IPv4, introduce 10.0.4.0/22.

  10. Haz clic en Crear intervalo de IPv4 secundario. En Nombre del intervalo de subred, introduce tier-1-services y, en Intervalo IPv4 secundario, escribe 10.0.32.0/20.

  11. Haz clic en Añadir intervalo de IPs. En Nombre del intervalo de subred, introduce tier-1-pods y, en Intervalo IPv4 secundario, escribe 10.4.0.0/14.

  12. Haz clic en Añadir subred.

  13. En Nombre, escribe tier-2.

  14. En Región, selecciona la misma región que hayas seleccionado para la subred anterior.

  15. En Intervalo de IPv4, introduce 172.16.4.0/22.

  16. Haz clic en Crear intervalo de IPv4 secundario. En Nombre del intervalo de subred, introduce tier-2-services y, en Intervalo IPv4 secundario, escribe 172.16.16.0/20.

  17. Haz clic en Añadir intervalo de IPs. En Nombre del intervalo de subred, introduce tier-2-pods y, en Intervalo IPv4 secundario, escribe 172.20.0.0/14.

  18. Haz clic en Crear.

gcloud

En tu proyecto host, crea una red llamada shared-net:

gcloud compute networks create shared-net \
    --subnet-mode custom \
    --project HOST_PROJECT_ID

En tu nueva red, crea una subred llamada tier-1:

gcloud compute networks subnets create tier-1 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 10.0.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-1-services=10.0.32.0/20,tier-1-pods=10.4.0.0/14

Crea otra subred llamada tier-2:

gcloud compute networks subnets create tier-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 172.16.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

Sustituye COMPUTE_REGION por una región de Compute Engine.

Determinar los nombres de las cuentas de servicio de tus proyectos de servicio

Tienes dos proyectos de servicio, cada uno de los cuales tiene varias cuentas de servicio. En esta sección se tratan las cuentas de servicio de GKE y las cuentas de servicio de las APIs de Google. Necesitará los nombres de estas cuentas de servicio para la siguiente sección.

En la siguiente tabla se indican los nombres de las cuentas de servicio de las APIs de GKE y Google de tus dos proyectos de servicio:

Tipo de cuenta de servicio Nombre de la cuenta de servicio
GKE service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
APIs de Google SERVICE_PROJECT_1_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com
SERVICE_PROJECT_2_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com

Habilitar VPC compartida y asignar roles

Para realizar las tareas de esta sección, asegúrate de que tu organización haya definido el rol Administrador de VPC compartida.

En esta sección, realizarás las siguientes tareas:

  1. En el proyecto host, habilita la VPC compartida.
  2. Vincula los dos proyectos de servicio al proyecto del host.
  3. Concede los roles de IAM adecuados a las cuentas de servicio que pertenezcan a tus proyectos de servicio:
    • En tu primer proyecto de servicio, concede a dos cuentas de servicio el rol Compute Network User en la subred tier-1 de tu proyecto host.
    • En el segundo proyecto de servicio, concede a dos cuentas de servicio el rol Compute Network User en la subred tier-2 de tu proyecto host.

Consola

Sigue estos pasos para habilitar la VPC compartida, adjuntar proyectos de servicio y asignar roles:

  1. Ve a la página VPC compartida de la Trusted Cloud consola.

    Ir a VPC compartida

  2. En el selector de proyectos, selecciona el proyecto host.

  3. Haz clic en Configurar VPC compartida. Se muestra la pantalla Habilitar proyecto del host.

  4. Haz clic en Guardar y continuar. Se muestra la página Seleccionar subredes.

  5. En Modo de compartir, selecciona Subredes concretas.

  6. En Subredes que quieres compartir, marca tier-1 y tier-2. Desmarque todas las demás casillas.

  7. Haz clic en Continuar. Se muestra la página Dar permisos.

  8. En Vincular proyectos de servicio, marca el primer y el segundo proyecto de servicio. Desmarca todas las demás casillas de Vincular proyectos de servicio.

  9. En Acceso de Kubernetes Engine, marca Habilitado.

  10. Haz clic en Guardar. Se muestra una nueva página.

  11. En Permisos de subredes concretas, marca tier-1.

  12. En el panel de la derecha, elimina las cuentas de servicio que pertenezcan a tu segundo proyecto de servicio. Es decir, elimina todas las cuentas de servicio que contengan SERVICE_PROJECT_2_NUM.

  13. En el panel de la derecha, busca los nombres de las cuentas de servicio de las APIs de GKE y Google que pertenezcan a tu primer proyecto de servicio. Quieres ver ambos nombres de cuentas de servicio en la lista. Si no aparece en la lista, introduce el nombre de la cuenta de servicio en Añadir miembros y haz clic en Añadir.

  14. En el panel central, en Permisos de subredes concretas, marca tier-2 y desmarca tier-1.

  15. En el panel de la derecha, elimina las cuentas de servicio que pertenezcan al primer proyecto de servicio. Es decir, elimina todas las cuentas de servicio que contengan SERVICE_PROJECT_1_NUM.

  16. En el panel de la derecha, busca los nombres de las cuentas de servicio de las APIs de GKE y Google que pertenezcan a tu segundo proyecto de servicio. Quieres ver ambos nombres de cuentas de servicio en la lista. Si no aparece en la lista, introduce el nombre de la cuenta de servicio en Añadir miembros y haz clic en Añadir.

gcloud

  1. Habilita la VPC compartida en tu proyecto host. El comando que uses dependerá del rol administrativo necesario que tengas.

    Si tienes el rol Administrador de VPC compartida a nivel de organización:

    gcloud compute shared-vpc enable HOST_PROJECT_ID

    Si tienes el rol Administrador de VPC compartida a nivel de carpeta:

    gcloud beta compute shared-vpc enable HOST_PROJECT_ID

  2. Vincula tu primer proyecto de servicio a tu proyecto del host:

    gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

  3. Vincula tu segundo proyecto de servicio a tu proyecto del host:

    gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

  4. Obtén la política de gestión de identidades y accesos de la subred tier-1:

    gcloud compute networks subnets get-iam-policy tier-1 \
   --project HOST_PROJECT_ID \
   --region COMPUTE_REGION

    El resultado contiene un campo etag. Anota el valor de etag.

  5. Crea un archivo llamado tier-1-policy.yaml con el siguiente contenido:

    bindings:
- members:
  - serviceAccount:SERVICE_PROJECT_1_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com
  - serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
  role: roles/compute.networkUser
etag: ETAG_STRING

    Sustituye ETAG_STRING por el valor de etag que anotaste anteriormente.

  6. Define la política de gestión de identidades y accesos de la subred tier-1:

    gcloud compute networks subnets set-iam-policy tier-1 \
    tier-1-policy.yaml \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

  7. Obtén la política de gestión de identidades y accesos de la subred tier-2:

    gcloud compute networks subnets get-iam-policy tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

    El resultado contiene un campo etag. Anota el valor de etag.

  8. Crea un archivo llamado tier-2-policy.yaml con el siguiente contenido:

    bindings:
- members:
  - serviceAccount:SERVICE_PROJECT_2_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com
  - serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com
  role: roles/compute.networkUser
etag: ETAG_STRING

    Sustituye ETAG_STRING por el valor de etag que anotaste anteriormente.

  9. Define la política de gestión de identidades y accesos de la subred tier-2:

    gcloud compute networks subnets set-iam-policy tier-2 \
    tier-2-policy.yaml \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

Gestionar recursos de cortafuegos

Si quieres que un clúster de GKE de un proyecto de servicio cree y gestione los recursos de cortafuegos de tu proyecto host, debes conceder a la cuenta de servicio de GKE del proyecto de servicio los permisos de IAM adecuados mediante una de las siguientes estrategias:

  • Asigna a la cuenta de servicio de GKE del proyecto de servicio el rol Compute Security Admin en el proyecto host.

Consola

  1. En la consola, ve a la página Gestión de identidades y accesos. Trusted Cloud

    Ir a Gestión de identidades y accesos

  2. Selecciona el proyecto host.

  3. Haga clic en Conceder acceso y, a continuación, introduzca la cuenta de servicio principal de GKE del proyecto de servicio. service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com

  4. Selecciona el rol Compute Security Admin en la lista desplegable.

  5. Haz clic en Guardar.

gcloud

Asigna a la cuenta de servicio de GKE del proyecto de servicio el rol Compute Security Admin en el proyecto del host:

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role=roles/compute.securityAdmin

Haz los cambios siguientes:

  • HOST_PROJECT_ID: el ID del proyecto host de la VPC compartida
  • SERVICE_PROJECT_NUM: el ID del proyecto que contiene la cuenta de servicio de GKE

  • Para un enfoque más detallado, crea un rol de gestión de identidades y accesos personalizado que incluya solo los siguientes permisos: compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update y compute.firewalls.delete. Asigna a la cuenta de servicio de GKE del proyecto de servicio ese rol personalizado en el proyecto host.

Consola

Crea un rol personalizado en el proyecto host que contenga los permisos de gestión de identidades y accesos mencionados anteriormente:

  1. En la Trusted Cloud consola, ve a la página Roles.

    Ir a la página Roles

  2. En la lista desplegable situada en la parte superior de la página, selecciona el proyecto host.

  3. Haz clic en Crear rol.

  4. Introduce el título, la descripción, el ID y la fase de lanzamiento del rol. El nombre del rol no se puede cambiar una vez creado.

  5. Haz clic en Añadir permisos.

  6. Filtra por compute.networks y selecciona los permisos de gestión de identidades y accesos que se han mencionado anteriormente.

  7. Una vez que hayas seleccionado todos los permisos necesarios, haz clic en Añadir.

  8. Haz clic en Crear.

Concede a la cuenta de servicio de GKE del proyecto de servicio el rol personalizado que acabas de crear en el proyecto host:

  1. En la consola, ve a la página Gestión de identidades y accesos. Trusted Cloud

    Ir a Gestión de identidades y accesos

  2. Selecciona el proyecto host.

  3. Haz clic en Conceder acceso y, a continuación, introduce el principal de la cuenta de servicio de GKE del proyecto de servicio, service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com.

  4. Filtra por el Título del rol personalizado que acabas de crear y selecciónalo.

  5. Haz clic en Guardar.

gcloud

  1. Crea un rol personalizado en el proyecto host que contenga los permisos de gestión de identidades y accesos mencionados anteriormente:

    gcloud iam roles create ROLE_ID \
    --title="ROLE_TITLE" \
    --description="ROLE_DESCRIPTION" \
    --stage=LAUNCH_STAGE \
    --permissions=compute.networks.updatePolicy,compute.firewalls.list,compute.firewalls.get,compute.firewalls.create,compute.firewalls.update,compute.firewalls.delete \
    --project=HOST_PROJECT_ID

  2. Concede a la cuenta de servicio de GKE del proyecto de servicio el rol personalizado que acabas de crear en el proyecto host:

    gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role=projects/HOST_PROJECT_ID/roles/ROLE_ID

    Haz los cambios siguientes:

    • ROLE_ID: el nombre del rol, como gkeFirewallAdmin
    • ROLE_TITLE: un título descriptivo para el rol, como GKE Firewall Admin
    • ROLE_DESCRIPTION: una breve descripción del rol, como GKE service account FW permissions
    • LAUNCH_STAGE: la fase de lanzamiento del rol en su ciclo de vida, como ALPHA, BETA o GA
    • HOST_PROJECT_ID: el ID del proyecto host de la VPC compartida
    • SERVICE_PROJECT_NUM: el ID del proyecto que contiene la cuenta de servicio de GKE

Si tienes clústeres en más de un proyecto de servicio, debes elegir una de las estrategias y repetirla para cada cuenta de servicio de GKE del proyecto de servicio.

.

Resumen de los roles concedidos en las subredes

A continuación, se muestra un resumen de los roles concedidos en las subredes:

Cuenta de servicio Rol Subred
service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com Usuario de red de Compute tier-1
SERVICE_PROJECT_1_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com Usuario de red de Compute tier-1
service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com Usuario de red de Compute tier-2
SERVICE_PROJECT_2_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com Usuario de red de Compute tier-2

Verificar el acceso a GKE

Al adjuntar un proyecto de servicio, habilitar el acceso de GKE concede a la cuenta de servicio de GKE del proyecto de servicio los permisos para realizar operaciones de gestión de redes en el proyecto host.

GKE asigna automáticamente el siguiente rol en el proyecto host al habilitar el acceso a GKE:

Miembro Rol Recurso
service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com Usuario agente de servicio del host Cuenta de servicio de GKE en el proyecto host

Sin embargo, debes añadir manualmente el permiso Compute Network User de gestión de identidades y accesos a la cuenta de servicio de GKE del proyecto de servicio para acceder a la red del host.

Miembro Rol Recurso
service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com Usuario de red de Compute Subred específica o todo el proyecto del host

Si se ha adjuntado un proyecto de servicio sin habilitar el acceso a GKE, y suponiendo que la API de GKE ya se ha habilitado tanto en el proyecto host como en el proyecto de servicio, puedes asignar manualmente los permisos a la cuenta de servicio de GKE del proyecto de servicio añadiendo los siguientes enlaces de roles de gestión de identidades y accesos en el proyecto host:

Miembro Rol Recurso
service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com Usuario de red de Compute Subred específica o todo el proyecto del host
service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com Usuario agente de servicio del host Agente de servicio de GKE en el proyecto host

Asignar el rol de usuario de agente de servicio del host

El agente de servicio de GKE de cada proyecto de servicio debe tener un enlace para el rol Usuario del agente de servicio host (roles/container.hostServiceAgentUser) en el proyecto host. El agente de servicio de GKE tiene el siguiente formato:

service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com

Donde SERVICE_PROJECT_NUM es el número de proyecto de tu proyecto de servicio.

Esta vinculación permite que el agente de servicio de GKE del proyecto de servicio realice operaciones de gestión de redes en el proyecto host, como si fuera el agente de servicio de GKE del proyecto host. Este rol solo se puede conceder al agente de servicio de GKE de un proyecto de servicio.

Consola

Si has usado la Trusted Cloud consola, no tienes que conceder el rol Usuario del agente de servicio de host de forma explícita. Esto se hizo automáticamente cuando usaste la consola Trusted Cloud para adjuntar proyectos de servicio a tu proyecto host.

gcloud

  1. En tu primer proyecto, asigna el rol Usuario del agente de servicio host al agente de servicio de GKE del proyecto. Este rol se concede en tu proyecto del host:

    gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

  2. En el segundo proyecto, asigna el rol Usuario del agente de servicio host al agente de servicio de GKE del proyecto. Este rol se concede en tu proyecto del host:

    gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

Verificar las subredes utilizables y los intervalos de direcciones IP secundarias

Cuando crees un clúster, debes especificar una subred y los intervalos de direcciones IP secundarias que se usarán para los pods y los servicios del clúster. Hay varios motivos por los que un intervalo de direcciones IP puede no estar disponible. Tanto si creas el clúster con la Trusted Cloud consola como con la CLI de gcloud, debes especificar intervalos de direcciones IP utilizables.

Un intervalo de direcciones IP se puede usar para los servicios del nuevo clúster si el intervalo no está en uso. El intervalo de direcciones IP que especifiques para los pods del nuevo clúster puede ser un intervalo sin usar o un intervalo compartido con los pods de tus otros clústeres. Tu clúster no puede usar los intervalos de direcciones IP que crea y gestiona GKE.

Puedes consultar las subredes y los intervalos de direcciones IP secundarias utilizables de un proyecto con la CLI de gcloud.

gcloud

gcloud container subnets list-usable \
    --project SERVICE_PROJECT_ID \
    --network-project HOST_PROJECT_ID

Sustituye SERVICE_PROJECT_ID por el ID del proyecto de servicio.

Si omite la opción --project o --network-project, el comando de la CLI de gcloud usará el proyecto predeterminado de su configuración activa. Como el proyecto host y el proyecto de red son distintos, debes especificar --project o --network-project, o ambos.

El resultado debería ser similar al siguiente:

PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-2
RANGE: 172.16.4.0/22

SECONDARY_RANGE_NAME: tier-2-services
IP_CIDR_RANGE: 172.20.0.0/14
STATUS: usable for pods or services

SECONDARY_RANGE_NAME: tier-2-pods
IP_CIDR_RANGE: 172.16.16.0/20
STATUS: usable for pods or services

PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-1
RANGE: 10.0.4.0/22

SECONDARY_RANGE_NAME: tier-1-services
IP_CIDR_RANGE: 10.0.32.0/20
STATUS: usable for pods or services

SECONDARY_RANGE_NAME: tier-1-pods
IP_CIDR_RANGE: 10.4.0.0/14
STATUS: usable for pods or services

El comando list-usable devuelve una lista vacía en las siguientes situaciones:

  • Cuando la cuenta de servicio de GKE del proyecto de servicio no tiene el rol Usuario del agente de servicio host en el proyecto host.
  • Cuando la cuenta de servicio de GKE del proyecto host no existe (por ejemplo, si la has eliminado por error).
  • Cuando la API de GKE no está habilitada en el proyecto host, lo que implica que falta la cuenta de servicio de GKE en el proyecto host.

Para obtener más información, consulta la sección Solución de problemas.

Límites de intervalos de direcciones IP secundarias

Puedes crear 30 intervalos secundarios en una subred determinada. En cada clúster, necesitas dos intervalos secundarios: uno para los pods y otro para los servicios.

Crea un clúster en tu primer proyecto de servicio

Para crear un clúster en tu primer proyecto de servicio, sigue estos pasos con la CLI de gcloud o la Trusted Cloud consola.

Consola

  1. Ve a la página Google Kubernetes Engine en la Trusted Cloud consola.

    Ir a Google Kubernetes Engine

  2. En el selector de proyectos, selecciona tu primer proyecto de servicio.

  3. Haz clic en Crear.

  4. En la sección Autopilot o Estándar, haz clic en Configurar.

  5. En Nombre, escribe tier-1-cluster.

  6. En la lista desplegable Región, selecciona la misma región que usaste para las subredes.

  7. En el panel de navegación, haz clic en Redes.

  8. En Redes de clúster, selecciona shared-net.

  9. En Subred de nodos, selecciona nivel 1.

  10. En Opciones de redes avanzadas, en Intervalo de direcciones de pods predeterminado del clúster, selecciona pods-de-nivel-1.

  11. En Intervalo de direcciones de servicios, selecciona tier-1-services.

  12. Haz clic en Crear.

  13. Cuando se haya completado la creación, en la lista de clústeres, haga clic en tier-1-cluster.

  14. En la página Detalles del clúster, haga clic en la pestaña Nodos.

  15. En Grupos de nodos, haz clic en el nombre del grupo de nodos que quieras inspeccionar.

  16. En Grupos de instancias, haz clic en el nombre del grupo de instancias que quieras inspeccionar. Por ejemplo, gke-tier-1-cluster-default-pool-5c5add1f-grp.

  17. En la lista de instancias, comprueba que las direcciones IP internas de tus nodos se encuentren en el intervalo principal de la subred de nivel 1: 10.0.4.0/22.

gcloud

Crea un clúster llamado tier-1-cluster en tu primer proyecto de servicio:

gcloud container clusters create-auto tier-1-cluster \
    --project=SERVICE_PROJECT_1_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-1 \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services

Sustituye CONTROL_PLANE_LOCATION por la región de Compute Engine del plano de control de tu clúster.

Cuando se haya completado la creación, comprueba que los nodos del clúster se encuentran en el intervalo principal de la subred de nivel 1: 10.0.4.0/22.

gcloud compute instances list --project SERVICE_PROJECT_1_ID

El resultado muestra las direcciones IP internas de los nodos:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.2
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.3
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.4

Crea un clúster en tu segundo proyecto de servicio

Para crear un clúster en tu segundo proyecto de servicio, sigue estos pasos con la CLI de gcloud o la Trusted Cloud consola.

Consola

  1. Ve a la página Google Kubernetes Engine en la Trusted Cloud consola.

    Ir a Google Kubernetes Engine

  2. En el selector de proyectos, selecciona el segundo proyecto de servicio.

  3. Haz clic en Crear.

  4. En la sección Estándar o Autopiloto, haz clic en Configurar.

  5. En Nombre, escribe tier-2-cluster.

  6. En la lista desplegable Región, selecciona la misma región que usaste para las subredes.

  7. En el panel de navegación, haz clic en Redes.

  8. En Red, selecciona shared-net.

  9. En Subred de nodos, selecciona tier-2.

  10. En Intervalo de direcciones de pods predeterminado del clúster, selecciona pods-nivel-2.

  11. En Intervalo de direcciones de servicio, selecciona servicios de nivel 2.

  12. Haz clic en Crear.

  13. Cuando se haya completado la creación, en la lista de clústeres, haga clic en tier-2-cluster.

  14. En la página Detalles del clúster, haga clic en la pestaña Nodos.

  15. En Grupos de nodos, haz clic en el nombre del grupo de nodos que quieras inspeccionar.

  16. En Grupos de instancias, haz clic en el nombre del grupo de instancias que quieras inspeccionar. Por ejemplo, gke-tier-2-cluster-default-pool-5c5add1f-grp.

  17. En la lista de instancias, comprueba que las direcciones IP internas de tus nodos estén en el intervalo principal de la subred de nivel 2: 172.16.4.0/22.

gcloud

Crea un clúster llamado tier-2-cluster en tu segundo proyecto de servicio:

gcloud container clusters create-auto tier-2-cluster \
    --project=SERVICE_PROJECT_2_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-2 \
    --cluster-secondary-range-name=tier-2-pods \
    --services-secondary-range-name=tier-2-services

Cuando se haya completado la creación, comprueba que los nodos del clúster se encuentran en el intervalo principal de la subred de nivel 2: 172.16.4.0/22.

gcloud compute instances list --project SERVICE_PROJECT_2_ID

El resultado muestra las direcciones IP internas de los nodos:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.2
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.3
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.4

Crear reglas de cortafuegos

Para permitir el tráfico en la red y entre los clústeres de la red, debes crear cortafuegos. En las siguientes secciones se muestra cómo crear y actualizar reglas de cortafuegos:

Crear una regla de cortafuegos para habilitar la conexión SSH a un nodo

En tu proyecto host, crea una regla de cortafuegos para la red shared-net. Permite que el tráfico entre por el puerto TCP 22, lo que te permite conectarte a los nodos de tu clúster mediante SSH.

Consola

  1. Ve a la página Cortafuegos de la Trusted Cloud consola.

    Ir a Cortafuegos

  2. En el selector de proyectos, selecciona el proyecto host.

  3. En el menú Redes de VPC, haz clic en Crear regla de cortafuegos.

  4. En Nombre, escribe my-shared-net-rule.

  5. En Red, selecciona shared-net.

  6. En Dirección del tráfico, selecciona Entrada.

  7. En Acción tras coincidencia, selecciona Permitir.

  8. En Destinos, selecciona Todas las instancias de la red.

  9. En Filtro de origen, selecciona Intervalos de IP.

  10. En Intervalos de IP de origen, introduce 0.0.0.0/0.

  11. En Protocolos y puertos, selecciona Protocolos y puertos especificados. En el cuadro, escribe tcp:22.

  12. Haz clic en Crear.

gcloud

Crea una regla de cortafuegos para tu red compartida:

gcloud compute firewall-rules create my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --direction INGRESS \
    --allow tcp:22

Conectarse a un nodo mediante SSH

Después de crear el cortafuegos que permite el tráfico de entrada en el puerto TCP 22, conéctate al nodo mediante SSH.

Consola

  1. Ve a la página Google Kubernetes Engine en la Trusted Cloud consola.

    Ir a Google Kubernetes Engine

  2. En el selector de proyectos, selecciona tu primer proyecto de servicio.

  3. Haz clic en tier-1-cluster.

  4. En la página Detalles del clúster, haga clic en la pestaña Nodos.

  5. En Grupos de nodos, haz clic en el nombre del grupo de nodos.

  6. En Grupos de instancias, haz clic en el nombre del grupo de instancias. Por ejemplo, gke-tier-1-cluster-default-pool-faf87d48-grp.

  7. En la lista de instancias, anota las direcciones IP internas de los nodos. Estas direcciones están en el intervalo 10.0.4.0/22.

  8. En uno de tus nodos, haz clic en SSH. Esto se realiza correctamente porque SSH usa el puerto TCP 22, que está permitido por tu regla de cortafuegos.

gcloud

Lista los nodos de tu primer proyecto de servicio:

gcloud compute instances list --project SERVICE_PROJECT_1_ID

La salida incluye los nombres de los nodos de tu clúster:

NAME                                           ...
gke-tier-1-cluster-default-pool-faf87d48-3mf8  ...
gke-tier-1-cluster-default-pool-faf87d48-q17k  ...
gke-tier-1-cluster-default-pool-faf87d48-x9rk  ...

Conéctate a uno de tus nodos mediante SSH:

gcloud compute ssh NODE_NAME \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

Haz los cambios siguientes:

  • NODE_NAME: el nombre de uno de tus nodos.
  • COMPUTE_ZONE: el nombre de una zona de Compute Engine de la región.

Actualiza la regla de cortafuegos para permitir el tráfico entre nodos

  1. En la ventana de línea de comandos de SSH, inicia CoreOS Toolbox:

    /usr/bin/toolbox

  2. En el shell de la caja de herramientas, haz ping a uno de tus otros nodos del mismo clúster. Por ejemplo:

    ping 10.0.4.4

    El comando ping se ejecuta correctamente porque tu nodo y el otro nodo están dentro del intervalo 10.0.4.0/22.

  3. Ahora, prueba a hacer ping a uno de los nodos del clúster en tu otro proyecto de servicio. Por ejemplo:

    ping 172.16.4.3

    Esta vez, el comando ping falla porque tu regla de cortafuegos no permite el tráfico del protocolo de mensajes de control de Internet (ICMP).

  4. En una petición de comando normal, no en el shell de tu caja de herramientas, actualiza la regla del cortafuegos para permitir ICMP:

    gcloud compute firewall-rules update my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --allow tcp:22,icmp

  5. En el shell de la caja de herramientas, haz ping al nodo de nuevo. Por ejemplo:

    ping 172.16.4.3

    Esta vez, el comando ping se ejecuta correctamente.

Crear reglas de cortafuegos adicionales

Puedes crear reglas de cortafuegos adicionales para permitir la comunicación entre nodos, pods y servicios de tus clústeres.

Por ejemplo, la siguiente regla permite que entre tráfico desde cualquier nodo, pod o servicio de tier-1-cluster en cualquier puerto TCP o UDP:

gcloud compute firewall-rules create my-shared-net-rule-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 10.0.4.0/22,10.4.0.0/14,10.0.32.0/20

La siguiente regla permite que entre tráfico desde cualquier nodo, pod o servicio de tier-2-cluster en cualquier puerto TCP o UDP:

gcloud compute firewall-rules create my-shared-net-rule-3 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 172.16.4.0/22,172.20.0.0/14,172.16.16.0/20

Kubernetes también intentará crear y gestionar recursos de firewall cuando sea necesario, por ejemplo, cuando crees un servicio de balanceador de carga. Si Kubernetes no puede cambiar las reglas del cortafuegos debido a un problema de permisos, se generará un evento de Kubernetes para indicarte cómo hacer los cambios.

Si quieres conceder permiso a Kubernetes para cambiar las reglas de firewall, consulta Gestión de recursos de firewall.

En el caso de los balanceadores de carga de entrada, si Kubernetes no puede cambiar las reglas de cortafuegos debido a que no tiene permisos suficientes, se emite un evento firewallXPNError cada varios minutos. En GLBC 1.4 y versiones posteriores, puedes silenciar el evento firewallXPNError añadiendo la anotación networking.gke.io/suppress-firewall-xpn-error: "true" al recurso de entrada. Puedes eliminar esta anotación en cualquier momento para reactivar el audio.

Crear un clúster basado en el emparejamiento entre redes de VPC en una VPC compartida

Puedes usar VPC compartida con clústeres basados en el emparejamiento entre redes de VPC.

Para ello, debes conceder los siguientes permisos en el proyecto host a la cuenta de usuario o a la cuenta de servicio que se utilice para crear el clúster:

  • compute.networks.get

  • compute.networks.updatePeering

También debes asegurarte de que el intervalo de direcciones IP del plano de control no se solape con otros intervalos reservados de la red compartida.

En esta sección, crearás un clúster nativo de VPC llamado cluster-vpc en una red de VPC compartida predefinida.

Consola

  1. Ve a la página Google Kubernetes Engine en la Trusted Cloud consola.

    Ir a Google Kubernetes Engine

  2. Haz clic en Crear.

  3. En la sección Autopilot o Estándar, haz clic en Configurar.

  4. En Nombre, escribe cluster-vpc.

  5. En el panel de navegación, haz clic en Redes.

  6. Selecciona Clúster privado.

  7. (Opcional para Autopilot): asigna el valor Intervalo de direcciones IP del plano de control a 172.16.0.16/28.

  8. En la lista desplegable Red, selecciona la red de VPC que has creado anteriormente.

  9. En la lista desplegable Subred de nodos, selecciona la subred compartida que has creado anteriormente.

  10. Configura el clúster según sea necesario.

  11. Haz clic en Crear.

gcloud

Ejecuta el siguiente comando para crear un clúster llamado cluster-vpc en una VPC compartida predefinida:

gcloud container clusters create-auto private-cluster-vpc \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT/global/networks/shared-net \
    --subnetwork=SHARED_SUBNETWORK \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services \
    --enable-private-nodes \
    --master-ipv4-cidr=172.16.0.0/28

Reservar direcciones IP

Puedes reservar direcciones IP internas y externas para tus clústeres de VPC compartida. Asegúrate de que las direcciones IP estén reservadas en el proyecto de servicio.

En el caso de las direcciones IP internas, debe proporcionar la subred a la que pertenece la dirección IP. Para reservar una dirección IP en varios proyectos, usa la URL de recurso completa para identificar la subred.

Puedes usar el siguiente comando en la CLI de Google Cloud para reservar una dirección IP interna:

gcloud compute addresses create RESERVED_IP_NAME \
    --region=COMPUTE_REGION \
    --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNETWORK_NAME \
    --addresses=IP_ADDRESS \
    --project=SERVICE_PROJECT_ID

Para llamar a este comando, debes tener el permiso compute.subnetworks.use añadido a la subred. Puedes asignar al llamante el rol compute.networkUser en la subred o asignarle un rol personalizado con el permiso compute.subnetworks.use a nivel de proyecto.

Limpieza

Después de completar los ejercicios de esta guía, realiza las siguientes tareas para quitar los recursos y evitar que se apliquen cargos no deseados en tu cuenta:

Eliminar los clústeres

Elimina los dos clústeres que has creado.

Consola

  1. Ve a la página Google Kubernetes Engine en la Trusted Cloud consola.

    Ir a Google Kubernetes Engine

  2. En el selector de proyectos, selecciona tu primer proyecto de servicio.

  3. Selecciona tier-1-cluster y haz clic en Eliminar.

  4. En el selector de proyectos, selecciona el segundo proyecto de servicio.

  5. Selecciona tier-2-cluster y haz clic en Eliminar.

gcloud

gcloud container clusters delete tier-1-cluster \
    --project SERVICE_PROJECT_1_ID \
    --location CONTROL_PLANE_LOCATION

gcloud container clusters delete tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --location CONTROL_PLANE_LOCATION

Inhabilitar VPC compartida

Inhabilita la VPC compartida en tu proyecto host.

Consola

  1. Ve a la página VPC compartida de la Trusted Cloud consola.

    Ir a VPC compartida

  2. En el selector de proyectos, selecciona el proyecto host.

  3. Haz clic en Inhabilitar VPC compartida.

  4. Introduce el HOST_PROJECT_ID en el campo y haz clic en Inhabilitar.

gcloud

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc disable HOST_PROJECT_ID

Eliminar reglas de cortafuegos

Elimina las reglas de cortafuegos que has creado.

Consola

  1. Ve a la página Cortafuegos de la Trusted Cloud consola.

    Ir a Cortafuegos

  2. En el selector de proyectos, selecciona el proyecto host.

  3. En la lista de reglas, selecciona my-shared-net-rule, my-shared-net-rule-2 y my-shared-net-rule-3.

  4. Haz clic en Eliminar.

gcloud

Elimina las reglas de cortafuegos:

gcloud compute firewall-rules delete \
    my-shared-net-rule \
    my-shared-net-rule-2 \
    my-shared-net-rule-3 \
    --project HOST_PROJECT_ID

Eliminar la red compartida

Elimina la red compartida que has creado.

Consola

  1. Ve a la página Redes de VPC de la consola de Trusted Cloud .

    Ir a redes de VPC

  2. En el selector de proyectos, selecciona el proyecto host.

  3. En la lista de redes, selecciona shared-net.

  4. Haz clic en Eliminar red de VPC.

gcloud

gcloud compute networks subnets delete tier-1 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks subnets delete tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks delete shared-net --project HOST_PROJECT_ID

Quitar el rol de usuario Agente de servicio del host

Quita los roles de usuario del agente de servicio de host de tus dos proyectos de servicio.

Consola

  1. Ve a la página Gestión de identidades y accesos de la Trusted Cloud consola.

    Ir a IAM

  2. En el selector de proyectos, selecciona el proyecto host.

  3. En la lista de miembros, selecciona la fila que muestra que se ha concedido el rol Usuario del agente de servicio de host de Kubernetes Engine aservice-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com.

  4. Selecciona la fila que muestra que se ha concedido el rol de usuario Agente de servicio de host de Kubernetes Engine a service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com.

  5. Haz clic en Quitar acceso.

gcloud

  1. Quita el rol Usuario del agente de servicio del host de la cuenta de servicio de GKE de tu primer proyecto de servicio:

    gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

  2. Quita el rol Usuario del agente de servicio del host de la cuenta de servicio de GKE de tu segundo proyecto de servicio:

    gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

Solución de problemas

En las siguientes secciones se explica cómo resolver problemas habituales con clústeres de VPC compartida.

Error: no se han podido obtener los metadatos del proyecto de red

El siguiente mensaje es un error habitual al trabajar con clústeres de VPC compartida:

Failed to get metadata from network project. GCE_PERMISSION_DENIED: Google
Compute Engine: Required 'compute.projects.get' permission for
'projects/HOST_PROJECT_ID

Este error puede producirse por los siguientes motivos:

  • La API de GKE no se ha habilitado en el proyecto host.

  • La cuenta de servicio de GKE del proyecto host no existe. Por ejemplo, puede que se haya eliminado.

  • La cuenta de servicio de GKE del proyecto host no tiene el rol Agente de servicio de Kubernetes Engine (container.serviceAgent) en el proyecto host. Es posible que la vinculación se haya eliminado por error.

  • La cuenta de servicio de GKE del proyecto de servicio no tiene el rol de usuario de agente de servicio Host en el proyecto host.

Para solucionar el problema, determina si existe la cuenta de servicio de GKE del proyecto host.

Si la cuenta de servicio no existe, haz lo siguiente:

  • Si la API de GKE no está habilitada en el proyecto host, habilítala. De esta forma, se crea la cuenta de servicio de GKE del proyecto host y se le asigna el rol Agente de servicio de Kubernetes Engine (container.serviceAgent) en el proyecto host.

  • Si la API de GKE está habilitada en el proyecto host, significa que se ha eliminado la cuenta de servicio de GKE del proyecto host o que no tiene el rol Agente de servicio de Kubernetes Engine (container.serviceAgent) en el proyecto host. Para restaurar la cuenta de servicio de GKE o la vinculación de roles, debes inhabilitar y volver a habilitar la API de GKE. Para obtener más información, consulta Error 400 o 403: la cuenta no tiene permisos de edición.

Problema: conectividad

Si tienes problemas de conectividad entre máquinas virtuales de Compute Engine que están en la misma red de nube privada virtual (VPC) o en dos redes de VPC conectadas mediante el emparejamiento de redes de VPC, consulta el artículo Solucionar problemas de conectividad entre instancias de máquinas virtuales con direcciones IP internas de la documentación de la nube privada virtual (VPC).

Problema: pérdida de paquetes

Si tienes problemas de pérdida de paquetes al enviar tráfico desde un clúster a una dirección IP externa mediante Cloud NAT, clústeres nativos de VPC o el agente de enmascaramiento de IP, consulta el artículo Solucionar problemas de pérdida de paquetes de Cloud NAT desde un clúster.

Siguientes pasos