Configurar clústeres con VPC compartida

En esta página se muestra cómo crear dos clústeres de Google Kubernetes Engine en proyectos distintos y que usen 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 de servicio a este. También puedes crear redes, subredes, rangos de direcciones secundarios, reglas de firewall y otros recursos de red en el proyecto host. Luego, puedes compartir con los proyectos de servicio las subredes seleccionadas, incluidos los rangos secundarios. Los componentes que se ejecutan en un proyecto de servicio pueden usar la VPC compartida para comunicarse con los componentes que se ejecutan en otro.

Puedes usar la VPC compartida con clústeres zonales y regionales. Los clústeres que la usan, 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 permite convertir clústeres existentes a este modelo.

Con la VPC compartida se aplican algunas cuotas y límites. 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 información, 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, los ejercicios usan la región us-central1 y la zona us-central1-a, pero también puedes modificarlas según tus necesidades.

Antes de comenzar

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

Debes tener la función de Administrador de VPC compartida de Compute en tu organización.

Antes de realizar el ejercicio de este tema, elige uno de tus proyectos para que sea el host y otros dos como los 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 host.
  • [HOST_PROJECT_NUM] es el número de tu proyecto host.
  • [SERVICE_PROJECT_1_ID] es el ID de tu primer proyecto de servicio.
  • [SERVICE_PROJECT_1_NUM] es el número de tu primer proyecto de servicio.
  • [SERVICE_PROJECT_2_ID] es el ID de tu segundo proyecto de servicio.
  • [SERVICE_PROJECT_2_NUM] es el número de tu segundo proyecto de servicio.

Buscar los ID y números de tus proyectos

gcloud

Enumera tus proyectos:

gcloud projects list

Con esto se mostrarán los nombres, ID y números de tus proyectos. Toma nota del número y el 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

Console

  1. Visita la página principal en Google Cloud Platform 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 ser los de servicio.

Habilitar la API de Google Kubernetes Engine en tus proyectos

Antes de continuar con el ejercicio de este tema, asegúrate de tener habilitada la API de Google Kubernetes Engine 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 una de estas cuentas.

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]

Console

  1. Visita el panel de API y servicios de GCP Console.
    Visitar el panel de API
  2. En el selector de proyectos, selecciona el proyecto que elegiste para ser 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 ser los de servicio.

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

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

Console

  1. Visita la página de redes de VPC en GCP Console.
    Visitar la página de redes de VPC
  2. En el selector de proyectos, selecciona el proyecto host.
  3. Haz clic en Crear una red de VPC.
  4. En Nombre, ingresa shared-net.
  5. En Modo de creación de subred, selecciona Personalizada.
  6. En la casilla Subred nueva, ingresa tier-1 en Nombre.
  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 del rango de la subred ingresa tier-1-services, y para el rango de IP secundario ingresa 10.0.32.0/20.
  10. Haz clic en Agregar rango de IP. En Nombre del rango de la subred ingresa tier-1-pods, y para el 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 del rango de la subred ingresa tier-2-services, y para el rango de IP secundario ingresa 172.16.16.0/20.
  16. Haz clic en Agregar rango de IP. En Nombre del rango de la subred ingresa tier-2-pods, y para el rango de IP secundario ingresa 172.20.0.0/14.
  17. Haz clic en Crear.

Determinar 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. Esta sección se trata sobre las cuentas de servicio de GKE y sus 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

Habilitar la VPC compartida y asignar 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.

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

Crea un archivo llamado tier-1-policy.yaml con este contenido:

bindings:
- members:
  - serviceAccount:<var>[SERVICE_PROJECT_1_NUM]</var>@cloudservices.gserviceaccount.com
  - serviceAccount:service-<var>[SERVICE_PROJECT_1_NUM]</var>@container-engine-robot.iam.gserviceaccount.com
  role: roles/compute.networkUser
etag: <var>[ETAG_STRING]</var>

en el que [ETAG_STRING] es el valor etag del que tomaste nota hace un momento.

