Configura la red para Managed Service for Apache Kafka

Los clientes pueden conectarse a un clúster de Google Cloud Managed Service para Apache Kafka desde cualquier red de nube privada virtual (VPC) en tus Google Cloud proyectos. También puedes activar el acceso desde rangos de IP de confianza a través de la Internet pública.

En esta página, se explica cómo se configuran las herramientas de redes en Managed Service para Apache Kafka, cómo activar las conexiones entre los clientes de Kafka y tu clúster, y cómo conectar de forma privada clientes y clústeres en diferentes proyectos.

Una red de VPC es una versión virtual de una red física, implementada en el interior Google Cloud. Proporciona conectividad de red privada y segura para tus instancias de VM, cargas de trabajo de contenedores y otros recursos. Para obtener más información, consulta la descripción general de las redes de VPC.

Descripción general

Cuando creas un clúster, el servicio coloca los agentes y los extremos de red del clúster en una red de VPC dentro de un proyecto administrado por Google. Este proyecto se denomina proyecto de usuario y la red se denomina red de usuario. Por el contrario, tus recursos, aplicaciones cliente y redes de VPC del cliente residen en tu propio proyecto, que se denomina proyecto de consumidor. Cada clúster de Managed Service para Apache Kafka tiene su propia red de usuario aislada.

Las redes de VPC se dividen en particiones llamadas subredes. Cada subred define un rango de direcciones IP en una región específica de tu red de nube. 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 usuario o, de manera opcional, activa el acceso público al clúster para conectarte a través de la Internet pública.

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 proyecto de consumidor que el clúster o a uno diferente. Las aplicaciones cliente en cualquier región dentro de las redes de VPC conectadas pueden conectarse al clúster. Para obtener más información sobre las ubicaciones y las cantidades de subredes, consulta Limitaciones.

Para obtener más información sobre cómo ver las subredes conectadas, consulta Visualiza 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. Cuando el servidor de arranque redirecciona un cliente a un agente en particular, usa la URL del agente en lugar de una dirección IP.

Las URLs de arranque y de agente son fijas durante la vida útil de un clúster, pero el formato de las URLs puede ser diferente para los distintos clústeres. Para obtener la dirección de arranque de un clúster, consulta Visualiza la dirección de arranque de un clúster.

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 ver 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 IP direcciones 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 CPU virtuales, entonces el clúster tiene un agente por cada 15 CPU virtuales. En ese caso, calcula la cantidad mínima de direcciones IP para cada subred de la siguiente manera:

  1. Divide la cantidad de CPU 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 CPU virtuales necesita al menos (60/15 + 1) = 5 direcciones IP utilizables.

Es posible que Google cambie la proporción de agentes a CPU virtuales. Para adaptarse a cualquier cambio, te recomendamos que asignes tres 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 al que esperas escalar tu clúster.

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

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 necesitas configuración adicional para conectarte 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 de forma privada en diferentes proyectos

Si deseas conectar de forma privada clientes de Kafka en diferentes Google Cloud proyectos a tu clúster, puedes usar uno de los siguientes métodos:

En las siguientes secciones, se describen estas opciones.

Conecta un clúster en diferentes proyectos

Puedes conectar subredes de otros proyectos a tu clúster. Para activar 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 deagente de servicio de Kafka administrado en ese proyecto. Este rol permite que el clúster acceda Google Cloud a los recursos, de modo que pueda crear recursos de red y entradas de DNS.

Por 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 IAM página de ese proyecto:

    Ir a 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: Es el nombre del proyecto que contiene la red de VPC para conectar.
    • CLUSTER_PROJECT_NUMBER: Es 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 de 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 en el proyecto host de la VPC compartida o en 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.

Conecta clientes a un clúster público

Si tienes aplicaciones cliente fuera de tu red de VPC, puedes activar el acceso público a tu clúster. Un clúster público aún requiere una subred conectada. Sin embargo, no necesitas enviar tráfico a través de él.

Cuando activas la función de clúster público, el servicio aprovisiona direcciones IPv4 externas para los extremos de agente y de arranque del clúster. El servicio también hace que las entradas de DNS del clúster se puedan resolver públicamente en estas direcciones IP públicas. Esto significa que los clientes externos pueden usar la misma dirección de arranque para ubicar los agentes y establecer una conexión. Esta implementación usa DNS de horizonte dividido. Los clientes en redes de VPC que contienen una subred conectada continúan resolviendo los extremos privados, mientras que los clientes en otras redes resuelven los extremos públicos. Activar la función de clúster público no crea recursos adicionales en tu proyecto de consumidor.

Cuando activas la función de clúster público, debes proporcionar uno o más rangos de IP de origen permitidos. Para obtener más información sobre los tamaños y límites de rangos permitidos, consulta Clústeres públicos o Limitaciones.

Puedes agregar o quitar rangos de IP de origen permitidos actualizando tu clúster. Managed Service para Apache Kafka usa Cloud Next Generation Firewall para restringir el acceso a clústeres públicos. Quitar rangos de IP de origen permitidos solo se aplica a las conexiones nuevas (consulta los efectos en el tráfico existente).

