Kubernetes 社区大数据生态集成现状盘点Spark、HDFS、Airflow 与 Flink 在 Kubernetes 上的演进速览【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本篇文章基于 Kubernetes Community 仓库中 Big Data User Group大数据用户组的 Resources 资源清单系统梳理 Apache Spark、HDFS、Airflow、Flink 四大主流大数据组件与 Kubernetes 集成的历史状态与演进方向并结合该用户组在仓库内的章程、目标与归档信息帮助读者快速理解大数据工作负载上 Kubernetes这一主题在社区层面的协作脉络。读完本文你将掌握这份资源文档的核心结论、各产品的集成进度与后续工作重点以及如何在当前仓库中继续追踪相关信息。文档背景Big Data User Group 与这份资源清单archive/ug-big-data/resources.md是 Kubernetes 社区中 Big Data User Group 维护的一份按大数据产品分类的 Kubernetes 集成状态跟踪文档。要正确理解它的定位需要先看该用户组的章程charterServe as a community resource for advising big data and data science related software projects on techniques and best practices for integrating with Kubernetes. Represents the concerns of users from big data communities to Kubernetes for the purposes of driving new features and other enhancements, based on big data use cases.这段话记录在 archive/ug-big-data/README.md#L11明确了该用户组的定位为大数据与数据科学相关的软件项目提供如何与 Kubernetes 集成的建议并把大数据用户的需求反向输入给 Kubernetes 社区从而驱动新特性与增强。该用户组在 archive/ug-big-data/README.md#L34-L44 中列出了清晰的目标Goals与非目标Non Goals目标推广 Kubernetes 集成的最佳实践就 Kubernetes 特性向大数据社区提供咨询引导社区成员的 issue 与 PR 处理为 Kubernetes 的大数据集成举办演示与讨论。非目标不推广或倡导任何特定的大数据项目不关注与数据科学、大数据毫无交集的软件与工具社区。需要特别说明的是从当前仓库的目录结构看该用户组已被移入archive/目录。根目录的 archive/README.md 明确写道The archive contains SIG information for those no longer active.归档目录存放不再活跃的 SIG 信息因此本文所依据的资源文档是一份历史状态快照其中记载的版本信息如 Spark 2.3/2.4、Airflow 1.10.0、Flink 1.6均以文档编写时约 2018—2019 年的社区状态为准阅读时请注意这一时间前提。此外从 archive/ug-big-data/OWNERS 可以看出该组的治理结构审查者reviewers与批准者approvers均为ug-big-data-leads并挂有ug/big-data标签用于在 GitHub 上统一筛选与大数据相关的 issue/PR对应的 Slack 频道#ug-big-data也登记在 communication/slack-config/channels.yaml 中。文档结构一张产品 × 集成状态的跟踪表这份资源文档本身结构非常清晰每个产品统一采用两段式写法大数据产品定位集成状态Status进行中的工作ActivitiesApache Spark分布式数据处理框架自 2.3 起 Kubernetes 成为主线调度器2.4 增强安全 HDFS 访问、Shuffle 可靠性Apache Hadoop HDFS分布式文件系统Hadoop 的持久化层文档标注为 TODO当时尚无正式发布数据本地性Data Locality设计含 Helm charts 的 Kubernetes 化仓库Apache Airflow工作流编排平台1.10.0 引入 Kubernetes Executor支持 Kubernetes 1.10官方路线图持续演进Apache Flink分布式数据处理框架1.6 支持在 Kubernetes 上运行 session 或 job 集群原生支持FLINK-9953Lyft 社区推进 Operator 方案这种Status当前状态 Activities后续动作的组织方式是社区跟踪异构项目集成进度的常用手法Status 回答现在能不能用Activities 回答下一步往哪走。下面逐产品展开。Spark on Kubernetes成为主线调度器之后状态自 2.3 起 Kubernetes 成为 Spark 主线调度器文档记载Apache Spark 自release 2.3起将 Kubernetes 作为主线mainline调度器予以支持。这意味着用户无需借助第三方补丁或独立分支即可通过 Spark 官方发行版直接让作业跑在 Kubernetes 集群上官方文档专门提供了一份 Running on Kubernetes 的详细说明。这段工作的源头是apache-spark-on-k8sgit 仓库中的Spark on Kubernetes 原始设计提案Design Proposal——社区先以独立仓库形式完成了原型与设计论证再将其合入 Spark 主线这是典型的孵化验证后上游化演进路径。进行中Spark 2.4 的集成增强文档列出 Spark 2.4 期间的两项重点增强均有对应的设计文档或 JIRA 支撑与 HDFS 的集成增强围绕Spark on Kubernetes 如何访问安全SecureHDFS社区产出了一份专门的设计文档。其核心背景是Spark 作业在 Kubernetes 上以容器化方式运行后如何安全地认证、挂载并访问受 Kerberos 等机制保护的 HDFS 数据成为从能跑到好用的关键一步。Shuffle 服务可靠性设计针对 Kubernetes 环境下 Shuffle 数据的持久性与故障恢复问题社区提出了使用远程存储持久化 Shuffle 数据的设计并跟踪在 JIRA 议题SPARK-25299Use remote storage for persisting shuffle data中。该方向的动因在于Kubernetes 上 Executor 的 Pod 随时可能被驱逐或重建若 Shuffle 中间数据只存在于本地磁盘作业的容错性会显著下降把 Shuffle 数据落到远程存储可以解耦 Executor 生命周期与中间数据生命周期。文档还提到上述 2.4 增强的总体概览可参考 Databricks 在 2018 年发布的一篇社区博客Whats New for Apache Spark on Kubernetes in the Upcoming Apache Spark 2.4 Release作为理解当时路线图的辅助材料。HDFS on Kubernetes数据本地性与 Helm 化部署HDFS 是 Hadoop 生态的持久化层文档给它的定位是a distributed file system, the persistence layer for Hadoop。与 Spark 相比HDFS 在当时的 Kubernetes 集成状态要原始得多状态文档直接以TODO, e.g. No release yet.占位即当时尚无正式发布版本属于社区仍在探索的阶段。活动两条线索并行推进数据本地性Data Locality设计文档这是 HDFS 上 Kubernetes 最核心的诉求之一——NameNode 与 DataNode 以容器/Pod 形态运行后如何让计算尽量靠近数据所在节点避免跨网络搬移数据导致的性能损耗当时仍处于设计论证阶段。HDFS on Kubernetes 独立仓库社区维护了一个包含Helm charts的 Kubernetes-HDFS 仓库借助 Helm 以声明式方式部署 NameNode、DataNode 等组件作为当时最接近开箱即用的部署方案。可以推断HDFS 条目之所以与 Spark 条目并列出现在同一份资源清单中是因为二者在大数据生态中高度耦合Spark 作业的输入输出大量依赖 HDFS因此 Spark on Kubernetes 的落地进度尤其是安全访问与数据本地性会直接决定 HDFS 容器化的优先级。Airflow on KubernetesKubernetes Executor 的引入Apache Airflow 的定位是以编程方式编排、调度与监控工作流a platform to programmatically author, schedule and monitor workflows是大数据管道常见的调度中枢。文档记载Airflow 在release 1.10.0中引入了Kubernetes Executor并支持 Kubernetes 1.10。这意味着调度器可以把每个任务Task动态地以 Pod 形式提交到 Kubernetes 集群中运行从而获得按任务粒度的资源隔离与弹性伸缩能力而不是像传统 Celery Executor 那样把任务丢给固定规模的 worker 队列。从社区协作角度看该产品条目下主要登记的是其官方路线图roadmap链接用于持续跟踪 Kubernetes Executor 后续的能力演进如 Pod 模板定制、资源配额管理、与 Kubernetes 原生特性的进一步对齐等。这一点也符合用户组把大数据社区关切反馈给 Kubernetes 生态的定位。Flink on Kubernetessession / job 集群与原生运行时探索Apache Flink 同样是一个分布式数据处理框架distributed data processing framework与 Spark 在流批处理领域形成竞争与互补。文档记载Flink 1.6已支持在 Kubernetes 上运行session cluster 或 job cluster两种部署形态Session 集群长期运行一个集群多个作业共享其资源适合作业密集、希望复用集群的场景Job 集群每个作业拉起独立集群作业结束即销毁隔离性强适合作业生命周期清晰的场景。在进行中一栏文档登记了两条方向原生支持 Kubernetes 作为 Flink 运行时通过 JIRA 议题FLINK-9953Native support for Kubernetes as a Flink runtime跟踪。这标志着社区的目标从在 Kubernetes 上运行 Flink借助外部资源管理适配升级为让 Kubernetes 成为 Flink 的一等运行时与后来 Flink 原生 Kubernetes 部署模式application mode 等的演进方向一脉相承。Lyft 社区推进 Operator 方案Lyft 当时在 Flink 开发者邮件列表中公布了其基于 Kubernetes Operator 模式管理 Flink 集群的工作即把 Flink 集群的创建、扩缩容、升级等操作封装为自定义控制器进一步向声明式管理演进。这两条线索体现了大数据组件上 Kubernetes 的两条典型路径上游原生支持Flink 自己实现 Kubernetes 调度与生态 Operator 化第三方以 Operator 模式接管生命周期管理在当时的社区讨论中是并行的探索方向。从资源清单到社区协作如何继续追踪与使用这份文档这份文档的阅读方法对读者而言这份资源清单的价值在于用最小的成本掌握一个异构生态的集成全貌每个产品条目都可以独立阅读Status给出开箱即用程度Activities给出值得关注的下一步。把它当作一张大数据 × Kubernetes 集成路线图来用比逐个翻各项目官方文档要高效得多。在本仓库中继续深挖的入口如果希望继续追踪该用户组及其它相关社区资产可以沿以下仓库内路径深入archive/ug-big-data/README.md用户组完整章程包含使命、会议机制、组织者与目标/非目标定义archive/ug-big-data/OWNERS治理角色ug-big-data-leads与ug/big-data标签定义archive/ug-big-data/resources.md本文所依据的资源清单原文archive/README.md归档目录的定位说明记录不再活跃的 SIG/用户组信息communication/slack-config/channels.yaml#ug-big-dataSlack 频道登记信息sigs.yaml社区全部 SIG/WG/用户组的统一登记表用于了解用户组在整个社区治理体系中的位置。使用前提与局限需要再次强调本资源文档并非实时状态其中记载的版本号Spark 2.3/2.4、Airflow 1.10.0、Flink 1.6与 JIRA 议题SPARK-25299、FLINK-9953均为文档编写时的社区快照。若要获取这些项目当前的最新集成能力应以各项目官方文档与发行说明为准本仓库内的这份文档更适合作为理解集成演进脉络与社区协作方式的历史资料来阅读。小结archive/ug-big-data/resources.md用一份精简的产品清单浓缩了 Kubernetes 生态早期与大数据世界的融合图景Spark 率先成为主线调度器并持续增强 HDFS 集成与 Shuffle 可靠性HDFS 处于从无正式发布到Helm 化部署 数据本地性设计的起步阶段Airflow 借由 1.10.0 的 Kubernetes Executor 打开按任务弹性调度的大门Flink 则在 session/job 集群之上同时探索上游原生支持与 Lyft 的 Operator 化两条路径。对关注大数据工作负载容器化的开发者与架构师而言这份文档既是可追溯的历史坐标也提供了一种以产品为维度跟踪集成状态的可复用方法论。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/15 21:06:33 · 阅读 1.2k Kubernetes 社区大数据生态集成现状盘点：Spark、HDFS、Airflow 与 Flink 在 Kubernetes 上的演进速览
Kubernetes 社区大数据生态集成现状盘点Spark、HDFS、Airflow 与 Flink 在 Kubernetes 上的演进速览【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本篇文章基于 Kubernetes Community 仓库中 Big Data User Group大数据用户组的 Resources 资源清单系统梳理 Apache Spark、HDFS、Airflow、Flink 四大主流大数据组件与 Kubernetes 集成的历史状态与演进方向并结合该用户组在仓库内的章程、目标与归档信息帮助读者快速理解大数据工作负载上 Kubernetes这一主题在社区层面的协作脉络。读完本文你将掌握这份资源文档的核心结论、各产品的集成进度与后续工作重点以及如何在当前仓库中继续追踪相关信息。文档背景Big Data User Group 与这份资源清单archive/ug-big-data/resources.md是 Kubernetes 社区中 Big Data User Group 维护的一份按大数据产品分类的 Kubernetes 集成状态跟踪文档。要正确理解它的定位需要先看该用户组的章程charterServe as a community resource for advising big data and data science related software projects on techniques and best practices for integrating with Kubernetes. Represents the concerns of users from big data communities to Kubernetes for the purposes of driving new features and other enhancements, based on big data use cases.这段话记录在 archive/ug-big-data/README.md#L11明确了该用户组的定位为大数据与数据科学相关的软件项目提供如何与 Kubernetes 集成的建议并把大数据用户的需求反向输入给 Kubernetes 社区从而驱动新特性与增强。该用户组在 archive/ug-big-data/README.md#L34-L44 中列出了清晰的目标Goals与非目标Non Goals目标推广 Kubernetes 集成的最佳实践就 Kubernetes 特性向大数据社区提供咨询引导社区成员的 issue 与 PR 处理为 Kubernetes 的大数据集成举办演示与讨论。非目标不推广或倡导任何特定的大数据项目不关注与数据科学、大数据毫无交集的软件与工具社区。需要特别说明的是从当前仓库的目录结构看该用户组已被移入archive/目录。根目录的 archive/README.md 明确写道The archive contains SIG information for those no longer active.归档目录存放不再活跃的 SIG 信息因此本文所依据的资源文档是一份历史状态快照其中记载的版本信息如 Spark 2.3/2.4、Airflow 1.10.0、Flink 1.6均以文档编写时约 2018—2019 年的社区状态为准阅读时请注意这一时间前提。此外从 archive/ug-big-data/OWNERS 可以看出该组的治理结构审查者reviewers与批准者approvers均为ug-big-data-leads并挂有ug/big-data标签用于在 GitHub 上统一筛选与大数据相关的 issue/PR对应的 Slack 频道#ug-big-data也登记在 communication/slack-config/channels.yaml 中。文档结构一张产品 × 集成状态的跟踪表这份资源文档本身结构非常清晰每个产品统一采用两段式写法大数据产品定位集成状态Status进行中的工作ActivitiesApache Spark分布式数据处理框架自 2.3 起 Kubernetes 成为主线调度器2.4 增强安全 HDFS 访问、Shuffle 可靠性Apache Hadoop HDFS分布式文件系统Hadoop 的持久化层文档标注为 TODO当时尚无正式发布数据本地性Data Locality设计含 Helm charts 的 Kubernetes 化仓库Apache Airflow工作流编排平台1.10.0 引入 Kubernetes Executor支持 Kubernetes 1.10官方路线图持续演进Apache Flink分布式数据处理框架1.6 支持在 Kubernetes 上运行 session 或 job 集群原生支持FLINK-9953Lyft 社区推进 Operator 方案这种Status当前状态 Activities后续动作的组织方式是社区跟踪异构项目集成进度的常用手法Status 回答现在能不能用Activities 回答下一步往哪走。下面逐产品展开。Spark on Kubernetes成为主线调度器之后状态自 2.3 起 Kubernetes 成为 Spark 主线调度器文档记载Apache Spark 自release 2.3起将 Kubernetes 作为主线mainline调度器予以支持。这意味着用户无需借助第三方补丁或独立分支即可通过 Spark 官方发行版直接让作业跑在 Kubernetes 集群上官方文档专门提供了一份 Running on Kubernetes 的详细说明。这段工作的源头是apache-spark-on-k8sgit 仓库中的Spark on Kubernetes 原始设计提案Design Proposal——社区先以独立仓库形式完成了原型与设计论证再将其合入 Spark 主线这是典型的孵化验证后上游化演进路径。进行中Spark 2.4 的集成增强文档列出 Spark 2.4 期间的两项重点增强均有对应的设计文档或 JIRA 支撑与 HDFS 的集成增强围绕Spark on Kubernetes 如何访问安全SecureHDFS社区产出了一份专门的设计文档。其核心背景是Spark 作业在 Kubernetes 上以容器化方式运行后如何安全地认证、挂载并访问受 Kerberos 等机制保护的 HDFS 数据成为从能跑到好用的关键一步。Shuffle 服务可靠性设计针对 Kubernetes 环境下 Shuffle 数据的持久性与故障恢复问题社区提出了使用远程存储持久化 Shuffle 数据的设计并跟踪在 JIRA 议题SPARK-25299Use remote storage for persisting shuffle data中。该方向的动因在于Kubernetes 上 Executor 的 Pod 随时可能被驱逐或重建若 Shuffle 中间数据只存在于本地磁盘作业的容错性会显著下降把 Shuffle 数据落到远程存储可以解耦 Executor 生命周期与中间数据生命周期。文档还提到上述 2.4 增强的总体概览可参考 Databricks 在 2018 年发布的一篇社区博客Whats New for Apache Spark on Kubernetes in the Upcoming Apache Spark 2.4 Release作为理解当时路线图的辅助材料。HDFS on Kubernetes数据本地性与 Helm 化部署HDFS 是 Hadoop 生态的持久化层文档给它的定位是a distributed file system, the persistence layer for Hadoop。与 Spark 相比HDFS 在当时的 Kubernetes 集成状态要原始得多状态文档直接以TODO, e.g. No release yet.占位即当时尚无正式发布版本属于社区仍在探索的阶段。活动两条线索并行推进数据本地性Data Locality设计文档这是 HDFS 上 Kubernetes 最核心的诉求之一——NameNode 与 DataNode 以容器/Pod 形态运行后如何让计算尽量靠近数据所在节点避免跨网络搬移数据导致的性能损耗当时仍处于设计论证阶段。HDFS on Kubernetes 独立仓库社区维护了一个包含Helm charts的 Kubernetes-HDFS 仓库借助 Helm 以声明式方式部署 NameNode、DataNode 等组件作为当时最接近开箱即用的部署方案。可以推断HDFS 条目之所以与 Spark 条目并列出现在同一份资源清单中是因为二者在大数据生态中高度耦合Spark 作业的输入输出大量依赖 HDFS因此 Spark on Kubernetes 的落地进度尤其是安全访问与数据本地性会直接决定 HDFS 容器化的优先级。Airflow on KubernetesKubernetes Executor 的引入Apache Airflow 的定位是以编程方式编排、调度与监控工作流a platform to programmatically author, schedule and monitor workflows是大数据管道常见的调度中枢。文档记载Airflow 在release 1.10.0中引入了Kubernetes Executor并支持 Kubernetes 1.10。这意味着调度器可以把每个任务Task动态地以 Pod 形式提交到 Kubernetes 集群中运行从而获得按任务粒度的资源隔离与弹性伸缩能力而不是像传统 Celery Executor 那样把任务丢给固定规模的 worker 队列。从社区协作角度看该产品条目下主要登记的是其官方路线图roadmap链接用于持续跟踪 Kubernetes Executor 后续的能力演进如 Pod 模板定制、资源配额管理、与 Kubernetes 原生特性的进一步对齐等。这一点也符合用户组把大数据社区关切反馈给 Kubernetes 生态的定位。Flink on Kubernetessession / job 集群与原生运行时探索Apache Flink 同样是一个分布式数据处理框架distributed data processing framework与 Spark 在流批处理领域形成竞争与互补。文档记载Flink 1.6已支持在 Kubernetes 上运行session cluster 或 job cluster两种部署形态Session 集群长期运行一个集群多个作业共享其资源适合作业密集、希望复用集群的场景Job 集群每个作业拉起独立集群作业结束即销毁隔离性强适合作业生命周期清晰的场景。在进行中一栏文档登记了两条方向原生支持 Kubernetes 作为 Flink 运行时通过 JIRA 议题FLINK-9953Native support for Kubernetes as a Flink runtime跟踪。这标志着社区的目标从在 Kubernetes 上运行 Flink借助外部资源管理适配升级为让 Kubernetes 成为 Flink 的一等运行时与后来 Flink 原生 Kubernetes 部署模式application mode 等的演进方向一脉相承。Lyft 社区推进 Operator 方案Lyft 当时在 Flink 开发者邮件列表中公布了其基于 Kubernetes Operator 模式管理 Flink 集群的工作即把 Flink 集群的创建、扩缩容、升级等操作封装为自定义控制器进一步向声明式管理演进。这两条线索体现了大数据组件上 Kubernetes 的两条典型路径上游原生支持Flink 自己实现 Kubernetes 调度与生态 Operator 化第三方以 Operator 模式接管生命周期管理在当时的社区讨论中是并行的探索方向。从资源清单到社区协作如何继续追踪与使用这份文档这份文档的阅读方法对读者而言这份资源清单的价值在于用最小的成本掌握一个异构生态的集成全貌每个产品条目都可以独立阅读Status给出开箱即用程度Activities给出值得关注的下一步。把它当作一张大数据 × Kubernetes 集成路线图来用比逐个翻各项目官方文档要高效得多。在本仓库中继续深挖的入口如果希望继续追踪该用户组及其它相关社区资产可以沿以下仓库内路径深入archive/ug-big-data/README.md用户组完整章程包含使命、会议机制、组织者与目标/非目标定义archive/ug-big-data/OWNERS治理角色ug-big-data-leads与ug/big-data标签定义archive/ug-big-data/resources.md本文所依据的资源清单原文archive/README.md归档目录的定位说明记录不再活跃的 SIG/用户组信息communication/slack-config/channels.yaml#ug-big-dataSlack 频道登记信息sigs.yaml社区全部 SIG/WG/用户组的统一登记表用于了解用户组在整个社区治理体系中的位置。使用前提与局限需要再次强调本资源文档并非实时状态其中记载的版本号Spark 2.3/2.4、Airflow 1.10.0、Flink 1.6与 JIRA 议题SPARK-25299、FLINK-9953均为文档编写时的社区快照。若要获取这些项目当前的最新集成能力应以各项目官方文档与发行说明为准本仓库内的这份文档更适合作为理解集成演进脉络与社区协作方式的历史资料来阅读。小结archive/ug-big-data/resources.md用一份精简的产品清单浓缩了 Kubernetes 生态早期与大数据世界的融合图景Spark 率先成为主线调度器并持续增强 HDFS 集成与 Shuffle 可靠性HDFS 处于从无正式发布到Helm 化部署 数据本地性设计的起步阶段Airflow 借由 1.10.0 的 Kubernetes Executor 打开按任务弹性调度的大门Flink 则在 session/job 集群之上同时探索上游原生支持与 Lyft 的 Operator 化两条路径。对关注大数据工作负载容器化的开发者与架构师而言这份文档既是可追溯的历史坐标也提供了一种以产品为维度跟踪集成状态的可复用方法论。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考