Consulta la política de 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 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 etag.

Crea un archivo llamado tier-2-policy.yaml con este contenido:

bindings:
- members:
  - serviceAccount:<var>[SERVICE_PROJECT_2_NUM]</var>@cloudservices.gserviceaccount.com
  - serviceAccount:service-<var>[SERVICE_PROJECT_2_NUM]</var>@container-engine-robot.iam.gserviceaccount.com
  role: roles/compute.networkUser
etag: <var>[ETAG_STRING]</var>

en el que [ETAG_STRING] es el valor etag del que tomaste nota hace un momento.

Consulta la política de 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

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.
    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 de 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, 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.

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 del primer proyecto de servicio se les otorga la función Usuario de 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 red de Compute en la subred tier-2 de tu proyecto host.

Resumen de las funciones otorgadas en las subredes

  • A la cuenta de servicio service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com se le otorga la función Usuario de 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 red de Compute en la subred tier-1.

  • A la cuenta de servicio service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com se le otorga la función Usuario de 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 red de Compute en la subred tier-2.

Otorgar la función Usuario del agente de servicios de host

En cada proyecto de servicio, debes otorgar la función Usuario del agente de servicios 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 del agente de servicios de host solo se otorga a la cuenta de servicio del proyecto de servicio. No se le puede otorgar a usuarios.

gcloud

Otorga la función Usuario del agente de servicios 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 del agente de servicios 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

Console

Si usas GCP Console, no es necesario que otorgues la función Usuario del agente de servicios de host de manera explícita, ya que esto se hizo automáticamente cuando vinculaste tus proyectos de servicio al proyecto host con GCP Console.

Verificar los rangos de IP secundarios y las subredes utilizables

Cuando creas un clúster, debes indicar una red 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. Si creas el clúster con GCP Console o la herramienta de línea de comandos de gcloud, deberías especificar los rangos de IP utilizables.

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

gcloud

gcloud beta container subnets list-usable \
    --project [SERVICE_PROJECT_ID] \
    --network-project [HOST_PROJECT_ID]

Si omites las opciones --project o --network-project, el comando de gcloud usa el proyecto predeterminado de tu configuración activa. Como el proyecto host y el de red son distintos, debes especificar la opción --project, --network-project o ambas.

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 utilizar para los servicios del clúster nuevo si aún no se usa. El rango de IP que especificas para los pods del clúster nuevo puede ser uno no utilizado o uno compartido con los pods de otros clústeres. Los rangos de IP que se crean y administran en GKE no se pueden usar en el clúster.

Crear un clúster en tu primer proyecto de servicio

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

Console

  1. Entra al menú Google Kubernetes Engine en GCP Console.

    Visitar el menú de 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 automáticamente.

  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 tier-1-pods.

  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.

Crear un clúster en tu segundo proyecto de servicio

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

Console

  1. Entra al menú Google Kubernetes Engine en GCP Console.

    Visitar el menú de 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, ingrese 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 automáticamente.

  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.

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

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

Console

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

    Visitar 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 fuente, 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 la casilla, ingresa tcp:22.

  12. Haz clic en Crear.

Conectarse a un nodo con SSH

gcloud

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

SSH en uno de tus nodos:

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

en el que [NODE_NAME] es el nombre de uno de tus nodos.

Console

  1. Entra al menú Google Kubernetes Engine en GCP Console.

    Visitar 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 de los nodos. Estas direcciones se encuentran en el rango 10.0.4.0/22.

  6. En uno de tus nodos, haz clic en SSH. Esto funciona gracias a que SSH usa el puerto TCP 22, que está permitido según la regla de tu firewall.

Hacer 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 esta, haz ping a uno de tus otros nodos del mismo clúster. Por ejemplo:

ping 10.0.4.4

El comando ping funciona correctamente, ya que ambos nodos se encuentran en el rango 10.0.4.0/22.

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

ping 172.16.4.3

