一、引言
大数据平台最早都是从脚本开始的，安装 Hadoop、Spark、Flink、Hive、Trino、Kafka 时，通常会准备一批初始化脚本、配置模板、启动脚本和故障处理手册。它们在单个集群里可能很好用，但一旦进入多环境、多租户、多版本、多团队协作，问题就会放大。
大数据平台上云原生之后，运维问题并没有消失，只是换了一种形态：过去是 Bash、Ansible、手工 Wiki 和离线包，现在变成了 Helm Chart、Kubernetes API、CRD 和 Operator。真正的变化在于，平台交付不再依赖“某个老师傅知道怎么装、怎么改、怎么救”，而是把安装部署、配置管理、版本升级、故障恢复沉淀成可声明、可审计、可复用的 Kubernetes 原生对象。
二、三个角色分工
Helm、CRD、Operator 经常一起出现，但它们解决的问题不同。
Helm 是 Kubernetes 的包管理工具，Helm Chart 是一组描述 Kubernetes 资源的文件，可以包含 Chart.yaml、values.yaml、templates/、crds/ 等目录或文件，Chart 可以被打包成带版本的归档并部署到集群中 。这意味着 Helm 更适合解决“如何把一组资源按版本发布出去”的问题。
CRD 是 Kubernetes API 的扩展机制，定义一个 CustomResourceDefinition 对象后，Kubernetes API 会提供并存储这种新的自定义资源，用户可以像操作 Pod 一样通过 kubectl 操作它 。这意味着 CRD 更适合解决“平台要暴露什么抽象给用户”的问题。
Operator 是把 CRD 和控制器结合起来的模式，它使用自定义资源管理应用及其组件的软件扩展，并遵循 Kubernetes 控制循环原则 。这意味着 Operator 更适合解决“如何自动处理复杂生命周期”的问题。
这三个角色合在一起，才构成平台级交付范式。
用户提交期望状态 | v +--------------------+ | FlinkDeployment | <-- CRD: 平台 API | SparkApplication | +--------------------+ | v +--------------------+ | Operator Controller| <-- Operator: 运维逻辑 | Reconcile Loop | +--------------------+ | v +--------------------+ | Deployment/STS/Job | | Service/PVC/CM | <-- K8s 原生资源 +--------------------+ Helm 的位置： - 安装 CRD - 安装 Operator - 安装默认 RBAC、Webhook、ServiceAccount、Metrics 等资源三、安装部署
在大数据云原生平台里，Helm 最常见的职责是安装 Operator 本身，而不是直接长期管理每个业务作业。比如 Flink，Flink Kubernetes Operator 将部署 Operator 与日常管理自定义资源区分开：Operator 通过 Helm 安装，而用户通过 FlinkDeployment、FlinkSessionJob 等 Custom Resource 声明 Flink 集群和作业 。
这种分层很重要，过去脚本通常把“安装平台组件”和“创建业务作业”混在一起，例如同一个脚本既创建命名空间、ServiceAccount，也提交某个 Flink 作业。云原生平台里更合理的边界是：
平台安装阶段： helm install flink-kubernetes-operator ... helm install spark-operator ... 业务交付阶段： kubectl apply -f flink-deployment.yaml kubectl apply -f spark-application.yaml 生命周期阶段： Operator watch CR -> reconcile -> update status/eventsHelm 的优势在安装部署阶段非常明显。Chart 可以把 Kubernetes 资源、默认配置、依赖关系和版本号打包到一起。Chart.yaml 中的 version 是 Chart 版本，appVersion 是应用版本，两者含义不同；kubeVersion 还可以表达兼容的 Kubernetes 版本范围 。这为平台团队提供了发布纪律：平台组件版本、应用运行时版本、Kubernetes 兼容范围可以被明确记录。
但 Helm 不擅长持续处理复杂状态。它可以安装一组资源，也可以升级 release，却不会天然理解“某个 Flink 作业升级前要不要做 savepoint”、“Spark 定时任务并发策略是什么”。这些属于 Operator 的职责。
四、配置管理
配置管理从“文件模板”走向“资源模型”，是大数据云原生化的重要分水岭。
Helm 的 values.yaml 适合表达安装时参数。Helm Chart 目录结构中，values.yaml 是 Chart 的默认配置，templates/ 目录中的模板会结合 values 渲染成 Kubernetes manifest；Chart 还可以包含 values.schema.json，用于约束 values 的结构 。因此 Helm 适合管理 Operator 安装参数，例如镜像、资源限制、Webhook 是否启用、metrics 是否开启、watch 哪些 namespace。
CRD 的 spec 更适合表达业务对象的期望状态。例如 Flink Kubernetes Operator 的 FlinkDeployment 使用 spec.image、spec.flinkVersion、spec.flinkConfiguration、spec.jobManager、spec.taskManager、spec.job等字段描述一个 Flink 应用集群或 Session 集群 。这些字段不只是配置，它们组成了平台 API。
Operator 的 status 则承载观测结果。Kubernetes 自定义资源通常使用 metadata、spec、status 三段结构；这些资源的 status 由 Operator 写入，用于报告生命周期状态和作业状态 。
+--------------------------+ | values.yaml | | Helm 安装参数 | | - operator image | | - webhook enabled | | - metrics enabled | | - watched namespaces | +-------------+------------+ | v +--------------------------+ | Custom Resource spec | | 用户期望状态 | | - flinkVersion | | - parallelism | | - upgradeMode | | - checkpoint dir | +-------------+------------+ | v +--------------------------+ | Custom Resource status | | Operator 观测状态 | | - lifecycleState | | - jobStatus | | - error/events | +--------------------------+这里有一个容易踩坑的边界：并不是所有配置都应该塞进 CRD。如果已有成熟配置文件格式、主要由 Pod 内程序以文件或环境变量消费，ConfigMap 可能更合适；如果希望使用 Kubernetes API、kubectl 顶层操作、.spec/.status/.metadata、以及自动化控制器，则更适合使用自定义资源 。
因此，大数据平台的配置建模可以采用三层原则：
配置类型 | 推荐载体 | 示例 |
Operator 安装配置 | Helm values | Operator 副本数、镜像、metrics、Webhook |
业务对象期望状态 | CRD spec | Flink 并行度、Spark driver/executor 资源、升级模式 |
程序内部配置文件 | ConfigMap/Secret | flink-conf.yaml 片段、catalog 配置、认证信息 |
五、版本升级
传统脚本升级常见的问题是：步骤可以写出来，但升级语义没有沉淀成平台对象。一个大数据作业到底是无状态升级、从 checkpoint 恢复，还是先做 savepoint 再恢复，脚本可以处理，但很难被 API 直接表达和审计。
Helm 解决的是 release 层面的升级。helm upgrade命令将 release 升级到新版 Chart，可以通过 --values 或 --set覆盖配置，多次指定时右侧或后出现的值优先；--reuse-values 可以复用已有 release 的 values 并合并新覆盖值 。这适合升级 Operator 版本、Chart 模板、默认参数和平台组件依赖。
Operator 解决的是应用生命周期层面的升级。当 FlinkDeployment 或 FlinkSessionJob 的 spec 变化时，运行中的作业需要升级；状态如何跨重启保留由 spec.job.upgradeMode 控制，支持 stateless、last-state、savepoint三种模式 。
升级层次对比： Helm upgrade | +-- 升级 Operator / Chart / RBAC / Webhook / 默认配置 +-- 关注 release revision +-- 不理解具体 Flink/Spark 作业状态语义 CR spec update | +-- 修改 flinkVersion / image / parallelism / upgradeMode +-- Operator 判断差异 +-- 根据状态策略执行 suspend / savepoint / restore / rollbackFlink Operator 的升级语义体现了 Operator 模式的价值。stateless不需要状态配置，但生产不推荐；last-state推荐用于生产，需要 checkpoint；savepoint也推荐用于生产，需要 checkpoint 或 savepoint 目录，并且作业需要处于 running 状态才能创建 savepoint；当作业不健康时，savepoint 模式在 HA 启用且 fallback 未关闭的情况下可能退回使用最新 checkpoint。
这比脚本更标准化，因为升级策略变成了 CRD 的字段，而不是脚本参数或文档约定。平台可以在 admission webhook、CI 校验、GitOps 流程中检查这些字段，例如禁止生产作业使用 stateless，要求 stateful 作业配置 checkpoint/savepoint 目录。
Spark Operator 的升级边界则不同。Operator 通常通过 Helm Chart 部署，升级 Operator 可以使用 helm upgrade 并更新镜像参数 。对于业务层面的 ScheduledSparkApplication，更新其 spec 不会更新或删除已创建的 SparkApplication，只影响后续调度产生的 SparkApplication；如果要更新当前运行中的应用，需要手动删除并重建或直接更新它 。
这说明一个关键事实：Operator 不是魔法，不同 Operator 的生命周期能力取决于它的领域模型。Flink Operator 更强调长运行有状态作业的升级与恢复；Spark Operator 更强调 SparkApplication 的提交、状态展示和定时调度。
六、故障恢复
故障恢复是 Operator 相比 Helm 最能体现价值的地方。Helm 可以回滚 release，但它不知道业务系统内部的恢复语义。Operator 则可以基于领域知识判断：是否需要重建 Deployment、是否从 checkpoint 恢复、是否保留 savepoint、是否阻止删除 session cluster。
运维人员掌握应用如何运行、如何部署、出现问题如何反应的知识，Operator 模式就是把超出 Kubernetes 内建能力的任务自动化。Operator 可以自动部署应用、备份和恢复状态、处理应用代码升级以及相关 schema 或配置变更。
Flink Operator 在故障恢复上提供了更具体的例子。它可以恢复被意外删除的 Flink cluster deployment；在 application mode 下需要 HA，作业状态从 HA metadata 恢复；该能力由 kubernetes.operator.jm-deployment-recovery.enabled 控制，默认值为 true 。它还支持在启用 HA 时重启不健康 deployment、在配置开启时重启达到终态 FAILED 的作业并从最新成功 checkpoint 重新部署 。
故障恢复职责边界： +------------------+ +-----------------------+ | Kubernetes | | Operator | |------------------| |-----------------------| | Pod 重启 | | 判断作业是否终态失败 | | Deployment 副本维持| | 判断是否从 checkpoint 恢复| | PVC 挂载 | | 触发 savepoint/redeploy | | Service 发现 | | 写入 status/events | +------------------+ +-----------------------+手工恢复仍然不可完全消除。如果 Operator 无法判断应用健康状态或最新 checkpoint 信息，用户可以通过 spec.job.savepointRedeployNonce 与 spec.job.initialSavepointPath 从指定 savepoint 重新部署；也可以删除并重建自定义资源，但删除会丢失 status 和 checkpoint history 。
这给平台团队一个重要启示：Operator 的目标不是消灭所有人工介入，而是把大部分可重复、可判断、可回放的运维动作交给控制器，把少数需要人判断的恢复路径设计成清晰的 API。
七、平台级交付范式
Helm 位于平台安装与发布侧，CRD 位于平台 API 侧，Operator 位于生命周期控制侧。这个分工能够解决传统脚本化运维的几个核心问题：
传统问题 | 云原生机制 | 改善方式 |
难复制 | Helm Chart + values | 把安装依赖、默认参数、版本约束打包 |
难升级 | Helm revision + CR spec + Operator reconcile | 区分平台组件升级和业务对象升级 |
难标准化 | CRD schema + admission + status | 把字段、状态、约束变成 API 契约 |
难恢复 | Operator domain logic | 把 checkpoint、savepoint、重建、回滚写进控制逻辑 |
这也是平台工程和普通资源编排的区别。资源编排关心“创建哪些 Kubernetes 对象”，平台工程关心“给用户暴露什么稳定抽象，并让这个抽象长期可运行”。
八、大数据场景示例
以 Flink 为例，用户不应直接维护一堆 JobManager Deployment、TaskManager Pod、Service、ConfigMap 和 PVC，而是声明一个 FlinkDeployment。FlinkDeployment 可以定义一个 Flink application cluster 或 bare session cluster，是最常用入口；FlinkSessionJob 则定义提交到已有 session cluster 的单个作业 。
示例结构可以简化理解为：
apiVersion: flink.apache.org/v1beta1 kind: FlinkDeployment metadata: name: realtime-risk-job spec: image: flink:1.20 flinkVersion: v1_20 flinkConfiguration: state.checkpoints.dir: s3://bucket/checkpoints state.savepoints.dir: s3://bucket/savepoints job: jarURI: local:///opt/flink/jobs/risk.jar parallelism: 8 upgradeMode: savepoint state: running这段 YAML 背后的含义不是“创建几个 Pod”，而是声明一个有状态流作业的生命周期策略：运行什么版本、用什么镜像、并行度是多少、如何升级、状态存在哪里。
以 Spark 为例，用户可以提交 SparkApplication，也可以通过 ScheduledSparkApplication 表达周期性运行。ScheduledSparkApplication 使用 .spec.schedule 配置 cron 调度，并从 .spec.template 创建每次运行的 SparkApplication；它还支持 Allow、Forbid、Replace 三种并发策略 。
Spark 定时任务模型： ScheduledSparkApplication | | cron schedule v SparkApplication run #1 ---> driver pod + executor pods SparkApplication run #2 ---> driver pod + executor pods SparkApplication run #3 ---> driver pod + executor pods concurrencyPolicy: Allow = 允许并发 Forbid = 上一次未结束则不启动下一次 Replace = 新一次到来时替换旧一次这比 crontab + spark-submit 脚本更平台化，因为调度、并发、历史状态和运行对象都在 Kubernetes API 中表达。
九、设计注意事项
CRD 不是越大越好。不应把 Custom Resource 当作应用数据、终端用户数据或监控数据的存储；大量数据存入 Kubernetes API 会造成过度耦合，云原生架构更偏向组件间松耦合 。大数据平台尤其要避免把作业运行明细、指标时间序列、审计日志塞进 CRD status。
Operator 也不是所有逻辑都该承载。适合写进 Operator 的逻辑通常满足三个条件：它可以通过 Kubernetes API 观测，它有明确的期望状态与实际状态差异，它的动作可以幂等重试。相反，临时诊断、跨系统复杂审批、一次性数据修复，不一定适合写进控制循环。
Helm 与 Operator 的边界要清晰。Helm 管安装 Operator，Operator 管业务对象生命周期。如果用 Helm 直接管理每个 Flink 作业或 Spark 作业，短期看模板复用方便，长期可能会把业务状态、升级策略和平台 release 绑在一起，导致回滚边界混乱。
版本策略也要显式设计。Helm Chart 有 Chart 版本和 appVersion；Operator 有自身版本；CRD 有 API version；大数据运行时还有 Flink、Spark、Hadoop、JDK、Scala 版本。平台团队需要明确哪些版本能独立升级，哪些必须绑定测试，否则“云原生”只是把版本矩阵从脚本目录搬到了 YAML 仓库。
