Configura clústeres con VPC compartida

Autopilot Estándar

---

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

Descripción general

Con una VPC compartida, designas un proyecto como el proyecto host y vinculas otros, llamados proyectos de servicio, a ese proyecto host. Puedes crear redes, subredes, rangos de direcciones secundarios, reglas de firewall y otros recursos de red en el proyecto host. Luego, puedes compartir las subredes seleccionadas, incluidos los rangos 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 la VPC compartida con clústeres de Autopilot y con clústeres de Standard zonales y regionales.

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

Puedes configurar la VPC compartida cuando creas un clúster nuevo. GKE no admite la conversión de clústeres existentes al modelo de VPC compartida.

Se aplican algunas cuotas y límites al uso de VPC compartidas. Por ejemplo, existe una cuota por la cantidad de redes de un proyecto y hay un límite para la cantidad de proyectos de servicio que se pueden vincular a un proyecto host. Para obtener más detalles, consulta Cuotas y límites.

Acerca de los ejemplos

En los ejemplos de esta guía, se configura la infraestructura para una aplicación web de dos niveles, como se señala en la Descripción general de la VPC compartida.

Antes de comenzar

Antes de comenzar a configurar un clúster con VPC compartida:

• Asegúrate de tener una organización de Google Cloud.
• Asegúrate de que tu organización tenga tres proyectos de Google Cloud.
• Asegúrate de estar familiarizado con los conceptos de la VPC compartida, incluidos los diferentes roles de Identity and Access Management (IAM) que usa la VPC compartida. Un administrador de VPC compartida puede realizar las tareas de esta guía.
• Asegúrate de estar familiarizado con las restricciones de las políticas de la organización que se aplican a tu organización, carpeta o a tus proyectos. Un administrador de políticas de la organización podría tener restricciones definidas que limitan qué subredes se pueden compartir o qué proyectos pueden ser proyectos host de VPC compartida. Consulta las restricciones de políticas de la organización para obtener más información.

Antes de realizar los ejercicios de esta guía, sigue estos pasos:

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

Todos los proyectos tienen un nombre, un ID y un número. En algunos casos, el nombre y el ID coinciden. En esta guía, se usan los siguientes marcadores de posición y nombres descriptivos para referirse a tus proyectos:

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

Nota: El primer y el segundo proyecto de servicio pueden no respetar ese orden. Los términos “primero” y “segundo” solo se usan para distinguirlos.

Busca los ID y números del proyecto

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

Console

1. Ve a la página principal de la consola de Google Cloud.

   Ir a la Página principal

2. En el selector de proyectos, selecciona el proyecto que elegiste para ser el host.

3. En Información del proyecto, puedes ver su nombre, ID y número. Toma nota del ID y el número para más adelante.

4. Haz lo mismo con todos los proyectos que elegiste para que sean los de servicio.

gcloud

Enumera tus proyectos con el siguiente comando:

gcloud projects list

En la salida, se muestran los nombres, ID y números de los proyectos. Toma nota de los números y los ID 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

Habilita 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. Cuando se habilita la API en un proyecto, se crea una cuenta de servicio de GKE. 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 consola de Google Cloud o la CLI de Google Cloud.

Console

1. Ve a la página API y servicios en la consola de Google Cloud.

   Ir a API y servicios

2. En el selector de proyectos, selecciona el proyecto que elegiste para que sea el host.

3. Si la API de Kubernetes Engine aparece en la lista, eso significa que ya está habilitada y no es necesario que hagas nada. De lo contrario, haz clic en Habilitar API y servicios. Busca Kubernetes Engine API. Haz clic en la tarjeta API de Kubernetes Engine y, luego, en Habilitar.

4. Repite estos pasos en todos los proyectos que elegiste para que sean de servicio. Es posible que cada operación tome un tiempo en completarse.

gcloud

Habilita la API de GKE para los tres proyectos. Es posible que cada operación tarde un poco 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

Crea una red y dos subredes

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

1. En tu proyecto host, crea una red llamada shared-net.
2. Crea dos subredes llamadas tier-1 y tier-2.
3. En cada subred crea dos rangos de direcciones secundarios: uno para objetos Service y otro para Pods.

Nota: Los rangos de direcciones secundarios para pods, objetos Service y nodos no se deben superponer con 172.17.0.0/16 y deben seguir los valores predeterminados y límites de tamaños de los rangos.

Console

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

   Ir a las redes de VPC

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

