Configura la red para Managed Service for Apache Kafka

Los clientes pueden conectarse a un clúster de Managed Service para Apache Kafka desde cualquier red de nube privada virtual (VPC) de tus Google Cloud proyectos.

En esta página, se explica cómo se configura la red en Managed Service para Apache Kafka, cómo habilitar las conexiones entre los clientes de Kafka y tu clúster, y cómo habilitar la conectividad entre proyectos.

Descripción general

Cuando creas un clúster, el servicio lo coloca en una red de VPC que administra Google Cloud. Esta red se denomina red de tenant. Cada clúster de Managed Service para Apache Kafka tiene su propia red de tenant aislada. Para permitir que las aplicaciones cliente se comuniquen con el clúster, conecta las subredes dentro de tus redes de VPC a la red de tenant.

En el siguiente diagrama, se muestran dos Google Cloud proyectos, project-1 y project-2. Un clúster de Managed Service para Apache Kafka se encuentra en project-1.

Un clúster de Managed Service para Apache Kafka con tres subredes conectadas

Las siguientes subredes están conectadas al clúster:

  • subnet-1, en la red de VPC vpc-1 en project-1
  • subnet-2, en la red de VPC vpc-2 en project-1
  • subnet-3, en la red de VPC vpc-3 en project-2

Conecta subredes a un clúster

Cuando creas un clúster de Managed Service para Apache Kafka por primera vez, debes especificar al menos una subred. Más adelante, puedes actualizar el clúster para agregar o quitar subredes.

Las subredes conectadas pueden pertenecer al mismo Google Cloud proyecto que el clúster o a uno diferente. Las subredes conectadas deben estar en la misma región que el clúster, pero los clientes de cualquier región dentro de la misma VPC pueden conectarse a las direcciones IP de esa subred. Como máximo, se puede conectar una subred por red de VPC al clúster.

Para ver las subredes que están conectadas a un clúster, consulta Visualiza las subredes de un clúster.

Entradas de DNS del clúster

Cuando conectas una subred a un clúster, el servicio crea entradas de DNS dentro de esa red de subred para la dirección de arranque y los agentes del clúster. Los clientes de Kafka usan la dirección de arranque para ubicar los agentes y establecer una conexión.

Los nombres de DNS son los mismos en todas las subredes conectadas, aunque corresponden a diferentes direcciones IP en cada subred. Debido a que los nombres de DNS son coherentes, todas tus aplicaciones cliente de Kafka pueden usar la misma dirección de arranque. Para obtener la dirección de arranque del clúster, consulta Visualiza la dirección de arranque de un clúster.

Para obtener ejemplos de aplicaciones cliente que se conectan a Managed Service para Apache Kafka, consulta los siguientes instructivos:

Tamaño de subred

Cuando agregas una subred a un clúster, la subred debe tener suficientes direcciones IP disponibles. Cada subred requiere una dirección IP para cada agente de Kafka, además de una dirección IP para la dirección de arranque. El tamaño mínimo del clúster para Managed Service para Apache Kafka tiene tres agentes, por lo que cada subred necesita al menos cuatro direcciones IP utilizables, incluida la dirección de arranque.

Si tu clúster tiene más de 45 CPUs virtuales, entonces el clúster tiene un agente por cada 15 CPUs virtuales. En ese caso, calcula la cantidad mínima de direcciones IP para cada subred de la siguiente manera:

  1. Divide la cantidad de CPUs virtuales por 15.
  2. Redondea al número entero más cercano.
  3. Agrega 1 para tener en cuenta la dirección de arranque.

Por ejemplo, un clúster con 60 CPUs virtuales necesita al menos (60/15 + 1) = 5 direcciones IP utilizables.

Es posible que Google cambie la proporción de agentes a CPUs virtuales en el futuro. Para adaptarse a cualquier cambio futuro, te recomendamos que asignes 3 veces la cantidad de direcciones IP calculadas en el paso anterior.

Cuando planifiques el tamaño de la subred, basa tus cálculos en el tamaño máximo que esperas que escale tu clúster en el futuro.

Si planeas usar Kafka Connect, también considera los requisitos de subred para el clúster de Connect. Para obtener más información, consulta la subred de trabajadores.

Rangos de IP públicas que se usan de forma privada

Puedes conectar tu clúster a subredes que usan el espacio de direcciones que no es RFC 1918. Esos rangos de direcciones IP se denominan rangos de IP públicas que se usan de forma privada (PUPI).

No se requiere configuración adicional para conectarse a subredes PUPI. Las subredes PUPI deben usar un rango IPv4 válido que no sea un rango de subred IPv4 prohibido.

Conecta clientes y clústeres entre proyectos

Si tienes clientes de Kafka en diferentes Google Cloud proyectos, puedes conectar los a tu clúster de las siguientes maneras:

En las siguientes secciones, se describen estas opciones.

Conecta un clúster entre proyectos

Puedes conectar subredes de otros proyectos a tu clúster. Para habilitar el acceso entre proyectos, debes otorgar permisos a la cuenta de servicio administrada por Google que está asociada con el clúster. Para cada proyecto en el que deseas que los clientes de Kafka accedan al clúster, la cuenta de servicio debe tener el rol de IAM de agente de servicio de Kafka administrado en ese proyecto. Este rol permite que el clúster acceda a los Google Cloud recursos, de modo que pueda crear recursos de red y entradas de DNS.

