深度解析容器云之Kubernetes 应用与实践

　　今天和大家分享的内容就是青云QingCloud 推出的容器云服务以及基于 Kubernetes 的应用与实践。

　　容器技术目前的市场现状是一家独大、百花齐放。容器的解决方案非常多，以 Docker 为首占据了大部分的市场，此外还有各种解决方案如 Rocket、Mesos Universal container、LXC、Hyper Container 等。

　　各种容器的实现，容器的外延非常广范，用户选型时经常会迷惑，应该选择什么？大家讨论的时候容易产生分歧，因为大家都在说容器，但各自的角度不同，表达的具体内容也完全不一样。

　　一是从资源隔离的角度。容器技术经常被拿来跟虚拟化技术作对比，从技术角度来说，容器是一种跟 VM 类似的资源隔离技术，它比 VM 的资源损耗小，但隔离性和安全性不如 VM ，等等。

　　二是从应用封装的角度。Docker 之所以兴起，原因在于其重点关注应用的标准化，而不是资源的隔离。Docker 的镜像机制提供了一种更高级的通用的应用制品包，也就是大家说的集装箱能力。原来各种操作系统或编程语言都有各自己的制品机制，各自的依赖管理，制品库都不相同。应用从源码打包，分发到制品库，再部署到服务器，很难抽象出一种通用的流程和机制。

　　而有了 Docker 的镜像以及镜像仓库标准之后，这个流程终于可以标准化了。同时 Docker 将进程的管理，比如启动停止也标准化了。类似杯子、筐、集装箱都是容器，它们的共同特点是能把杂物打包，标准化，方便运输和定价。在此之上，容器可以做更高级的逻辑分装和调度。

　　从资源视角和应用视角分析一下青云QingCloud 提供的容器解决方案。

　　就资源视角来说，用户希望 VM 能像 Docker 一样，可对标准进程进行封装，使得 VM 也是一个完整的操作系统。为延续用户对 VM 的操作体验，青云QingCloud 在统一的 IaaS 平台上同时支持 VM（Virtual Machine 虚拟主机）与 CM（Container Machine 容器主机），使得用户对虚拟化的部署习惯得以沿袭，同时还可享受容器资源轻量隔离的特点。

　　为什么是 Kubernetes？我们做一个选择时，总有各种选择的理由。选择 Kubernetes 主要从这几个方面来看。

　　这不仅仅是 Kubernetes 本身的复杂性带来的困难，还因为众所周知的原因，国外某着名公司的服务在国内都无法访问，这可能是很多人试用 Kubernetes 的第一道坎。

　　微服务和容器，是当前服务架构领域最热门的技术。如果不谈微服务，都会感觉自己过时了。它的敏捷交付、伸缩等优势我不再多说，但微服务架构给我们带来最大的挑战是如何管理这么多服务。

　　原来人工编排的方式难以管理这么多微服务。如果你能管理，说明你的微服务不够多，拆分的还不够细、或是规模还不够大。在这种情况下，Kubernetes 本身提供的对服务规范的定义、Deployment 的滚动升级，以及 DNS 服务发现的支持，都非常好的支持了微服务，这是我们选择它的另一个理由。

　　IaaS 更关注于资源层面，而 Kubernetes 更关注应用层面，所以这两者的结合是互补的结果。

　　目前 QingCloud 已经支持用户一键部署 Kubernetes 集群，不仅解决了用户很大的痛点，同时也验证了 AppCenter 支持应用的广泛性。

　　接下来将会从容器调度系统的网络、数据本地存储的读取、容器平台与负载均衡器集成、实现 Kubernetes 应用的弹性伸缩能力以及集成服务五个方面跟大家介绍青云的 Kubernetes 应用，分享我们整个过程中做的事情，也让大家更容易在我们平台上使用 Kubernetes。

　　首先是网络。这应该是除部署外，大家使用 Kubernetes 时遇到的第二个槛。因为 Kubernetes 本身没有提供网络解决方案，它将这部分让渡给云平台或社区去解决。

　　这样用户使用时会面临在众多社区解决方案中进行选型，我们可以回顾一下。Docker 为了解决应用的网络端口冲突，给每个容器分配了一个 IP。当我们的容器只和本主机容器互通时，这没有问题，但我们想通过调度系统把多台主机的容器连接在一起，就会遇到网络问题。

　　这时我们实际上是需要有一层 SDN 来解决问题，大多开源容器网络的解决方案，基本是比较简易的 SDN。然后我们把这层网络方案部署到云时会发现，在云之上已经有了一层 SDN。这样在 SDN 上再做一层 SDN，性能损耗会非常大。

