容器、Docker、K8S们的相爱相杀

2020-10-22 人浏览 点击收藏: 分享至:


扯扯容器、Docker、K8S们的相爱相杀


容器、Docker、K8S、云原生,这些热词都是啥,他们彼此有啥联系,今天我们简单直白一点,来个你问我答。


 容器是什么?和虚拟化到底有啥不一样。


在很久以前,服务器小哥哥都是直接扛活,就像胸口碎大石!

一个服务器,对应一个操作系统,这种玩法,实在是太浪费了,明明可以拼颜值,现在却来碎大石,简直是暴殄天物。

于是乎,虚拟化技术容器技术被开发出来,目的就是让服务器小哥哥人尽其才、物尽其用。



看图一目了然:容器撇掉了臃肿的操作系统,只需把基础的库文件打包带走就可以了,所以身轻如燕。



一台物理机通常能支持成百上千的容器,而且创建和释放的速度都是秒级的,甩了虚拟机好几条街。

正因为这样,容器才成了当红炸子鸡,大部分云原生架构,都是以容器为算力单元的。





 容器就是Docker吗?


Docker≠容器,Docker只是众多容器引擎之一。

容器引擎主要负责两件事:

第一,负责容器的整个生命周期管理,从生到死。



第二、负责本地容器镜像的构建和管理。同时配合镜像仓库,完成海量镜像的存储和管理。



早在Docker出现之前,容器就已经存在了,但Docker公司生逢其时,推动了容器的大发展,结果,很多人就把Docker跟容器划了等号。


时至今日,已经有n多容器引擎,开始挑战Docker的王者地位,也正因为如此,Docker公司走下了神坛。





 既然有了容器引擎,还要K8S作甚?


随着容器的火爆,利用容器架构来搭建业务系统的人越来越多。可是,大家在实操中发现,像Docker之类的容器引擎,折腾少量容器还行。

但如今的云原生应用、机器学习任务或者大数据分析业务,动辄就要使用成百上千的容器。要管理这么多容器,Docker们就力不从心了。


江山代有才人出,各领风骚三五年,有需求就有改变,于是乎,市场上就出现了一批容器编排工具,典型的是Swarm、Mesos和K8S。

经过几年大浪淘沙,K8S“击败”Swarm和Mesos,几乎成了当前容器编排的事实标准。



K8S最初是由Google开发的,后来捐赠给了CNCF(云原生计算基金会,隶属Linux基金会)。


K8S的全名是kubernetes,读作“库伯耐踢死”,很多国人既拼不对也写不对,而K和S之间有8个字母,索性就简单一点,叫“开八司”了。

K8S是个杂技高手,最擅长的就是“搬箱子”,盘各种容器玩。




K8S的大致架构,就像上面。Master节点,用来放“脑子”,“腿脚”搭在工作节点上“搬砖”,工作节点就是实际业务容器的存放地。

单个容器或多个关系密切的容器,被编成一组,称为pod。K8S就是以pod为单位进行编排操作。

同时,K8S还要和其它相关软件配合,来完成联网、存储、安全等功能。


诞生六年来,K8S一路高歌,成为容器编排和调度领域的No.1。但需要注意的是,K8S和Docker们不是替代关系,而是配合关系。

K8S仍然会使用Docker之类的容器引擎(Docker、Containerd、RKT、CRI-O等),来对容器进行生命周期管理。





 K8S既然那么猛,直接拿来用不香吗?


这样做,看起来没毛病,K8S是开源软件,社区版K8S也很完美。

你可以在网上找到各种安装指导文档,然后从github轻松找到最新的版本,然后一步一步搭建集群。

只是安装过程漫长而痛苦,毕竟搭建集群不是我们的目的,我们的目的是利用集群来干活。


搭一个K8S学习环境倒也罢了,权当练手涨经验。可当我们要搭建生产环境的时候,事情就变得不一样了。


这时候,为了保证集群的可靠性,我们可能要跨多个可用区来部署K8S集群。对于大多数人来说,这个工作不太好玩。




不止搭建集群过程很复杂,后期还要面对更繁琐的K8S控制平面维护工作:版本升级、安全管控、数据备份等等。

所以,面对生产级别的业务,大家往往喜欢选择Turnkey(一站式)的商用方案,而不是自己慢慢鼓捣,老牛拉破车。






 云上一站式K8S方案,到底哪家强?


目前,各大云服务商几乎都推出了Turnkey方案,帮助用户快速搭建K8S集群。

到底哪家强呢?王婆卖瓜,自卖自夸,似乎没有定论。