El servicio toma varias precauciones para garantizar la seguridad de tus clústeres públicos. Todas las conexiones se encriptan en tránsito con TLS y todas las conexiones requieren autenticación. Debes autenticarte con una identidad de IAM con SASL o un certificado de cliente con mTLS. No se permite el acceso anónimo. Para obtener más información, consulta Tipos de autenticación para agentes de Kafka.

Los administradores de seguridad pueden prohibir los clústeres públicos en tu proyecto con una restricción personalizada de la política de la organización. Para obtener más información sobre las políticas de la organización, consulta Crea restricciones personalizadas.

Configura firewalls de salida desde redes externas

En algunos casos, es posible que debas determinar las direcciones IPv4 externas de tus extremos de agente y de arranque. Para obtener instrucciones sobre cómo recuperar estos valores, consulta Detalles del clúster público.

El servicio pone esta información a disposición de las siguientes maneras:

  1. Las direcciones IPv4 externas asociadas con tu clúster están disponibles en la API de Managed Service para Apache Kafka, gcloud y Terraform.

  2. El servicio mantiene uno o más registros DNS de descubrimiento. Estos son registros A de DNS que contienen todas las direcciones IPv4 externas asociadas con tu clúster. Puedes usar estos registros en firewalls basados en FQDN, como Cloud NGFW, que actualizan automáticamente las reglas cuando cambia la lista de extremos. La lista de extremos de descubrimiento está disponible en la API, gcloud y Terraform.

Ten en cuenta lo siguiente cuando uses las direcciones IP públicas asociadas con tu clúster:

  1. La lista de direcciones IPv4 públicas asociadas con tu clúster puede cambiar o aumentar. Por este motivo, automatiza la forma en que consumes esta información o define un proceso para tener en cuenta los registros DNS de descubrimiento nuevos cuando aumentes la escala de tu clúster. Los cambios pueden ocurrir cuando sucede lo siguiente:

    • Aumentas la escala de tu clúster. El aumento de escala puede agregar una o más direcciones IPv4 externas a medida que se agregan agentes nuevos. Para comprender cómo la cantidad de CPU virtuales influye en la cantidad de agentes, consulta Tamaño de subred

    • Inhabilitas y, luego, habilitas la función de clúster público. Esta acción asigna un nuevo conjunto de direcciones IPv4 externas al clúster.

  2. Cada registro DNS de descubrimiento contiene un máximo de 30 direcciones IP. Esto se mantiene dentro de los límites comunes que aplican los firewalls de FQDN. Los clústeres con 29 agentes o menos tienen un registro DNS de descubrimiento que contiene 30 direcciones IPv4 externas (incluido el registro de arranque). El servicio agrega un registro DNS de descubrimiento por cada 30 agentes adicionales. Para comprender cómo la cantidad de CPU virtuales influye en la cantidad de agentes, consulta Tamaño de subred.

  3. No configures tus clientes de Kafka para que se conecten a registros DNS de descubrimiento. En su lugar, configura los clientes para que se conecten a la dirección de arranque. Para obtener más información, consulta Limitaciones.

  4. Si usas esta información para configurar firewalls de salida, permite la conectividad a los puertos TCP 9092 (SASL) y 9192 (mTLS).

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 usuario y una o más redes de consumidor.

  • En la red de usuario, 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 de forma individual, pero te recomendamos que uses la dirección de arranque para obtener confiabilidad.

  • Dentro de cada red de consumidor, 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 consumidor.

  • 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 direcciones IP y las URLs 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 se encuentra en la VPC de usuario.

  • 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 la alta disponibilidad y la tolerancia a fallas regionales, ya que la dirección de arranque no está limitada a un solo agente o zona.

Limitaciones

Las siguientes limitaciones se aplican a las conexiones de VPC y a los clústeres públicos:

  • Región de subred. Las subredes conectadas deben estar en la misma región que tu clúster.

  • Cantidad de subredes. Puedes conectar un mínimo de una y un máximo de diez subredes a un clúster.

  • Subredes por red. Puedes conectar como máximo una subred por red de VPC a un clúster.

  • Tamaño de subred. Cada subred conectada requiere al menos una dirección IP para cada agente, además de una dirección IP para la dirección de arranque. Se requiere un mínimo de cuatro direcciones IP utilizables. Para obtener más información, consulta Tamaño de subred.

  • Subredes conectadas para clústeres públicos. Para activar el acceso público, tu clúster debe tener al menos una subred conectada, aunque no necesitas enviar tráfico a través de ella.

  • Rangos de IP de origen permitidos. Cada rango de IP de origen permitido para un clúster público debe especificarse en la notación CIDR con IPv4. Cada tamaño de subred CIDR debe estar entre /16 y /32. Los rangos CIDR no deben superponerse. No se admiten direcciones IPv6. Puedes especificar un máximo de 500 rangos de IP de origen permitidos.

  • Resolución de DNS de registros de descubrimiento. Los registros DNS de descubrimiento están diseñados solo para configurar firewalls de salida basados en FQDN. No configures tus clientes de Kafka para que se conecten a estos registros de descubrimiento. En su lugar, configura los clientes para que se conecten a la dirección de arranque.

Solucionar problemas

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

Próximos pasos