一、引言大数据平台最早都是从脚本开始的安装 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 本身而不是直接长期管理每个业务作业。比如 FlinkFlink 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 manifestChart 还可以包含 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 valuesOperator 副本数、镜像、metrics、Webhook业务对象期望状态CRD specFlink 并行度、Spark driver/executor 资源、升级模式程序内部配置文件ConfigMap/Secretflink-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推荐用于生产需要 checkpointsavepoint也推荐用于生产需要 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 管安装 OperatorOperator 管业务对象生命周期。如果用 Helm 直接管理每个 Flink 作业或 Spark 作业短期看模板复用方便长期可能会把业务状态、升级策略和平台 release 绑在一起导致回滚边界混乱。版本策略也要显式设计。Helm Chart 有 Chart 版本和 appVersionOperator 有自身版本CRD 有 API version大数据运行时还有 Flink、Spark、Hadoop、JDK、Scala 版本。平台团队需要明确哪些版本能独立升级哪些必须绑定测试否则“云原生”只是把版本矩阵从脚本目录搬到了 YAML 仓库。