Managed Service para Apache Kafka es un Google Cloud servicio que te ayuda a ejecutar clústeres de Apache Kafka de código abierto seguros y escalables. En esta página, se proporciona 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 simples
Para dimensionar o escalar un clúster de Servicio administrado 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 intermediarios, incluido el almacenamiento, está completamente automatizada. Para satisfacer las demandas de los clientes, puedes supervisar el uso de las CPU virtuales y otros recursos, y ajustarlos según sea necesario.
Cuando configuras el recuento 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 nuevo agente, el servicio puede rebalancear automáticamente las particiones entre los agentes.
Aprovisionamiento de agentes
Cuando configuras el tamaño total de CPU virtuales y RAM para el clúster, el servicio aprovisiona nuevos agentes y escala los existentes. En una configuración de clúster típica, el tamaño total de la CPU virtual y la RAM se divide de manera uniforme entre todos los agentes. Esto significa que se permiten recuentos de CPU virtuales fraccionarios 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 vCPU por agente. Una vez que se alcanza este límite, el servicio crea nuevos intermediarios. 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 el recuento de vCPU.
Algoritmo de ajuste
La cantidad de intermediarios se determina según la capacidad total de CPU virtuales o memoria del clúster. La proporción de ajuste es de 1 agente por cada 15 CPU virtuales o 120 gibibytes (GiB) de recursos, lo que genere una mayor cantidad de agentes. La proporción de CPU virtual y memoria (CPU virtual:GiB) debe mantenerse entre 1:1 y 1:8. Los intermediarios 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 intermediarios:
Calcula la cantidad de intermediarios necesarios para tener en cuenta las CPU virtuales:
ceiling(70 vCPUs / 15 vCPUs)= 5 intermediariosCalcula la cantidad de intermediarios necesarios para tener en cuenta la memoria:
ceiling(130 GiB / 120 GiB)= 2 intermediarios
En esta situación, el clúster tiene 5 intermediarios, ya que la cantidad de intermediarios se determina según la cantidad de CPU virtuales. Dos de las 3 zonas tienen 2 intermediarios asignados, y la última zona tiene 1 intermediario.
Administración de almacenamiento
La administración del almacenamiento es automática. En la mayoría de los casos, tú eres responsable de establecer el tiempo de retención en temas individuales para controlar los costos 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 y conectados a los agentes con almacenamiento de objetos prácticamente ilimitado.
El servicio asigna al menos 100 GiB de discos persistentes SSD para cada CPU virtual con el objetivo de 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 podría superar este valor. El tamaño del disco por agente nunca se reduce, incluso si se reduce la escala del clúster.
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 completa la rotación de un segmento, este se mueve al almacenamiento de objetos persistente respaldado por Cloud Storage regional. El tamaño de estos archivos de segmento se establece con los parámetros de configuración log.roll.ms y log.segment.bytes.
Si bien estos detalles son útiles para comprender el almacenamiento, el servicio lo administra. 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 recién aprovisionados sean útiles para mantener el rendimiento, se debe trasladar parte del tráfico de los agentes existentes a estas máquinas nuevas. Para que sea más fácil, puedes activar el rebalanceo automático.
Con el rebalanceo automático activado, cuando se aprovisiona un nuevo agente, el servicio rebalancea automáticamente las particiones de los agentes existentes. El modelo de almacenamiento por niveles verifica que se debe copiar una cantidad relativamente pequeña de datos a los nuevos intermediarios, lo que acelera el reequilibrio.
El algoritmo de rebalanceo se basa en el recuento de particiones. No tiene en cuenta el tráfico real que entrega cada partición.
Redes flexibles
El servicio hace que un clúster sea accesible desde cualquier VPC de forma segura. Esto incluye el acceso desde varias VPCs, proyectos y regiones.
Para configurar las redes de un clúster, debes proporcionar el conjunto de subredes en las que se puede acceder al clúster. 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 prohíbe las conexiones y el almacenamiento sin autenticar y sin encriptar.
Autenticación
El servicio admite dos métodos de autenticación: la capa de autenticación y seguridad simple (SASL) y la TLS mutua (mTLS). La autenticación mTLS está disponible en los clústeres creados después del 24 de junio de 2025. Todas las conexiones a clústeres administrados se autentican con una principal que es una identidad de IAM a través de SASL o un certificado de cliente a través de mTLS. Se admiten cuentas humanas, de servicio y federadas 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 de autorización por capas. IAM controla las acciones de administración de clústeres, como la creación, actualización y eliminación de recursos. La autorización para las entidades autenticadas depende del método utilizado:
SASL: Las principales que usan IAM se autorizan a través de vinculaciones de roles deGoogle Cloud IAM o con LCA de Kafka en el clúster. Para obtener más información, consulta Configura la autenticación SASL.
mTLS: Los principales que se autentican con mTLS se autorizan a través de las ACL de Kafka. Para obtener más información, consulta Configura la autenticación de mTLS.
Puedes administrar las ACL de Kafka con las herramientas de Google Cloud o herramientas de Kafka de terceros. Para obtener más información sobre cómo configurar la IAM y las LCA de Kafka, consulta Control de acceso con la IAM y las LCA de Kafka.
Encriptación
Se requiere encriptación. Todas las conexiones a los clústeres deben usar TLS. Los certificados TLS que presentan los intermediarios 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 administradas por el cliente (CMEK) para la encriptación en reposo.
Aplica parches
El equipo de servicio hace un seguimiento de las vulnerabilidades de seguridad descubiertas en el código fuente 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 inquilinos 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 inquilino 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 for 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 del registro de esquemas de Confluent, que ayuda a la integración con las aplicaciones de Kafka existentes. Se admiten los formatos de esquema de Apache Avro y Protocol Buffer (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. El conjunto de herramientas incluye la consola deGoogle Cloud , 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 for Apache Kafka a varios sistemas, incluidas 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 menor sobrecarga operativa, 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 esenciales. Específicamente, el servicio te protege de las fallas de zonas o intermediarios individuales.
Para lograr esto, todos los clústeres se aprovisionan en una configuración de tres zonas que reconoce los racks. La configuración predeterminada del tema requiere al menos tres réplicas. El reconocimiento de racks garantiza que las réplicas se creen en diferentes zonas. La cantidad mínima predeterminada de réplicas sincronizadas es dos. Esto significa que tu clúster puede tolerar la pérdida completa de una zona o un agente.
Cuando un agente falla debido a un problema de software, hardware o red, se reemplaza automáticamente. Cuando el servicio detecta una falla del agente, lo reinicia automáticamente, en otra máquina 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 nuevo agente. Sin embargo, el clúster seguirá 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 mantienen de forma proactiva el buen estado del servicio, el código de Apache Kafka y las actualizaciones. Las copias de seguridad de los datos y los 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 brinda protección contra fallas regionales o de doble zona. Para las aplicaciones que requieren este nivel de protección, recomendamos ejecutar 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.
El servicio administrado 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 consola de Google Cloud 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 desarrollo y 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. En Cloud Monitoring, hay disponible un conjunto completo para el trabajo interactivo, la configuración de alertas y la exportación a otros sistemas.
El servicio también exporta registros del agente 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 automáticamente parches para las vulnerabilidades de seguridad críticas.
Las actualizaciones de la infraestructura subyacente, incluidas las capas de orquestación y el sistema operativo, 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 los que consumes (almacenamiento persistente y transferencia de datos). El almacenamiento persistente y el costo de las CPU virtuales son más altos con Managed Service para Apache Kafka en comparación con la configuración de un sistema similar por tu cuenta. En cambio, 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.
Es compatible porque ejecutamos Apache Kafka
Por último, Managed Service for Apache Kafka ejecuta el mismo software de código abierto que tal vez ya ejecutes 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 la misma cantidad de 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 la configuración del agente con el modo de actualización
read-onlyen cualquier momento, estos cambios solo se aplican 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 programa establecido ni una forma de activarlos manualmente. Por lo tanto, no puedes controlar cuándo se aplican estos cambios. Algunos ejemplos de configuraciones deread-onlyincluyenauto.create.topics.enableybackground.threads. Las actualizaciones de configuraciones con el modo de actualizacióncluster-wide, comomessage.max.bytes, no requieren reinicios y se aplican 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 más información sobre los precios de Managed Service para Apache Kafka.