Apache Pulsar Helm Chart 生产级部署指南：从架构解析到安全运维

1. 项目概述与核心价值

如果你正在寻找一种在 Kubernetes 上部署和管理 Apache Pulsar 的“标准答案”，那么apache/pulsar-helm-chart项目就是你绕不开的起点。作为一个在云原生消息队列和流处理领域摸爬滚打多年的从业者，我深知将 Pulsar 这样一个由多个有状态组件（ZooKeeper、Bookie、Broker）构成的复杂系统，手动编排到 K8s 集群里是多么耗时且容易出错。这个官方维护的 Helm Chart 项目，本质上就是社区将最佳实践和复杂配置封装成可复用的“配方”，让你能通过几条命令，快速拉起一个功能完整、架构标准的 Pulsar 集群。

这个 Chart 的价值远不止于“一键安装”。它覆盖了从开发测试到准生产环境的全链路需求：内置了 ZooKeeper、Bookies、Brokers、Functions Worker 和 Proxy 等所有核心组件；集成了认证授权（JWT、OpenID）、TLS 加密、持久化存储等安全与可靠性特性；甚至还打包了监控栈（VictoriaMetrics + Grafana）和管理界面（Dekaf UI、Pulsar Manager）。这意味着，你无需从零开始编写几十个 YAML 文件，去处理服务发现、配置同步、证书管理这些琐碎但关键的问题。项目文档中反复强调的安全警告，恰恰说明了它的务实——它不提供“开箱即用”的生产配置，而是给你一个高度可定制、符合云原生范式的坚实基础，要求你根据自身的安全和运维规范去填充血肉。对于任何计划在 K8s 上规模化使用 Pulsar 的团队来说，深入理解并正确使用这个 Helm Chart，是构建稳定、可运维数据流平台的第一步。

2. 核心架构与安全设计解析

2.1 组件拓扑与通信流

在深入配置之前，我们必须先厘清这个 Helm Chart 部署出的 Pulsar 集群内部是如何工作的。它构建了一个经典的多层架构：

1. 控制平面（ZooKeeper）：由 Chart 部署的 ZooKeeper 集群（默认3节点）担任配置存储和元数据协调者的角色。所有 Broker、Bookie 的元数据（如 Topic 分区信息、Broker 负载、Bookie ledger 映射）都存储于此。这是集群的“大脑”，其稳定性和性能至关重要。
2. 数据平面（BookKeeper）：Bookie 节点组成了持久化存储层。Pulsar 的持久化消息、Cursor（消费位置）信息都以 Ledger 的形式存储在 BookKeeper 中。Chart 默认部署3个 Bookie，采用StatefulSet确保每个 Pod 有稳定的网络标识和独立的PersistentVolume，这是保证数据持久性和顺序性的关键。
3. 服务平面（Broker）：Broker 是无状态的服务层，负责处理客户端的生产/消费请求、进行 Topic 查找、负载均衡以及与 BookKeeper 交互进行消息读写。多个 Broker 之间通过 ZooKeeper 协同工作。
4. 接入层（Proxy）：Proxy 作为集群的单一入口点，为客户端提供连接管理和协议转换。客户端只需连接 Proxy，由 Proxy 负责将请求路由到正确的 Broker。这简化了客户端配置，并便于实现负载均衡和连接池管理。
5. 功能与监控（可选组件）：Pulsar Functions（轻量级计算框架）作为独立组件运行；VictoriaMetrics 栈负责指标抓取、存储和展示（Grafana）；Dekaf UI 或 Pulsar Manager 提供图形化管理界面。

这些组件之间的网络通信（如 Broker 与 ZooKeeper、Broker 与 Bookie、Proxy 与 Broker）在启用 TLS 后都会进行加密。Chart 利用cert-manager可以自动为各组件签发和管理 TLS 证书，这是生产环境不可或缺的一环。

2.2 安全模型与“零信任”起点