3. Haz clic en Crear red de VPC.

4. En Nombre, ingresa shared-net.

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

6. Dentro de la casilla Subred nueva, en Nombre, ingresa tier-1.

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

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

9. En el Rango de IPv4, ingresa 10.0.4.0/22.

10. Haz clic en Crear rango IPv4 secundario. En Nombre de rango de subred, ingresa tier-1-services y, en Rango de IPv4 secundario, ingresa 10.0.32.0/20.

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

12. Haz clic en Agregar subred.

13. En Nombre, ingresa tier-2.

14. En Región, elige la misma región que seleccionaste para la subred anterior.

15. En el Rango de IPv4, ingresa 172.16.4.0/22.

16. Haz clic en Crear rango IPv4 secundario. En Nombre de rango de subred, ingresa tier-2-services y, en Rango de IPv4 secundario, ingresa 172.16.16.0/20.

17. Haz clic en Agregar rango de IP. En Nombre de rango de subred, ingresa tier-2-pods y, en Rango de IPv4 secundario, ingresa 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 red nueva, 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

Reemplaza COMPUTE_REGION por una región de Compute Engine.

Determina los nombres de las cuentas de servicio en tus proyectos de servicio

Tienes dos proyectos de servicio y cada uno de ellos tiene varias cuentas de servicio. En esta sección se tratan las cuentas de servicio de GKE y las cuentas de servicio de las API de Google. Necesitarás los nombres de estas cuentas de servicio en la próxima sección.

En la siguiente tabla, se enumeran los nombres de las cuentas de servicio de GKE y las API de Google en tus dos proyectos de servicio:

Tipo de cuenta de servicio	Nombre de la cuenta de servicio
GKE	[e-mail]
	[e-mail]
API de Google	[e-mail]
	[e-mail]

Habilita la VPC compartida y asigna funciones

Para realizar las tareas de esta sección, asegúrate de que tu organización haya definido una función de administrador de VPC compartida.

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

1. En tu proyecto host, habilita la VPC compartida.
2. Vincula los dos proyectos de servicio al proyecto host.
3. Otorga las funciones de IAM adecuadas a las cuentas de servicio que pertenecen a tus proyectos de servicio:
   • En tu primer proyecto de servicio, otorga a dos cuentas de servicio la función Compute Network User en la subred tier-1 de tu proyecto host.
   • En tu segundo proyecto de servicio, otorga a dos cuentas de servicio la función Compute Network User en la subred tier-2 de tu proyecto host.

Console

Realiza los siguientes pasos para habilitar la VPC compartida, vincular proyectos de servicio y otorgar roles:

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

   Ir a VPC compartida

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

3. Haz clic en Configurar VPC compartida. Aparecerá la pantalla Habilitar proyecto host.

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

5. En Modo de uso compartido, selecciona Subredes individuales.

6. En Subredes que se compartirán, marca tier-1 y tier-2. Desmarca todas las otras casillas de verificación.

7. Haz clic en Continuar. Aparecerá la página Otorgar permisos.

8. En Vincular proyectos de servicio, marca tus dos proyectos de servicio. Desmarca todas las otras casillas de verificación en Vincular proyectos de servicio.

9. En Acceso a Kubernetes Engine, marca Habilitado.

10. Haz clic en Guardar. Aparecerá una página nueva.

11. En Permisos individuales de la subred, marca tier-1.

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

13. En el panel de la derecha, busca los nombres de las cuentas de servicio de Kubernetes Engine y las API de Google que pertenezcan a tu primer proyecto de servicio. Deberías ver los nombres de ambas cuentas en la lista. Si alguna de ellas no aparece, ingresa su nombre en Agregar miembros y haz clic en Agregar.

14. En el panel central, en Permisos individuales de la subred, marca tier-2 y desmarca tier-1.

15. En el panel de la derecha, borra las cuentas de servicio que pertenezcan a tu primer proyecto de servicio. Es decir, las que contengan SERVICE_PROJECT_1_NUM.

16. En el panel de la derecha, busca los nombres de las cuentas de servicio de Kubernetes Engine y las API de Google que pertenezcan a tu segundo proyecto de servicio. Deberías ver los nombres de ambas cuentas en la lista. Si alguna de ellas no aparece, ingresa su nombre en Agregar miembros y haz clic en Agregar.

gcloud

