K8s概述：几种集群方案的对比

最新推荐文章于 2024-11-06 14:26:09 发布

2401_86401423

最新推荐文章于 2024-11-06 14:26:09 发布

阅读量671

点赞数 15

文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/2401_86401423/article/details/141994510

版权

Endpoint：一个资源对象，用于记录一个service对应的所有pod的访问地址
Service：容器互联或者对外暴露的服务。Service通过label选择Pod，这些 Pod 通过endpoints 暴露出来。通过与具体后端pod解耦，使得后端pod迁移时访问不受影响。

k8s组件

kube-dns：用Service向集群内部提供服务的
Etcd：存储配置数据库。存储网络的配置信息和各种对象的状态和元信息配置
kube-apiserver：k8s主节点的管理中心，整个集群的控制入口。它有助于各个组件之间的通信，从而保持集群的健康。
kube-controller-manager：确保通过向上和向下扩展工作负载来使群集的期望状态与当前状态相匹配。
kube-scheduler：将工作负载放置在适当的节点上。
Kubelet：从API服务器接收pod规范并管理在主机中运行的pod。

kubelet会在API Server上注册节点信息，定期向Master汇报节点资源使用情况，并通过cAdvisor监控容器和节点资源。可以把kubelet理解成【Server-Agent】架构中的agent，是Node上的pod管家。

scheduler负责集群的资源调度，为新建的pod分配机器。这部分工作分出来变成一个组件，意味着可以很方便地替换成其他的调度器。

controller-manager负责执行各种控制器，目前有两类：

endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。
replication-controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。

K8s概述：几种集群方案的对比

提交流程

提交一个pod的流程

用户提交pod，APIServer记录到etcd中；
scheduler周期性查询APIServer，以获取未绑定的pod，尝试为pod分配节点；
scheduler调度：首先过滤不符合pod资源要求的主机。然后考虑整体优化策略对主机打分，比如使用最低负载，使用分散主机等。最后选择最高分的主机存储绑定信息到etcd中；
kubelet周期查询绑定对象，获取需要在本机启动的pod并通过docker启动。

K8s概述：几种集群方案的对比

提交一个controller的流程

用户提交一个controller；
APIServer把controller对象保存到etcd中；
controller周期性查询APIServer获取未绑定的pod：APIServer获取每个节点上绑定的kubeletkubelet请求docker获取pod状态kubelet返回pod状态
controller创建pod

K8s概述：几种集群方案的对比

提交一个service的流程

APIServer创建service对象写入etcd。
controller不断扫描service对应的pod。
controller调用APIServer创建对应的访问端点endpoint。
APIServer将endpoint对象写入etcd。
proxy不断发现有没有可以放在自己上面的转发规则，如果有则创建socket监听端口，并且创建相应的iptables规则。

K8s概述：几种集群方案的对比

mesos

mesos+marathon

mesos复制资源管理，主要有以下四个组件：

Agent：即Slave，上报资源
Master：接入framework和slave
Framework：如Hadoop、Marathon，修改调度器，获取Mesos分配给自己的资源
Executor：如何启动task

这里面有两层的Scheduler，一层在Master里面，allocator会将资源公平的分给每一个Framework，二层在Framework里面，Framework的scheduler将资源按规则分配给Task。其它框架的调度器是直接面对整个集群，Mesos的优势在于，第一层调度先将整个Node分配给一个Framework，然后Framework的调度器面对的集群规模小很多，然后在里面进行二次调度，而且如果有多个Framework，例如有多个Marathon，则可以并行调度不冲突。

以下面这个调度图为例子：

Slave1 向 Master 报告，有4个CPU和4 GB内存可用。
Master 发送一个 Resource Offer 给 Framework1 来描述 Slave1 有多少可用资源。
FrameWork1 中的 FW Scheduler会答复 Master，我有两个 Task 需要运行在 Slave1，一个Task 需要<2个cpu，1 gb内存=“”>，另外一个Task需要<1个cpu，2 gb内存=“”>。
最后，Master 发送这些 Tasks 给 Slave1。然后，Slave1还有1个CPU和1 GB内存没有使用，所以分配模块可以把这些资源提供给 Framework2。

K8s概述：几种集群方案的对比

DC/OS

DC/OS是以Mesos为内核，加上marathon和chronos作为运行和管理任务和应用的框架。它集成了许多大数据处理框架（hadoop、spark等）。

K8s概述：几种集群方案的对比

Mesosphere DCOS除了内核Mesos，还有两个关键组件Marathon和Chronos。其中，Marathon(名分布式的init)是一个用于启动长时间运行应用程序和服务的框架，Chronos(又名分布式的cron)是一个在Mesos上运行和管理计划任务的框架。

Mesosphere DCOS在其公有仓库上已提供了40多种服务组件，比如Hadoop，Spark，Cassandra, Jenkins, Kafka, MemSQL等等。

DC/OS上面的Framework实现也可以使用k8s。

k8s vs mesos

K8s概述：几种集群方案的对比

DC/OS采用二次调度的机制，使得应用调度与资源调度相分离。这一点与Kubernetes不同，Kubernetes的应用调度与资源调度全部都是通过内部的组件完成的，其自身的资源调度平台仅能为容器运行提供支撑，不能为其它的Framework提供资源支撑，可以说Kubernetes的容器调度与资源调度是紧耦合的。而在DC/OS平台下，各应用调度框架与Mesos资源实现了松耦合，Mesos仅负责资源的调度，而上层应用的调度则由各应用的Framework自身完成，Framework自身也可以通过容器的方式运行在平台之上。