FIT2CLOUD徐桂林：容器云之Kubernetes应用与实践-软件开发

Docker运行GUI软件的方法

微信群分享之后，11月4日晚，我们CSDN Container技术交流群又邀请到FIT2CLOUD负责公司的技术布道师徐桂林，他深入分享了容器云之Kubernetes应用与实践。

讲师简介：徐桂林，当前在FIT2CLOUD负责公司的技术布道和生态合作。在此之前先后供职于意法半导体、Autodesk和阿里云。徐桂林热衷于云计算（尤其是公有云IaaS平台），有过多年云计算生产环境工作经历，是较早在国内分享云计算实践经验的作者之一。

以下为演讲实录

首先，让我们从容器、容器云开始今天的分享。从去年年初开始，以

    Docker为代表的容器技术快速火起来，以至于今天大家基本把容器等同于Docker（这次分享，我们姑且也这么“等于”一下）估计大家都听了很多Docker相关的分享、介绍，甚至都已经在生产上用上了Docker，所以这里我就不展开说Docker的细节。

但是，不同的人对于Docker带来的价值还有不同理解。我们认为Docker主要提供了两个方面重要价值：一个轻量级、可独立调度的运行环境以及一个标准的镜像模型。

如果观察现在容器相关的技术和产品基本也对应到这两点上。一部分容器技术与产品关注使用Docker来简化运行环境管理，打通从代码到容器镜像的整条链路。另一部分则关注如何更好的管理和编排容器运行时环境，让容器真正能够达到服务高可用、强弹性的业务场景。当然，还有连接两者的Docker Registry。

作为落地容器技术的一个重要产品方向就是“容器云”。一般来说，一个完整的容器云需要包括以上说到的三方面产品（镜像发布、镜像仓库和容器编排）。

说到“容器云”，就必然要联系到另一个云，即基础设施云（IaaS）。那这两者之间到底是什么关系？一般认为，“容器云”是一种特化（技术路线上）的平台云（PaaS），按照云计算普遍采纳的三层架构，其应该在IaaS之上。这也是我们今天要表达的第一个观点：我们认为只有运行在IaaS平台上的“容器云”才能够算真正意义上的容器云。直接运行在物理机以及虚拟化环境上的“容器云”则缺少底层基础设施弹***付的能力，并不能拥有“云”最核心的优势：弹***付，按需付费。当然，IaaS平台提供的丰富基础设施服务也为容器云的运营带来很多价值。例如，IaaS 提供的云磁盘，云存储可以作为 Kubernetes 中 pod 的存储的一个选择。区别于宿主机硬盘，云磁盘在数据可靠性要好非常多。  

类似与IaaS，容器云也可以有公有容器云、托管容器云或者私有容器云之分。但是无论那种形态，我们都认为其应该运行在某种IaaS层之上（可以是公有IaaS云：如青云），也可以是私有IaaS云（如OpenStack）。

在说完我们对于容器、容器云以及它和IaaS之间的关系后，这次分享重点想沟通关于容器编排这方面的工作。前面提到的另外两个容器方面工作（镜像发布、镜像仓库）我们也会很快涉及，不过今天就不展开讲了。

在容器编排和调度方面，主要需要解决的问题可以分成两类：一是承载容器运行的集群管理（包括，集群节点管理、服务负载均衡管理、名字服务管理、请求转发等），另外就是进行任务调度和资源管理（包括资源分配、容器伸缩、容错处理等）。

现在，最主流的容器编排和调度系统有三个分支：Cloud Foundry、Mesos和今天要讲的Kubernetes。在这三类中，Cloud Foundry和Mesos是在Docker之前就已经为大家所知，而Kubernetes则是由Google于去年六月开源出来的全新项目。目前，这三个项目在支持Docker编排调度上都还在快速发展阶段，到完全成型或者成熟阶段可能还要一点时间。但，在这三者之中我们非常看好Kubernetes未来的发展潜力。不过究其原因来看还真不仅仅是技术上的考量，具体如下：

1）Kubernetes是由Google发起并主导的项目，而Google应该是这个世界上最懂得容器运行的公司，Kubernetes就是参考、借鉴Google内部运营Brog的十几年经验设计而来的（具体细节可以参考Google今年发布的Brog论文）。

2）Kubernetes这个项目上Google是投入了重兵。如分布式系统设计中的基础性理论--CAP--的提出者Eric

    Brewer就是Kubernetes项目中的重要决策人。另外，Google的云战略在其公司整体战略的重要性已经大幅提高。而Google在BigTable上吃过亏：作为NoSQL的最早实践者，由于未亲自上阵，使得Hbase成为了事实上的工业标准，等Google Cloud自己需要开放NoSQL服务时还得支持他们认为设计并不好的HBase接口。所以，这次在容器编排调度上不希望再次重复同样的故事，决定亲自上阵。同时，基于Kubernetes的Google Container Service服务也是Google云有可能弯道超车AWS的一个机会。