1. Habilita la VPC compartida en tu proyecto host. El comando que uses depende de la función administrativa requerida que tengas.

   Si tienes una función de administrador de VPC compartida a nivel de organización, usa este comando:

   gcloud compute shared-vpc enable HOST_PROJECT_ID
   

   Si tienes una función de administrador de VPC compartida a nivel de carpeta, usa este comando:

   gcloud beta compute shared-vpc enable HOST_PROJECT_ID
   

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

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

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

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

4. Obtén la política de IAM para 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. Toma nota del valor de etag.

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

   bindings:
   - members:
     - serviceAccount:[e-mail]
     - serviceAccount:[e-mail]
     role: roles/compute.networkUser
   etag: ETAG_STRING
   

   Reemplaza ETAG_STRING por el valor de etag que anotaste antes.

6. Establece la política de IAM para 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 IAM para 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. Toma nota del valor de etag.

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

   bindings:
   - members:
     - serviceAccount:[e-mail]
     - serviceAccount:[e-mail]
     role: roles/compute.networkUser
   etag: ETAG_STRING
   

   Reemplaza ETAG_STRING por el valor de etag que anotaste antes.

9. Establece la política de IAM para la subred tier-2:

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

Administra recursos de firewall

Si deseas que un clúster de GKE en un proyecto de servicio cree y administre los recursos de firewall en tu proyecto host, a la cuenta de servicio de GKE del proyecto de servicio se le debe otorgar los permisos de IAM adecuados mediante una de las siguientes estrategias:

Nota: Para seguir las prácticas recomendadas de seguridad, elige el enfoque más detallado. Si otorgas a la cuenta de servicio de GKE del proyecto de servicio la función de administrador de seguridad de Compute, se le otorgarán más permisos de IAM de los necesarios para los fines de esta guía.

• Otorga a la cuenta de servicio de GKE del proyecto de servicio la función Compute Security Admin para el proyecto host.

Console

1. En la consola de Google Cloud, ve a la página IAM.

   Ir a IAM

2. Selecciona el Proyecto host.

3. Haz clic en Otorgar acceso y, luego, ingresa el principal de la cuenta de servicio de GKE del proyecto de servicio, [e-mail].

4. Selecciona la función Compute Security Admin en la lista desplegable.

5. Haz clic en Guardar.

gcloud

Otorga a la cuenta de servicio de GKE del proyecto de servicio la función Compute Security Admin para el proyecto host.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:[e-mail] \
    --role=roles/compute.securityAdmin

Reemplaza lo siguiente:

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

• Para un enfoque más detallado, crea una función de IAM personalizada 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. Otorga a la cuenta de servicio de GKE del proyecto de servicio esa función personalizada para el proyecto host.

Console

Crea un rol personalizado en el proyecto host que contiene los permisos de IAM que se mencionaron antes:

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

   Ir a la página Roles

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

3. Haz clic en Crear función.

4. Ingresa un Título, una Descripción, un ID y una Etapa de lanzamiento de la función para la función. El nombre de la función no se puede cambiar después de que se crea la función.

5. Haz clic en Agregar permisos.

6. Filtra compute.networks y selecciona los permisos de IAM que se mencionaron antes.

7. Una vez que hayas seleccionado todos los permisos necesarios, haz clic en Agregar.

8. Haz clic en Crear.

Otorga a la cuenta de servicio de GKE del proyecto de servicio la función personalizada recién creada en el proyecto host:

1. En la consola de Google Cloud, ve a la página IAM.

   Ir a IAM

2. Selecciona el Proyecto host.

3. Haz clic en Otorgar acceso y, luego, ingresa el principal de la cuenta de servicio de GKE del proyecto de servicio, [e-mail].

4. Filtra el Título de la función personalizada recién creada y selecciónala.

5. Haz clic en Guardar.

gcloud

1. Crea un rol personalizado en el proyecto host que contiene los permisos de IAM que se mencionaron antes:

   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. Otorga a la cuenta de servicio de GKE del proyecto de servicio la función personalizada recién creada en el proyecto host:

   gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
       --member=serviceAccount:[e-mail] \
       --role=projects/HOST_PROJECT_ID/roles/ROLE_ID
   

   Reemplaza lo siguiente:

   • ROLE_ID: Es el nombre de la función, como gkeFirewallAdmin.
   • ROLE_TITLE es un título descriptivo para la función, como GKE Firewall Admin.
   • ROLE_DESCRIPTION es una descripción breve de la función, como GKE service account FW permissions.
   • LAUNCH_STAGE: Es la etapa de lanzamiento de la función en su ciclo de vida, como ALPHA, BETA o GA.
   • HOST_PROJECT_ID: El ID del proyecto host de VPC compartida
   • SERVICE_PROJECT_NUM: El ID del proyecto de servicio 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 la cuenta de servicio de GKE del proyecto de servicio.

