Configura clústeres con VPC compartida

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 zonales y regionales. Los clústeres que usan una VPC compartida no pueden usar redes heredadas y deben tener habilitadas las IP de alias.

Puedes configurar la VPC compartida cuando creas un clúster nuevo. Google Kubernetes Engine 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.

En los ejemplos de esta guía, se usan rangos de direcciones y nombres específicos para demostrar los procedimientos generales. Si lo deseas, puedes cambiarlos para que se adapten a tus necesidades. Además, en los ejercicios se usa la región us-central1 y la zona us-central1-a. Si lo deseas, puedes cambiarlas para que se adapten a tus necesidades.

Antes de comenzar

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

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

Busca los ID y los números del proyecto

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

Console

  1. Visita la página principal en Google Cloud Console.

    Visitar 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 Google Kubernetes Engine en los proyectos

Antes de continuar con los ejercicios de esta guía, asegúrate de que la API de Google Kubernetes Engine 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 Google Kubernetes Engine con Google Cloud Console o la herramienta de gcloud.

Console

  1. Visita el panel de API y servicios en Cloud Console.
    Visita el panel de la API
  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 Google Kubernetes Engine en tus 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.

Console

  1. Visita la página de redes de VPC en Cloud Console.
    Visita la página 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, selecciona us-central1.
  8. En Rango de direcciones IP, ingresa 10.0.4.0/22.
  9. Haz clic en Crear rango de IP secundario. En Nombre de rango de subred, ingresa tier-1-services y, en Rango de IP secundario , ingresa 10.0.32.0/20.
  10. Haz clic en Agregar rango de IP. En Nombre de rango de subred, ingresa tier-1-pods y, en Rango de IP secundario, ingresa 10.4.0.0/14.
  11. Haz clic en + Agregar subred.
  12. En Nombre, ingresa tier-2.
  13. En Región, selecciona us-central1.
  14. En Rango de direcciones IP, ingresa 172.16.4.0/22.
  15. Haz clic en Crear rango de IP secundario. En Nombre de rango de subred, ingresa tier-2-services y, en Rango de IP secundario , ingresa 172.16.16.0/20.
  16. Haz clic en Agregar rango de IP. En Nombre de rango de subred, ingresa tier-2-pods y, en Rango de IP secundario, ingresa 172.20.0.0/14.
  17. 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 us-central1 \
    --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 us-central1 \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

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 service-service-project-1-num@container-engine-robot.iam.gserviceaccount.com
service-service-project-2-num@container-engine-robot.iam.gserviceaccount.com
API de Google service-project-1-num@cloudservices.gserviceaccount.com
service-project-2-num@cloudservices.gserviceaccount.com

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 proyectos 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 funciones:

  1. Visita la página VPC compartida en Cloud Console.

    Visitar la página 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-project2-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:

    gcloud 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 us-central1
    

    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:service-project-1-num@cloudservices.gserviceaccount.com
      - serviceAccount:service-service-project-1-num@container-engine-robot.iam.gserviceaccount.com
      role: roles/compute.networkUser
    etag: etag-string
    

    En el código anterior, etag-string es el valor 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 us-central1
    
  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 us-central1
    

    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:service-project-2-num@cloudservices.gserviceaccount.com
      - serviceAccount:service-service-project-2-num@container-engine-robot.iam.gserviceaccount.com
      role: roles/compute.networkUser
    etag: etag-string
    

    En el código anterior, etag-string es el valor 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 us-central1
    

