Bash 和 Ansible 在云原生大数据集群中已频繁失效

过去运维团队习惯用 Bash 脚本完成 Hadoop 和 Spark 的安装、配置和启动，用 Ansible 实现批量推送和状态检查，用 Wiki 记录每一步操作，用离线包解决网络隔离问题。这些工具在物理机和虚拟机时代运转良好，但当集群迁移到 Kubernetes 后，情况迅速恶化。

K8s 环境下的 Pod 可能因为节点漂移、资源抢占或滚动更新而随时重启，IP 地址不再固定，存储卷需要动态挂载。Bash 脚本里硬编码的路径、主机名和顺序依赖立刻失效。一次简单的节点重启可能导致脚本卡在 SSH 连接超时或配置文件覆盖错误上。Ansible 的幂等性假设也被打破，因为 K8s 本身会不断调和资源状态，脚本执行的结果常常被控制器覆盖。

更麻烦的是状态漂移。脚本只能在执行那一刻检查集群，执行完后集群可能因为自动伸缩或故障恢复而偏离预期。运维人员不得不手动登录容器、修改 ConfigMap 或重启 Deployment，这些操作既不记录也不可追溯。离线包的交付方式也变得多余，因为容器镜像已经把二进制和依赖打包在一起，脚本再去下载和解压只会增加失败点。

国内不少团队在把 Spark on K8s 或 Hadoop on K8s 的初期，都遇到过同样的问题：凌晨的扩容任务因为脚本里的 sleep 语句错过时机，导致任务积压；升级 Flink 版本时，Ansible playbook 因为缺少对 StatefulSet 的处理而把历史数据清空。这些真实案例说明，脚本化部署在动态、声明式的 K8s 环境中已经无法满足大数据平台的运维需求。

转向 Helm、CRD 和 Operator 不是技术炫耀，而是为了让运维从“执行命令”变成“描述目标”。系统不再依赖人去一步步操作，而是由 Kubernetes 持续对账，确保实际状态逼近期望状态。这种转变减少了人为错误，也让部署流程可版本化、可审计。

（本节约 420 字）

Helm Chart 把大数据部署配置变成可版本化对象

Helm 把原来散落在多个 Bash 脚本和 Ansible playbook 里的配置、模板和依赖关系打包成 Chart。一个 Chart 里包含 values.yaml、templates 目录下的 Deployment、Service、ConfigMap 等 YAML 模板，以及 Chart.yaml 中的版本信息。运维人员不再需要手动维护一堆 sh 文件，而是通过 helm install、helm upgrade 来管理整个大数据组件的生命周期。

以 Spark 为例，官方维护的 Spark-on-K8s Operator 也提供了 Helm Chart。用户只需修改 values.yaml 中的 executor 数量、driver 内存、镜像版本等参数，Helm 就会渲染出对应的 Kubernetes 资源。升级时执行 helm upgrade，Helm 会计算差异，只更新变化的部分，避免了脚本里常见的“全量重装”风险。

Chart 还解决了依赖管理问题。Hadoop 的 NameNode、DataNode、JournalNode 需要按顺序启动，Helm 通过依赖关系和 hook 机制保证安装顺序。以前 Ansible 需要写复杂的 when 条件，现在 Chart 的 subchart 和 condition 字段就能处理。离线包的场景也被镜像仓库取代，Chart 可以引用私有 Harbor 中的镜像，彻底摆脱手工拷贝 tar 包的做法。

版本化是 Helm 另一个关键优势。每个 release 都有版本号，rollback 操作可以直接回到上一个稳定 Chart 版本。团队把 Chart 放在 Git 仓库里，配合 CI/CD 流水线，每次修改配置都留下可追溯的记录。这和过去把 Wiki 当作唯一部署文档的做法完全不同。

在国内生产环境中，不少公司已经把 HBase、Hive、Kafka 的部署全部 Chart 化。运维团队不再为“这个版本的配置文件在哪里”而争论，helm list 和 helm history 就能给出清晰答案。Helm 把配置从脚本逻辑中剥离出来，让大数据组件的部署变得像管理普通应用一样标准化。