项目文档开篇就用大量篇幅警告“默认配置不安全”，这绝非危言耸听，而是云原生部署的黄金法则：默认拒绝，显式允许。Chart 的默认值（values.yaml）是为了让你能最快地跑起来一个集群，用于功能验证和开发测试。它默认关闭了认证和授权，内部通信也可能未加密。直接将其暴露给公网，无异于将数据库裸奔。

核心安全原则：永远假设你的 Kubernetes 集群网络是不可信的。即使是在私有云或 VPC 内，也应遵循最小权限原则和深度防御策略。

因此，基于这个 Helm Chart 进行生产部署，你的核心工作就是围绕以下几个层面构建安全防线：

1. 网络隔离：

   • 服务类型：Proxy 的 Service 类型默认已从LoadBalancer改为更安全的ClusterIP。这意味着 Proxy 默认只能在集群内部访问。如果你需要从集群外部访问，必须显式配置。
   • 内部负载均衡器：如果必须暴露 Proxy，强烈建议使用云供应商的内部负载均衡器（Internal LoadBalancer），并配合loadBalancerSourceRanges严格限制源 IP 范围（例如，仅允许办公网或跳板机 IP 段）。绝对避免使用面向公网的负载均衡器。
   • Network Policies：Chart 本身不创建复杂的 Network Policies。你需要根据业务需求，手动定义 Pod 之间的网络流量规则，例如，只允许 Proxy Pod 访问 Broker 的特定端口，限制不必要的 Pod 间通信。

2. 传输安全（TLS）：

   • 启用 mTLS：为所有组件间通信启用双向 TLS（mTLS）。Chart 支持通过cert-manager自动签发证书。你需要为每个组件（proxy，broker，bookie，zookeeper）的tls.enabled设置为true，并配置相应的证书颁发机构（CA）和证书签发逻辑。
   • 证书管理：生产环境应使用企业内部的私有 CA 或像cert-manager这样集成 Let‘s Encrypt 等公共 CA 的工具来管理证书生命周期（签发、续期、轮换）。避免使用自签名证书长期运行。

3. 身份认证与授权：

   • 认证（Authentication）：Chart 支持 JWT 和 OpenID Connect (OIDC)。JWT 适合服务间通信和自动化脚本，OIDC 适合集成企业单点登录（SSO）供管理用户使用。你需要在values.yaml中启用并配置auth.authentication。
   • 授权（Authorization）：认证解决了“你是谁”的问题，授权则解决“你能做什么”。Pulsar 支持基于角色的访问控制（RBAC）。你需要通过 Pulsar 的 Admin API 或管理工具，为每个角色（对应一个 Token 或 OIDC 用户）在命名空间（Namespace）或主题（Topic）级别精细配置生产（produce）、消费（consume）等权限。

4. 数据安全：

   • 存储加密：确保为 BookKeeper 和 ZooKeeper 使用的PersistentVolume启用存储加密（如 AWS EBS 加密、Azure Disk Encryption）。这通常在云平台或存储类（StorageClass）级别配置。
   • Secret 管理：Chart 会生成 JWT 密钥、数据库密码等敏感信息，并存储为 Kubernetes Secret。确保你的集群配置了 Secret 加密（如使用 KMS），并严格控制对这些 Secret 的访问权限。

忽视任何一层，都可能成为攻击者渗透的突破口。这个 Helm Chart 提供了拼图的所有板块，但如何将它们严丝合缝地组装成坚固的堡垒，完全取决于你的设计和配置。

3. 生产级部署实操全流程

3.1 环境准备与前置依赖

在运行helm install之前，需要确保你的 Kubernetes 环境已就绪。以下是我在多次部署中总结的检查清单：

