通过三个概念看 Kubernetes 的另一面
之前对容器圈一直不太感冒，一直以传统 VM 的角度去思考容器的作用和使用，在最近的交流中发现还是有较大的误区。正好 Ceph 社区要在容器世界里占坑，作者就存储在容器世界里的作用和使用方式做了一番深入了解，认为容器的使用的确是一种新的的 IT 架构方式，不敢说是不是下一代，但是绝对是另一个颠覆。简单说它就是以应用为中心的生产模式，这里容器这个词的本身(LXC, Solaris Zone, FreeBSD Jail) 不是核心，核心是围绕 Image 产生的应用打包和部署方式。而 LXC 这类 Namespace 技术带来的高速、简洁并不是容器技术的杀手锏，实际上利用 kvm/xen 这类虚拟化技术经过一定优化仍然能达到较快的启动速度，比如 DVM。
在容器的生态圈里，Docker 的确是名副其实的始祖，贡献了 Docker Image 这套基础，而后面的 CoreOS，Redhat 的 Atomic 作为 Host OS 提供了较好的容器环境，最后 Kubernetes 和 Mesos 以及更多的集群管理添上了最后一环。如果是仅仅这样的体系可能感觉只是一套新的轮子罢了，通过对 Kubernetes 的设计理解结合本人对云的认识，感觉”容器”是一个非常好的云平台基石。本文就跳过对容器技术的基本介绍，简单列出 Kubernetes 的概念，然后详述 Kubernetes 在现在云背景下的角色和能力。
Kubernetes 基础
Kubernetes 是 Google 开源的容器集群管理平台，用于应用的部署、维护和扩展。Google 内部一直是容器技术的重度使用者，Kubernetes 是一套经过多年容器技术使用和管理而重新设计及实现的项目。因此，在其中我们可以得到非常多 Google 对于容器技术的理解和使用。首先 Kubernetes 定义了几个非常重要的概念:
Pod: 一组 Container 实例加上共享目录的组合。因为一个应用服务往往有多个进程组成，容器化往往要求细粒度，因此一个服务往往可能由多个容器组成，细粒度又造成服务内部的松耦合带来的不便，因此 Pod 为这类困难提出了解决方案，单个 Pod 内多类资源可见，这个约束条件使得一个 Pod 内所有容器只能存在通一个 Host 上。
复制控制器: 管理 Pod 的生命周期，确保足够的 Pod 存在于集群内来保证应用和高可用需求。
服务: 其实就是用来标识一组 Pod 的地址，换句话就是负载均衡，但实际上它额外引申出的能力才是 Kubernetes 的核心。
以上三个概念是 Kubernetes 的主要承载，下面我们看看 Kubernetes 有哪些在目前云时代的亮点。
Kubernetes 服务
我们知道在应用生产环境，在对外服务往往是需要地址的，而负载均衡实际上就承担了大部分的服务注册并分发作用。因此，Kubernetes 服务就是一个负载均衡，而实现是每一个 Node 上都有有一个 proxy 进程，通过对注册服务对象的检测，动态在 Node 上绑定新的 IP:Port 地址，完成对于一组 Pod 的连接，因为一组 Pod 实际上是有一个固定(User defined) 的 IP:Port，而 Proxy 会在 Node 上随机分配一个 IP:Port 然后与 Pod 的相关联。这样解决了应用间可能的地址冲突问题。第二方面也在这一层实现了负载均衡的逻辑 Policy。
这时，我们可以注意到 Kubernetes 作为一个管理框架将自己的服务嵌入到了数据流中，这是最大的差异。大部分管理框架往往将自己定位在控制器，的确能减少对于性能和复杂度的影响，但是大大减小了其活动空间，Kubernetes 实现的负载均衡可能不能在大规模平台中承受压力，实际上它不也是这么用的。
这时候我们需要引入另外一个背景，在目前的公有云、私有云和混合云的分类下，对于云基础设施之上的颠覆性变化实际上只能发生在私有云，一个厂商的公有云是无法改变用户的架构，更谈不上整个应用平台。那么 Google 在公有云追不上 AWS 的情况下推出了一个完全以社区方式运作开发的项目实际上是意味深远的(之前这样的项目就是 Andriod 和 Chromium)。Google 仍然希望能在用户端撬动变革来改变 VM 中心化这个现实，那么 GCE 作为这个变革的云端产物，自然能四两拨千斤的改变公有云的格局。
回到 Kubernetes 本身，传统 IAAS 以 VM 为核心作为一个物理服务器的兼容，在灵活的应用业务变迁上存在一定无力。如果在涉及到私有云和混合云甚至不同云平台之间的联合，方案会非常复杂，这也是其 VM 本质决定了。那么 Kubernetes 最重要的事情就是打通不同平台、集群和利旧。因此这里的服务就充当了本地应用平台的边缘，不管是将本地应用拓展到云端，还是云端业务利用传统负载均衡分发到本地，又或者是传统应用在保持不变的情况下与 Kubernetes 打通。这些方式都是以应用为中心的方案，而不是传统的 VM 的业务迁移。
另外，云平台的多集群设计实际上是以 vm 为中心的应用多集群很难在基础设施平台做到的，Kubernetes 这里的多集群仍然跟传统 VM 方式思路不同，不仅仅是控制层面的联合，也是业务应用层面的联合。在业务的多集群化上解决本地区域 Overflow 问题，实际上也是混合云最核心的问题。本地私有云在大部分情况下都只会存储核心甚至机密数据，跟远端云平台或者跟业务需要相比都有一定差距，另外多集群对于避免 vendor lockin 也有极大帮助，因此最重要的就是实现跨集群的调度策略、location affinity、服务发现和自动迁移问题。
Kubernetes 存储
目前 Kubernetes 以 Docker 作为计算运行后端的情况下，存储方案以只能基于 LXC 的实现，也就是共享目录的方式。但是 Kubernetes 比原生 Docker 已经迈进了一步，它在原有的 EmptyDir(默认的读写目录) 和 HostDir(readonly)情况下，增加了对 NFS、iSCSI、GlusterFS 的支持。另外 GCE 和块存储和 AWS 的 EBS 也在支持之列。实际上 Kubernetes 在具备集群 Host 管理上也用于更大的存储释放空间，比如 Docker 使用 NAT 方式方式 iSCSI Target 使得网络会成为瓶颈，而 Kubernetes 采用 Host 端挂载的方式。
图来自参考[6]
而 Ceph RBD 和 CephFS 后端目前也在 Review 过程中，相信较短时间内就可以被 Merge 到主线，而 CephFS 作为 Ceph 的 Posix 接口实际上被寄予了厚望，在容器方案中文件接口实际上比块接口更合适，在强调业务无缝迁移、整合、扩张的实现上，一个没有语意的块接口面临很大的局限性。因此，CephFS 纳入 Kubernetes 并成为继 OpenStack & RBD 之后的另一个强力组合也理所当然成为 Ceph 社区的目标。另一方面，容器的 LXC 技术在文件接口上的优势就在于在 Host 端完成了 Automount，而传统 VM 在 mount 自动化上有很大的难处。
小结
在 Kubernetes 试图改变应用架构本身的努力上仍然有许多路要走，目前聚焦的是简单但常用的 Web server，缓存服务，应用服务等等，一些核心的数据库服务、大数据处理服务仍然需要一定时间去解决。
本文简单介绍了 Kubernetes 在脱离传统 VM 的思路下如何将容器技术真正作为用户转身云平台的利器，其完全脱离传统云对于控制层面的掌握，加强了数据层面的介入，并利用以应用为中心的镜像机制实现了更强的云平台基础设施能力。
如果本文对于容器或者 Kubernetes 的理解有误还请多多指正!
参考
Kubernetes(https://github.com/GoogleCloudPlatform/kubernetes)
Kubernetes Service(https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/services.md)
Kubernetes Ceph RBD Driver(https://github.com/GoogleCloudPlatform/kubernetes/pull/6578)
Kubernetes Storage(https://github.com/GoogleCloudPlatform/kubernetes/issues/5129)
Kubernetes CephFS Driver(https://github.com/GoogleCloudPlatform/kubernetes/pull/6649)