3）Kubernetes的另外一位大玩家就是Redhat。至于是Google主动邀请Redhat加入，还是Redhat主动要求加入这一点我无从得知。但是，最终Redhat是全情投入了。下图就是Kubernetes过去一年多Contribution的公司分布，其中Google和Redhat是绝对的主力。

Redhat现在是把Kubernetes作为其下一代PaaS云平台（OpenShift）的核心组件。最近发布的OpenShift V3主打的就是基于Kubernetes的容器云平台。

在过去一年多时间里，Kubernetes项目的活跃度非常好。根据Github项目首页显示，其提交次数超过两万次。超过一万次的Star也说明其在社区上的关注度也是非常高的。

说了这么多关于Kubernetes的好话，那我们来看看其具体能力吧。这里直接引用Kubernetes官方文档的总结。从用户角度看，Kubernetes能带给用户的包括：

●  在线的应用伸缩能力；

●  无缝的应用更新能力；

●  充分的资源利用能力；

顺便插开一句，如果把这三点对应到IaaS平台带给用户的核心价值，你会发现他们竟然非常一致（只是在不同层面来提供这些能力）。优秀的IaaS平台（尤其是公有IaaS平台）提供的服务一定需要做到“强弹性”、“热升级”和“高资源利用率”。强弹性需要靠庞大的资源池保证，热升级需要优秀的设计架构和强大的运维能力保证，高资源利用率则是公有云最终能否赚钱的核心能力。所以，从这个角度看，Kubernetes的设计目标就是为大规模运营容器云所准备的，也是Google有勇气使用其作为Google Container Service服务的原因所在。

为达到上面这些能力，我们看Kubernetes是如何设计架构。首先，Kubernetes整个架构图如下：

Kuberenetes是典型的Master-Slave架构，其中包括如下这些关键组件：

● 

Cluster：Kubernetes维护一个集群，Docker的containers都运行其上。并且，这个集群可以运维在任何云及Bare Metal物理机上。

● 

Master：Master节点包含apiserver，controller-manager，sheduler等核心组件（常常也将etcd部署于其中）。

● 

Node：Kubernetes采用Master-Slaves方式部署，单独一台Slave机器称为一个Node（以前叫

Minion）。

● 

Pods：Kubernetes最小管理单位，用于控制创建、重启、伸缩一组功能相近，共享磁盘的Docker容器。虽然Pod可以单独创建使用，但是推荐通过Replication Controller管理。

● 

Replication controllers(RC)：管理其下控制的Pods的生命周期，保证指定数量（replicas）的Pods正常运行。

● 

Service：可用作服务发现，类似于Loadbalancer，通过Selectors为一组Pods提供对外的接口。

● 

Labels：K/V键值对，用来标记Kubernetes组件的类别关系（例如标记一组Pods是frontServices，另一组是backServices）。Labels对于Kubernetes的伸缩调度非常重要。

Pod是Kubernetes中的核心观念，它提供了一种管理Docker实例的新结构，把一组功能接近、需要相互直接通讯和共享磁盘的Docker实例组合起来管理，而Kubernetes的调度机制也是基于pod，完成整个应用的弹性伸缩能力。

Kubernetes在设计上可以适配各种基础设施形态。但是，如前所述，我们认为IaaS平台才是部署Kubernetes集群的最理想环境。在国内多个公有云IaaS环境内，我们选择了青云作为Kubernetes入门实践的环境，这其中的原因包括：

● 

从安全角度看，类似Kubernetes这类的PaaS应该是部署在VPC内。青云VPC在国内是独树一帜，特别适合用来部署Kubernetes这种分布式应用。

● 

从部署管理角度看，青云提供的“userdata”和“metadata”功能在自动初始化云主机上非常有用，可以简化整个部署过程。

● 

从成本和灵活性角度看，青云的按秒计费，资源快速响应是非常有吸引力的。这点以我们自身为例：一年多以来我们已经在青云上面创建了超过1万五千台虚机，花费仅在1000多。

从前面关于Kubernetes集群的介绍可以了解到，整个集群部署还是有不少的工作量，尤其是需要完整的发挥出来Kubernetes+IaaS带来的弹性伸缩能力，并提供广泛的日常宿主机管理功能。所以，我们使用FIT2CLOUD来管理Kubernetes集群下面使用的IaaS平台资源，并在其上完成集群的自动化部署，统一监控，Kuberenetes集群自身升级等工作。

