Kubernetes集群Sentry升级后sentry-ingest-replay-recordings Pod崩溃求助

从日志来看，核心问题是Pod依赖的Kafka主题ingest-replay-recordings不存在，导致消费者无法订阅主题引发崩溃。以下是具体修复步骤：

• 确认Kafka中是否存在目标主题
  进入Kafka Broker Pod，执行主题列表查询命令：

  kubectl exec -it <kafka-broker-pod-name> -- kafka-topics.sh --list --bootstrap-server <kafka-service-name>:9092
  

  替换<kafka-broker-pod-name>和<kafka-service-name>为集群中实际的Kafka Pod名称和服务名称，检查输出中是否包含ingest-replay-recordings。

• 手动创建缺失的Kafka主题
  如果主题不存在，执行创建命令（分区数和副本数根据你的Kafka集群规模调整）：

  kubectl exec -it <kafka-broker-pod-name> -- kafka-topics.sh --create --topic ingest-replay-recordings --bootstrap-server <kafka-service-name>:9092 --partitions 3 --replication-factor 1
  

  若为多节点Kafka集群，建议将--replication-factor设为2或3以保证高可用。

• 检查Helm Chart的自动主题配置
  查看Sentry Helm Chart的values.yaml配置，确认是否开启了Kafka主题自动创建功能（通常对应kafka.topics.autoCreate或类似参数）。如果未开启，修改values.yaml后重新升级Helm Chart：

  helm upgrade sentry sentry/sentry -f your-custom-values.yaml
  

  确保后续升级时主题能自动初始化。

• 验证Pod恢复状态
  删除崩溃的Pod触发重启：

  kubectl delete pod <sentry-ingest-replay-recordings-pod-name>
  

  用以下命令检查Pod是否正常运行：

  kubectl get pods | grep ingest-replay-recordings
  

  再查看Pod日志确认无报错：

  kubectl logs <new-pod-name>
  

• 排查Kafka ACL权限（若启用）
  如果你的Kafka集群启用了ACL权限控制，需确保Sentry对应的服务账号拥有ingest-replay-recordings主题的读写权限，可通过kafka-acls.sh命令配置权限：

  kubectl exec -it <kafka-broker-pod-name> -- kafka-acls.sh --bootstrap-server <kafka-service-name>:9092 --add --allow-principal User:<sentry-service-account> --operation Read --operation Write --topic ingest-replay-recordings
  

内容的提问来源于stack exchange，提问作者Maciej Małkowski