Configura clústeres con VPC compartida

En esta página, se muestra cómo crear dos clústeres de Google Kubernetes Engine, en proyectos separados, que usan una nube privada virtual (VPC) compartida. Para obtener información general sobre las Herramientas de redes de GKE, visita Descripción general de la red.

Descripción general

Con una VPC compartida, designas un proyecto como el proyecto host y vinculas uno o más proyectos, 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.

En los ejemplos de este tema, se configura la infraestructura para una aplicación web de dos niveles, tal como se describe en la Descripción general de la VPC compartida.

En los ejemplos de esta página, 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

Para realizar esta tarea, debes tener una organización de Google Cloud con tres proyectos de Google Cloud.

Debes estar familiarizado con los conceptos de la VPC compartida incluidas las diversas funciones de Cloud Identity and Access Management (Cloud IAM) que usa la VPC compartida. Un administrador de VPC compartida debe realizar los pasos que se indican en esta página.

Asegúrate de que comprendes las restricciones de las políticas de la organización que 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 el ejercicio de este tema, elige uno de tus proyectos para que sea el host y otros dos como los proyectos de servicio. Todos los proyectos tienen un nombre, un ID y un número. En algunos casos, el nombre y el ID son iguales. En este tema se usan los siguientes nombres para tus proyectos, ya que son fáciles de recordar:

  • Tu proyecto host
  • Tu primer proyecto de servicio
  • Tu segundo proyecto de servicio

En este tema, se usan los siguientes marcadores de posición para a los ID y números de tus proyectos.

  • [HOST_PROJECT_ID] es el ID del proyecto de tu proyecto host.
  • [HOST_PROJECT_NUM] es el número de proyecto de tu proyecto host.
  • [SERVICE_PROJECT_1_ID] es el ID del proyecto de tu primer proyecto de servicio.
  • [SERVICE_PROJECT_1_NUM] es el número de proyecto de tu primer proyecto de servicio.
  • [SERVICE_PROJECT_2_ID] es el ID del proyecto de tu segundo proyecto de servicio.
  • [SERVICE_PROJECT_2_NUM] es el número de proyecto de tu segundo proyecto de servicio.

Busca los ID y números de tu proyecto

Console

  1. Visita la página principal en Google Cloud Console.
    Visita la página principal
  2. En el selector de proyectos, selecciona el proyecto que elegiste para que sea 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

Haz una lista de los proyectos:

gcloud projects list

En el resultado, se muestran los nombres, ID y números de tus 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 tus proyectos

Antes de continuar con los ejercicios de este tema, 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 los pasos restantes, todos tus proyectos deben tener esta cuenta.

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.

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 tu proyecto host, crea una red llamada shared-net. Luego, crea dos subredes: una llamada tier-1 y otra llamada tier-2. En cada subred crea dos rangos de direcciones secundarios: uno para servicios 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 tu 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.

Estos son los nombres de las cuentas de servicio de GKE que se encuentran en tus dos proyectos de servicio:

  • service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com
  • service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com

Estos son los nombres de las cuentas de servicio de las API de Google que se encuentran en tus dos proyectos de servicio:

  • [SERVICE_PROJECT_1_NUM]@cloudservices.gserviceaccount.com
  • [SERVICE_PROJECT_2_NUM]@cloudservices.gserviceaccount.com

Habilita la VPC compartida y asigna funciones

En tu proyecto host, habilita la VPC compartida y vincula los dos proyectos de servicio a él. Luego, asigna las funciones adecuadas a las cuentas de servicio que pertenecen a tus proyectos de servicio.

Console

Sigue estos pasos para habilitar la VPC compartida, vincular proyectos de servicio y asignar funciones:

  1. Visita la página VPC compartida en GCP Console.
    Visita la página VPC compartida
  2. En el selector de proyectos, selecciona tu proyecto host.
  3. Haz clic en Configurar VPC compartida.
    Se muestra 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.
    Se muestra 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.
    Se abrirá 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, borra 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 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, borra 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 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

Habilita la VPC compartida en tu proyecto host:

gcloud compute shared-vpc enable [HOST_PROJECT_ID]

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]

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]

Obtén la política de Cloud IAM para la subred tier-1:

gcloud beta 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.

Crea un archivo llamado tier-1-policy.yaml que tenga este 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 ejemplo anterior, se ilustra lo siguiente: [ETAG_STRING] es el valor etag que anotaste antes.