Ahora, el comando ping fallará, ya que la regla de tu firewall no permite tráfico del Protocolo de mensajes de control de Internet (ICMP).

En un símbolo de sistema normal, no la shell de tu caja de herramientas, actualiza la regla de tu firewall para que permita tráfico del 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

Ahora, el comando ping funcionará correctamente.

Crear reglas adicionales para el firewall

Puedes crear reglas adicionales para el firewall a fin de permitir la comunicación entre los nodos, los pods y los servicios de tus clústeres. Por ejemplo, esta regla permite que el tráfico ingrese desde cualquier nodo, pod o servicio de tier-1-cluster en cualquier puerto TCP o UDP.

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

Esta regla permite que el tráfico ingrese desde cualquier nodo, pod o servicio de tier-2-cluster en cualquier puerto TCP o UDP.

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

Kubernetes también intentará crear y 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 quieres otorgar un permiso de Kubernetes para cambiar las reglas de tu firewall, puedes ir a tu proyecto host y otorgarle la función Compute Security Admin o una personalizada compute.firewalls.* a la cuenta de servicio de 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" para silenciar el evento firewallXPNError al recurso de entrada. Podrás quitar esta anotación en cualquier momento para volver a activar el sonido.

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

La cantidad de clústeres privados de una VPC compartida se limita a 25.

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

gcloud

Con el siguiente comando se crea un clúster private-cluster-vpc, in 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

Console

  1. Ve al menú de Google Kubernetes Engine en GCP Console.

    Visitar el menú de GKE.

  2. Haz clic en Crear clúster.

  3. En Nombre del cluster, ingrese 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 anteriormente.

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

  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 al clúster principal con su dirección IP externa esté marcada.

  10. Configura el rango de IP principal en 172.16.0.16/28.

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

Notas sobre rangos secundarios

Puedes crear cinco rangos secundarios en una subred. Necesitas dos de estos por cada clúster, uno para los pods y otro para los servicios. Esto significa que solo puedes crear dos clústeres que usen una subred determinada.

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

Problemas conocidos

Otros clústeres podrían usar los rangos de CIDR secundarios

Cuando se crea un clúster de VPC compartida con Google Cloud Platform Console, es posible que otro clúster tenga en uso los rangos secundarios para los pods y los servicios. Si un clúster se crea con estos rangos de CIDR, la operación fallará.

Si detectas este problema, borra el clúster con errores. Antes de volver a crearlo, verifica que los rangos secundarios se puedan usar.

Solucionaremos este problema con futuras actualizaciones.

Eventos del firewall durante 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 de 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, los 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.

Limpiar

Después de completar los ejercicios de esta página, sigue estos pasos para quitar los recursos a fin de prevenir cobros no deseados en tu cuenta:

Borrar los clústeres

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

Console

  1. Ve al menú de Google Kubernetes Engine en GCP Console.

    Visitar el menú de 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.

Inhabilitar VPC compartidas

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]

Console

  1. Visita la página VPC compartida en GCP 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. En la casilla de texto, ingresa [HOST_PROJECT_ID] y haz clic en Inhabilitar.

Cómo borrar las reglas de tu firewall

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]

Console

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

    Visitar la página Reglas de firewall

  2. En el selector de proyectos, selecciona el 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.

Borrar la red shared-net

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]

Console

  1. Visita la página de redes de VPC en GCP 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, haz clic en shared-net.
  4. Haz clic en Borrar red de VPC.

Quitar la función Usuario del agente de servicios de host

gcloud

Quita la función Usuario del agente de servicios 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 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

Console

  1. Visita la página de IAM en GCP Console.
    Visitar la página de IAM
  2. En el selector de proyectos, selecciona el 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 del agente de servicios de host en Kubernetes Engine.
  4. Además, marca la fila que indica que service-[SERVICE_PROJECT_2_NUM] @container-engine-robot.iam.gserviceaccount.com posee la función Usuario del agente de servicios de host en Kubernetes Engine.
  5. Haz clic en Quitar.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...