本文讲的是Kubernetes：过去、现在与未来【编者的话】本文讨论了Kubernetes的过去、现在和将来，包括了Kubernetes的优点和缺点等等。
有些人将自动化、云计算和人工智能称为第四次工业革命。IT行业中自动化的日渐兴起也就不足为奇，尤其是在应用程序部署与管理方面（我保证这绝不是吹嘘）。几年前，Google宣布启动一个名为Kubernetes的项目，即大家所熟知的K8s。Kubernetes是一个开源的容器集群管理器，其目标是成为容器应用程序自主部署与扩展平台。
Kubernetes简史
Kubernetes出自希腊语“helmsman”，由Google于2014年公布。它由Joe Beda、Brendan Burns及Craig McLuckie创建。Kubernetes v1.0于2015年7月21日正式发布，并立即作为云原生计算基金会（Cloud Native Computing Foundation）的一部分捐赠给了Linux基金会。
容器的兴起
在说明Kubernetes的兴起之前，很重要的一点是要理解如果没有容器，Kubernetes将不复存在。从高层次看，容器与虚拟机类似，不过一个主要差异在于：容器与其他容器共享宿主机的内核。之所以说它是主要差异因素，是因为容器共享物理主机的操作系统，这使得它们易于迁移。同时，一台宿主机能容纳的容器比虚拟机多得多，因为它们共享了内核、库文件及二进制文件。举个例子，一个虚拟机可能会占用20GB，而一个运行相同应用程序的容器可能只占用200MB。
容器（不论是Docker或是CoreOS的rkt）让开发人员可以无缝地专注于运行时的应用程序。敏捷应用程序开发过程中碰到凌乱的基础设施问题的日子一去不复返。使用容器，开发人员只需要考虑如何正确地扩展、部署及管理新写的应用程序即可。不过，现有的容器方案自身还不能进行跨多节点环境的容器管理、调度和部署。
Kubernetes应运而生
Kubernetes在容器环境中是作为该环境的管理与部署引擎而存在的。使用最基本的Kubernetes就可以在物理硬件或虚拟机上调度和运行应用程序。Kubernetes的更高级用法让开发人员得以从以宿主机为中心的世界中脱身，进入一个以容器为中心的环境。
Kubernetes的工作原理
Kubernetes的入门很简单。有一个REST API用于操作Kubernetes内部的主要组件。虽然Kubernetes被称为一个平台，但它具有多个组件服务于自身特有的角色。Master是Kubernetes集群的控制服务（它也被称之为控制平面）。Master非常重要，因为对那些与它交互的组件来说它起着API调用的作用。它位于主服务器内，这是集群单元规则生效及调度服务存在的所在。
Kubernetes工作单元
在主服务器之下是Kubernetes工作单元，它们定义了相关实体编程所要实现的指定工作。虽然最终目标是交付一个应用程序，这些单元还是拥有更具体的功能。
Pod：最基本的单元是一个pod，在分配容器时，它实际上并不会被分配到物理硬件上，而是被分配到一个pod上。Pod通常包含了基础容器或提供单一应用程序的容器。这意味着一个pod里的所有容器可以共享数据卷和IP空间，从而作为一个单一应用程序进行扩展。
服务：一旦开始构建一个更加强健的容器化策略，“服务”的概念就变得很重要。服务作为资源均衡器，可在容器之间做切换。后端容器可通过一个单一的、稳定的入口与前端应用程序通信。这项功能为用户提供了易用性和可扩展性。
复制控制器（Replication Controller，简称RC）：这些单元的任务是确保在任何时间点都有指定数量的容器启动及运行。假如出现内核错误，一个容器（或一组容器）崩溃，RC会负责启动一个复制的pod，直到原pod重新启动上线。一旦原pod再次启动并运行，RC将杀掉复制的pod。
标签：尽管标签不是一个真正的工作单元，但对组织而言却至关重要。标签用作组的名称，让用户可以设定一个单元组作为目标或进行操作。让你可以组织你的容器环境。
在最基本的层面上，这些就是组成Kubernetes平台的实体。
虚拟化类比
想想如今大家熟知的一项技术，让我们从虚拟化的视角来说明Kubernetes。Kubernetes里的Master类似于VMware里的vCenter。Master知晓集群的节点以及节点的容量。此外，Master调度和放置Pod与vCenter将虚拟机部署到vSphere宿主机相类似。Pod的作用与vApp非常相近，它们都是将多个容器放置在一个扁平化的网络里。容器与VM类似，除非被赋予了网络中定义的路径，它们相互之间是独立的。最后，复制控制器与HA类似，RC会持续对环境轮询以确保正确数量的pod处于运行状态，如果数量短缺，它将调度一个新的实例。
Kubernetes的优点
Kubernetes并不是市面上唯一的容器管理平台（其他如Docker Swarm或Mesos），但它是行业首选。为何会这样？从一个高层次角度看，Kubernetes吸引人的一点是它提供了一个平台，实现容器化应用程序的一次编写并在各类型云基础设施上运行。它将公有云与私有云之间存在的复杂的基础设施差异抽象化掉了。并且，Kubernetes下一步将允许开发人员运行任何他们觉得适合在Kubernetes运行的应用程序。Box的合伙人Sam Ghods相信只要一个二进制文件可以运行，那它就能在Kubernetes里运行。
使用Kubernetes，开发人员可以快速地部署应用程序而无须面对传统平台所具有的风险（想象一下跨多操作系统环境的横向扩展）、动态地扩展应用程序以及更佳的资源分配。
硬件使用率的下降也是企业推动Kubernetes的另外一个原因。有些公司报告说，由于容器的轻量特性以及（相比传统架构）更快速杀掉未使用的实体，对硬件的需求降低了40-50%。EBay是Kubernetes著名的支持者及用户，它声称在转换到该平台后服务器的开销支出急剧减少。
最后，Kubernetes的一个最大的优势是它面向的是社区而不是一个技术规范，这让它的功能更加强大。Google将其作为一个开源项目发布，获得超过1千个社区贡献者及3万4千个提交的支持。其社区比Mesos（第二大的竞争社区）要大5倍，比所有竞争社区加起来还大。
Kubernetes的缺点
Kubernetes赢得了行业的广泛赞誉，不过也存在一些显著的缺点。当涉及初始部署时（扩展时），据说要进行正确地设置会很复杂和困难。它需要一个具有特定技能组的工程师，而这在如今的工程行业很难找到。
另外，Kubernetes是容器的第三方管理系统。容器技术自身存在的缺点和痛苦的成长经历对Kubernetes能提供的服务也存在影响。
Kubernetes缺少的一个领域是调度器。Kubernetes默认的规化器依赖于应用程序属主提供的资源分配需求，而无视实时的消耗。这一做法将在每个节点上产生资源碎片。
最后，容器内允许运行的负载范围将限制Kubernetes的普及，不过这是一个Kubernetes无法直接解决的问题。举个例子，很多工程师对在容器中运行“关键性任务”负载会比较犹豫，一是因为其崩溃的倾向，二是因为容器设计之初就不打算用于存储数据。一个通常做法是只在容器中运行那些崩溃时不会造成停机时间的应用程序。
即便存在这些缺点，也不妨碍像高盛、Box、SAP及纽约时报这类公司将该平台列为下一代数据中心计划的一部分。
Kubernetes的未来
应用程序已经成为当今多数企业不可或缺的部分。所有公司对更快的部署及高质量的应用程序提出了更高的要求。这些要求也是开发人员涌向容器的原因。随着容器的爆发，若要说Kubernetes对其市场定位不佳的话那是不明智的。这个平台具有很大的潜力，但上了规模就变得难以管理。Kubernetes初始设置与其在生产环境中大规模运行之间存在着巨大的鸿沟。未来几年，在管理这些部署和负载方面，它将面临第三方强有力的竞争。对Kubernetes而言，不要迷失在过去成就它的因素之中将显得格外重要。如果其社区能正确地扩展该平台，Kubernetes的未来一片文明。
原文链接：Kubernetes: Its Past, Present & Future（翻译：梁晓勇）
原文发布时间为：2017-01-13
本文作者：梁晓勇
原文标题：Kubernetes：过去、现在与未来