Configura la política de Cloud IAM para la subred tier-1:

gcloud beta compute networks subnets set-iam-policy tier-1 \
    tier-1-policy.yaml \
    --project [HOST_PROJECT_ID] \
    --region us-central1

Luego, obtén la política de Cloud IAM para la subred tier-2:

gcloud beta 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.

Crea un archivo llamado tier-2-policy.yaml que tenga este 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 ejemplo anterior, se ilustra lo siguiente: [ETAG_STRING] es el valor etag que anotaste antes.

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

gcloud beta compute networks subnets set-iam-policy tier-2 \
    tier-2-policy.yaml \
    --project [HOST_PROJECT_ID] \
    --region us-central1

El propósito de los pasos anteriores es otorgar la función adecuada de Cloud IAM a cuatro cuentas de servicio. A las dos cuentas de servicio del primer proyecto de servicio se les otorga la función Usuario de la red de Compute en la subred tier-1 de tu proyecto host. Mientras que a las dos del segundo proyecto de servicio se les otorga la función Usuario de la red de Compute en la subred tier-2 de tu proyecto host.

Resumen de las funciones otorgadas en las subredes

  • La cuenta de servicio service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com tiene la función Usuario de la red de Compute en la subred tier-1.

  • A la cuenta de servicio [SERVICE_PROJECT_1_NUM]@cloudservices.gserviceaccount.com se le otorga la función Usuario de la red de Compute en la subred tier-1.

  • La cuenta de servicio service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com posee la función Usuario de la red de Compute en la subred tier-2.

  • A la cuenta de servicio [SERVICE_PROJECT_2_NUM]@cloudservices.gserviceaccount.com se le otorga la función Usuario de la red de Compute en la subred de tier-2.

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

En cada proyecto de servicio, debes otorgar la función Usuario de agente de servicio de host a la cuenta de servicio de GKE. Con esto, la cuenta de servicio de GKE del proyecto de servicio podrá usar la cuenta de servicio de GKE del proyecto host a fin de configurar los recursos de la red compartida.

La función Usuario de agente de servicio de host solo se otorga a la cuenta de servicio del proyecto de servicio. No se le puede otorgar a usuarios.

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

Otorga la función Usuario de agente de servicio de host a la cuenta de servicio de GKE de tu primer proyecto de servicio. Esta función se otorga en tu 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

Otorga la función Usuario de agente de servicio de host a la cuenta de servicio de GKE de tu segundo proyecto de servicio. Esta función se otorga en tu 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 utilizables

Cuando creas un clúster, debes indicar una subred y los rangos de IP secundarios que se usarán para los pods y servicios del clúster. Existen varios motivos por los que un rango de IP podría no estar disponible para usarse. Cuando creas el clúster con Cloud Console o la herramienta de línea de comandos de gcloud, debes especificar rangos de IP utilizables.

También puedes enumerar las subredes utilizables de un proyecto y los rangos de IP secundarios desde la línea de comandos:

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.

El resultado del comando es similar a lo 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 │
    └──────────────────────┴───────────────┴─────────────────────────────┘

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.

Crea un clúster en tu primer proyecto de servicio

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 Crear clúster.

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

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

  6. En Zona, selecciona us-central1-a.

  7. En la parte inferior de la página, haz clic en Opciones avanzadas.

  8. En la sección VPC nativas, selecciona Habilitar VPC nativas (con alias de IP).

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

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

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

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

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

  14. Haz clic en Crear.

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

  16. En Grupos de nodos, haz clic en el nombre de tu grupo de instancias. Por ejemplo, gke-tier-1-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-1: 10.0.4.0/22.

gcloud

Crea un clúster 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 los resultados, 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 tu segundo proyecto de servicio

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 tu segundo proyecto de servicio.

  3. Haz clic en Crear clúster.

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

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

  6. En Zona, selecciona us-central1-a.

  7. En la parte inferior de la página, haz clic en Opciones avanzadas.

  8. En la sección VPC nativas, selecciona Habilitar VPC nativas (con alias de IP).

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

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

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

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

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

  14. Haz clic en Crear.

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

  16. En Grupos de nodos, haz clic en el nombre de tu grupo de instancias. 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 en tu 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 los resultados, 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

Crea una regla de firewall para la red shared-net en tu proyecto host. Permite la entrada de tráfico a través del puerto TCP 22. Esto te permitirá conectarte a los nodos de tu clúster con 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 tu 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 con 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 tus nodos:

gcloud compute ssh [NODE_NAME] \
    --project [SERVICE_PROJECT_1_ID] \
    --zone us-central1-a \

En el ejemplo anterior, se ilustra lo siguiente: [NODE_NAME] es el nombre de uno de tus nodos.

Haz ping entre nodos

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

/usr/bin/toolbox

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.

Ahora intenta hacer ping a un nodo del clúster tu 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).

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

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 servicios en tus clústeres. Por ejemplo, esta regla permite que el tráfico ingrese desde cualquier nodo, pod o servicio en tier-1-cluster a 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

Esta regla permite que el tráfico ingrese desde cualquier nodo, pod o servicio en tier-2-cluster a 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 detecta que no puede modificar las reglas del firewall debido a un problema con los 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 ir a tu proyecto de host y otorgarle la función Compute Security Admin. Como alternativa, puedes otorgar una función personalizada con los permisos compute.firewalls.* y compute.networks.updatePolicy a la cuenta de servicio GKE del proyecto de servicio.

En los balanceadores de cargas de Ingress, si Kubernetes no puede modificar las reglas del 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 agregar la anotación networking.gke.io/suppress-firewall-xpn-error: "true" al recurso Ingress para silenciar el evento firewallXPNError. Podrás quitar esta anotación en cualquier momento para volver a activar el sonido.

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 de instancia principal no se superponga con otros rangos reservados en la red compartida.

La cantidad máxima de clústeres de GKE privados que puedes tener por red de VPC se limita a la cantidad de conexiones de intercambio de tráfico desde una sola red de VPC .

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

Console

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

    Visita el menú de GKE.

  2. Haz clic en Crear clúster.

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

  4. Haz clic en Opciones avanzadas en la parte inferior del menú.

  5. En Nativo de VPC, selecciona la casilla de verificación Habilitar nativo de VPC (con IP de alias).

  6. En el menú desplegable Red, selecciona la red de VPC que creaste antes.

  7. En el menú desplegable de Subred del nodo, selecciona la subred compartida que creaste antes.

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

  9. Asegúrate de que la casilla de verificación Acceso a la instancia principal con su dirección IP externa esté marcada.

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

  11. Configura tu clúster como desees. Luego, haga clic en Crear.

gcloud

Con el siguiente comando, se crea un clúster, 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 del recurso completa para que podamos 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=[REGION] \
    --subnet=projects/[HOST_PROJECT_ID]/regions/[REGION]/subnetworks/[SUBNETWORK_NAME] \
    --addresses=[IP_ADDRESS] \
    --project=[SERVICE_PROJECT_ID]

Si deseas llamar a ese comando, debes tener el permiso compute.subnetworks.use para 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.

Notas sobre rangos secundarios

Puedes crear 30 rangos secundarios en una subred. Necesitas dos de estos por cada clúster, uno para los pods y otro para los servicios.

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.

Realiza una limpieza

Luego de completar los ejercicios de esta página, sigue estos pasos para quitar los recursos y evitar cargos no deseados en tu cuenta:

Borra los clústeres

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. Marca tier-1-cluster y haz clic en Borrar.

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

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

Console

  1. Visita la página VPC compartida en GCP Console.
    Visita la página VPC compartida
  2. En el selector de proyectos, selecciona tu proyecto host.
  3. Haz clic en Inhabilitar VPC compartida.
  4. Ingresa [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 tu firewall

Console

  1. Visita la página Firewalls en Cloud Console.

    Visita la página Reglas de firewall

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

  3. En la lista de reglas, marca 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 tu 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 shared-net

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 tu proyecto host.
  3. En la lista de redes, haz clic en 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 Usuario de agente de servicio de host

Console

  1. Visita la página de Cloud IAM en Cloud Console.
    Visita la página de Cloud IAM
  2. En el selector de proyectos, selecciona tu proyecto host.
  3. En la lista de miembros, marca la fila que indica que service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com posee la función Usuario de agente de servicio de host en Kubernetes Engine.
  4. También, marca la fila que indica que service-[SERVICE_PROJECT_2_NUM] @container-engine-robot.iam.gserviceaccount.com posee la función Usuario de agente de servicio de host en Kubernetes Engine.
  5. Haz clic en Quitar.

gcloud

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

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:service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

Próximos pasos