Si deseas que el clúster de GKE cree y administre los recursos de firewall en tu proyecto host, puedes realizar una de las siguientes tareas:

  • En tu proyecto host, otorga la función Compute Security Admin.
  • Otorga una función personalizada con los permisos compute.firewalls.* y compute.networks.updatePolicy a la cuenta de servicio de GKE del proyecto de servicio. Para obtener más información, consulta la sección Crea reglas de firewall adicionales.

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
service-service-project-1-num@container-engine-robot.iam.gserviceaccount.com Usuario de la red de Compute tier-1
service-project-1-num@cloudservices.gserviceaccount.com Usuario de la red de Compute tier-1
service-service-project-2-num@container-engine-robot.iam.gserviceaccount.com Usuario de la red de Compute tier-2
service-project-2-num@cloudservices.gserviceaccount.com 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.

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
service-service-project-num@container-engine-robot.iam.gserviceaccount.com Usuario de red Subred específica o proyecto host completo
service-service-project-num@container-engine-robot.iam.gserviceaccount.com Usuario del agente de servicio de host Cuenta de servicio de GKE en el proyecto host

Otorga la función de usuario del agente de servicios 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 toma la siguiente forma, en la que service-project-num es el número de tu proyecto de servicio:

service-service-project-num@container-engine-robot.iam.gserviceaccount.com

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 Cloud Console, 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 Cloud Console.

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:service-service-project-1-num@container-engine-robot.iam.gserviceaccount.com \
       --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:service-service-project-2-num@container-engine-robot.iam.gserviceaccount.com \
       --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 IP puede no estar disponible. Cuando crees el clúster con Cloud Console o la herramienta de línea de comandos de gcloud, debes especificar rangos de IP que se pueden usar.

Un rango de IP se puede usar para los servicios del clúster nuevo si aún no está en uso. El rango de 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 IP que se crean y administran en GKE no se pueden usar en el clúster.

Puedes enumerar los rangos de IP secundarios y las subredes que se pueden usar de un proyecto mediante la herramienta de línea de comandos de gcloud.

gcloud

gcloud container subnets list-usable \
    --project service-project-id \
    --network-project host-project-id

Si omites la opción --project o --network-project, el comando de gcloud 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.

La salida del comando es similar a la siguiente:

PROJECT   REGION       NETWORK      SUBNET          RANGE
xpn-host  us-central1  empty-vpc    empty-subnet    10.0.0.0/21
xpn-host  us-east1     some-vpc     some-subnet     10.0.0.0/19
    ┌──────────────────────┬───────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
    ├──────────────────────┼───────────────┼─────────────────────────────┤
    │ pods-range           │ 10.2.0.0/21   │ usable for pods or services │
    │ svc-range            │ 10.1.0.0/21   │ usable for pods or services │
    └──────────────────────┴───────────────┴─────────────────────────────┘
xpn-host  us-central1  shared-net   tier-2          172.16.4.0/22
    ┌──────────────────────┬────────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE  │            STATUS           │
    ├──────────────────────┼────────────────┼─────────────────────────────┤
    │ tier-2-services      │ 172.16.16.0/20 │ usable for pods or services │
    │ tier-2-pods          │ 172.20.0.0/14  │ usable for pods or services │
    └──────────────────────┴────────────────┴─────────────────────────────┘
xpn-host  us-central1  shared-net   tier-1          10.0.4.0/22
    ┌──────────────────────┬───────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
    ├──────────────────────┼───────────────┼─────────────────────────────┤
    │ tier-1-services      │ 10.0.32.0/20  │ unusable                    │
    │ tier-1-pods          │ 10.4.0.0/14   │ usable for pods             │
    │ tier-1-extra         │ 10.8.0.0/14   │ 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.

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 herramienta de gcloud o Google Cloud Console.