从目标用户视角看，Kubernetes集群(容器云)的使用者是应用开发人员，或者准确的讲是基于Docker容器的微服务开发者，而FIT2CLOUD和QingCloud的使用者是Kubernetes集群（容器云）运维和系统管理员。下图描述了Kubernetes、QingCloud、FIT2CLOUD三者及其使用者之间的关系：

如果你对于整个部署和实践的过程非常感兴趣，可以参考我们的在线博客文章：。按照其中的详细介绍一步步完成整个过程。整个实践过程只需要拥有青云公有云帐号并开通FIT2CLOUD在线版就可以完成，尝试门槛非常低。

可能会有不少了解Kubernetes的人会奇怪为啥使用FIT2CLOUD在青云上部署一个Kuberenetes这么“复杂”。尽管现在是做一个Kuberenetes入门实践的演示，但是我们仍然希望能够完整的展示在IaaS平台上运行Kuberenetes集群需要涉及的很多方面工作（尤其是和IaaS平台在弹性伸缩能力的打通、对于日常运维Kuberenetes集群的支撑、自动化部署集群的需求等方面）。例如，在我们示例的结尾就会演示kubernetes集群在遇到突发高负载的情况下如何借助FIT2CLOUD自动向IaaS请求更多资源，自动完成部署操作，自动加入集群并承载溢出负载的场景。这个场景再次说明了Kubernetes运行在IaaS平台上的重要性，同时也展示了FIT2CLOUD在粘合IaaS层和容器云PaaS层的作用。

当然，这个例子也说明了FIT2CLOUD在以kubernetes为代表的容器云技术栈中的定位。具体如下图所示：

这也是我们今天要表达的第二个观点：我们认为在IaaS和PaaS容器云之间还需要一层Management

& Enabling平台，而FIT2CLOUD则就是定位于这一层平台。

当然，目前的示例还是有一些明显的不足之处需要改进。主要包括如下两点：

1）当前的Kubernetes集群仍然是单Master节点，并且保存所有集群状态信息的etcd也是部署在该台Master节点上。这个还需要等待Kubernetes能够在Master的HA上解决问题才能够搞定。目前这个已经在Proposal阶段

2）当前部署方式仍然对于Master和Slave节点的顺序关系有要求（需要先启动Master节点，再启动Slave节点）。

在这个入门实践中，IaaS层管理以及Kubernetes集群自身的部署、运维工作都可以通过FIT2CLOUD控制台完成。但是对于Kubernetes自身的管理工作还是离不开Kubernetes的命令行工具：kubectl。大家可以到Kubernetes官网下载、安装该命令行工具，从而可以远程操作Kubernetes集群。当然，FIT2CLOUD也提供执行脚本的能力，通过其直接在Kuberenetes的Master节点（该节点已经被FIT2CLOUD管理）执行kubectl命令，完成相关管理操作。

最后，总结一下本次分享，包括如下几个部分：

1） 首先介绍了容器、容器云以及和IaaS的关系，提出我们关于容器云的第一个观点，即只有运行在IaaS之上的容器云才是真正意义上的容器云。

2）其次说明我们在容器编排和调度技术选型方面的观点，认为kubernetes未来会有很大发展潜力。

3）然后介绍了Kubernetes的基本架构，功能特征等方面知识，方便大家对其有基本了解。

4）最后介绍了如何利用FIT2CLOUD在青云上快速部署Kubernetes集群，并阐述了我们的第二个观点：在IaaS和容器云PaaS之间仍然需要一层，而FIT2CLOUD则定位于此。

QA

问：微软的windows server 2016称支持docker，这对容器生态圈有何影响 ？ 另外，我是先接触的容器，再接触的kvm，我感觉容器比KVM弱很多，特别是KVM技术引领了芯片的设计和优化很多年。所以 我想问一下，docker未来与KVM是什么个关系？

徐桂林：这个影响短时间不会太大。但是其潜在影响会慢慢出来，即使在今天，服务端基于Windows堆栈的市场占有率任然》30%，Windows支持Docker是其在服务端市场自救的一个重要举措，让Windows用户有继续留下来的理由。但是需要注意Microsoft公司策略在新CEO上台后有很大变化。最明显的就是“Windows Azure” 命名成为“Microsoft Azure”，这其中滋味相信大家都懂的。

我这里补充一点：很多人一听Docker运行在IaaS的VM中觉得很奇怪，Docker诞生的时候不是说要解决VM虚拟化过重的问题嘛，怎么又跑到VM内部Run了。首先，无论是KVM，还是其他虚拟化技术。它的业务价值在于解决计算资源灵活交付的问题。而Docker为代表的容器技术到目前还没有办法达到KVM级别的资源交付能力，更多是定位在资源调度和利用层。就如我前面所述，我们认为未来相当长的时间内，两者仍然会各自为阵。及KVM完成资源虚拟化交付给Docker为主的容器云充分使用