1. Kubernetes 集群：版本 >= 1.25。确保节点资源充足，建议至少 3 个 Worker 节点，每个节点配置不低于 4核 CPU、8GB 内存。Pulsar 对 I/O 敏感，建议使用高性能云盘或本地 SSD。
2. Helm 与 kubectl：安装 Helm 3.12.0+ 和与集群版本兼容的 kubectl。
3. 存储类（StorageClass）：这是最容易被忽略但影响深远的一步。BookKeeper 和 ZooKeeper 需要持久化存储。
   • BookKeeper：对 I/O 延迟和吞吐量要求极高，因为它要持久化消息数据。强烈建议使用本地 SSD 或高性能云盘（如 AWS gp3/io2， Azure Premium SSD）。对应的 StorageClass 应配置适当的iops和throughput。在values.yaml中，通过bookkeeper.persistence.storageClass指定。
   • ZooKeeper：存储元数据，对顺序写入性能有要求，但数据量不大。可以使用性能稍逊但可靠的云盘。
   • 测试：部署前，务必创建一个 PVC 测试读写性能，确保满足预期。
4. 证书管理器（cert-manager）：如果你计划启用 TLS（生产环境必须），需要先安装cert-manager。项目提供了安装脚本 (./scripts/cert-manager/install-cert-manager.sh)，它会安装一个较稳定的 LTS 版本（如 1.12.17）。特别注意：如果你使用的cert-manager版本低于 1.15.0 且需要为 ZooKeeper 启用 TLS，必须确保在cert-manager的部署中启用了AdditionalCertificateOutputFormats=true特性门控，否则 Chart 的 TLS 配置可能不生效。安装脚本的最新版本通常会处理此问题。
5. 负载均衡器：如果计划从集群外部访问，确认你的云供应商支持创建内部负载均衡器，并且你的 Kubernetes 集群有相应的控制器（如 AWS Load Balancer Controller, Azure Cloud Provider）。

3.2 定制化 values.yaml 配置详解

不要直接修改官方的values.yaml。最佳实践是创建一个你自己的my-values.yaml文件，只覆盖需要修改的配置。我们从最简配置开始，逐步加固。

第一步：基础配置与资源规划

# my-values.yaml # 1. 启用必要的核心组件 components: zookeeper: true bookkeeper: true broker: true proxy: true # 根据需求启用 functions, manager 等 functions: false pulsar_manager: false dekaf: true # 新的管理UI，比Pulsar Manager更活跃 # 2. 设置各组件副本数（根据集群规模调整） zookeeper: replicaCount: 3 # 必须为奇数，建议3或5 bookkeeper: replicaCount: 3 # 至少3个，生产环境建议更多（如5-7个） broker: replicaCount: 2 # 至少2个以实现高可用，可根据负载增加 proxy: replicaCount: 2 # 至少2个以实现高可用 # 3. 资源配置（根据实际负载调整，此处为示例） resources: requests: memory: "2Gi" cpu: "1000m" limits: memory: "4Gi" cpu: "2000m" # 可以为每个组件单独覆盖，例如 Bookie 需要更多内存 bookkeeper: resources: requests: memory: "4Gi" cpu: "2000m" limits: memory: "8Gi" cpu: "4000m" # 4. 持久化存储配置 zookeeper: persistence: enabled: true storageClassName: "standard-ssd" # 替换为你的高性能存储类 size: 20Gi bookkeeper: persistence: enabled: true storageClassName: "local-ssd" # 为Bookie使用本地SSD存储类 size: 200Gi # 根据消息保留策略和吞吐量预估 # Bookie 使用多个日志磁盘和索引磁盘，这里配置的是每个Pod的总数据卷大小。 # 更高级的配置可以通过 `ledgerDirs` 和 `journalDirs` 指定多个卷。

第二步：启用 TLS 与认证

这是将集群推向生产环境的关键一步。

# my-values.yaml (续) # 5. 全局启用TLS tls: enabled: true # 使用 cert-manager 自动签发证书 certmanager: enabled: true # 假设你已有一个配置好的 ClusterIssuer，例如名为 `letsencrypt-prod` 或 `ca-issuer` issuer: name: "ca-issuer" kind: "ClusterIssuer" # 为各个组件启用TLS proxy: enabled: true broker: enabled: true bookie: enabled: true zookeeper: enabled: true # ZooKeeper TLS 配置需要 cert-manager 的特定特性门控，确保已按文档配置。 # 6. 启用 JWT 认证 auth: authentication: enabled: true jwt: enabled: true # 使用一个已存在的Secret，其中包含base64编码的密钥 # 或者让Chart自动生成（仅用于测试，生产环境应自己管理密钥） usingSecretKey: true secretName: "pulsar-token-asymmetric-key" # 你预先创建的Secret名称 # 或者使用对称密钥（更简单，但安全性稍逊） # usingSecretKey: false # tokenPublicKey: "file:///pulsar/keys/public.key" # 公钥文件路径（容器内） # tokenPrivateKey: "file:///pulsar/keys/private.key" # 私钥文件路径（容器内） # 授权通常通过Pulsar Admin API在集群部署后配置 authorization: enabled: true superUserRoles: # 超级用户角色，拥有所有权限 - "admin" - "superuser"