Console

  1. Visita el menú de Google Kubernetes Engine en Cloud Console.

    Visita el menú Google Kubernetes Engine

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

  3. Haz clic en el botón Crear clúster.

  4. En Nombre del clúster, ingresa tier-1-cluster.

  5. En Tipo de ubicación, selecciona Zonal.

  6. En la lista desplegable Zona, selecciona us-central1-a.

  7. En el panel de navegación, en Clúster, haz clic en Herramientas de redes.

  8. Selecciona Habilitar enrutamiento de tráfico nativo de la VPC (con alias de IP).

  9. Anula la selección en Crear rangos secundarios de forma automática.

  10. Selecciona Redes compartidas conmigo (del proyecto host: …).

  11. En Red, selecciona shared-net.

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

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

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

  15. Haz clic en Crear.

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

  17. En Grupos de nodos, haz clic en el nombre de tu grupo de instancias. 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 tier-1-cluster \
    --project service-project-1-id \
    --zone=us-central1-a \
    --enable-ip-alias \
    --network projects/host-project-id/global/networks/shared-net \
    --subnetwork projects/host-project-id/regions/us-central1/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 la salida, se mostrarán las direcciones IP internas de los nodos:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-1-cluster-...  us-central1-a  ... 10.0.4.2
gke-tier-1-cluster-...  us-central1-a  ... 10.0.4.3
gke-tier-1-cluster-...  us-central1-a  ... 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 herramienta de gcloud o Google Cloud Console.

Console

  1. Visita el menú de Google Kubernetes Engine en Cloud Console.

    Visita el menú Google Kubernetes Engine

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

  3. Haz clic en el botón Crear clúster.

  4. En Nombre del clúster, ingresa tier-2-cluster.

  5. En Tipo de ubicación, selecciona Zonal.

  6. En la lista desplegable Zona, selecciona us-central1-a.

  7. En el panel de navegación, en Clúster, haz clic en Herramientas de redes.

  8. Selecciona Habilitar enrutamiento de tráfico nativo de la VPC (con alias de IP).

  9. Anula la selección en Crear rangos secundarios de forma automática.

  10. Selecciona Redes compartidas conmigo (del proyecto host: …).

  11. En Red, selecciona shared-net.

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

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

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

  15. Haz clic en Crear.

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

  17. En Grupos de nodos, haz clic en el nombre de tu grupo de instancias. Por ejemplo, gke-tier-2-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-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 tier-2-cluster \
    --project service-project-2-id \
    --zone=us-central1-a \
    --enable-ip-alias \
    --network projects/host-project-id/global/networks/shared-net \
    --subnetwork projects/host-project-id/regions/us-central1/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 la salida, se mostrarán las direcciones IP internas de los nodos:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.2
gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.3
gke-tier-2-cluster-...  us-central1-a  ... 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 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. Visita la página Firewalls en Cloud Console.

    Visita la página Reglas de 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. Visita el menú de Google Kubernetes Engine en Cloud Console.

    Visita la página Reglas de firewall

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

  3. Haz clic en tier-1-cluster.

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

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

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

Establece una conexión SSH en uno de los nodos:

gcloud compute ssh node-name \
    --project service-project-1-id \
    --zone us-central1-a \

En el ejemplo anterior, node-name es el nombre de uno de tus nodos.

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, puedes realizar una de las siguientes acciones:

  • En tu proyecto host, otorga la función Compute Security Admin.
  • Otorga una función personalizada con los permisos compute.firewalls.* y compute.networks.updatePolicy a la cuenta de servicio de GKE del proyecto de servicio.

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. No es necesario realizar una configuración especial. Sin embargo, debes asegurarte de que el rango de CIDR del plano de control (principal) 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. Visita el menú de Google Kubernetes Engine en Cloud Console.

    Ir al menú Google Kubernetes Engine

  2. Haz clic en el botón Crear clúster.

  3. En Nombre del clúster, ingresa private-cluster-vpc.

  4. En el panel de navegación, en Clúster, haz clic en Herramientas de redes.

  5. Haz clic en Clúster privado.

  6. Asegúrate de que la casilla de verificación Acceder a la instancia principal con su dirección IP externa esté seleccionada.

  7. Configura el Rango de IP de instancia principal 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. Asegúrate de que la casilla de verificación Habilitar enrutamiento de tráfico nativo de la VPC (con alias de IP) esté seleccionada.

  11. Configura tu clúster como desees.

  12. 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 private-cluster-vpc \
    --project project-id \
    --enable-ip-alias \
    --network projects/host-project/global/networks/shared-net \
    --subnetwork shared-subnetwork \
    --cluster-secondary-range-name c0-pods \
    --services-secondary-range-name c0-services \
    --enable-private-nodes \
    --master-ipv4-cidr 172.16.0.0/28