Nota: Si usas Ingress para balanceadores de cargas de aplicaciones internos, el controlador de Ingress no crea una regla de firewall para permitir conexiones desde los proxies del balanceador de cargas en la subred de proxy. Debes crear esta regla de firewall de forma manual. Sin embargo, el controlador de Ingress crea reglas de firewall a fin de permitir el ingreso para las verificaciones de estado de Google Cloud.

Resumen de las funciones otorgadas en las subredes

Este es un resumen de las funciones otorgadas en las subredes:

Cuenta de servicio	Función	Subred
[e-mail]	Usuario de la red de Compute	tier-1
[e-mail]	Usuario de la red de Compute	tier-1
[e-mail]	Usuario de la red de Compute	tier-2
[e-mail]	Usuario de la red de Compute	tier-2

Acceso a Kubernetes Engine

Cuando se vincula un proyecto de servicio, habilitar el acceso a Kubernetes Engine otorga a la cuenta de servicio de GKE del proyecto de servicio los permisos para realizar operaciones de administración de red en el proyecto host.

GKE asigna automáticamente el siguiente rol en el proyecto host cuando se habilita el acceso a Kubernetes Engine:

Miembro	Función	Recurso
[e-mail]	Usuario del agente de servicio de host	Cuenta de servicio de GKE en el proyecto host

Sin embargo, debes agregar el permiso Compute Network User de IAM de forma manual a la cuenta de servicio de GKE del proyecto de servicio para acceder a la red host.

Miembro	Función	Recurso
[e-mail]	Usuario de la red de Compute	Subred específica o proyecto host completo

Si se vinculó un proyecto de servicio sin habilitar el acceso a Kubernetes Engine, siempre y cuando se haya habilitado la API de Kubernetes Engine en el proyecto host y en el de servicio, puedes asignar de forma manual los permisos a la cuenta de servicio de GKE del proyecto de servicio mediante las siguientes vinculaciones de funciones de IAM en el proyecto host.

Miembro	Función	Recurso
[e-mail]	Usuario de la red de Compute	Subred específica o proyecto host completo
[e-mail]	Usuario del agente de servicio de host	Cuenta de servicio de GKE en el proyecto host

Otorga la función Usuario de agente de servicio de host

Cada cuenta de servicio de GKE del proyecto de servicio debe tener una vinculación para la función de usuario del agente de servicios de host en el proyecto host. La cuenta de servicio de GKE adopta el siguiente formato:

[e-mail]

En el ejemplo anterior, SERVICE_PROJECT_NUM es el número del proyecto de servicio.

Esta vinculación permite que la cuenta de servicio de GKE del proyecto de servicio realice operaciones de administración de red en el proyecto host, como si fuera la cuenta de servicio de GKE de ese proyecto. Esta función solo se puede otorgar a una cuenta de servicio de GKE de un proyecto de servicio.

Console

Si usas la consola de Google Cloud, no es necesario que otorgues la función Usuario de agente de servicio de host de forma explícita, ya que esto se hizo de forma automática cuando vinculaste tus proyectos de servicio al proyecto host con la consola de Google Cloud.

gcloud

1. Para tu primer proyecto, otorga la función de usuario del agente de servicios de host a la cuenta de servicio de GKE del proyecto. Esta función se otorga en el proyecto host:

   gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

2. Para tu segundo proyecto, otorga la función de usuario del agente de servicios de host a la cuenta de servicio de GKE del proyecto. Esta función se otorga en el proyecto host:

   gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

Verifica los rangos de IP secundarios y las subredes que se pueden usar

Cuando creas un clúster, debes especificar una subred y los rangos de IP secundarios que se usarán para los pods y los objetos Service del clúster. Existen varios motivos por los que un rango de direcciones IP puede no estar disponible. Cuando crees el clúster con la consola de Google Cloud o gcloud CLI, debes especificar rangos de direcciones IP que se pueden usar.

