Managed Service para Apache Kafka es un Google Cloud servicio que te ayuda a ejecutar clústeres seguros, escalables de Apache Kafka de código abierto. En esta página, se ofrece una descripción general de lo que el servicio automatiza y simplifica para ti. Para obtener más información sobre Apache Kafka, consulta el sitio web de Apache Kafka.
Tamaño y escalamiento sencillos
Para dimensionar o escalar un clúster de Managed Service para Apache Kafka, solo debes establecer la cantidad total de CPU virtuales y el tamaño de la RAM del clúster. La administración de los agentes, incluido el almacenamiento, está completamente automatizada. Para satisfacer las demandas de los clientes, puedes supervisar la CPU virtual y el uso de otros recursos, y ajustarlos según sea necesario.
Cuando estableces la cantidad de CPU virtuales y el tamaño de la RAM, el servicio automatiza el cambio de tamaño y el aprovisionamiento de los agentes. Si aumentar el tamaño del clúster requiere un agente nuevo, el servicio puede rebalancear automáticamente las particiones entre los agentes.
Aprovisionamiento de agentes
Cuando configuras la cantidad total de CPU virtuales y el tamaño de la RAM del clúster, el servicio aprovisiona agentes nuevos y escala los existentes. Para una configuración de clúster típica, la cantidad total de CPU virtuales y el tamaño de la RAM se dividen de manera uniforme entre todos los agentes. Esto significa que se permiten cantidades fraccionarias de CPU virtuales por agente, aunque se requiere un mínimo de una sola CPU virtual por agente. Todos los clústeres se distribuyen en tres zonas. Esto significa que se requiere un mínimo de 3 CPU virtuales y 3 GiB de RAM por clúster.
A medida que aumentas el tamaño del clúster, los agentes se escalan verticalmente hasta 15 CPU virtuales por agente. Una vez que se alcanza este límite, el servicio crea agentes nuevos. Cuando disminuyes el tamaño del clúster, los agentes existentes se reducen a una sola CPU virtual, pero no se borran.
El tamaño máximo del agente puede cambiar en cualquier momento. Se eligió este límite para mantener el escalamiento lineal de la capacidad de procesamiento del agente con la cantidad de CPU virtuales.
Algoritmo de escalamiento
La cantidad de agentes se determina según la capacidad total de CPU virtuales o de memoria del clúster. La proporción de escalamiento es de 1 agente por cada 15 CPU virtuales o 120 gibibytes (GiB) de recursos, lo que dé como resultado una mayor cantidad de agentes. La proporción de CPU virtuales a memoria (CPU virtuales:GiB) debe permanecer entre 1:1 y 1:8. Los agentes se distribuyen de manera equitativa entre las 3 zonas, con una diferencia máxima de uno.
Por ejemplo, si configuras un clúster con 70 CPU virtuales y 130 GiB de RAM, junto con un factor de replicación de 3, el siguiente cálculo determina la cantidad de agentes:
Calcula la cantidad de agentes necesarios para tener en cuenta las CPU virtuales:
ceiling(70 vCPUs / 15 vCPUs)= 5 agentesCalcula la cantidad de agentes necesarios para tener en cuenta la memoria:
ceiling(130 GiB / 120 GiB)= 2 agentes
En este caso, el clúster tiene 5 agentes, ya que la cantidad de agentes se determina según la cantidad de CPU virtuales. Dos de las 3 zonas tienen 2 agentes asignados, y la última zona tiene 1 agente.
Administración de almacenamiento
La administración de almacenamiento está automatizada. En la mayoría de los casos, eres responsable de establecer el tiempo de retención en temas individuales para controlar el costo o satisfacer tus políticas de retención de datos. No es necesario que aprovisiones ni administres discos persistentes.
El servicio se basa en el almacenamiento por niveles (KIP-405). El almacenamiento por niveles combina volúmenes de disco persistente aprovisionados previamente conectados a agentes con almacenamiento de objetos prácticamente ilimitado.
El servicio asigna al menos 100 GiB de SSD discos persistentes por cada CPU virtual para equilibrar el rendimiento, la disponibilidad y el costo. Se te facturarán 100 GiB por CPU virtual, aunque el tamaño real del disco por agente puede superar este valor. El tamaño del disco por agente nunca se reduce, incluso si el clúster se reduce.
Cada líder de partición almacena en búfer los mensajes en archivos de segmento en estos discos persistentes. Después de que se implementa un segmento, se mueve al almacenamiento de objetos persistente
respaldado por Cloud Storage regional. El tamaño de estos archivos de segmento se establece con la configuración de log.roll.ms y log.segment.bytes.
Si bien estos detalles son útiles para comprender, el servicio administra el almacenamiento. Las configuraciones específicas, como la cantidad de capacidad de disco persistente por CPU virtual, son detalles de implementación que pueden cambiar. No tienes acceso directo a los buckets de Cloud Storage que se usan para el almacenamiento persistente.
Rebalanceo
Para que los agentes aprovisionados recientemente sean útiles para mantener el rendimiento, se debe mover parte del tráfico de los agentes existentes a estas máquinas nuevas. Para facilitar esto, puedes activar el rebalanceo automático.
Con el rebalanceo automático activado, cuando se aprovisiona un agente nuevo, el servicio rebalancea automáticamente las particiones de los agentes existentes. El modelo de almacenamiento por niveles verifica que se deba copiar una cantidad relativamente pequeña de datos a los agentes nuevos, lo que acelera el rebalanceo.
El algoritmo de rebalanceo se basa en el recuento de particiones. No tiene en cuenta el tráfico real que publica cada partición.
Herramientas de redes flexibles
El servicio hace que un clúster sea accesible de forma segura desde cualquier VPC. Esto incluye el acceso desde varias VPCs, proyectos y regiones.
Para configurar las herramientas de redes de un clúster, debes proporcionar el conjunto de subredes en las que el clúster es accesible. El servicio aprovisiona direcciones IP privadas para los servidores de arranque y los agentes en cada subred. También configura Cloud DNS privado con URLs para cada dirección IP. Los servidores de arranque tienen un balanceador de cargas, por lo que hay una sola URL de arranque por clúster. Las URLs son las mismas en todas las VPCs, por lo que las configuraciones del cliente pueden ser coherentes en todos los entornos.
Este nivel de flexibilidad se logra gracias a Private Service Connect (PSC). Cada dirección IP asignada a un clúster requiere un extremo de PSC. Los extremos se aprovisionan automáticamente.
Clústeres seguros
El servicio ofrece las siguientes funciones para la seguridad de los clústeres: autenticación, autorización, encriptación, aplicación de parches y aislamiento de recursos. También inhabilita las conexiones y el almacenamiento no autenticados y no encriptados.
Autenticación
El servicio admite dos métodos de autenticación: la capa de seguridad y autenticación simple (SASL) y TLS mutuo (mTLS). La autenticación mTLS está disponible en los clústeres creados después del 24 de junio de 2025. Todas las conexiones a los clústeres administrados se autentican con una principal que es una identidad de IAM con SASL o un certificado de cliente con mTLS. Las cuentas humanas, de servicio y federadas se admiten como principales cuando se usa SASL.
El servicio no admite otros protocolos, incluidos SASL/GSSAPI, SASL/SCRAM-SHA-256 y SASL/SCRAM-SHA-512. El servicio tampoco permite conexiones no autenticadas.
Autorización
El servicio emplea un enfoque por capas para la autorización. IAM controla las acciones de administración de clústeres, como crear, actualizar y borrar recursos. La autorización para las principales autenticadas depende del método que se use:
SASL: Las principales que usan IAM se autorizan a través de Google Cloud vinculaciones de roles de IAM o con ACL de Kafka en el clúster. Para obtener más información, consulta Configura la autenticación SASL.
mTLS: Las principales que se autentican con mTLS se autorizan a través de Kafka ACLs. Para obtener más información, consulta Configura la autenticación mTLS.
Puedes administrar las ACL de Kafka con las Google Cloud herramientas o herramientas de Kafka de terceros. Para obtener más información sobre la configuración de IAM y las ACL de Kafka, consulta Control de acceso con IAM y ACL de Kafka.
Encriptación
Se requiere encriptación. Todas las conexiones a los clústeres deben usar TLS. Los certificados TLS que presentan los agentes están firmados por Public Certificate Authority. Los datos almacenados siempre están encriptados. Elige si deseas usar claves de encriptación administradas por Google o por el cliente (CMEK) para la encriptación en reposo.
Aplicación de parches
El equipo de servicio hace un seguimiento de las vulnerabilidades de seguridad descubiertas en el código abierto. Cuando el servicio descubre vulnerabilidades, aplica parches a tus clústeres automáticamente.
Aislamiento de recursos
Otra función de seguridad del servicio es el aislamiento de recursos. El servicio administrado implementa clústeres en proyectos de usuario en una VPC privada a la que no se puede acceder a través de direcciones IP públicas. Cada uno de tus proyectos tiene un proyecto de usuario dedicado, con una cuenta de agente de servicio dedicada. Esto ayuda a limitar el alcance del acceso otorgado al servicio.
Registro de esquemas
Para simplificar la coordinación entre productores y consumidores, Managed Service para Apache Kafka incluye una API de registro de esquemas. Un registro proporcionado por el servicio actúa como un repositorio de esquemas que se comparten entre las aplicaciones.
El servicio implementa la API de REST de Confluent Schema Registry que ayuda en la integración con las aplicaciones de Kafka existentes. Se admiten los formatos de esquema de Apache Avro y búfer de protocolo (Protobuf). No se admite JSON.
Managed Service para Apache Kafka también ofrece una API administrativa y un conjunto de herramientas para administrar registros y esquemas de esquemas. El conjunto de herramientas incluye la Google Cloud consola, gcloud CLI y las bibliotecas cliente.
Para obtener más información sobre el registro de esquemas, consulta la descripción general del registro de esquemas.
Integración de datos con Kafka Connect
Managed Service para Apache Kafka simplifica la integración de datos a través de Kafka Connect. Kafka Connect ofrece varios complementos de conectores integrados alojados en clústeres de Connect. Estos conectores se usan para la migración, la copia de seguridad, la recuperación ante desastres, la alta disponibilidad y la integración de datos. Estos conectores te permiten conectar tus clústeres de Managed Service para Apache Kafka a varios sistemas, incluidos otras implementaciones de Kafka y Google Cloud servicios como BigQuery, Cloud Storage y Pub/Sub. Kafka Connect proporciona una integración de datos confiable y escalable con una sobrecarga operativa más baja, y supervisión y registro integrados.
Para obtener más información sobre Kafka Connect, consulta la descripción general de Kafka Connect.
Clústeres de alta disponibilidad
El objetivo del servicio es proporcionar clústeres regionales para aplicaciones fundamentales. En particular, el servicio te protege de las fallas de zonas o agentes individuales.
Para lograr esto, todos los clústeres se aprovisionan en una configuración de tres zonas compatible con racks. La configuración predeterminada del tema requiere al menos tres réplicas. La compatibilidad con racks garantiza que las réplicas se creen en diferentes zonas. La cantidad mínima predeterminada de réplicas sincronizadas es de dos. Esto significa que tu clúster puede tolerar la pérdida completa de una zona o un agente.
Cuando falla un agente debido a una falla de software, hardware o redes, se reemplaza automáticamente. Cuando el servicio detecta una falla del agente, lo reinicia automáticamente, en una máquina diferente si es necesario. Una vez que el agente está disponible, Apache Kafka lo integra en el clúster. Una falla completa de la zona podría imposibilitar la creación de un agente nuevo. Sin embargo, el clúster continúa funcionando mientras las otras dos zonas permanezcan disponibles.
Además de estas funciones específicas, una lista cada vez mayor de herramientas y procesos internos mantiene de forma proactiva el estado del servicio, el código de Apache Kafka y las actualizaciones. Las copias de seguridad de datos y metadatos se mantienen en varios niveles, lo que permite que el servicio se recupere de muchos errores humanos y fallas de software.
El servicio no proporciona protección contra fallas regionales o de dos zonas. Para las aplicaciones que requieren este nivel de protección, te recomendamos que ejecutes dos clústeres regionales separados. Puedes sincronizar los datos entre dos clústeres con herramientas como MirrorMaker 2.0 de Kafka Connect.
Herramientas para tu estilo de administración
El objetivo del servicio es ofrecer un conjunto completo de herramientas para tu estilo de administración y solución de problemas de clústeres. Esto incluye herramientas para la administración, la supervisión y el registro.
Managed Service para Apache Kafka se expone como una API de Google Cloud. Esto significa que puedes administrar clústeres y recursos de clústeres con las APIs de REST y gRPC. Se proporcionan varios clientes e interfaces para estas APIs, incluidos los siguientes:
- Proveedores de Terraform si prefieres el enfoque de infraestructura como código
- IU en la Google Cloud consola para el trabajo interactivo en un navegador.
- Gcloud CLI para el trabajo interactivo en una shell
- Bibliotecas cliente en Java, Python, Go y otros lenguajes para el desarrollo y la creación de secuencias de comandos personalizados
Para la supervisión y la solución de problemas, el servicio exporta métricas a Cloud Monitoring. Algunas de las métricas están disponibles en la IU del servicio. Un conjunto completo está disponible en Cloud Monitoring para el trabajo interactivo, la configuración de alertas y la exportación a otros sistemas.
El servicio también exporta registros de agentes a Cloud Logging. Se pueden buscar y usar para crear métricas y alertas basadas en registros.
Actualizaciones y parches
Los clústeres de Managed Service para Apache Kafka se ejecutan en la versión 3.7.1 de Apache Kafka. El servicio aplica parches automáticamente a las vulnerabilidades de seguridad críticas.
Las actualizaciones de la infraestructura subyacente, incluidas las capas del sistema operativo y de orquestación, son continuas y automáticas. Los agentes se actualizan con un reinicio progresivo, sin tiempo de inactividad para el clúster.
El servicio no actualiza automáticamente el código de Apache Kafka que se ejecuta en los agentes a versiones secundarias nuevas.
Costo transparente
El modelo de precios de Managed Service para Apache Kafka es similar a los cargos que ves cuando ejecutas Apache Kafka por tu cuenta en Compute Engine. Pagas por los recursos que aprovisionas (CPU virtuales, RAM y almacenamiento local) y consumes (almacenamiento persistente y transferencia de datos). El almacenamiento persistente y la CPU virtual cuestan más con Managed Service para Apache Kafka en comparación con la configuración de un sistema similar por tu cuenta. Por el contrario, los precios de la transferencia de datos y el almacenamiento local son similares entre Managed Service para Apache Kafka y Kafka autoadministrado. Para obtener más información sobre los precios, consulta Precios de Managed Service para Apache Kafka.
Compatibilidad porque ejecutamos Apache Kafka
Por último, Managed Service para Apache Kafka ejecuta el mismo software de código abierto que ya puedes ejecutar en tu entorno. No es necesario que cambies el código de tu aplicación para migrarla al servicio.
Limitaciones
Managed Service para Apache Kafka tiene las siguientes limitaciones:
Cada clúster debe tener los mismos recursos en cada una de las tres zonas. No se admiten los clústeres de Managed Service para Apache Kafka de una o dos zonas.
No puedes elegir las zonas cuando creas el clúster.
No puedes configurar el volumen de almacenamiento local en un clúster.
Managed Service para Apache Kafka se ejecuta en el modo KRaft. No se admite el modo Zookeeper.
No se admiten las APIs de JMX para las métricas.
No se admite la compresión de temas con
zstd. Los valores admitidos paracompression.typeincluyenlz4,gzip,snappyyuncompressed.Si bien puedes cambiar las configuraciones del agente con el modo de actualización
read-onlyen cualquier momento, estos cambios solo entran en vigencia cuando se reinician los agentes. Los reinicios ocurren periódicamente como parte de los procesos de mantenimiento y actualización de Google, pero no hay un cronograma establecido ni una forma de activarlos de forma manual. Como resultado, no puedes controlar cuándo entran en vigencia estos cambios. Entre los ejemplos de configuracionesread-only, se incluyenauto.create.topics.enableybackground.threads. Las actualizaciones de las configuraciones con el modo de actualizacióncluster-wide, comomessage.max.bytes, no requieren reinicios y entran en vigencia de inmediato.El servicio administra algunos parámetros de configuración del agente, y no se pueden actualizar. Esto incluye
broker.idy la configuración relacionada con el almacenamiento, comoremote.log.storage.system.enable.
Próximos pasos
- Crea un clúster de Managed Service para Apache Kafka.
- Envía y recibe mensajes con un clúster de Managed Service para Apache Kafka.
- Revisa las limitaciones de Managed Service para Apache Kafka.
- Obtén información sobre los precios de Managed Service para Apache Kafka.