Kubernetes 的前世今生和未来
技术
作者:崔婧雯
译者:Docker
2018-01-12 02:55

 有人认为自动化,云计算和人工智能是第四次工业革命。如果你开始感受到IT领域自动化率的飙升,特别是在应用程序部署和管理领域(我觉得还不是无缝的自插拔式),那么不用太过惊讶。几年前,Google就正式启动了名为Kubernetes的项目,也就是现在广为人知的k8s。Kubernetes是开源的容器集群管理器,意图成为能够在容器领域自治化部署以及扩展应用程序的平台。


Kubernetes简史

Kubernetes这个词是“舵手”的希腊语,该项目是Google在2014年启动的。它由 Joe Beda,Brendan Burns和Craig McLuckie创建。Kubernetes v1.0在2015年7月21日正式发布,并且迅速贡献给Linux Foundation,作为Cloud Native Computing Foundation的一部分。


容器的兴起

在深入研究Kubernetes之前,要认识到如果没有容器的出现,Kubernetes也不会存在。从高层看,容器看上去像虚拟机,但是最大的区别是容器和其他容器共享主机系统的内核。这是最主要的差异要素,因为容器共享物理主机的OS,所以它们很容易移动。用户也可以在同一台主机上启动比VM数量多得多的容器,因为它们共享内核,库和二进制文件。比如,一个VM的大小大概是20GB,而运行着相同应用程序的容器大概只有200MB。


容器(无论是Docker还是CoreOS的rkt)允许开发人员无缝地关注于应用程序的运行时。基础架构的问题会影响到脆弱的应用程序开发的日子一去不复返了。使用容器,开发人员仅仅需要考虑如何恰当地扩展,部署以及管理他们新开发的应用程序,但是现有的容器方案并不能在跨多节点的环境里自己管理,调度以及部署容器。


Kubernetes是关键一环

在容器化的世界里,Kubernetes是环境的管理和部署引擎。使用Kubernetes的最基本功能,用户就可以轻松地在物理硬件或者虚拟机上调度并且运行应用程序。Kubernetes的更多高级用法让开发人员可以彻底摆脱主机为中心的世界,而进入容器为中心的环境里。


Kubernetes是怎么工作的

使用Kubernetes很容易。可以使用REST API来操作Kubernetes所包含的主要组件 。Kubernetes的定位是平台,但是它包含多个组件,每个都有各自的角色。Master是Kubernetes集群里的控制服务(也称为control plane),Master很重要,因为它会API调用和其交互的其他组件。集群单元管理发生在Master里,调度服务也在这里。


Kubernetes工作单元



Master之下就是Kubernetes工作单元,这里定义特定工作的实体。既然最终目标是要交付一个应用程序,那么这些单元还有更多其他的特定功能。


Pod:最基础的单元是Pod,当指派容器时,容器实际上并不会指派到物理硬件上,相反,容器会被分配到一个Pod里。Pod通常负责托管服务于单个应用程序的容器。这意味着Pod内的所有容器都能够共享卷和IP空间,允许它们扩展为单个应用程序。


Service(服务):如果想要构建更为稳健的容器化策略,那么“服务”的概念就更加重要。服务的功能是资源均衡器,将工作负载在容器间导流。这使得后台容器可以通过单一稳定的接入点和前端应用程序通信。这个特性让使用者更易于使用并且可扩展。


Replication Controller(副本控制器):这些单元的目的是确保在某个时间点,有所需数量的特定容器在运行。比如说突然某个内核出错了,导致某个容器(多个容器组内的)崩溃了,那么RC的责任是新启动一个副本Pod,直至之前的Pod在重启后恢复为止。一旦之前的Pod启动并且再次运行了,RC就会杀死副本Pod。


Label(标签):虽然标签并不是一种工作单元,但是它起着至关重要的组织作用。标签的功能是组命名,这样用户可以针对一组单元做操作。这是用户组织容器环境的方式。


在最基础的级别上,这些是组成Kubernetes平台的实体。

和虚拟化的类比