Un rango de direcciones IP se puede usar para los servicios del clúster nuevo si aún no está en uso. El rango de direcciones IP que especificas para los Pods del clúster nuevo puede ser uno que no hayas usado o uno compartido con los Pods de tus otros clústeres. Los rangos de direcciones IP que se crean y administran en GKE no se pueden usar en el clúster.

Para enumerar los rangos de direcciones IP secundarios y las subredes que se pueden usar de un proyecto, usa la gcloud CLI.

gcloud

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

Reemplaza SERVICE_PROJECT_ID por el ID del proyecto de servicio.

Si omites la opción --project o --network-project, el comando de gcloud CLI usa el proyecto predeterminado de tu configuración activa. Debido a que el proyecto host y el de red son distintos, debes especificar --project o --network-project, o ambos.

El resultado es 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 muestra una lista vacía en las siguientes situaciones:

• Cuando la cuenta de servicio de Kubernetes Engine del proyecto de servicio no tiene la función de usuario del agente de servicios de host para el proyecto host.
• Cuando la cuenta de servicio de Kubernetes Engine no existe en el proyecto host (por ejemplo, si la borraste por accidente).
• Cuando la API de Kubernetes Engine no está habilitada en el proyecto host, lo que implica que falta la cuenta de servicio de Kubernetes Engine en el proyecto host.

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

Notas sobre rangos secundarios

Puedes crear 30 rangos secundarios en una subred. Necesitas dos rangos secundarios por cada clúster: uno para los pods y otro para los objetos Service.

Nota: El rango primario y el rango secundario del pod se pueden compartir entre clústeres, pero no se recomienda.

Crea un clúster en el primer proyecto de servicio

Para crear un clúster en el primer proyecto de servicio, realiza los siguientes pasos con la CLI de gcloud o la consola de Google Cloud.

Console

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

   Ir a Google Kubernetes Engine

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

3. Haz clic en Crear.

4. En la sección Autopilot o Standard, haz clic en Configurar.

5. En Nombre, ingresa 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 Herramientas de redes.

8. Selecciona Redes compartidas conmigo (del proyecto host).

9. En Red, selecciona shared-net.

10. En Subred del nodo, selecciona tier-1.

11. En Rango de CIDR secundario de pods, selecciona pods de tier-1.

12. En Rango de CIDR secundario de servicios, selecciona tier-1-services.

13. Haz clic en Crear.

14. Cuando finalice la creación, haz clic en tier-1-cluster en la lista de clústeres.

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

16. En Grupos de nodos, haz clic en el nombre del grupo de nodos que deseas inspeccionar.

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

18. En la lista de instancias, verifica que las direcciones IP internas de tus nodos se encuentren en el rango principal de la subred tier-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=COMPUTE_REGION \
    --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

Cuando finalice la creación, verifica que los nodos de tu clúster se encuentren en el rango principal de la subred tier-1: 10.0.4.0/22

gcloud compute instances list --project SERVICE_PROJECT_1_ID

En los resultados, se mostrarán 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 el segundo proyecto de servicio

Para crear un clúster en el segundo proyecto de servicio, realiza los siguientes pasos con la CLI de gcloud o la consola de Google Cloud.

Console

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

   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 Standard o Autopilot, haz clic en Configurar.

5. En Nombre, ingresa 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 Herramientas de redes.

8. En Red, selecciona shared-net.

9. En Subred del nodo, selecciona tier-2.

10. En Rango de CIDR secundario de pods, selecciona tier-2-pods.

11. En Rango de CIDR secundario de servicios, selecciona tier-2-services.

12. Haz clic en Crear.

13. Cuando finalice la creación, haz clic en tier-2-cluster en la lista de clústeres.

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

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

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

17. En la lista de instancias, verifica que las direcciones IP internas de tus nodos se encuentren en el rango principal de la subred tier-2: 172.16.4.0/22.

gcloud

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

gcloud container clusters create-auto tier-2-cluster \
    --project=SERVICE_PROJECT_2_ID \
    --location=COMPUTE_REGION \
    --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 finalice la creación, verifica que los nodos de tu clúster se encuentren en el rango principal de la subred tier-2: 172.16.4.0/22.

gcloud compute instances list --project SERVICE_PROJECT_2_ID

En los resultados, se mostrarán 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

Crea reglas de firewall

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

• Crea una regla de firewall para habilitar la conexión SSH a un nodo: Demuestra cómo crear una regla de firewall que habilite el tráfico desde fuera de los clústeres mediante SSH.