如何生成 JWT 密钥和 Token？

# 1. 生成密钥对（如果使用非对称加密） openssl ecparam -name prime256v1 -genkey -out private-key.pem openssl ec -in private-key.pem -pubout -out public-key.pem # 2. 创建Kubernetes Secret（假设使用对称密钥，内容为base64编码的密钥字符串） echo -n "my-secret-jwt-key" | base64 # 得到 bXktc2VjcmV0LWp3dC1rZXk=

然后创建jwt-secret.yaml:

apiVersion: v1 kind: Secret metadata: name: pulsar-token-symmetric-key namespace: pulsar type: Opaque data: SECRET_KEY: bXktc2VjcmV0LWp3dC1rZXk= # 上一步得到的base64字符串

应用：kubectl apply -f jwt-secret.yaml。然后在values.yaml中引用这个 Secret。

第三步：配置外部访问与监控

# my-values.yaml (续) # 7. 配置Proxy外部访问（谨慎！） proxy: service: type: LoadBalancer # 改为LoadBalancer以从外部访问 annotations: # AWS EKS 内部负载均衡器注解 service.beta.kubernetes.io/aws-load-balancer-internal: "true" # 或 Azure AKS # service.beta.kubernetes.io/azure-load-balancer-internal: "true" # 或 GCP GKE # networking.gke.io/load-balancer-type: "Internal" loadBalancerSourceRanges: - "10.0.0.0/8" # 仅允许来自公司内网VPC的访问 - "192.168.1.0/24" # 或特定的办公网IP段 # 如果使用TLS，需要指定端口 ports: pulsar: port: 6651 # TLS端口 nodePort: null # 8. 配置监控（VictoriaMetrics Stack默认启用，按需调整） victoria-metrics-k8s-stack: enabled: true grafana: enabled: true adminPassword: "strong-password" # 务必修改！ # 导入Pulsar仪表盘 dashboardProviders: dashboardproviders.yaml: apiVersion: 1 providers: - name: 'pulsar' orgId: 1 folder: 'Pulsar' type: file disableDeletion: false editable: true options: path: /var/lib/grafana/dashboards/pulsar dashboards: pulsar: pulsar-overview: url: https://raw.githubusercontent.com/lhotari/pulsar-grafana-dashboards/master/dashboards/pulsar-overview.json pulsar-broker: url: https://raw.githubusercontent.com/lhotari/pulsar-grafana-dashboards/master/dashboards/pulsar-broker.json # 可以添加更多仪表盘 # 9. 配置反亲和性（提高可用性） affinity: anti_affinity: true # 默认启用，确保同一组件的Pod分散在不同节点上 # 如果你的集群节点少于3个，必须设置为 false，否则Pod无法调度。

3.3 执行部署与验证

配置好my-values.yaml后，就可以开始部署了。

# 1. 添加Helm仓库并更新 helm repo add apachepulsar https://pulsar.apache.org/charts helm repo update # 2. 创建命名空间 kubectl create namespace pulsar # 3. 安装Chart（这是一个示例，请确保所有前置条件已满足） helm install pulsar-cluster apachepulsar/pulsar \ --namespace pulsar \ --values my-values.yaml \ --wait # 等待所有资源就绪 # 4. 观察部署状态 kubectl -n pulsar get pods --watch # 等待所有Pod状态变为 Running 且 READY 列为 1/1, 2/2 等。 # 5. 验证关键服务 kubectl -n pulsar get svc # 找到 proxy 的 EXTERNAL-IP（如果是LoadBalancer）或 CLUSTER-IP。 # 如果使用ClusterIP，可以通过端口转发测试： kubectl -n pulsar port-forward svc/pulsar-cluster-proxy 6651:6651 &

