今天下午我分享的话题是基于Kubernetes构建企业级的容器云平台，整个分为三个大部分，首先我们简单对比容器和虚拟机两个之间的差异性，有一些特征，优势和劣势。第二我们看一下容器云平台在建构的时候需要面临哪些问题，第三可以看一下容器云平台的典型应用场景。
首先看一下容器和虚拟机的区别，这个图大家都是比较清楚。容器其实是对操作系统的封装，把所有的应用和它对应的运行时封装在一个容器里面，然后以快速的容器进行的方式发布上线应用，这是容器的主要作用。虚拟机是相反，它是相对于容器来说是更重量级的虚拟化技术，本身是对物理硬件的虚拟，把整个一套CBO、IO存储系统整个虚拟化出来，也有相应的应用软件在里面，这是容器和虚拟机两个最大的差异，一个是虚拟层级不一样，一个是在操作系统的虚拟，一个是对物理硬件的虚拟，这样所带来的差异就是说容器相对于虚拟机来讲更轻量级，密度可以更能让真正的硬件更好的发挥它的最大的资源利用率，这是它两者之间的一个差异。
从这边我们可以看到其实这个截图是来自于官方对容器的介绍页面，其实官方推荐我们对容器使用方式是说让容器和虚拟机在一起，就是说把容器运行在虚拟机之内，这样的话能让应用的部署和管理更加方便和高效。其实容器技术产生以后，真实的部署场景其实在国外是最先兴起的，但是国外大部分百分之八九十的容器都是在云平台上，所以说容器和虚拟机其实它更多的不是一个相互替代的技术，它更多的是两者之间结合来共同的为企业运行空间里面来支撑下一代的运营的基础设施。这个是官方推荐的容器和虚拟机的一个最佳的组合方式。
这边我们可以简单看一下跟容器相关的一个生态圈的情况。上午这个图已经见到了，这边我和大家简单再说一下。CNL是一个面向基金会的，他可以囊括的项目非常多，除了底层的基础架构这一层项目他不去管理之外，再往上包括移动、定义和部署这一层，这几层有非常多的优秀开源项目，这些开源项目一旦成熟了之后其实都有可能对他们进行内存管理。目前这个基金会托管项目一共有10个，这个都是相对比较多。运行时就是当前运行时在还是应用Docker来管理虚拟机和容器，从下一个版本开始，其实可能在一些里面运行时可能就会被代替COA，就是官方的标准容器。
接下来我们看一下为什么要把OpenStack和Kubernetes结合在一起来构建我们的容器的云平台。首先OpenStack跟Kubernetes两个为什么结合在一起？其实主要的一个原因就是说OpenStack它更多的是以基础资源作为中心，其实比较擅长的是管理数据中心里面的像网络设备、存储设备，各种交换机，其实更多比较擅长底层的基础设施。Kubernetes相反，它更多的专注于应用层的开发，以应用为中心，更多的是关注用户更快速的把这个应用从开发到部署上线，专注于创新型云原生应用的交付和管理。
我们把它们两者结合起来，就是说使两者之间1+1大于2，把两者之间优势互补，就是底层的基础设施管理交给OpenStack来做，上层的云原生应用的交付和管理来做，两者相互互补，加速应用交付，助力业务创新。这是OpenStack和Kubernetes融合的一个最大的理念，就是它们两者之间所擅长的时间并不一样，但是关注点各有不同。
接下来，我们会从OpenStack跟Kubernetes融合所具体的一些详细的结构来跟大家分享一下。
第一部分就是说OpenStack和Kubernetes云平台架构，最底层我们涉及到OpenStack和Kubernetes两者之间的融合，所以最底层是以OpenStack作为企业级的云平台，来管理里面的计算资源、网络资源、存储资源等等，把这些资源形成池化，池化之后再把这些已经虚拟化的资源交给一个核心的容器管理集群，这样我们可以在OpenStack所管理出来的虚拟机或者是物理机之上来创建我们的容器集群，这样就是说我们容器集群跟OpenStack这个环境是可以使用到统一到网络和统一的存储。统一的网络在后面我们也会细说，统一的网络就是说因为OpenStack网络组件是OA，Kubernetes里面对应的网络组件也有很多的解决方案，如果没有跟OpenStack这个平台融合，它的网络问题就是说在虚拟化再之上，再有一层OA网络，两层OA会带来网络系统的损失。
另外就是两者之间相当于是多层网络底层网络其实是一个黑盒，运维管理起来管理管理的话相对于比较复杂，所以我们让Neutron作为一个统一网络管理组件，这样把Neutron管理的这些原有的比如说企业级的硬件设备交换机，能很好的把网络能力传递给容器平台，能更好的让我们的容器应用用到这些传统的网络设备，这些网络设备的支持包括后面存储设备的支持，其实在容器生态领域是相对比较薄弱的环节，这是统一网络。
统一存储是说当前存储能力比较弱，没有像Cinder一样这么丰富的对接这么高端的商业存储，容器里面基本没有做到，很少有存储厂商再为Kubernetes对应一个存储。如果我们企业里面已经有商业化存储，已经有这样一个存储设备，同时我要把这个设备非常方便的给这个容器来用，这个时候基本上很难用到，我们把两者结合起来，用Cinder作为统一的整个大平台的管控中心，把存储能给虚拟化的应用来用，又能给容器来用，这个是OpenStack跟Kubernetes平台结合的一个最大的特点，相比于运行于裸机或者是运行在公有云上或者私有云平台上最大的一个亮点和特点，后面我们会有详细的片子来跟大家分享。再网上就是我们的企业级容器云平台包括镜像管理、持续集成、持续部署、应用管理、容器集群管理，后面有更详细的讲解，我们有统一的管理界面，然后也有统一的编排，还有统一的支持OpenStack虚拟化应用和统一应用中心，我们可以让整个云平台的租户管理、监控告警、日志管理都可以达到最高要求。企业级的OpenStack平台也是计算机资源管理、网络资源管理、存储资源管理。
这边是容器云平台功能模块，后面有更详细的我就不仔细讲了。然后我们可以看一下技术栈，OpenStack大家比较清楚。Kubernetes跟OpenStack的差别是Kubernetes本身它只是容器编排，并没有像OpenStack那么丰富，如果只用Kubernetes，其实你离把容器真正运用到生产上面还有很长的一段路要走，整个我们构建容器云平台的一个技术栈就是包括以Kubernetes为核心的一个容器调度和资源管理者的引擎。在核心的引擎之外我们集成了很多容器或者一些应用一些技术组件，比如我们采用Harbor作为容器镜像中心，目前还是采用Docker作为容器运行时，底层的SDN和SDS统一的用Neutron还有Cinder作为容器和OpenStack平台的统一存储和统一管理平台。最底层的容器操作系统主要是跑容器化的Kubernetes应有，可以更好更安全的来支撑容器化的应用。
再上面是功能模块，这个分为几大部分，DevOps、应用管理和运维管理，这个不详细说，下面会有详细介绍。这是功能模块所涉及到的一些技术栈。
然后这边是应用管理的方式，大家都知道Kubernetes里面应用管理的功能相对是比较弱的，它本身其实是没有一个应用管理的概念。现在是有像him应用商店应用管理在里面，但是应用商店如果你从开发到运维上线的过程来说，对于Kubernetes来说涉及到交付和迭代比较多，复杂度也是比较高多，这样的话我们是针对应用商店比较难以使用的情况，我们封装了一层简单的应用，这样为了让运维更加方便。第一我们可以从镜像仓库封装我们自己的应用来部署，同时支持编排模板，也就是说我们可以用可视化的方式把整个容器应用编排成一个模板，这样我们不需要更多的去编写，也就是说我们可以通过托代系统方式来交互和维护这种应用。同时我们可以在后续支持以应用商店的方式来交互我们的云应用，这是应用管理的一些在原生基础上的一些情况。
这是是Kubernetes的关键特性，这边列了几个点第一个Autoscaling是说我们可以设置一个预值，可以弹性的把这个应用进行伸缩。第二个灰度升级，就是我们应用如果上线比较频繁的话，我们可以采用滚动更新的方式让应用同时在不断线的情况下完全升级。服务发现是说我们如果把一个大的系统拆成一个小的移动的话，服务之间肯定要有一套完整的发言机制，因为容器的网络，容器的IP变化非常频繁，因为不停地会创建项目，这样就有一个比较完整的服务发现的机制，我们也是把Kube-DNS这一套插件引入到整个容器平台，为各种应用来提供服务方向的机制。
后面的ConfigMap比较好理解，就是配置管理，这种配置在容器应用里面也是通过对应的组件来管理应用。Secret也是涉及到比如数据库要提供给其他的应用来消费，这个时候你基本上是避免明文的传输，这个时候我们建立一个Secret来管理密码，这种东西主要是私秘的对象管理。健康检查就是一般容器如果规模上亿之后我们很难对容器做单个容器的一个管理，这个时候对容器的健康检查比较重要，也就是说我们可以在应用里面设置他健康检查点，可以设置比如容器的某一个端口，判断这个容器是不是在正常的提供服务，如果不正常的话，会把不健康的容器进行干掉，重新启动比较健康的容器。负载均衡就是说容器在负载运行，这个时候如果没有负载均衡的话。
另外故障自愈因为系统组件本身就是恢复化的管理。持久化存储就是说Kubernetes里面提供了一套持久化存储的机制，我们很容易把这些组件接入上来为Kubernetes容器化存储提供能力。集群高可用比较好理解。
接下来我们可以看一下拿OpenStack和Kubernetes平台两者结合在一起能解决一个问题就是它支持两层的弹性伸缩，我们知道如果仅仅是Kubernetes的话，它所涉及到的事情就是我们一旦是发现哪一个容器负载过高，我们可以把负个数量提升到3或者到5或者到10。如果我们对应的Kubernetes平台是运行在物理机上，峰值非常高的时候，所有的物理机负载压力都非常高，这个时候你想要扩一台物理机到容器里面去是非常困难的事情，如果把OpenStack加上Kubernetes融合在一起，因为OpenStack加上Kubernetes是非常快的，我们可以做到两层的弹性伸缩。
所以说第一级的时候如果容器本身它的压力负载过高我们可以对容器本身的应用本身维度进行弹性伸缩，这样的话整个平台变得非常灵活，能更好的来应对高并发的比如说618，或者天猫双十一都肯定需要这种双层弹性支撑，来突然的面对这种高并发压力。
这边可以看一下监控告警，因为Kubernetes本身内制有hmts，我们是把OpenStack加进来之后，监控告警相对比较完善。就是可以支持多维度的监控，包括容器，容器从大的方面就是包括容器维度，包括容器节点维度，包括整个集群的状态都可以监控到。到容器里面，其实对于容器的CPU内存，网络，其实都可以监控到，节点维度也是这样，它整个可以监控不仅仅是容器维度进行监控，同时在容器节点本身，如果CPU、内存处于压力锅大的话，也可以被监控工具来监控到。监控到之后可以通过我们提前设置的这些预值，如果达到这个预值之后，可以进行告警信息状态，同时让管理人及时发现整个系统的负载压力情况。同时告警信息可以对接企业里面的系统，比如通过邮件或者是短信的方式通知到运维人员来及时处理系统的高压情况，这个是监控报警的特性。
日志的搜集和存储的功能点，Kubernetes里面只能看到单个户的里面的容器，它并没有对容器日志进行归类，日志统一检索这些功能都没有。如果一旦把应用拆分了之后肯定涉及到很多应用同时在运行，如果我们只是单个来做其实并没有办法很好的帮我们定位和解决问题。这时候就需要有一个日志搜集和管理系统来帮我们管理这些问题，我们也是基于整个方案来实现这个日志搜集和管理的功能，这就是日志管理。
接下来看一下网络，前面我们提到网络其实是OpenStack和Kubernetes平台融合的时候最重要的一个特性之一。我们看到现在的容器网络方案存在的一些问题，从成熟度来讲与OpenStack中生产级别的Neutron网络相比，现有的容器网络解决方案，如Flannel、Veave等的成熟度还有一定欠缺，特别是国内容器刚刚兴起，大家普遍的大规模的使用还不是太多，如果用的话其实也是对容器现有的方案有一些改造，没有多少是直接用容器里面的某个方案的。所以从成熟度来说没有OpenStack这种平台成熟。
第二就是嵌套Overlay网络，性能损耗、延迟、管理、调试复杂度。这个是现有容器一些问题，我们采用Neutron统一管理容器平台和OpenStack平台的网络，网络架构扁平化实现容器与容器之间，以及容器与虚拟机之间的直连，引入高级网络特性，可将Neutron的高级特性引入容器网络中，诸如安全组、FloatingIP、QoS、LBaaS、FWaaS、VPNaaS等，来更好的管理容器的网络。这边是容器网络的一些存在的问题和我们的一些优势。
这边是具体的容器网络和OpenStack网络两者之间的一个交汇架构。它最大的思路就是说我们以Kuryr作为控制器，这个时候Kuryr对应的从Neutron这边对应Port、Network，这样的话就是达到OpenStack和Kubernetes两者之间的网络组件的流通。
我们接下来再看一下Neutron LB作为容器外部负载均衡器，Neutron
LB作为容器集群外部负载均衡器支持L4/L7层负载均衡、支持应用会话保持、自动键控隔离不可用节点、支持资源池动态扩缩。
这个是OpenStack和Kubernetes结合非常重要的一个优势，或者说我们可以把企业里面已经有的开源式分布式存储，或者是第三方双向存储，比如说EMC的存储设备，IEM的存储设备，这些存储设备在QoS里面没有很好的驱动去管理的，把OpenStack平台引进进来之后，就可以利用丰富的移动存储进行虚拟化，再把这个存储提供给容器化的应用，这边是两者之间融合存储的一个优势。
另外可以看一下多租户隔离问题，在OpenStack里面多租户隔离特性增强容器安全隔离性，每个OpenStack租户可单独创建并管理Kubernetes集群。也就是说我们的应用是很容易的就能相互干扰，我们利用OpenStack和Kubernetes的特性，每个租户里面都有一个容器集群，这样的话能针对同一个业务，让每一个业务能避免相互之间的干扰。
最后一部分可以看一下典型的应用场景，这个可能大家也比较熟悉。第一个就是说像6·18，双十一高流量，同时有比较大峰值的波动的话，通常比较适合这种轻量级的产品。像京东，大家也可以看到京东的分享。这边就是很好的支持微服务的改造，这个也是组大的一个使用场景。最后一个收益就是说我们除了这个容器，我们融合架构可以带来异构平台统一管理、资源统一调度、提升安全性，这个是我们所带来的一些优势。今天的分享就到这边，谢谢大家！
|