• Actualiza la regla de firewall para hacer ping entre nodos: Demuestra cómo actualizar la regla de firewall para permitir el tráfico ICMP entre los clústeres.

  Se usan ICMP y SSH como ejemplos; debes crear reglas de firewall que te permitan cumplir con los requisitos de red de tu aplicación específica.

Nota: Los administradores de VPC compartida son responsables de crear reglas de firewall en la red de VPC compartida.

Crea una regla de firewall para habilitar la conexión SSH con un nodo

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

Console

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

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

3. En el menú Herramientas de redes de VPC, haz clic en Crear regla de firewall.

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

5. En Red, selecciona shared-net.

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

7. En Acción en caso de coincidencia, selecciona Permitir.

8. En Destinos, haz clic en Todas las instancias de la red.

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

10. En Rangos de IP de origen, ingresa 0.0.0.0/0.

11. En Protocolos y puertos, selecciona Puertos y protocolos especificados. En el cuadro, ingresa tcp:22.

12. Haz clic en Crear.

gcloud

Crea una regla de firewall 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

Conéctate a un nodo mediante SSH

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

Console

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

   Ir a Google Kubernetes Engine

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

3. Haz clic en tier-1-cluster.

4. En la página Detalles del clúster, haz 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 nodos, toma nota de la dirección IP interna de los nodos. Las direcciones se encuentran en el rango 10.0.4.0/22.

8. En uno de tus nodos, haz clic en SSH. Esto funciona porque SSH usa el puerto TCP 22, que tu regla de firewall permite.

gcloud

Haz una lista de los nodos de tu primer proyecto de servicio:

gcloud compute instances list --project SERVICE_PROJECT_1_ID

En el resultado aparecerán 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 los nodos con SSH:

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

Reemplaza lo siguiente:

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

Actualiza la regla de firewall para hacer ping entre nodos

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

   /usr/bin/toolbox
   

2. En la 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 funciona porque ambos nodos están en el rango 10.0.4.0/22.

3. Ahora intenta hacer ping en un nodo del clúster del otro proyecto de servicio. Por ejemplo:

   ping 172.16.4.3
   

   Esta vez, el comando ping fallará porque tu regla de firewall no permite el tráfico del Protocolo de mensajes de control de Internet (ICMP).

4. En un símbolo de sistema normal, no en la shell de tu caja de herramientas, actualiza tu regla de firewall para que permita el ICMP:

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

5. En la shell de tu caja de herramientas, vuelve a hacer ping al nodo. Por ejemplo:

   ping 172.16.4.3
   

   Esta vez, el comando ping se ejecuta de forma correcta.

Crea reglas de firewall adicionales

Puedes crear reglas de firewall adicionales para permitir la comunicación entre nodos, pods y objetos Service en tus clústeres.

Por ejemplo, la siguiente regla permite que el tráfico ingrese desde cualquier nodo, objeto Service o pod 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 el tráfico ingrese desde cualquier nodo, objeto Service o pod 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 administrar los recursos del firewall cuando sea necesario, por ejemplo, cuando crees un servicio de balanceador de cargas. Si Kubernetes no puede cambiar las reglas de firewall debido a un problema de permisos, se generará un evento de Kubernetes para indicarte cómo realizar los cambios.

Si deseas otorgar permiso a Kubernetes para cambiar las reglas de firewall, consulta Administra recursos de firewall.

En el caso de los balanceadores de cargas de Ingress, si Kubernetes no puede modificar las reglas de firewall debido a que no cuenta con los permisos suficientes, se emitirá un evento firewallXPNError cada algunos minutos. En GLBC 1.4 y versiones posteriores, puedes silenciar el evento firewallXPNError si agregas la anotación networking.gke.io/suppress-firewall-xpn-error: "true" al recurso de entrada. Podrás quitar esta anotación en cualquier momento para dejar de silenciar el evento.

Crea un clúster privado en una VPC compartida

Puedes usar la VPC compartida con clústeres privados.

Esto requiere que otorgues los siguientes permisos en el proyecto host, ya sea a la cuenta de usuario o a la cuenta de servicio, que se usa para crear el clúster:

• compute.networks.get

• compute.networks.updatePeering

También debes asegurarte de que el rango direcciones IP del plano de control no se superponga con otros rangos reservados en la red compartida.

