Kafka 渐进式安全升级：KRaft/Broker 零停机实战指南

在运行中的 Kafka 集群渐进式启用安全机制，同时保证业务零停机，是一项极具挑战性的任务。尤其是在 KRaft 模式下，由于架构的变化，传统的安全升级方法可能不再适用。本文将深入探讨如何实现 KRaft 和 Broker 模式下 Kafka 集群的安全零停机升级，并分享相关的实战经验。

问题场景重现：业务不能停！

假设我们有一个运行中的 Kafka 集群，它负责收集电商平台的订单数据，支撑着实时的交易分析和风控系统。由于业务的快速发展，我们需要为 Kafka 集群启用 Kerberos 认证和 SSL 加密，以满足更高的安全合规要求。然而，任何停机都会直接影响交易分析，导致风控失效，带来巨大的经济损失。因此，我们必须找到一种零停机的安全升级方案。

底层原理深度剖析：理解 Kafka 安全机制

Kafka 的安全机制主要包括以下几个方面：

• 认证 (Authentication)：验证客户端的身份。常用的认证方式包括 SASL/Kerberos 和 SSL 客户端认证。
• 授权 (Authorization)：控制客户端可以访问的 Kafka 资源（例如 Topic、Group）。通常通过 ACL (Access Control List) 实现。
• 加密 (Encryption)：保护 Kafka 集群内部以及客户端与 Kafka 集群之间的通信数据，防止数据泄露。通常通过 SSL/TLS 加密实现。

在 KRaft 模式下，Controller 节点的安全配置也至关重要。我们需要确保 Controller 节点之间的通信是安全的，并且只有授权的用户才能对 Kafka 集群进行管理操作。

具体配置解决方案：逐步启用安全机制

以下是 Kafka 集群安全零停机升级的步骤（KRaft 和 Broker 模式通用）：

1. 准备 Kerberos 环境 (可选)

   如果选择使用 Kerberos 认证，需要先搭建 Kerberos 服务，并为 Kafka Broker 和客户端创建 Kerberos principal。

   

   # 创建 Kafka Broker 的 Kerberos principal
   sudo kadmin.local -q "addprinc -randkey kafka/your.kafka.broker.host@YOUR.REALM"
   sudo kadmin.local -q "ktadd -k /etc/security/keytabs/kafka_broker.keytab kafka/your.kafka.broker.host@YOUR.REALM"
   
   # 创建 Kafka 客户端的 Kerberos principal
   sudo kadmin.local -q "addprinc -randkey client/your.client.host@YOUR.REALM"
   sudo kadmin.local -q "ktadd -k /etc/security/keytabs/kafka_client.keytab client/your.client.host@YOUR.REALM"
   

2. 配置 Kafka Broker/Controller 的 SSL/TLS 加密

   生成 Kafka Broker/Controller 的 KeyStore 和 TrustStore，并配置 server.properties 和 controller.properties 文件。

   # server.properties
   listeners=PLAINTEXT://:9092,SSL://:9093
   security.inter.broker.protocol=SSL
   ssl.client.auth=required # 可选，要求客户端进行 SSL 认证
   ssl.keystore.location=/etc/kafka/ssl/kafka.keystore.jks
   ssl.keystore.password=your_keystore_password
   ssl.truststore.location=/etc/kafka/ssl/kafka.truststore.jks
   ssl.truststore.password=your_truststore_password
   
   # controller.properties (KRaft 模式)
   controller.listener.names=CONTROLLER://:9094,SSL://:9095
   controller.security.protocol=SSL
   controller.ssl.client.auth=required # 可选，要求 Controller 进行 SSL 认证
   controller.ssl.keystore.location=/etc/kafka/ssl/kafka.keystore.jks
   controller.ssl.keystore.password=your_keystore_password
   controller.ssl.truststore.location=/etc/kafka/ssl/kafka.truststore.jks
   controller.ssl.truststore.password=your_truststore_password
   

