K8s概述:几种集群方案的对比 Linux到底该怎么学?RHCA架构师整理了300页学习笔记 到了2020年,技术水平到底需要达到怎样的程度才能成为顶级的阿里P8架构师 Linux怎么学?一张思维导图带你深入Linux核心原理 金九银十首战告捷!凭借这份Alibaba爆款“面试宝典”成功斩获美团Offer 大数据杀熟:我投之以元宝,它报之以砍刀! “物联网加持”下的社区长啥样儿? 潘云鹤院士:大数据智能是人工智能2.0的核心组成部分 防小孩和老人走失,定位精度达1厘米?上海社区为先进物联网产品提供落地场景 技术老兵十年专攻MySQL编写了763页核心总结,90MySQL问题全解 【Jenkins自动化部署】Windows节点Apache+Django服务自动化构建 Mybatis 使用通用 mapper 正道的光!阿里爆款Jenkins+K8s笔记终于全网开源了 不要死磕Java并发了,阿里P7架构师带你深入剖析synchronized的实现原理 EtherNet/IP协议基础知识(Part 1) CGB2005-京淘13 思科 OSPF协议简单配置与分析 在一家公司呆了 10 年的程序员,最后都怎么了? 致力物联网芯片研发,奕斯伟计算获逾20亿元融资 Unity性能优化技巧 纪念首次撸出来的编程题--2020深信服软件测试岗 qml 去除标题栏后 拖动窗口和改变窗口大小 如何舒服地在图书馆用ipad入门深度学习【windows jupyter远程】 力扣Java版个人代码分享-树篇( 107. 二叉树的层次遍历 II) 第十届蓝桥杯省赛java类B组 试题 E:迷宫 (动态规划之回溯法) Unity+罗技G29方向盘+Realistic Car Controller 制作简单的模拟驾驶 2020阿里笔试题解(9.11) 起飞!这份技术点拉满的ELk+Lucene笔记,可能价值百万 好文精选整理--Redis+Nginx+设计模式+Spring全家桶+SQL+Dubbo技术 覆盖全网的微服务架构笔记,看完还不懂你来打我 技术干货:JVM架构体系与GC命令全梳理,建议收藏 跪拜,阿里P9加班到凌晨,硬肝三个月推出这份IT架构运维实践 太厉害了,华为架构师终于整理出SSM+Nginx+Redis+SQL+微服务pdf 膜拜!终于有人总结出Spring+SpringMVC+MyBatis源码层PDF了 开发1-5年的Java程序员,该学习哪些知识实现涨薪30K? 云原生景观:供应层(Provisioning)介绍 vulhub学习笔记-struts2 S2-057 Remote Code Execution Vulnerablity远程代码执行 微服务启动报 Error creating bean with name ‘eurekaAutoServiceRegistration‘ 异常 「信息安全-密码与隐藏技术」RSA加密算法的实现(CPP 实现) 单例模式线程是否安全? DDCTF2020 Writeup 迭代器模式在开源代码中的应用 微信群总是有人发广告?看我用Python写一个自动化机器人消灭他! 极光大数据持续亏损,称风控产品数据涉10亿移动端用户、包括财产消费等信息,对外投资极贷管家 揭秘英飞凌最新安全芯片解决方案:为物联网设备量身定制,小封装易开发 蒙草大数据西乌旗智慧畜牧业系统建设取得新进展 移动转售产业与大数据产业交流座谈会即将召开 19-2!62比24!湖人4大数据碾压对手,夺赛点进西决稳了 Web前端程序员每天的工作都是做什么的?有哪些是必须要做的? 四面楚歌祭利剑:华为再推鸿蒙OS,另辟蹊径进军物联网
您的位置:首页 >开发 >

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

几种集群方案简介

下面以docker部署为主,主流的容器化集群部署方案主要有以下几种:

Docker Compose:帮助在 同一个节点 上部署多个容器。Docker Swarm:多台机器上部署容器。开箱即用,快速部署容器。偏重容器部署K8s:社区活跃度高,组件丰富。微服务化,偏重应用的部署。Marathon+Mesos:大数据组件部署。双层调度,侧重底层资源管理。任务调度需自己实现

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替代旧的rsEndpoint:一个资源对象,用于记录一个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和slaveFramework:如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自身也可以通过容器的方式运行在平台之上。

不同集群规模的选择

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

因为容器和集群编排有学习成本,所以对于小集群,建议是使用Iaas和裸机部署docker。

然后当发展到一定程度,有50+个以上的服务的中等规模集群,建议使用Docker Swarm,Swarm与docker紧密结合,命令与docker相对一致,比较容易上手。

到了百级别的集群,在这个量级上需要有一些定制化工作,swarm调度方面开始有压力,组件内置又不好debug。这时候会比较多选择Mararthon+Mesos,双层调度机制使得集群可以大很多。

到了千级别的集群,kubernetes的模块划分的更细,设计思想也更偏向于微服务部署,就是学习成本比较高。

然后是万级别的节点,这时候Kubernetes的调度和etcd等组件的压力在万级别上会达到瓶颈,单个etcd集群和串行调度,controller监听单队列会遇到性能的问题。这时候需要定制化K8s组件,比如etcd做多集群,对于多租户可以实现并行调度,监听多个队列,定制事件优先级,比如add优先于delete等等。

在这个级别上也可以使用DC/OS做定制化,天生的双层调度可以给不同的租户独立使用Marathon并行调度。

最后是部署大数据组件,推荐是使用Mesos做调度,因为天生就是从做大数据组件部署起来的,拥有丰富的大数据Framework。

 

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。