k8s的诞生历史
PaaS项目被大家接纳的一个主要原因，就是它提供了一种名叫“应用托管”的能力
Docker镜像解决的，恰恰就是打包这个根本性的问题
Docker项目给PaaS世界带来的“降维打击”，其实是提供了一种非常便利的打包机制。这种机制直接打包了应用运行所需要的整个操作系统，从而保证了本地环境和云端环境的高度一致，避免了用户通过“试错”来匹配两种不同运行环境之间差异的痛苦过程。
CaaS，即Container-as-a-Service
OCI（ Open Container Initiative ）。OCI的提出，意在将容器运行时和镜像的实现从Docker项目中完全剥离出来
这样做，一方面可以改善Docker公司在容器技术上一家独大的现状，另一方面也为其他玩家不依赖于Docker项目构建各自的平台层能力提供了可能。
CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理解：它希望，以Kubernetes项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以Docker公司为核心的容器商业生态。
而为了打造出这样一条围绕Kubernetes项目的“护城河”，CNCF社区就需要至少确保两件事情：
1、Kubernetes项目必须能够在容器编排领域取得足够大的竞争优势；
2、CNCF社区必须以Kubernetes项目为核心，覆盖足够多的场景。
我们先来看看CNCF社区如何解决Kubernetes项目在编排领域的竞争力的问题。
在容器编排领域，Kubernetes项目需要面对来自Docker公司和Mesos社区两个方向的压力。不难看出，Swarm和Mesos实际上分别从两个不同的方向讲出了自己最擅长的故事：Swarm擅长的是跟Docker生态的无缝集成，而Mesos擅长的则是大规模集群的调度与管理。
Kubernetes项目的基础特性，并不是几个工程师突然“拍脑袋”想出来的东西，而是Google公司在容器化基础设施领域多年来实践经验的沉淀与升华。这，正是Kubernetes项目能够从一开始就避免同Swarm和Mesos社区同质化的重要手段。
mesos和k8s对比
Mesos 项目简介
Apache Mesos 是一个开源的分布式系统内核（Cluster Manager），用于高效管理集群资源，支持分布式应用程序和容器的运行。它于 2010 年首次由 UC Berkeley AMPLab 推出，后来捐献给了 Apache 基金会，并成为其顶级项目。
Mesos 的目标是为数据中心或计算集群提供一个抽象的资源管理和调度层，允许开发者和运维人员以更简单的方式运行各种应用程序框架（如 Apache Hadoop、Apache Spark、Kubernetes 等）以及容器化工作负载。
核心特性
-
资源抽象
- Mesos 提供了对 CPU、内存、磁盘等资源的抽象化管理，支持资源的动态分配和共享。
- 集群中的所有资源通过一个统一的接口进行管理，屏蔽了底层硬件的复杂性。
-
两级调度（Two-Level Scheduling）
- Mesos 的调度分为两级：
- 第一层：Mesos 主节点（Master）将资源分配给各个框架（Framework）。
- 第二层：各框架根据自己的任务需求进一步调度和使用这些资源。
- 这种方式支持不同框架的自定义调度逻辑。
- Mesos 的调度分为两级：
-
多框架支持
- Mesos 原生支持多种大数据框架，例如 Apache Hadoop、Apache Spark、Apache Kafka 等。
- 还支持容器化的工作负载运行（如 Docker、Kubernetes）。
-
高可用性
- 支持通过 ZooKeeper 进行主节点（Master）的高可用性配置，确保故障节点能够自动切换。
- 从节点（Agent）也会定期向主节点汇报状态，防止资源丢失。
-
模块化设计
- 通过插件机制支持资源调度器、资源分配策略的自定义，便于扩展。
主要组件
-
Master（主节点）
- 管理整个集群的资源。
- 将资源分配给不同的框架。
-
Agent（从节点/工作节点）
- 提供计算资源（CPU、内存、磁盘等）。
- 承载具体的任务（Task）运行。
-
Framework（框架）
- 用户程序需要实现的组件，用于接收资源并运行任务。
- 包括两个子组件：
- Scheduler：负责向 Master 请求资源并调度任务。
- Executor：在 Agent 上启动和管理任务。
-
ZooKeeper
- 用于管理主节点（Master）的高可用性和选举。
工作原理
-
启动
- Master 节点启动后，注册到 ZooKeeper，成为 Leader。
- Agent 节点启动后，与 Master 建立连接，并报告可用资源。
- 各 Framework 的 Scheduler 注册到 Master，表示其准备接受资源分配。
-
资源分配
- Master 根据资源调度策略，将 Agent 上的资源分配给 Framework。
- Framework 的 Scheduler 接受资源，并决定如何运行任务。
-
任务执行
- Scheduler 通过 Executor 向 Agent 分发任务。
- Agent 启动任务，并报告任务的运行状态。
-
状态更新
- Executor 持续将任务状态发送回 Framework 和 Master。
- Master 维护集群全局状态。
常见使用场景
-
大数据处理
- 运行分布式框架（如 Hadoop、Spark）进行批量数据处理和实时数据流分析。
-
容器编排
- 通过 Marathon 或其他容器编排工具运行和管理容器化应用。
-
混合工作负载
- 支持在同一集群中同时运行多种框架和工作负载（如批处理任务和服务型应用）。
-
弹性资源管理
- 动态调整资源分配，优化集群的利用率。
与 Kubernetes 的对比
尽管 Mesos 曾在容器编排和集群管理领域广受欢迎，但随着 Kubernetes 的崛起，Mesos 的影响力逐渐下降。以下是两者的主要区别：
| 特性 | Mesos | Kubernetes |
|---|---|---|
| 架构模式 | 两级调度（Master + Framework 调度） | 单一调度（由 Kubernetes 负责调度） |
| 资源管理 | 通用资源抽象，适合多框架混合运行 | 专注于容器化工作负载 |
| 复杂性 | 配置复杂，开发者需要实现 Framework | 用户友好，开箱即用 |
| 生态支持 | 支持 Hadoop、Spark 等大数据框架 | 以容器编排为核心，支持 Helm 等生态 |
| 流行度 | 降低，已被其他工具取代 | 主流容器编排平台 |
现状与发展
Mesos 在其早期（2010 年代初期）是分布式资源管理领域的佼佼者。然而，随着 Kubernetes 的快速发展和广泛采用，Mesos 的受欢迎程度逐渐下降，目前主要被一些特定的企业或组织（如 Twitter、Uber）在定制化场景中继续使用。
对于新项目，如果主要目标是容器编排，通常会优先选择 Kubernetes。Mesos 更多地用于遗留系统或需要运行多种分布式框架的环境。
总结
Apache Mesos 是一个强大的分布式资源管理平台，擅长管理大规模混合工作负载。它的两级调度架构和高度灵活性曾经是其核心优势，但在现代容器化时代，Kubernetes 提供了更好的用户体验和生态支持。如果你在处理多种框架的工作负载时，Mesos 仍然是一个值得考虑的选择。