3. 配置 Kafka Broker/Controller 的 SASL/Kerberos 认证 (可选)

   

   修改 server.properties 和 controller.properties 文件，启用 SASL/Kerberos 认证。

   # server.properties
   security.protocol=SASL_SSL # 如果同时启用 SSL 加密
   sasl.mechanism.inter.broker.protocol=GSSAPI
   sasl.kerberos.service.name=kafka
   sasl.kerberos.kinit.command=/usr/bin/kinit -kt /etc/security/keytabs/kafka_broker.keytab kafka/your.kafka.broker.host@YOUR.REALM
   sasl.kerberos.principal.to.local.rules=DEFAULT
   
   # controller.properties (KRaft 模式)
   controller.security.protocol=SASL_SSL # 如果同时启用 SSL 加密
   controller.sasl.mechanism.controller.protocol=GSSAPI
   controller.sasl.kerberos.service.name=kafka
   controller.sasl.kerberos.kinit.command=/usr/bin/kinit -kt /etc/security/keytabs/kafka_broker.keytab kafka/your.kafka.broker.host@YOUR.REALM
   controller.sasl.kerberos.principal.to.local.rules=DEFAULT
   

4. 滚动重启 Kafka Broker/Controller

   逐个重启 Kafka Broker 和 Controller，每次重启一个节点，确保 Kafka 集群始终可用。在重启之前，可以使用 Kafka Manager 或 Kafka Eagle 等工具监控集群的状态，确保数据复制和 Leader Election 正常。

   

5. 配置 Kafka 客户端

   修改 Kafka 客户端的配置，启用 SSL 加密和 SASL/Kerberos 认证。

   // Java 客户端配置
   Properties props = new Properties();
   props.put(CommonClientConfigs.SECURITY_PROTOCOL_CONFIG, "SASL_SSL"); // 如果同时启用 SSL 加密
   props.put(SaslConfigs.SASL_MECHANISM, "GSSAPI");
   props.put(SaslConfigs.SASL_KERBEROS_SERVICE_NAME, "kafka");
   props.put(SaslConfigs.SASL_JAAS_CONFIG, "com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab=\"/etc/security/keytabs/kafka_client.keytab\" principal=\"client/your.client.host@YOUR.REALM\";");
   props.put(SslConfigs.SSL_TRUSTSTORE_LOCATION_CONFIG, "/etc/kafka/ssl/kafka.truststore.jks");
   props.put(SslConfigs.SSL_TRUSTSTORE_PASSWORD_CONFIG, "your_truststore_password");
   

6. 灰度发布 Kafka 客户端

   逐步升级 Kafka 客户端，先在一小部分客户端上启用安全机制，观察运行情况，确认没有问题后再推广到全部客户端。

实战避坑经验总结

• 规划先行：在开始安全升级之前，务必制定详细的规划，包括升级步骤、回滚方案、监控指标等。
• 监控告警：在升级过程中，密切关注 Kafka 集群的各项指标，例如 CPU 使用率、内存使用率、磁盘 IO、网络流量等，确保集群运行稳定。可以使用 Prometheus 和 Grafana 构建监控告警系统。
• 小步快跑：不要一次性升级所有节点，而是采用小步快跑的方式，逐步推进升级过程。每次升级少量节点，可以降低风险，方便回滚。
• 兼容性测试：在升级 Kafka Broker 之前，务必对新版本的 Kafka Broker 进行兼容性测试，确保与现有客户端兼容。
• Kerberos 配置：Kerberos 的配置非常复杂，容易出错。建议使用 kinit 命令验证 Kerberos 认证是否正常。如果遇到 Kerberos 认证问题，可以查看 Kafka Broker 的日志，查找错误信息。
• Controller 选举：在 KRaft 模式下，需要特别关注 Controller 节点的选举。确保 Controller 节点的配置正确，并且能够正常选举出 Leader。
• Nginx 反向代理：在高并发场景下，可以考虑使用 Nginx 作为 Kafka 客户端的反向代理，实现负载均衡和安全防护。Nginx 可以配置 SSL/TLS 加密，保护 Kafka 客户端与 Kafka 集群之间的通信数据。同时，Nginx 可以限制客户端的并发连接数，防止恶意攻击。
• 宝塔面板监控：如果服务器使用宝塔面板管理，可以利用其内置的监控功能，实时查看 Kafka 集群的 CPU、内存、磁盘 IO 等资源使用情况，及时发现潜在问题。

通过以上步骤，我们可以在运行中的 Kafka 集群上渐进式启用安全机制，同时保证业务零停机。在实际操作中，需要根据具体的环境和需求进行调整，并密切关注 Kafka 集群的状态，确保升级过程顺利完成。