Docker 与 K8s 在企业基础设施服务的应用

转载本文需注明出处：EAII企业架构创新研究院（微信号：eaworld），违者必究。如需加入微信群参与微课堂、架构设计与讨论直播请直接回复此公众号：“加群 姓名 公司 职位 微信号”。

『发送关键字“Docker”至此公众号，获取完整PPT下载』

大家好，本次内容我在我司上个月的PWorld大会上分享过，线下会议参与人数有限，这次应邀在微信上向更广泛的人群分享，同时也加入了我近期的一些新想法，不仅仅是上次分享的重复。

一、新时代——即基于容器的云时代的来临。

下面出场的是容器时代的两大主角——Docker和Kubernetes，未来相当长的时间里，容器时代的种种爱恨情仇，都将在这两大主角之间展开。

 

先看下Docker：

Docker刚刚三岁半，虽出身草莽，但早已显露王者风范，据说Docker开源之后，很多VMware的老员工就开始找工作了~

 

再来看下Kubernetes：

Kubernetes不到两岁半，系出名门，脱胎于Google Borg，出道以来吊打各路高手，俨然一位不可一世的富二代！

 

面世不过两三年的开源项目，就取得了如此广泛的关注度和实际应用，回顾历史，这样的项目屈指可数，那么这种状况的原因又是什么呢？或者说，他们带来了哪些独特的价值呢？

 

在很多技术资料里，在提到容器的价值的时候，都会出现如下两张图：左边是拿容器和虚拟机的层次结构做对比，说容器是个分层更少、更加轻量的虚拟化工具；右边是拿容器和虚拟机的性能做对比，说容器是个性能更好的虚拟化工具。

那么容器的价值就仅仅是轻量和高性能吗？这显然很不充分，因为容器相对虚拟机的性能提升，最多也就是百分之几十的样子，在IT界，不带来十倍以上的性能提升，是很难被赋予颠覆者地位的。仅仅百分之几十的提升，会迅速被摩尔定律抹平，长期看不值一提。

 

那么容器的最大价值到底是什么？为了说明这个问题，我们来回顾下基础设施层多年以来的苦苦挣扎~

二、提升抽象层级是基础设施的宿命

 

不知道各位有没有了解过OASIS指定的TOSCA规范，一个面向云应用拓扑和编排的规范，这个规范的工作已经开始了五年多，我本人也是委员，之前的规范工作主要围绕虚拟机展开，看下这页PPT的左图，TOSCA通过Node Type描述节点（这里可以简单的认为就是一个虚拟机镜像）的属性和对外接口，通过Relationship Type描述描述节点之间的关系，通过Plan描述部署流程等等……这些共同组成了一个Service Template。

我在这里提这个五年前出现的规范的目的是：在这一波容器浪潮出现之前，业界就已经在如何利用虚拟机更好的管理应用的问题上探索多年了。

 

就好像一个运维人员，不会满足仅仅维护一下服务器，会希望往上层走，创造更大的价值一样~

 

之前业界也出现过一些基于类似理念的商业产品。

 

比如Oracle的Virtual Assembly Builder：

比如VMware的vRealize Automation：

这些产品都能利用虚拟机很方便的编排出一些典型的应用拓扑。

可是却很少有人用，我想群里的大部分朋友可能都没用过。

 

原因是什么呢？

这张图我在之前的PPT里也出现过，又放在这里的意思是：

 

中间2013年的这种多层架构，相对比较简单，使用脚本部署就已经比较高效了，很少有企业会因为这个事情去采购昂贵的商业软件，而且这些商业软件也没有为部署之外的运维流程带来太多的便捷性。

 

右边2016年的这种分布式架构，是现阶段的趋势，这种架构给部署和运维都带来了极大的困难，这些昂贵的商业软件也无从处理。

 

我想这就是原因和尴尬之处吧！