　　我们的容器主机在 SDN 优化下只有 10% 左右的损耗，我们的虚拟主机可能有 25% 多一点的损耗。但是在 SDN 上再做一次 Overlay，我们会把 75% 的性能都损耗掉。

　　所以，我们想既然 IaaS 有 SDN，为什么不能把它穿透上来，直接提供给容器使用？这就是青云的容器网络方案，叫做 SDN Passthrough，也就是容器可以和虚拟主机共享一层网络。我们基于 Kubernetes CNI 标准做了一个插件，并且在 GitHub 上进行了开源，如果大家想部署 Kubernetes 的时候，也可以使用。

　　解决网络后，服务已经可以跑起来了。但是我们想在容器里保存数据，就遇到存储的问题。

　　用过 Docker 的人可能都知道，使用 Docker 存储文件时，我们会映射主机目录到 Docker 容器里，然后把文件存在主机目录上。

　　但当我们在容器上面架一层调度系统后，调度系统会有各种各样的原因将容器迁移到其他主机上，而这种存储方案是无法支持迁移的。所以 Kubernetes 推出了自己的 Presistent Volume 标准。

　　但如 NFS、Ceph 等这分布式存储系统，他们最大的问题是依赖于网络，因此稳定性和性能会有一点问题。所以，我们把 IaaS 的存储硬盘映射成 Kubernetes 的持久化存储卷，当容器在我们的主机之间迁移，我们的存储卷也可以跟着迁移，解决容器状态数据存储迁移的问题。

　　目前已经支持性能盘和容量盘，未来也会支持 NeonSAN 分布式存储系统。当然，有人会问，如果我们用了青云的 Kubernetes，会不会导致我的应用本身迁移遇到问题，会不会绑定在上面，导致我无法在不同的 Kubernetes 发行版之间迁移。这个 Kubernetes 本身考虑到了，它提供的是存储卷声明的方式，也就是在 Image 中只是声明依赖多少存储，这个存储由谁来提供，应用不用关心，整个都是完全透明化的方式。

　　Kubernetes 本身的负载均衡器提供了一种插件，让云服务商实现插件和 IaaS 层整合。因为最终用户暴露的时候需要一个公网 IP，这个实现和各云厂商的服务是息息相关的，而 Kubernetes 自己比较难直接提供这样的服务，所以它就提供插件让云服务商去实现。

　　但是云厂商的负载均衡器只能感知到节点主机这一层，对主机里面的容器是无感的，所以大多数情况下只能把 Kubernetes 集群下所有的节点都挂载到 LoadBalancer之后。前面讲到 Service 时说到，Kubernetes 为每一个 Service 都在所有主机上监听一个随机的端口，也就是 NodePort，这个请求会转发到主机的随机端口上，由随机端口转发到 ClusterIP 上，再由 ClusterIP 转发到后面的容器，可以看出，这样就多了几层转发。

　　如果负载均衡器能感知到容器的网络，就可以直接透传请求到容器中。我们的负载均衡器后面直接挂在的是容器网卡，这样就省去了几层转发。同时我们的支持公网和私网两种 Load Balancer。因为一般不可能把所有的服务迁到 Kubernetes，有一部分迁进去了，有一部分服务可能在外面。这种情况下外部服务访问不了 Kubernetes  Service 的 Cluster IP 和 DNS ，这个时候需要私网的 Load Balancer 去转发这种请求。

　　Kubernetes 提供了本身一种机制，通过相应命令可自动增加 Pod 的节点数。但光有这一层伸缩是不够的，部署 Kubernetes 集群的时候，节点数是提前规划好的。当自动伸缩使Kubernetes容量达到上限的时候，就无法伸缩了。这个时候集群本身需要有自动伸缩的功能，当前只有谷歌云实现了集群的伸缩能力。

　　当 Kubernetes 集群的资源不够了，它会触发一个事件，IaaS 层监听这个事件，收到事件请求之后增加集群的节点。这样就实现了业务应用层的自动伸缩以及 Kubernetes 资源池的伸缩。

　　Kubernetes 本身提供一种扩展机制，可以把一些服务内置在里面。

　　我们现在主要内置了 DNS，主要用于微服务的应用发现。如果没有这种 DNS 服务发现，应用配置文件会跟具体资源相关联，比如数据库 IP，当我们的应用从不同环境迁移时，比如从测试环境迁移到生产环境，我们的配置是就会是异构的。而有 DNS 机制，配置文件就可以完全保持一致。

　　另外一个是 Kubernetes 本身的一个 Dashboard，还有日志与监控服务。这个服务从日志监控数据收集、存储、展示是一体化的，应用无须关心这些事情。