部署后关键检查点：

1. 所有Pod运行正常：kubectl get pods -n pulsar应无Error或CrashLoopBackOff。
2. 证书已签发：如果启用了TLS和cert-manager，检查证书是否已就绪。

   kubectl get certificates -n pulsar kubectl get certificaterequests -n pulsar

3. 基础功能测试：使用pulsar-admin或客户端连接集群。

   # 获取 broker 服务地址（集群内） BROKER_URL=$(kubectl get svc -n pulsar pulsar-cluster-broker -o jsonpath='{.spec.clusterIP}') # 使用 pulsar-perf 进行简单生产消费测试（需在集群内运行Pod或使用端口转发） kubectl run -it --rm pulsar-test --image=apachepulsar/pulsar:latest --namespace=pulsar --restart=Never -- \ bin/pulsar-perf produce persistent://public/default/test-topic -r 100 -s 1024

4. 监控界面：端口转发访问 Grafana，检查 Pulsar 仪表盘是否有数据。

   kubectl -n pulsar port-forward svc/pulsar-cluster-grafana 3000:80 # 浏览器访问 http://localhost:3000，使用 admin/你设置的密码登录。

4. 高级配置、运维与故障排查

4.1 存储与性能调优

BookKeeper 的存储配置直接影响 Pulsar 的吞吐量和延迟。在values.yaml中，bookkeeper部分提供了高级配置：

bookkeeper: configData: # Journal 日志目录：用于写入预写日志（WAL），对延迟极其敏感。建议使用高性能 SSD，并与 Ledger 目录分离。 journalDirectories: "/pulsar/data/journal" # Ledger 数据目录：用于存储实际消息数据。对吞吐量要求高。 ledgerDirectories: "/pulsar/data/ledgers" # 索引目录：存储 Ledger 索引。可以放在与 Ledger 相同的磁盘，但如果IO压力大，可分离。 # indexDirectories: "/pulsar/data/index" # 在Kubernetes中，可以通过挂载多个PVC来实现目录分离 persistence: enabled: true # 主数据卷（用于 ledgerDirectories） storageClassName: "local-ssd" size: 500Gi # 可以定义额外的卷，挂载到 journal 目录 # 这需要更复杂的 StatefulSet 配置，可能需要自定义 charts 或使用 initContainer 进行符号链接。

性能调优参数（configData下）：

• journalMaxSizeMB: 每个 Journal 文件的最大大小（默认 2GB）。根据磁盘速度和容量调整。
• journalMaxBackups: 保留的旧 Journal 文件数量（默认 5）。
• gcWaitTime: 垃圾回收等待时间（默认 10 分钟）。在写入密集型场景可适当调低。
• flushInterval: Bookie 将数据从 Journal 刷写到 Ledger 存储的间隔（默认毫秒级）。权衡数据持久性和写入延迟。
• numAddWorkerThreads/numReadWorkerThreads: 处理读写请求的线程数。根据 CPU 核心数调整。

实操心得：对于生产环境，我强烈建议将 Journal 目录放在本地 NVMe SSD上，甚至使用hostPath卷（需妥善管理），因为 Journal 的同步写入对延迟的抖动极为敏感。Ledger 目录可以使用高性能云盘。同时，监控 Bookie 的journalQueueLength和ledgerAddEntry延迟指标，它们是判断存储是否成为瓶颈的关键。

4.2 监控与告警配置

VictoriaMetrics Stack 提供了强大的监控能力，但默认的 Grafana 仪表盘可能不够。你需要建立自己的告警规则。