所以说，天堂向左，虚机向右，通过虚拟机来解决分布式系统的部署和运维问题，已经被业界的多年努力验证为此路不通，而这些挤压已久的需求，在容器上找到了突破口。

 

这就是容器最核心的价值。

 

三、Docker和Kubernetes实现基础设施的多年梦想

我们来看一下Docker和Kubernetes如何实现基础设施的多年梦想。

Docker，真正的实现了Infrastructure as Code，Infrastructure as Code作为一个Buzz Word已被炒作了多年，以前只是Infrastructure提供一些API，供上层调用，可是仅仅提供了API，还不能说是Code，Code是可以Compile、可以Link的，而Docker实现了这些。

把Docker编译好、链接好的镜像发布到Kubernetes的集群里，Kubernetes就接管了应用的大部分运维工作，kubernetes会负责处理应用的高可用和自动伸缩，对应用的任何一次变更，小到修改一个参数，大到一次全面的升级，都会被Kubernetes纳入版本控制，就像管理代码一样~

 

可以看到，Docker和Kubernetes联手解决了分布式系统运维的大量问题，但是这远远不是问题的全部。

 

如果基于Docker和Kubernetes打造一个DevOps平台，还面临着很多问题：

四、我们的进一步工作

现有的开发、集成、测试、运维工具大多为单体应用设计，难以处理微服务带来的复杂度。

 

所以我们针对这个问题升级了我们原有的产品。

我们使用元数据治理产品对微服务进行全生命周期的管理，使整个研发和交付流程更加顺畅。

我们开发了全新的工作空间，降低了团队间的协作成本。

我们还做了很多很多，这里不一一列举，总而言之，我们通过精益运营建立了一个数字化企业云平台。

说到这里，各位有没有觉得，基于容器的云平台有一种发展方向，就是成为一个更全面的应用服务器，这里的更全面指支持大规模集群环境、更多类型的应用、并更加完整的覆盖软件的生命周期。

 

但是我们这几年经常听到这句话：

应用服务器已死。

 

举例来说，基于JAVA的应用服务器，有资源隔离差（JVM缺乏CPU、内存、IO的资源控制能力）、与应用紧耦合（应用服务器需要为应用做出针对性的配置）、依赖管理能力弱（库版本冲突、只能管理Java世界的依赖）、持续集成/部署困难（应用服务器无法参与持续集成、部署应用服务器本身比部署应用复杂的多）等诸多问题，而这些问题在分布式、碎片化的软件环境下，变得日趋严重，所以传统的应用服务器面临了快速的衰败。

 

但是这些问题总要有个新平台去解决，只是目前旧王已死，新王未立。

 

在上一页PPT中我们可以看到，容器镜像就像一个包含了运行环境依赖的WAR包，基于容器的云平台也将提供类似消息引擎、JNDI、安全服务、Workload管理、Job管理等能力，而且这些能力将为更多类型的软件提供服务。

 

最后我们畅想一下未来：

如果像Gartner所说，未来所有的公司都将是IT公司，那么必然不是每个公司都像现在的大型互联网公司一样，在IT的各个技术领域雇佣大量的专业人员，一些共性的需求必将剥离出来，由专门的公司提供解决方案，历史是螺旋上升的，社会分工将被再次重建。

今天的分享就到这里，谢谢大家！

欢迎扫描二维码加入宋潇男所在的“普元云计算架构设计群”，讨论更多关于Docker 、K8S等相关技术内容，加群暗号“云计算”。

关于作者：

宋潇男

EAII-企业架构创新研究院 专家委员

现任普元云计算架构师，曾任华为云计算产品技术总监。曾负责国家电网第一代云资源管理平台以及中国银联基于OpenStack的金融云的技术方案、架构设计和技术原型工作。

关于EAII

EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，致力于软件架构创新与实践，加速企业数字化转型。

eaworld项目（微信号：eaworld，长按二维码关注）

eaworld是EAII的官方微信账号。