Ejemplo: Si project-1 contiene el clúster y deseas que los clientes de project-2 accedan al clúster, otorga a la cuenta de servicio de Kafka administrada para project-1 el rol de agente de servicio de Kafka administrado en project-2. Luego, conecta una subred de project-2 al clúster, como se describe en Conecta subredes al clúster.

Para otorgar los roles necesarios, sigue estos pasos:

Console

  1. Determina los Google Cloud proyectos en los que deseas que tus clientes de Kafka accedan al clúster de Managed Service para Apache Kafka.

  2. Para cada proyecto, en la Google Cloud consola, ve a la página **IAM** de ese proyecto:

    Ve a la página IAM

  3. Haz clic en Grant access.

  4. En el campo New principals, ingresa lo siguiente:

    service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com
    

    Reemplaza CLUSTER_PROJECT_NUMBER por el número del proyecto que contiene el clúster de Managed Service para Apache Kafka.

  5. Haz clic en Add roles.

  6. En el campo Search for roles, ingresa Managed Kafka Service Agent. El nombre del agente de servicio aparece en los resultados de la búsqueda.

  7. En los resultados de la búsqueda, selecciona Managed Kafka Service Agent.

  8. Haz clic en Aplicar.

  9. Haz clic en Guardar.

gcloud

  1. Determina los Google Cloud proyectos en los que deseas que tus clientes de Kafka accedan al clúster de Managed Service para Apache Kafka.

  2. Para cada proyecto, ejecuta el gcloud projects add-iam-policy-binding comando:

    gcloud projects add-iam-policy-binding CLIENT_PROJECT_ID \
        --member=serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com \
        --role=roles/managedkafka.serviceAgent
    

    Reemplaza lo siguiente:

    • CLIENT_PROJECT_ID: el nombre del proyecto que contiene la red de VPC para conectar
    • CLUSTER_PROJECT_NUMBER: el número del proyecto que contiene el clúster de Managed Service para Apache Kafka

Usa la VPC compartida para conectar proyectos

La VPC compartida permite que una organización conecte recursos desde varios proyectos a una red de VPC común. Para usar la VPC compartida con Managed Service para Apache Kafka, sigue estos pasos:

  1. Crea un clúster de Managed Service para Apache Kafka.

  2. Aprovisiona la VPC compartida.

  3. Otorga a la cuenta de servicio de Kafka administrada los roles necesarios en el proyecto host de la VPC compartida, como se describe en la sección anterior.

  4. Conecta el clúster de Managed Service para Apache Kafka a una subred en la red de VPC compartida.

Los clientes del proyecto host de la VPC compartida o de los proyectos de servicio pueden conectarse al clúster.

Para obtener información sobre cuándo usar la VPC compartida en tus arquitecturas de red, consulta Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC.

Arquitectura de red de un clúster

En esta sección, se describen los detalles de la arquitectura de red que se usa en Managed Service para Apache Kafka.

  • Un clúster de Kafka abarca una red de tenant y una o más redes de consumidores.

  • En la red de tenant, el clúster tiene una sola dirección IP y URL de arranque. Esta dirección de arranque corresponde a un balanceador de cargas conectado a todos los agentes del clúster. Cada agente también puede actuar como un servidor de arranque, pero te recomendamos que uses la dirección de arranque para obtener confiabilidad.

  • Dentro de cada red de consumidores, el servicio crea un extremo de Private Service Connect para la dirección de arranque y un extremo para cada agente.

  • La URL de la dirección de arranque es la misma en todas las redes de VPC a las que está conectado un clúster. La dirección IP es local para la red de consumidores.

  • Los clientes se conectan a los agentes de Kafka mediante nombres de DNS. Estos nombres se registran automáticamente en cada red de VPC a la que está conectado un clúster de Kafka. La dirección de arranque y su número de puerto están disponibles como una propiedad del clúster.

  • Los clientes usan la dirección de arranque para recuperar las URLs de los agentes. Estas URLs se resuelven en direcciones IP locales para cada red de VPC. Puedes encontrar las URLs y las direcciones IP reales de los agentes en Cloud DNS.

En el siguiente diagrama, se muestra una arquitectura de muestra de una red de clúster de Managed Service para Apache Kafka.

Una red de Managed Service para Apache Kafka

  • En este ejemplo, el clúster tiene tres agentes y está en la VPC de tenant.

  • Los agentes se comunican con los clientes a través del puerto predeterminado de Kafka (9092) y tienen direcciones IP únicas. En este ejemplo, los tres agentes tienen las direcciones IP 10.128.10.2, 10.128.10.3 y 10.128.10.4, respectivamente.

  • Los tres agentes se conectan al balanceador de cargas de arranque. Esto garantiza una alta disponibilidad y tolerancia a fallas regionales, ya que la dirección de arranque no se limita a un solo agente o zona.

Solucionar problemas

Para obtener información sobre cómo solucionar problemas de herramientas de redes, consulta Errores de herramientas de redes.

Próximos pasos