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

最新推荐文章于 2024-09-04 19:03:20 发布

2401_85822286

最新推荐文章于 2024-09-04 19:03:20 发布

阅读量409

点赞数 4

文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/2401_85822286/article/details/141110370

版权

compose支持在 同一节点 上部署，swarm支持在多个节点上部署容器。这两者都是docker原生支持的docker集群部署方式，开箱即用，比较方便，偏重于容器的部署。

swarm偏重的是容器的部署，而k8s偏重于应用的部署。k8s对容器的所有操作都渗透着为应用而服务的理念，比如pod是为了让联系紧密但又不适合部署在一起的应用分别部署在不同docker里面，但docker之间共享volume和network namespace方式，以便实现紧密地“交流”，在比如service是为了隐藏pod（容器的集合，下文会介绍到）的网络细节，让pod提供固定的访问入口，从而方便地让其他应用访问等。

在swarm中，被创建、调度和管理的最小单元就是docker。在k8s中，最小单元则是pod。

marathon+mesos，一开始是给大数据组件部署用的，这个框架是一个双层调度框架，侧重于底层资源管理。需要自己实现任务调度。

下面重点对比一下k8s和mesos。

k8s vs mesos

k8s

k8s一些概念

Node：资源节点的抽象
Pod：pod为kubernetes的最小管理单元，一个pod中可以部署多个容器，通常建议是一个容器
Daemonset：每个node上有一个，比如使用gpu、联通上的seman服务
Statefulset：解决有状态服务，保证部署和scale的顺序。比如mysql。
Deployment：一个Deployment通过多个ReplicaSet管理pod，一个Replica Set拥有一个或多个Pod。滚动升级的时候是用新的rs替代旧的rs
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，例如有多个Mara

本文已被开源项目：【一线大厂面试真题解析+核心总结学习笔记+最新全套讲解视频+实战项目源码讲义】收录

thon，则可以并行调度不冲突。

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

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。