想一想我们现在都很熟悉的技术,通过虚拟化类比一下Kubernetes。


Kubernetes的Master和VMware的vCenter类似。Master知道集群里的所有节点,以及所有节点的容量。而且,Master对Pod的调度及放置,类似于vCenter如何在vSphere的主机上部署VM。Pod的功能和vApp很类似,因为它们都在一个网络里托管多个容器。容器类似VM,因为它们之前都是互相隔离的,除非它们被指定特定的网络路径。最后,Replication Controller类似于HA,因为RC持续监控环境,确保正确数量的Pod在运行,如果数量少于预期,就会调度一个新的实例。


Kubernetes的优势


虽然Kubernetes并不是市场里唯一的容器管理平台(还有Docker Swarm和Mesos),但是它更受欢迎。为什么呢?从高层看,Kubernetes正获得关注,因为它提供了这样一个平台,容器化的应用程序可以只编写一次,就能够在所有类型的云供应商以及私有云上运行,无论底层使用的是哪种基础架构。而且,Kubernetes还在发展,让开发人员能够在Kubernetes上运行任意适合的应用程序。Sam Ghods,Box的联合创始人认为只要是能运行的二进制文件,就可以运行在Kubernetes上。


使用Kubernetes,开发人员可以快速部署应用程序,而无需担心传统平台上的诸多风险(想想跨多OS环境的垂直扩展),可以随时扩展应用程序,并且更好地分配资源。


硬件使用量的下降是使用Kubernetes带来的另一个好处。一些公司报告由于容器的轻量天性,以及能够快速杀死不需要的实体(和传统架构相比),硬件使用量减少了40-50%。eBay是Kubernetes的支持者和用户,声称自从他们切换了平台之后,看到了服务器上overhead的急剧降低[1]。


最后,Kubernetes最大的不同之处并非和技术相关,而是促成各种方案的社区。Google将其发布为开源项目,吸引了1000+的社区贡献者,34000次commit。它的社区比Mesos的社区(次大的竞争者社区)大5倍,比所有竞争者的社区加起来都要大。


Kubernetes的缺点

Kubernetes受到了广泛的称赞,但是它也有一些缺点。当第一次使用它做部署(大规模)时,它很复杂,并且很难搭建。它要求具有特定技能的工程师,在现在的行业里可能很难找到。


第二,Kubernetes作为容器的第三方管理系统。容器技术本身的缺陷和成长之痛会影响到Kubernetes所能够提供的服务。


Kubernetes欠缺的领域是调度器。默认的Kubernetes调度器依赖于应用程序所有者提供的分配资源的需求,而不管实时使用量。这个方案会加重每个节点上的资源分片情况。


最后,能够在容器里运行的工作负载范围将影响Kubernetes的广泛使用,但是这并非Kubernetes可以直接解决的问题。比如,很多工程师还不想把“核心”工作负载放到容器里,因为它可能会崩溃,而容器从设计上就不是为了存储数据的。常见的实践是只在容器里运行那些崩溃后也不会导致下线时间的应用程序。


即使有这些不足,也并没有阻止Goldman Sachs,Box,SAP以及The New York Times这样的公司引入Kubernetes平台作为其下一代数据中心计划的一部分。


Kubernetes的未来


应用程序是如今大多数业务的生命线。公司需要快速的部署和高质量的应用程序。这些需求正是开发人员转向容器的原因。随着容器的发展,如果还认为Kubernetes的定位有问题那就难免有些愚蠢了。Kubernetes平台有很多的可能性,但是规模大了的话它也很难管理。最初的搭建和在生产环境上大规模运行Kubernetes之间的空白是很大的。近几年里,可能会有来自于第三方的强劲挑战,来管理这些部署和工作负载。对于Kubernetes来说,不囿于已经取得的成就至关重要。如果社区能够恰当地扩展平台,那么Kubernetes的前途甚为光明。


相关链接:

  1. https://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/

原文链接:https://turbonomic.com/blog/on-technology/kubernetes-its-past-present-and-future/

 

274 comCount 0