Para los clústeres privados creados antes del 15 de enero de 2020, la cantidad máxima de clústeres privados de GKE que puedes tener por red de VPC se limita a la cantidad de conexiones de intercambio de tráfico de una sola red de VPC. Los clústeres privados nuevos vuelven a usar las conexiones de intercambio de tráfico de red de VPC, lo que quita esta limitación. 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.

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

Console

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

   Ir a Google Kubernetes Engine

2. Haz clic en Crear.

3. En la sección Autopilot o Standard, haz clic en Configurar.

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

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

6. Selecciona Clúster privado.

7. (Opcional para Autopilot): Configura el Rango de IP del plano de control como 172.16.0.16/28.

8. En la lista desplegable Red, selecciona la red de VPC que creaste antes.

9. En la lista desplegable Subred del nodo, selecciona la subred compartida que creaste antes.

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

11. Haz clic en Crear.

gcloud

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

gcloud container clusters create-auto private-cluster-vpc \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION \
    --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

Realiza una 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 a tu cuenta:

Borra los clústeres

Borra los dos clústeres que creaste.

Console

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

   Ir a Google Kubernetes Engine

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

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

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

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

gcloud

gcloud container clusters delete tier-1-cluster \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

gcloud container clusters delete tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --zone COMPUTE_ZONE

Inhabilita la VPC compartida

Inhabilita la VPC compartida en tu proyecto host.

Console

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

   Ir a VPC compartida

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

3. Haz clic en Inhabilitar VPC compartida.

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

Borra las reglas de firewall

Quita las reglas de firewall que creaste.

Console

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

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 y my-shared-net-rule.

4. Haz clic en Borrar.

gcloud

Borra las reglas de firewall:

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

Borra la red compartida

Borra la red compartida que creaste.

Console

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

   Ir a las 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 Borrar 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

Quita la función de usuario del agente de servicios de host

Quita las funciones de usuario del agente de servicios de host de tus dos proyectos de servicio.

Console

1. Ve a la página de IAM en la consola de Google Cloud.

   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 [e-mail] tiene la función de usuario del agente de servicios de host de Kubernetes Engine.

4. Selecciona la fila que muestra que [e-mail] tiene la función de usuario del agente de servicios de host de Kubernetes Engine.

5. Haga clic en Quitar acceso.

gcloud

1. Quita la función Usuario de agente de servicio de 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:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

2. Quita la función Usuario de agente de servicio de 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:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

Soluciona problemas

Permiso denegado

Síntoma:

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

Motivos posibles:

• La API de Kubernetes Engine no se habilitó en el proyecto host.

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

• La cuenta de servicio de GKE del proyecto host no tiene la función de agente de servicio de Kubernetes Engine (container.serviceAgent) en el proyecto host. Es posible que la vinculación se haya quitado por accidente.

• La cuenta de servicio de GKE del proyecto de servicio no tiene la función de usuario del agente de servicio de host en el proyecto host.

Opciones para solucionar el problema: Determina si existe la cuenta de servicio de GKE del proyecto host. Si no existe, haz lo siguiente:

• Si la API de Kubernetes Engine no está habilitada en el proyecto host, habilítala. De esta manera, se crea la cuenta de servicio de GKE del proyecto host y se le otorga la función de agente de servicio de Kubernetes Engine (container.serviceAgent) en el proyecto host.

• Si la API de Kubernetes Engine está habilitada en el proyecto host, significa que se borró la cuenta de servicio de GKE del proyecto host o que no tiene la función de agente de servicio de Kubernetes Engine (container.serviceAgent) en el proyecto host. Para restablecer la cuenta de servicio de GKE o la vinculación de funciones, debes inhabilitar y volver a habilitar la API de Kubernetes Engine. Para obtener más información, consulta Soluciona problemas de Google Kubernetes Engine.

  Nota: Inhabilitar y volver a habilitar la API de Kubernetes Engine en el proyecto host no afectará el funcionamiento de los clústeres existentes en proyectos de servicio. Sin embargo, no puedes crear clústeres nuevos que usen una red de VPC compartida, en un proyecto de servicio ni en el proyecto host, mientras la API de Kubernetes Engine está inhabilitada.

¿Qué sigue?

• Lee la descripción general de la VPC compartida.
• Obtén más información sobre cómo aprovisionar de la VPC compartida.
• Lee la descripción general de redes de GKE.
• Obtén más información sobre las reglas de firewall creadas automáticamente.
• Obtén información sobre cómo solucionar problemas de conectividad entre instancias de máquina virtual (VM) con direcciones IP internas.