当然 Helm 本身不负责持续对账。它只负责把资源推送到 Kubernetes，之后的状态维护需要 CRD 和 Operator 接手。

（本节约 410 字）

CRD 为 Spark 和 Hadoop 定义了期望状态

Custom Resource Definition（CRD）让 Kubernetes 理解 SparkApplication、HadoopCluster 这样的领域概念。用户不再通过一堆 Deployment 和 ConfigMap 描述集群，而是直接创建 SparkCluster 这个 CR 对象，里面写清楚 master 数量、executor 规格、版本、配置覆盖等信息。

在 Spark on K8s 场景中，CRD 定义了 SparkApplication 资源。运维人员提交一个 YAML，指定 mainClass、image、driverMemory、executorInstances 等字段，Kubernetes 就知道这个 Spark 作业的期望状态是什么。Hadoop 也有对应的 CRD，比如定义 HDFSCluster、YARNCluster，里面描述 NameNode 的副本数、DataNode 的存储类型、ResourceManager 的高可用配置。

国内互联网公司把这种方式应用在实时数仓和机器学习平台上。一个典型的 Spark 作业 CR 可能只有几十行，却完整描述了整个计算集群的拓扑。这比之前维护几百行 Ansible playbook 清晰得多。CRD 还支持 validation webhook，在提交时就能检查参数合法性，避免了脚本运行到一半才报错的尴尬。

CRD 的最大价值在于把“期望状态”变成了 Kubernetes 原生 API 对象。kubectl get sparkcluster、kubectl describe sparkcluster 就能看到当前状态和事件。运维人员可以用和 Deployment 完全相同的方式管理大数据组件，监控、日志、权限体系全部复用现有工具链。

在 Hadoop on K8s 项目中，CRD 还把 ZooKeeper、HDFS、YARN 的依赖关系显式表达出来。用户创建一个 HadoopCluster CR，控制器会自动创建对应的子资源。这种声明式描述让集群拓扑一目了然，也为后续自动化运维提供了统一入口。

CRD 本身只定义了数据结构，真正把期望状态变成现实的是 Operator。

（本节约 380 字）

Operator 负责把 CRD 自动调和成真实集群

Operator 是一个自定义控制器，持续监听 CRD 的变化，并把实际集群状态调和到 CR 中声明的期望状态。它相当于把原来写在 Bash 和 Ansible 里的逻辑搬到了 Go 或 Java 代码中，以事件驱动的方式运行。

当用户修改 SparkCluster CR 的 executorInstances 从 10 改成 20 时，Operator 会检测到 spec 变化，创建新的 executor Pod，并更新相关 Service 和 ConfigMap。节点故障时，Operator 自动拉起新的 Pod，保持副本数不变。这些操作不再需要人工干预，也不需要脚本定时巡检。

Operator 通常包含三个部分：CRD 定义、控制器逻辑、以及可选的 webhook。控制器里实现了 Reconcile 函数，每次循环都会对比 observed state 和 desired state，然后执行创建、更新或删除操作。这和 Helm 的一次性渲染完全不同，Helm 只管推送，Operator 管后续一辈子的对账。

在国内的落地项目中，Spark Operator 和 Flink Operator 已经被广泛使用。团队不再为 Spark 任务的资源抢占编写复杂的监控脚本，而是让 Operator 根据 CR 中的 autoscaler 配置自动伸缩。Hadoop Operator 则负责管理 HDFS 的 rolling upgrade、YARN 的 queue 动态调整，这些以前都需要人工写 playbook 的工作现在由 Operator 自动完成。

Operator 还把领域知识固化下来。以前资深运维离职后，团队需要花很长时间熟悉脚本逻辑。现在这些逻辑被编码在 Operator 镜像里，新人只需要阅读 CRD 的 API 文档就能上手。