但是有个数据很有参考意义,根据咨询机构「Nucleus Research」的数据,所有云中K8S的工作负载,竟然有82%都是运行在AWS上的。


so,我们差不多可以这样说,云上K8S,还是AWS最强!

AWS提供了一个神器,叫做Amazon EKS,可以快速帮我们搭建高可用的云上托管K8S服务。






 Amazon EKS 到底牛在哪儿?


作为一个从来没摸过K8S的生手,我用了不到10分钟,就创建了一个横跨3个可用区的生产级集群,实在太魔幻了。

整个过程,只需要区区两步↓



在添加工作节点的时候,可以选择各种EC2实例,AWS准备了丰富的实例类型,满足不同的容器用途。

当然,还可以选择新酷的Fargate工作节点,这是一种Serverless的方式,说白了,你不需要去考虑什么实例呀、服务器呀,直接按需使用容器即可,要多少有多少,计费精确到容器,而非主机。

集群创建完成后,我们就可采用自己习惯的工具,比如kubectl,像使用标准K8S集群一样,进行各种业务部署的操作了。


除了简单、易用、生产级高可用以外,Amazon EKS与社区版的K8S是保持同步的,原生体验完全一致,可以使用社区所有插件和工具…

so,不需要额外的学习成本,也不用担心锁定,轻松迁移。



作为云上K8S大户,AWS也充分发扬开源精神,源于社区、反哺社区,不断为K8S项目做贡献,推动K8S的改进。


AWS为EKS提供了多达270种节点,可以满足所有工作负载和业务需求,并提供为EKS定制优化的操作系统镜像,高效、安全、开源。

同时,EKS还与AWS其他服务无缝集成,诸如负载均衡、弹性伸缩、身份认证、存储、安全、监控、日志,用户不需要苦逼滴自己造轮子,站在AWS肩膀上就行。

更令人心动的是,不止于EKS,围绕容器、K8S、微服务这些云原生的关键技术,AWS提供了一揽子解决方案。



随着云计算进入深水区,云原生的理念越来越深入人心,利用AWS的「容器全家桶」,用户可以轻松搭建各种高可用「云原生」服务,把上云的价值最大化。





本文首发于特大号


  后  记  


有人问:AWS既有ECS,又有EKS,这两者有啥区别?

我是这么理解的:ECS是AWS在K8S还没有成为容器编排的事实标准之前,自己推出的一套容器编排平台,完全不依赖于k8s,而是AWS自己定义的一套标准。

理论上讲,ECS是AWS“原生”的,所以与AWS的各项服务集成度更高,但目前看EKS跟AWS其他服务集成度也越来越高了。

EKS适合原本就入了K8S的坑的,希望在云上继续使用托管式高可用K8S的,有一定使用惯性的用户,或者他们更喜欢开源,担心被锁定。

ECS则适合AWS的“铁粉”,对K8S没什么基础或者迷恋,就容器编排能力上讲,EKS和ECS差不多。

另外:EKS集群和工作节点分别收费,而ECS集群不收费,只收工作节点的费用(EC2实例费用,或者Fargate容器费用)。

另外,在我看来,随着容器化对虚拟化的替代或部分替代,K8S也正在悄然碾压曾经红极一时的OpenStack,现在人人都谈K8S的盛况,宛如3、5年前人人都谈OpenStack。

未来K8S会不会也盛极而衰呢?
(文章转自小黑羊和他的猫,鸣谢)

查看全部
相关文章推荐相关文章推荐
容器服务K8S网络策略分析 容器服务K8S如何命名空间呢? 浪潮容器k8s部署服务产品功能分析 容器服务K8S产品功能分析 容器服务K8S安全策略解析 浪潮云容器服务K8S应用场景有哪些 容器服务K8S常见问题分析 容器服务K8S操作疑问分析,手把手教你如何用 容器服务K8S模板如何安装和查看呢?这里给你答案 k8s部署服务应用实例分析
热门解决方案热门解决方案
浪潮酒业云 高性能计算云解决方案_高性能计算服务平台_HPC云-浪潮云 教育云盘解决方案_教育数据云盘平台_教育云盘资源共享平台 工业互联网机械制造质量管理与追溯解决方案_质量追溯管理系统 液化天然气(LNG)产业互联网解决方案_LNG产业物联网大数据服务平台 运输管理系统(TMS)解决方案_物流运输管理系统 区块链技术服务解决方案_企业级区块链应用服务平台 电子采购平台解决方案_采购与供应管理平台_电子采购系统搭建 云会计+云进销存解决方案_企业云财务系统搭建 仿真云平台-仿真云服务-企业仿真体系
热门产品推荐热门产品推荐
热门标签热门标签