1. 关键监控指标：

   • Broker：pulsar_broker_load（负载），pulsar_broker_topics（Topic 数），pulsar_broker_subscriptions（订阅数），消息进出速率、请求延迟（P99， P999）。
   • Bookie：bookie_journal_JOURNAL_SYNC（Journal 同步延迟），bookie_ledger_ADD_ENTRY（添加条目延迟），bookie_ledger_READ_ENTRY（读取条目延迟），各磁盘使用率、IOPS。
   • ZooKeeper：zk_avg_latency，zk_num_alive_connections，zk_outstanding_requests。
   • 系统：Pod CPU/内存使用率、网络流量、节点磁盘 IO。

2. 配置 VictoriaMetrics 告警： 在values.yaml中，可以配置victoria-metrics-k8s-stack.vmagent的抓取规则和victoria-metrics-k8s-stack.vmalert的告警规则。更常见的做法是使用 Grafana Alerting 或集成外部告警系统（如 PagerDuty， OpsGenie）。

   victoria-metrics-k8s-stack: vmalert: enabled: true # 在此处或通过额外的ConfigMap定义告警规则 additionalPrometheusRulesMap: rule-name: groups: - name: pulsar.rules rules: - alert: PulsarBrokerHighLoad expr: pulsar_broker_load > 0.85 # 负载超过85% for: 5m labels: severity: warning annotations: summary: "Broker {{ $labels.pod }} is under high load" description: "Broker {{ $labels.pod }} load is {{ $value }} (threshold 0.85)."

4.3 升级与版本管理

升级 Pulsar 集群或 Helm Chart 版本需要谨慎操作，务必遵循“先备份，再升级”的原则。

1. 备份关键数据：

   • ZooKeeper 元数据：虽然 Chart 不直接提供备份工具，但你可以通过kubectl exec进入 ZooKeeper Pod，使用zkCli.sh导出数据，或使用云供应商的持久卷快照功能。
   • BookKeeper 数据：确保 Bookie 使用的 PersistentVolume 有定期快照策略。在升级前，手动触发一次快照是良好的习惯。
   • Helm Release 状态：执行helm get values -n pulsar pulsar-cluster > values-backup.yaml备份当前配置。

2. 执行升级：

   # 1. 更新仓库，获取最新Chart helm repo update apachepulsar # 2. 查看可升级版本和变更说明 helm search repo apachepulsar/pulsar -l # 务必阅读目标版本的 Release Notes 和 UPGRADING.md（如本文档中的升级说明）。 # 3. 执行升级（以升级到4.6.0为例，注意版本号） helm upgrade pulsar-cluster apachepulsar/pulsar \ --namespace pulsar \ --version 4.6.0 \ -f my-values.yaml \ --wait

3. 特别注意的升级场景：

   • 跨大版本升级（如 3.x -> 4.x）：Chart 4.0.0 将监控栈从kube-prometheus-stack换成了victoria-metrics-k8s-stack。升级前必须先禁用旧的监控组件，如文档所述，否则可能冲突。
   • 非Root容器升级（Pulsar 2.10.0+）：如果从旧版本升级到使用非Root容器的版本，可能会遇到文件权限问题（如文中提到的 RocksDB LOCK 文件）。解决方案是在第一次升级时，在values.yaml中为bookkeeper和zookeeper设置securityContext.fsGroupChangePolicy: "Always"，升级成功后，再改回"OnRootMismatch"。
   • API 废弃：如果遇到类似no matches for kind "PodDisruptionBudget" in version "policy/v1beta1"的错误，说明集群版本已移除旧的 Kubernetes API。按照文档使用helm mapkubeapis插件修复 Helm 的发布历史记录。

4.4 常见问题与排查技巧实录

即使按照最佳实践部署，也难免会遇到问题。以下是我在运维中积累的一些常见问题及其排查思路。

问题一：Pod 启动失败，状态为CrashLoopBackOff。