Reserva direcciones IP

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

Para las direcciones IP internas, debes proporcionar la subred a la que pertenece la dirección IP. A fin de reservar una dirección IP en todos los proyectos, usa la URL completa del recurso para identificar la subred.

Puedes usar el siguiente comando en la herramienta de línea de comandos de gcloud 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 agregado a la subred. Puedes otorgarle al emisor una función compute.networkUser en la subred o puedes otorgarle al emisor una función personalizada con el permiso compute.subnetworks.use a nivel de proyecto.

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. Visita el menú de Google Kubernetes Engine en Cloud Console.

    Visita el menú 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 us-central1-a

gcloud container clusters delete tier-2-cluster \
    --project service-project-2-id \
    --zone us-central1-a

Inhabilita la VPC compartida

Inhabilita la VPC compartida en tu proyecto host.

Console

  1. Visita la página VPC compartida en Cloud Console.

    Visitar la página VPC compartida

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

  3. Haz clic en Inhabilitar VPC compartida.

  4. Ingresa el host-project-id en el cuadro de texto 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. Visita la página Firewalls en Cloud Console.

    Visita la página Reglas de 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-2 y my-shared-net-rule-3.

  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. Visita la página de redes de VPC en Cloud Console.

    Visitar la página de 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 us-central1

gcloud compute networks subnets delete tier-2 \
    --project host-project-id \
    --region us-central1

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. Visita la página IAM en Cloud Console.

    Visitar la página de IAM

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

  3. En la lista de miembros, selecciona la fila que muestra que service-service-project-1-num@container-engine-robot.iam.gserviceaccount.com tiene la función de usuario del agente de servicios de host de Kubernetes Engine.

  4. Selecciona la fila que muestra que service-service-project-2-num@container-engine-robot.iam.gserviceaccount.com tiene la función de usuario del agente de servicios de host de Kubernetes Engine.

  5. Haz clic en Quitar.

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:service-service-project-1-num@container-engine-robot.iam.gserviceaccount.com \
       --role roles/container.hostServiceAgentUser
    
  2. Quita la función de usuario del agente de servicios 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:service-service-project-2-num@container-engine-robot.iam.gserviceaccount.com \
       --role roles/container.hostServiceAgentUser
    

Problemas conocidos

Eventos del firewall en la creación de balanceadores de cargas

Si a la cuenta de servicio de Kubernetes no se le otorgaron permisos de administración en el firewall, es posible que el controlador del servicio de Kubernetes no cree eventos para los cambios requeridos en el firewall. Esto se debe a un problema con los permisos RBAC en Kubernetes 1.9 y versiones anteriores. El controlador del servicio no puede generar eventos.

Para solucionar este problema, aplica estos archivos YAML, que contienen las políticas de RBAC que permiten que se creen los eventos.

Los clústeres basados en Kubernetes 1.10 y versiones posteriores ya tienen las políticas de RBAC aplicadas.

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 Google Kubernetes Engine del proyecto host no tiene la función de agente del objeto Service 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 Google Kubernetes Engine del proyecto de servicio no tiene la función de usuario del agente de servicios de host en el proyecto host.

Opciones para solucionar el problema: Determina si existe la cuenta de servicio de Google Kubernetes Engine 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 Google Kubernetes Engine del proyecto host y se le otorga la función de agente del objeto Service 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 Google Kubernetes Engine del proyecto host o que no tiene el agente del objeto Service de Kubernetes Engine (container.serviceAgent) en el proyecto host. Para restablecer la cuenta de servicio de Google Kubernetes Engine 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.

Próximos pasos