部署方式发展史
石器时代
最原始的时代,所有应用部署在物理主机上,要部署Applications
,首先需要组网,然后部署存储、购买硬件、安装操作系统、部署数据库、安全组件、运行时环境,最后部署应用,之后还要花大量的时间,在数据库之间做数据同步,不利于多人多地协同的。
云计算时代
后来进入虚拟化部署时代,虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机(VM),虚拟化技术能够更好地利用物理服务器上的资源,每个 VM 是一台完整的计算机,在虚拟化硬件之上运行所有组件,包括其自己的操作系统。但是虚拟化仍然存在环境笨重,耦合度高等缺点。
云原生时代
利用云计算,实现3种服务模式,IaaS
(Infrastructure-as-a-Service
)、PaaS
(Platform-as-a-Service
)、SaaS
(Software-as-a-Service
)。
IaaS
阶段,基础服务设施即服务,只需向供应商购买相应的基础设施服务,基础设置包含了网络、虚拟化、操作系统等服务,然后在其上面部署数据库、安全组件、运行时环境、最后部署应用即可。PaaS
阶段,平台即服务,平台服务包含了基本的网络、磁盘、操作系统、数据库、运行环境等,只需将应用部署到上面即可。SaaS
阶段,软件设施即服务,例如Office,我们不需要经过一小时的安装,只需通过浏览器访问到其服务器端即可完成我们的需求。
Paas
PaaS
经过了好几代的更替,最开始的时候是人工的构建方式,比如我向供应商打一个电话,说”我需要一个LAMP
的环境,Apache
要求2.3
版本,PhP
要求5.3
版本,MySQL
需要5.5
版本“,那么供应商需要人工或者通过脚本的方式去生成相应的运行平台,然后再将这个地址给我,我远程登陆即可,后来由OpenStack
一直发展到以Colud Foundry
为代表的开源PaaS
项目,成为了当时云计算技术中的一股清流。
PaaS
项目被大家接纳的一个主要原因,就是它提供了一种名叫应用托管的能力。之前用户租赁的服务器或者平台服务,用户难免会遇到云端虚拟机和本地环境不一致的问题,所以当时的云计算,比的就是谁能更好地模拟本地服务器环境,能带来更好的“上云”体验。PaaS
项目是当时解决这个问题的一个最佳方案。事实上,像Cloud Foundry
这样的PaaS
项目,最核心的组件就是一套应用的打包和分发机制。Cloud Foundry
定义了一种打包方式,将用户的可执行文件和启动脚本打进一个压缩包内,上传至云端,接着,Cloud Foundry
会通过调度策略选择一个可以运行这个应用的虚拟机,然后通知这个机器将应用压缩包下载下来并启动。
这时候关键来了,由于需要在一个虚拟机上启动很多个来自不同用户的应用,Cloun Foundry
会调用操作系统的Cgroups
和Namespace
机制为每一个应用单独创建一个称作“沙盒”的隔离环境,然后在这个“沙盒”中启动这些应用程序。这样,就实现了把多个用户的应用互不干涉地在虚拟机里批量地、自动地运行起来的目的。这正式PasS
项目最核心的能力。而这些“沙盒“,就是所谓的”容器“。
Docker
在这股PaaS
热潮中,当时还名叫dotCloud
的Docker
公司,也是其中的一份子,长期以来无人问津。眼看就要被如火如荼的PaaS
风潮抛弃,dotCloud
公司决定开发自己的容器项目Docker
。然而,短短几个月,Docker
项目就迅速崛起。Docker
项目确实与Cloud Foundry
的容器在大部分功能和实现原理上都是一样的,可偏偏就是这剩下的一小部分不一样的功能,成了Docker
项目接下来”呼风唤雨“的不二法宝。这个功能就是Docker
镜像。
Docker
镜像从根本上解决了打包这个问题。所谓Docker
镜像,其实就是个压缩包。但是这个压缩包里面的内容,比PaaS
的应用可执行文件+启停脚本的组合就要丰富多了。实际上,大多数Docker
镜像是直接由一个完整操作系统的所有文件和目录构成的,所以这个压缩包里的内容跟你本地开发和测试环境用的操作系统是完全一样的。即该镜像不论在哪儿运行,都可以得到和你本地测试时一样的环境。这正式Docker
镜像的精髓。
所以,Docker
项目给Paas
世界带来了“降维打击”,其实是提供了一种非常便利的打包机制。这种机制直接打包了应用运行所需要的整个操作系统,从而保证了本地环境和云端环境的高度一致,避免了用户通过“试错“来匹配两种不同运行环境之间差异的痛苦过程。
解决了应用打包这个根本性的问题,同开发者与生俱来的亲密关系,再加上PaaS
概念已经深入人心的完美契机,成为Docker
这个技术上看似平淡无奇的项目一举走红的重要原因。
Kubernetes
但是容器化也带了一个问题,例如我需要部署一个JavaWeb
项目,用到4台物理机,A
、B
、C
、D
,A
服务器部署Nginx
、B
、C
部署Tomcat
、D
服务器部署MySQL
服务器,他们之间的网络联通通过基本的TCP
就可以访问。但是如果一旦容器化之后,例如我在A
服务器上部署Docker-Nginx
并将容器例如80端口映射到物理机80端口、B
、C
服务器上部署Docker-Tomcat
并将容器例如8080端口映射到物理机8080端口、D
服务器上部署MySQL
服务器并将端口3306端口映射到物理机3306端口,并且我们一般容器化就是最大化利用资源,一台物理机上会部署多个Docker
容器,你会发现仅端口管理就让人头大,更不用说集群的容错恢复等,那么怎么解决这个问题呢?也就是说容器的集群化有没有好的方案呢?有需求就会有产品,这个产品叫资源管理器。
Docker
公司也意识到这个问题,在2014年12月的 DockerCon
上发布Swarm
,之后,大量围绕着Docker
项目的网络、存储、监控、CI/CD
,甚至UI
项目纷纷出台,也涌现出了很多 Rancher
、Tutum
这样在开源与商业上均取得了巨大成功的创业公司。这令人兴奋的繁荣背后,却浮现出了更多的担忧。很多从业者意识到Docker
项目此时已经成为Docker
公司一个商业产品,而开源,只是 Docker
公司吸引开发者群体的一个重要手段,更重要的是,Docker
公司在Docker
开源项目的发展上,始终保持着绝对的权威和发言权,并在多个场合用实际行动挑战到了其他玩家(比如,CoreOS
、RedHat
,甚至谷歌和微软)的切身利益。
所以这次,Google
、RedHat
等开源基础设施领域玩家们,共同牵头发起了一个名为CNCF
(Cloud Native Computing Foundation
)的基金会。这个基金会的目的其实很容易理解:它希望,以Kubernetes
项目为基础,建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区,来对抗以Docker
公司为核心的容器商业生态。
Kubernetes
项目,并不是几个工程师突然“拍脑袋”想出来的东西,而是Google
公司在容器化基础设施领域多年来实践经验的沉淀与升华,另一方面,kubernetes
整个社区推进“民主化”架构,即:从API
到容器运行时的每一层,Kubernetes
项目都为开发者暴露出了可以扩展的插件机制,鼓励用户通过代码的方式介入到Kubernetes
项目的每一个阶段。
Kubernetes
项目的这个变革的效果立竿见影,很快在整个容器社区中催生出了大量的、基于Kubernetes API
和扩展接口的二次创新工作,比如:
目前热度极高的微服务治理项目Istio
;
被广泛采用的有状态应用部署框架Operator
;
还有像Rook
这样的开源创业项目,它通过Kubernetes
的可扩展接口,把Ceph
这样的重量级产品封装成了简单易用的容器存储插件。
就这样,在这种鼓励二次创新的整体氛围当中,Kubernetes
社区在2016 年之后得到了空前的发展。更重要的是,不同于之前局限于“打包、发布”这样的PaaS
化路线,这一次容器社区的繁荣,是一次完全以Kubernetes
项目为核心的“百花争鸣”。
– 引用自知乎一起学习k8s