• 排查步骤：
  1. 查看 Pod 日志：kubectl logs -n pulsar <pod-name> --previous（查看上一次崩溃的日志）或kubectl logs -n pulsar <pod-name> -f（实时查看）。
  2. 检查事件：kubectl describe pod -n pulsar <pod-name>，关注Events部分，常见原因有：
     • FailedScheduling：节点资源不足、节点选择器/污点不匹配、PVC 无法绑定（StorageClass 不存在或资源不足）。
     • FailedMount/FailedAttachVolume：持久卷挂载失败，检查 PVC/PV 状态。
     • CrashLoopBackOff：容器内进程崩溃。结合日志看，常见于：
       • 配置错误：如 JWT 密钥格式不对、TLS 证书路径错误。
       • 权限问题：非Root容器场景下的文件权限错误（如前述的 RocksDB LOCK 问题）。
       • 依赖服务不可达：例如 Broker 启动时连接不上 ZooKeeper。检查 ZooKeeper Service 和 Pod 是否健康。
  3. 检查依赖服务：确保 ZooKeeper 集群所有 Pod 都Ready，并且 Broker/Bookie 的配置中 ZooKeeper 连接字符串正确。

问题二：客户端无法连接 Proxy 或 Broker。

• 排查步骤：
  1. 检查服务状态：kubectl get svc -n pulsar，确认 Proxy Service 有正确的CLUSTER-IP或EXTERNAL-IP。
  2. 检查网络策略：如果集群启用了NetworkPolicy，确认是否有规则阻止了客户端 Pod 或外部 IP 访问 Proxy 的端口（6651/6650, 8080/8443）。
  3. 检查防火墙/安全组：如果是外部负载均衡器，检查云平台的安全组是否放行了相应端口。
  4. 检查认证：如果启用了 JWT，确认客户端使用的 Token 有效且未过期。可以通过kubectl exec进入 Broker Pod，使用bin/pulsar tokens create命令生成一个测试 Token。
  5. 端口转发测试：在集群内部署一个临时客户端 Pod 进行连接测试，排除外部网络问题。

     kubectl run -it --rm pulsar-client --image=apachepulsar/pulsar:latest --namespace=pulsar --restart=Never -- \ bin/pulsar-client consume persistent://public/default/test-topic -s test-sub -n 0

问题三：消息堆积或消费延迟高。

• 排查步骤：
  1. 查看 Grafana 仪表盘：重点关注pulsar_broker_publish_latency、pulsar_broker_consumer_throughput、bookie_ledger_ADD_ENTRY等指标。
  2. 检查 Bookie 磁盘 IO：使用节点监控或kubectl top pod查看 Bookie Pod 的 CPU/内存，并通过云监控查看底层磁盘的 IOPS 和吞吐量是否达到瓶颈。Journal 目录的 IO 延迟是首要怀疑对象。
  3. 检查 Broker 负载：pulsar_broker_load指标应平均分布在所有 Broker 上。如果负载不均，可能是 Topic 分配不均，可以考虑手动拆分 Bundle 或触发 Leader Broker 选举。
  4. 检查 GC 日志：如果 Broker 或 Bookie 的 JVM GC 频繁且耗时长，会导致服务暂停。需要调整 JVM 参数（通过extraVolumes和extraVolumeMounts挂载自定义jvm.options文件）。

问题四：VictoriaMetrics 抓取不到指标。

• 排查步骤：
  1. 检查 PodMonitor：kubectl get podmonitors -n pulsar，确认各组件（broker， bookie， etc.）的 PodMonitor 资源是否存在且ENDPOINTS数量正确。
  2. 检查 vmagent Targets：按照文档，端口转发到 vmagent Pod 的 8429 端口，访问/targets页面，查看抓取目标的状态是否为UP，以及是否有错误信息。
  3. 检查 ServiceMonitor 配置：如果使用了 ServiceMonitor，检查对应的 Service 和 Endpoints 是否正常。
  4. 查看 vmagent 日志：kubectl logs -n pulsar -l app.kubernetes.io/name=vmagent。

问题速查表：

最后，一个非常重要的习惯是：在做出任何生产变更（尤其是升级和配置修改）之前，先在测试环境完整地演练一遍。利用 Helm 的--dry-run和--debug选项可以预览变更内容。这个pulsar-helm-chart项目是强大的工具，但它赋予你便利的同时，也要求你具备相应的运维责任感和对细节的掌控力。