基于Kubernetes的私有容器云建设实践

《基于Kubernetes的私有容器云建设实践》要点：
本文介绍了基于Kubernetes的私有容器云建设实践，希望对您有用。如果有疑问，可以联系我们。

本次分享为大家介绍易宝支付私有容器云从0到1的建设之路.包括技术选型、理论基础、基于Kubernetes的容器云和CI/CD落地过程中的挑战和踩过的坑.

建设背景及目标

在Docker技术流行开来之前,保证软件交付的质量和速度对于大多数企业来说都是困难的.业务的复杂性带来了应用的复杂性,面对成千上万的不同应用,运维部门需要时刻应对来自不同应用、不同环境的挑战.特别是在自动化运维程度不高的企业,“人肉运维”成了解决问题的常用手段,人肉运维使软件交付的周期变得漫长、人为事故风险升高. 2013年,Docker横空出世,它的”Build once,Run anywhere”的特性让软件交付焕然一新.我们在认真调研了Docker技术后,决定构建自己的私有容器云,背景和目标如下：

实现运维自动化是我们立项之初最主要的目标,而它又是实现后面目标的基础.这个因素直接决定了我们的技术选型.

技术选型

我们是在2015年6月份开始调研技术,2015年8月份开始容器云立项,首先要面对的问题,就是如何进行容器编排引擎的选型,可供选择的有Swarm,Mesos,Kubernetes,甚至自主研发集群编排,我们认真调研了每一种方案：

Swarm当时是0.4版本,功能还相对简单,优势是技术栈比较简单,小团队即可驾驭,但是考虑到它不是稳定版,虽然它发展很快,但是没有解决我们现有的问题,所以Swarm不被优先考虑.

Mesos当时是0.23版本,它能够胜任大规模场景的容器编排,偏重于资源抽象,与我们大多数是Java Web的应用的场景不符,另外,Mesos技术栈与我们现有技术栈差别太大,不得不放弃这个选择.

自主研发容器编排引擎我们也考虑过,但是经过认真的探讨,自研编排引擎对标三个开源的组件的功能,研发投入需要很多的成本,可能结果并不能达到预期,投入产出比低.另外,容器云作为底层的基础设施,选择更要慎重,如果自研项目失败,可能会离主流的容器技术越来越远,机会成本太高,所以自研的路线也被否定.

Kubernetes是我们的最终选择,它当时是1.0.2版本,已经是”Production Ready”,我们选择Kubernetes的最主要的原因是它理念的先进,而且非常适合我们公司的主流应用,Java Web应用都是Long time running的任务,Kubernetes的”Replication controller”对它支持非常好.Kubernetes以应用为中心的理念和社区的活跃度更是坚定了我们的选择,历时三个月的技术选型终于落下帷幕,我们决定使用Kubernetes构建我们的私有容器云平台.

理论基础和原则

在我们决定使用Kubernetes的作为容器编排引擎后,关于选型的争论持续了很长的一段时间,当时国内Kubernetes的使用者还比较少,很难找到成功的案例.我们需要深入的研究Docker,Kubernetes相关的容器技术,确保我们的决策是正确的,这对我们构建容器云至关重要.经过很多的调研和讨论,我们发现容器云的是有一套完成的理论基础支撑的,这些理论又引申出我们构建容器云的原则：

• 不可变基础设施,是利用Docker镜像的不可变性,以更加便捷的方式维护基础设施:当基础设施损坏或者变更时,以直接替换的方式达到目的,而不是通过修缮损坏的基础设施,这么做需要替换的成本足够低,Docker显然做到了这一点；对于已经运行的Docker容器,如果它出现异常,不再是传统ssh上去调试的方式,应该是杀掉这个容器,重新启动一个新的容器；替换操作具有快速和可重复的特性,任何操作都可以随时回滚,安全可靠；对于生产环境的运维,不可变基础设施的理念尤为重要,很多事故都是在生产环境中直接修改造成的.
• 基础设施即代码,管理基础设施像管理代码一样,每个基础设施都是“可描述”的,例如Kubernetes中的Node概念,他们也应该作为“代码”的一部分以代码的方式进行管理.
• 可编程的基础设施,基础设施不仅仅是提供计算、存储、网络资源,还要为上层应用提供可编程的接口,让上层应用可以更加灵活的使用基础设施,容器云从立项之初就考虑到了这一点,容器云平台有一套完整的对外Restful API,可供上层应用,甚至外部应用调用.

保证构建容器云的过程能够正确的进行,还需要一些原则,”Build once,Run anywhere”,一个Docker镜像要贯穿QA到生产环境的每个环节,不允许QA和生产的镜像出现不一致的情况.”All in one”,对于Java Web应用,由于历史原因,可能多个Web App运行在同一个Tomcat中,要求每个Docker镜像中只运行一个Web App.

以应用为中心,是我们最重要的原则,也是建设容器云的出发点,这个原则确保我们关注的重点是应用,而不是进行计算资源的抽象和资源的调度,我们的理想目标是,在“优雅地“管理应用的整个生命周期同时,顺便做好资源抽象,提高资源的利用率.

分层治理,基础设施的治理由容器云完成,上层应用的治理由应用治理层负责,从SaaS,到PaaS,再到CaaS,分层治理,各层通过接口相互调用,层与层之间互不侵入.

以Kubernetes为中心构建容器云

容器云的目标决定了我们面对的是应用的管理,即应用对应的Docker容器的管理,这就要求我们要以Kubernetes为中心构建容器云,而不是以Docker为中心.Docker只作为应用打包、传递、运行时的工具,所有的API都要面向Kubernetes进行设计.

容器云要实现高可用的基础设施,能够支持多个数据中心.对于应用,要有多维度的高可用保证,要贯通部署流水线,通过CI/CD实现快速交付,容器云的建设肩负的额外目标是要为未来2~4年的技术发展做铺垫,为应用的CloudNative改造和整个技术团队的DevOps实践奠定基础.

（编辑：ASP站长网）