Helm 和 Operator 的分工逐渐清晰：Helm 负责初始安装和版本升级，Operator 负责运行时状态维护。两者结合形成了完整的大数据声明式运维体系。

（本节约 390 字）

从 Ansible 到 Operator 的迁移路径在国内已有落地案例

国内多家公司在 Spark on K8s 和 Hadoop on K8s 项目中已经完成从 Ansible 到 Operator 的迁移。典型路径是先把现有部署用 Helm Chart 包装起来，逐步引入 CRD，最后开发或引入成熟 Operator。

第一步通常是把 Ansible playbook 里的变量抽取到 values.yaml，写出对应的 Helm Chart。测试环境先跑通 helm install，确保和原来脚本结果一致。然后在生产集群并行部署新旧两套，逐步切换流量。

第二步是引入 CRD。团队会选择开源的 Spark Operator 或自己基于 Operator SDK 开发轻量 CRD。先从非核心的测试集群开始，把 SparkApplication CR 作为作业提交入口，逐步替换 kubectl exec 方式。

第三步是让 Operator 接管运行时管理。原来用于监控 Pod 状态的 crontab 脚本被删除，改由 Operator 的 metrics 和 alert 机制替代。迁移过程中需要特别注意 StatefulSet 的持久化卷声明，HDFS 的数据目录迁移要使用 PVC 而不是 hostPath。

注意事项包括：1）CRD 的版本管理要使用 v1 而不是 v1beta1，避免后续升级问题；2）Operator 的权限需要严格控制，使用 ServiceAccount 限制只能操作特定 namespace 的大数据资源；3）历史脚本中的配置逻辑要逐个 review，确认没有被 Operator 忽略的边缘情况；4）性能调优参数如 JVM 参数、shuffle 分区数要放在 CR 的 spec 而不是 ConfigMap，避免状态不一致。

已经有公司在数百节点的 K8s 集群上稳定运行 Hadoop Operator，日常扩缩容、版本升级全部通过修改 CR 完成，运维人力从原来的 5 人降到 2 人。迁移虽然需要投入时间，但长期收益明显。

（本节约 380 字）

声明式运维仍留下的调试和兼容性空白

声明式运维没有完全消灭所有问题。Operator 的 Reconcile 逻辑有时难以调试，当集群处于复杂失败状态时，运维人员仍然需要查看 controller 日志、事件和 CR status 来定位问题。以前直接改脚本加日志的做法，变成了修改 Operator 代码并重新部署，这提高了调试门槛。

老的 Ansible 脚本里常包含大量临时 hack，比如特定版本的 JVM 参数、绕过某些 bug 的 shell 命令。这些逻辑迁移到 Operator 时容易丢失或实现不完整，导致某些极端场景下集群行为和以前不同。

性能调优仍是另一个空白。Operator 通常提供通用配置，而大数据组件的调优高度依赖具体 workload。Spark 的 executor 内存、Hadoop 的块大小、压缩算法等参数虽然能放在 CR 里，但如何根据实时指标自动调整，仍需要额外开发或依赖外部 autoscaler。

兼容性方面，不同 Operator 对 Kubernetes 版本的支持程度不同。有的 Operator 只测试到 1.25，有的已经支持 1.28。升级 K8s 集群时需要同步验证 Operator 的兼容性，否则可能出现 CRD 转换失败或控制器崩溃的情况。

对运维团队的实际影响是技能要求提高。团队需要掌握 Go 语言、Kubernetes 控制器模式、CRD 设计等知识。以前写 Shell 脚本的同事必须学习新的工具链，短期内可能出现效率下降。但长期来看，声明式运维让运维工作更接近开发，团队可以共享同一套代码库和 CI 流程。

这些空白意味着声明式运维目前还不是银弹。团队需要在引入 Helm、CRD 和 Operator 的同时，保留必要的脚本作为应急手段，并在内部持续完善 Operator 的可观测性和可扩展性。

（本节约 370 字）

参考来源