运维简史 - 从单机版应用到容器的运维历程

百家号
天地会珠海分舵
为了解决这个问题,后来云服务就开始被提出来了。与其自己去维护一堆硬件设备,倒不如按需购买人家已经提供好的云服务,直接部署到人家云端算了。所以这里阿里云的ECS这些Iaas就应运而生了。

1.png

要说清楚Kubernetes解决了哪些问题,首先要知道容器是怎么回事,为什么要用容器。而要说容器,又要了解下微服务是怎么回事。要说微服务,又要说下微服务之前云部署是怎么回事,依次回溯。

这里我看下是否能简单扒一扒软件的运维部署历史,然后看容器给运维人员带来了什么问题,而这些问题,就是k8s要解决的了!如果大家觉得费时的,可以直接从第二点看是往下看。

第一,容器出现前的运维简史

记得还是在读初中的时候吧,那时候电脑基本上是没有联网的。所以那个时候一个软件的所有功能基本上都是包含在一个安装包上面的,也就是所谓的单机版软件。

因为不同的操作系统环境,有时候软件安装上去了因为缺少了某些库,会运行不了。所以一旦软件出了问题,往往就会找电脑城那些人看下应该怎么弄。

而这个时期企业软件往往也是需要专门的人员进行部署安装,一旦出问题了就会找对应的软件生产商派人来维护。

2.png

那个时候对软件升级部署所需要的关机时间也没有什么大的要求,毕竟大家都习惯了,下班时候找人来升级,第二天继续开机工作就好了。

后来到了2000年前后吧,也就是互联网开始爆发甚至都引起了.com泡沫的年代吧。经过多年的发展,软件,特别是企业软件,已经发展得越来越复杂和臃肿,UI和后端都绑定在一起,动不动就出问题,且难以维护。

这时大家就想要不把前后端分离吧,不要把一整套软件整在一起了,也就是所谓的C/S的概念就出来了,后来又进一步延伸出B/S的模式,也就是所谓的Web App的概念了。

记得那个时候基于网络进行通讯的RPC技术可谓多种多样,很多估计年青一代的都没有听过,比如CORBA,SOAP,COM/DCOM等。当时大家其实挺看好SOAP等,谁知道后来Restful异军突起一统江山了。

虽然前后端分离进一步的将软件进行解耦,但是后端的部署和运维还是很重。比如有些大型软件需要专门的机房,然后增加写功能后负载不够又要添加硬件设备等。

为了解决这个问题,后来云服务就开始被提出来了。与其自己去维护一堆硬件设备,倒不如按需购买人家已经提供好的云服务,直接部署到人家云端算了。所以这里阿里云的ECS这些Iaas就应运而生了。

第二,容器和微服务的出现带来的机会和问题

过了一段时间,大家发现部署在云端虽好,但是还是没有办法解决这个后端越来越复杂的问题,所有的服务都在一个服务器上跑,一个模块出问题了就整个服务器挂了,运维又得通宵了。况且升级一个模块就要整个后端升级,这也太麻烦了吧。

3.png

这时微服务和容器的概念就开始被提出来了。既然把所有模块打包到一起不好维护和部署,那就把不同的模块分开吧,每个模块放到一个容器里面作为微服务,然后容器之前进行rpc通讯,这样一个模块要升级的时候就升级这个模块,一个模块挂了也不至于影响整个后端。

这种模式好是好,但是运维工程师眉头一皱,感觉这个也没有减少我运维的工作量呀,很多东西都需要我手动去做,感觉工作量反而更大了。主要体现在以下几个方面:

首先,容器之间的通信和互相发现,我还是需要手动的去通过docker命令等搭建起来。你说一两个容器还好,但是你现在几十上百的,每个容器所处的网络可能还不一样。

其次,有时我们需要多个相同的容器来做负载均衡和水平扩展,那现在我还需要自己编码去监控什么时候你一个容器负载过大,然后起一个新的相同的容器来分担一部分流量,等流量没有这么高了,我又要去掉一个备份以节省资源

然后,我还要去检测你一个容器什么时候因为我们开发人员写的代码引发的crash,而需要去决定是否要重新初始化一个新的容器来取代crash掉的。

再次,你一个新版本出来了,我还要一个个容器去升级,出问题了我还要一个个容器去降级。还是那句话,一两个容器我么有问题,但是你这里往往是几十上百的容器呀

最后,因为容器支持在不同机器上部署,然后共同提供后端的功能,不同的容器因为不同的功能需求,可能需要挂载的存储设备也不一样,比如有需要本地不同格式文件系统磁盘的,还有有需要NFS网盘的,你让我一个个容器去配,配完了我估计都可以申请拿养老金了。

第三,Kubernetes来救驾

作为运维人员,碰到这么多东西需要自己手工去做,我当然是非常不乐意了。这时我就会想,如果有一个软件能帮我把这些东西自动化管理起来,我只需要敲几个命令,将其配置下就好了。

4.png

这时容器编排服务就在运维的欢呼声中登上历史的舞台了。而在众多选手的竞争角逐中,Kubernetes笑到了最后。

那么Kubernetes又带来什么问题呢?这就有点超出范畴了。简要说下的话,就是懒惰不仅是程序员也是运维人员的美德!在命令行上敲命令写配置文件,我们还是嫌太麻烦了,能不能整个好用的UI出来,底层用的是K8s?

这时Rancher 2.0等就出来了。注意这里特意说的是2.0,因为那之间Kubernetes还没有完全在角逐中胜出,所以那个时候Rancher是既支持K8s也支持Swarm等的。后来一看K8s基本胜局已定,Rancher 2.0立刻抛弃所有,投入到K8s的怀抱中去。

THEEND

最新评论(评论仅代表用户观点)

更多
暂无评论