在深入研究Kubernetes之前，要认识到如果没有容器的出现，Kubernetes也不会存在。从高层看，容器看上去像虚拟机，但是最大的区别是容器和其他容器共享主机系统的内核。这是最主要的差异要素，因为容器共享物理主机的OS，所以它们很容易移动。用户也可以在同一台主机上启动比VM数量多得多的容器，因为它们共享内核，库和二进制文件。比如，一个VM的大小大概是20GB，而运行着相同应用程序的容器大概只有200MB。

使用Kubernetes很容易。可以使用REST API来操作Kubernetes所包含的主要组件 。Kubernetes的定位是平台，但是它包含多个组件，每个都有各自的角色。Master是Kubernetes集群里的控制服务（也称为control plane），Master很重要，因为它会API调用和其交互的其他组件。集群单元管理发生在Master里，调度服务也在这里。

Master之下就是Kubernetes工作单元，这里定义特定工作的实体。既然最终目标是要交付一个应用程序，那么这些单元还有更多其他的特定功能。

Pod：最基础的单元是Pod，当指派容器时，容器实际上并不会指派到物理硬件上，相反，容器会被分配到一个Pod里。Pod通常负责托管服务于单个应用程序的容器。这意味着Pod内的所有容器都能够共享卷和IP空间，允许它们扩展为单个应用程序。

Service（服务）：如果想要构建更为稳健的容器化策略，那么“服务”的概念就更加重要。服务的功能是资源均衡器，将工作负载在容器间导流。这使得后台容器可以通过单一稳定的接入点和前端应用程序通信。这个特性让使用者更易于使用并且可扩展。

Replication Controller（副本控制器）：这些单元的目的是确保在某个时间点，有所需数量的特定容器在运行。比如说突然某个内核出错了，导致某个容器（多个容器组内的）崩溃了，那么RC的责任是新启动一个副本Pod，直至之前的Pod在重启后恢复为止。一旦之前的Pod启动并且再次运行了，RC就会杀死副本Pod。

在最基础的级别上，这些是组成Kubernetes平台的实体。

想一想我们现在都很熟悉的技术，通过虚拟化类比一下Kubernetes。

虽然Kubernetes并不是市场里唯一的容器管理平台（还有Docker Swarm和Mesos），但是它更受欢迎。为什么呢？从高层看，Kubernetes正获得关注，因为它提供了这样一个平台，容器化的应用程序可以只编写一次，就能够在所有类型的云供应商以及私有云上运行，无论底层使用的是哪种基础架构。而且，Kubernetes还在发展，让开发人员能够在Kubernetes上运行任意适合的应用程序。Sam Ghods，Box的联合创始人认为只要是能运行的二进制文件，就可以运行在Kubernetes上。

使用Kubernetes，开发人员可以快速部署应用程序，而无需担心传统平台上的诸多风险（想想跨多OS环境的垂直扩展），可以随时扩展应用程序，并且更好地分配资源。

硬件使用量的下降是使用Kubernetes带来的另一个好处。一些公司报告由于容器的轻量天性，以及能够快速杀死不需要的实体（和传统架构相比），硬件使用量减少了40-50%。eBay是Kubernetes的支持者和用户，声称自从他们切换了平台之后，看到了服务器上overhead的急剧降低[1]。

Kubernetes受到了广泛的称赞，但是它也有一些缺点。当第一次使用它做部署（大规模）时，它很复杂，并且很难搭建。它要求具有特定技能的工程师，在现在的行业里可能很难找到。

第二，Kubernetes作为容器的第三方管理系统。容器技术本身的缺陷和成长之痛会影响到Kubernetes所能够提供的服务。

Kubernetes欠缺的领域是调度器。默认的Kubernetes调度器依赖于应用程序所有者提供的分配资源的需求，而不管实时使用量。这个方案会加重每个节点上的资源分片情况。

最后，能够在容器里运行的工作负载范围将影响Kubernetes的广泛使用，但是这并非Kubernetes可以直接解决的问题。比如，很多工程师还不想把“核心”工作负载放到容器里，因为它可能会崩溃，而容器从设计上就不是为了存储数据的。常见的实践是只在容器里运行那些崩溃后也不会导致下线时间的应用程序。

相关链接：

1. https://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/