1 Kubernetes是什么？

在单台机器上，Docker容器技术解决了：

• 通过Docker镜像解决了应用如何部署、部署环境如何准备和配置、应用部署件如何分发；
• Docker创建、启停容器解决了在机器的本地环境下应用启停、参数传递、应用的管理能力

那么Kubernetes技术解决了什么问题呢？

• **容器集群的集中管理：**通过ssh免登录的能力，以及docker技术管理单机上的容器，实现在成百上千台机器上进行容器集群的集中管理；
• **智能运维：**为应用在容器集群上以智能、自动、无人工干预的形式提供了资源调度、部署运行、服务发现、扩容及缩容等一整套功能：
  • **容器的调度：**某个应用应该部署在哪一类节点上？节点上是否只能（或不能）部署某些应用？
  • **多副本、负载均衡：**怎么为应用部署多个副本？副本个数是否可以横向自动伸缩？自动伸缩之后，负载均衡的设置是否需要调整？
  • **容器的状态检测：**容器是活动还是僵死？容器是否可用？如果容器不可用之后，怎么办？
  • **节点管理：**如何增加/下线某些节点？下线节点时，其上面原本正在运行的容器应该怎么停止服务？如果某个节点突然崩溃，上面有哪些正在运行的应用呢？需要花多长时间才能使所有相关服务恢复正常？
  • **操作系统层面、Kubernetes层面的节点升级：**成百上千台机器上如何实现节点升级？如何实现应用持续服务的前提下，实现节点升级？
  • 上述这些常规的机房运维的日常工作，本质上均与一个具体的应用是什么无关的，而且这些日常运维工作量大、重复性强、可以发生在7*24的任何时刻，而且日常运维还在企业SLA考核的严格管理之下。上述这些梦魇般的日常运维，完全被Kubernetes解决方案全部以智能、自动、无人工干预的形式被完美地解决了。
• **开放的部署平台：**本质上Kubernetes是IT运维层面的解决方案，对于应用的具体功能是什么、应用是以什么语言开发均是无关的，而且对现有的编程语言、编程框架、中间件没有任何侵入性，因此现有的应用系统均可以非常地容易改造升级并部署到Kubernetes平台上。

简而言之，Kubernetes是一个完备的分布式系统支撑平台：

• Kubernetes具有完备的集群管理能力：
  • 多层次的安全防护和准入机制；
  • 多租户应用支撑能力；
  • 透明的服务注册和服务发现机制；
  • 内建的智能负载均衡器；
  • 强大的故障发现和自我修复能力；
  • 服务滚动升级和在线扩容能力；
  • 可扩展的资源自动调度机制；
  • 细粒度、多层次的资源配额管理能力。
• 同时，Kubernetes提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控、日志查看在内的各个环节。

因此，Kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

2 Kubernetes的资源节省

自从2015年Google将Kubernetes贡献给开源社区之后，Kubernetes一鸣惊人，迅速称霸容器领域。在国内外众多大型科技企业中的Kubernetes实践中，慢慢总结出：Kubenetes+Docker一起的容器平台能节省30%～70%的资源。那么，如此大幅度的资源节省，背后有什么样的魔法呢？其实，这些节省是Docker技术和Kubernetes技术合二为一的结果。

2.1 源自于Docker技术的资源节省

**Docker不需要Guest OS所直接节省下来的大量CPU和内存资源：**在3.2章节中已经阐述，相比于Docker容器，每个虚拟机均有其独享的操作系统。每一个运行态的操作系统均是要额外占用1G～2G的内存和CPU；但在Docker容器技术中，容器直接共享宿主机的操作系统的内核，无论一个宿主机上有多少容器在运行，均不需要额外的操作系统。很显然，由于Docker这一共享操作系统特性，直接带来巨大的内存和CPU节省。

相比虚拟机，Docker在存储方面有两三个数量级的节省：

• 每一个虚拟机，由于含有一个独立的操作系统，其大小经常是几十G～几百G；而Docker容器的大小经常是几十M～几百M。
• 又由于Docker容器的分层设计思想，每一层均可以在不同的容器复用，因而多个容器下载到同一个宿主机上后，其实际总大小会由于可复用的容器层的设计而进一步减少。但虚拟机镜像就没有这方面的设计，任何一个虚拟机的镜像与其他虚拟机的镜像是完全独立没有任何复用关系。

Docker资源额度的设置vs虚拟机的资源硬占用：

• Docker容器启动时，均会为其设置CPU和内存的最大可用量，但极大多数情况下一个容器真正实际所使用到的CPU和内存远远小于最大设定值。这就如同JVM一样：最大堆栈总是要设置，但JVM真正是高位（CPU和内存）运行的时间非常之短暂。
• 这样一来，运行在同一个宿主机上的所有容器的内存和CPU资源总和，是可以大幅度超过宿主机的总资源。
• 但虚拟机一旦启动，其所分派的内存和CPU资源会被足额占用并从宿主机中可用资源中扣除；并且在虚拟机运行过程中，对于宿主机来说，被虚拟机所占用的这些资源一直保持不变，无论虚拟机本身的资源利用率是如何。

由于这种资源占用的不同设计，直接导致Docker容器化体系中有非常高的资源利用率。整体而言，运行同样多的应用，哪怕忽略有无操作系统的差异，Docker容器化体系中所需要的总硬件资源也小很多。

2.2 源自于Kubernetes智能调度的资源节省

真正的资源节省，主要是由于Docker容器技术所带来的，但Kubernetes智能调度也带来了一定的资源节省，虽然这种节省不是这么明显和直接。

**Kubernetes的横向自动伸缩所带来的资源节省：**对于一个特定的应用，Kubernetes会根据该应用的所有副本的总使用情况（比如平均CPU利用率），而对副本的个数进行自动伸缩。而企业中，总是有一部分应用很忙，而另外一部分很闲；过了一段时间，这个忙闲的关系又反转过来。鉴于这种忙闲交错的特点，Kubernetes的横向自动伸缩，就可以使得更少的硬件承担更多的应用。

**Kubernetes的大集群、共享buffer池所带来的节省：**Kubernetes中资源池是跨节点、跨应用的共享，而无需确保每个节点上、或每个应用均有一定比例的buffer资源以便应对业务繁忙。哪怕只是两个应用之间，也不大可能有完全相同的忙闲时段，自然而然，Kubernetes集群就可以维护一个略小的buffer资源池。但在虚拟机环境下，为应用A准备的buffer资源是无法为应用B所使用。

**Docker隔离+Kubernetes智能调度所带来的节省：**原本在同一个节点中部署而相冲突的多个应用（比如对SeLinux有不同的要求），在Docker容器隔离技术下，在同一个宿主机进行部署成为可能；而Kubernetes的智能调度能力，进一步确保这个可能变成现实发生。

3 Kubernetes+CICD：业务敏捷交付、敏捷迭代

Kubernetes不仅是对于数据中心有着难以拒绝的吸引力，对于应用（应用项目开发团队、应用业务方）也意味着全自动的敏捷交付、敏捷迭代。

Kubernetes全部操作均是基于配置文件，使得端到端地全自动部署成为可能；下面这张图阐述了当开发人员或者部署人员提交了特定代码之后，就会自动触发完整的CICD流程，并在几分钟之内就完成。

同时Docker整体镜像的设计中包含了操作系统层面的环境配置、应用层面的基础环境配置，确保了无论该镜像在什么环境（测试环境、生产环境）运行，均是同一套代码运行在同样的环境配置之中。

简而言之，Docker镜像的分发策略、Kubernetes全配置文件的操作模式，使得业务敏捷交付、敏捷迭代非常容易实现。

4 Kubernetes的前世今生和挑战

4.1 Kubernetes的前世

Kubernetes是一个全新的容器集群管理方案，虽然其直到2015年才正式开源，但它是谷歌十几年以来大规模应用容器技术的经验积累和升华的重要成果：

• Kubernetes是谷歌严格保密十几年的秘密武器--Borg的一个开源版本。
• Borg是谷歌的一个久负盛名的内部使用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。
• 十几年以来，谷歌一直通过Borg系统管理着数量庞大的应用程序集群。
• 直到2015年4月，传闻许久的Borg论文伴随Kubernetes的高调宣传被谷歌首次公开，大家才得以了解它的更多内幕。

正是由于站在Borg这个前辈的肩膀上，汲取了Borg过去十年间的经验与教训，所以Kubernetes一经开源就一鸣惊人，并迅速称霸容器领域。

4.2 Kubernetes的今生

在过去几年中，IT大玩家，如Docker、Google、CoreOS、RedHat、OpenStack、VMWare、IBM、Oracle等，纵横捭阖、合纵连横，主导下一代数据中心的相关主要技术路线终于完善、明确下来了：

• 基于虚拟机技术为代表的系统形态；
• 基于Docker容器技术为代表的应用形态；
• 软件定义网络
• 软件定义存储

如今，IT界将Kubernetes看作Docker的上层架构，而Kubernetes则以Docker为基础打造了一个云计算时代的全新分布式系统架构。

4.3 Kubernetes的挑战

无论是Docker容器技术还是Kubernetes容器集群集中管理技术，均是近十年才出现的技术。虽然自面世以来，就一鸣惊人、广受认可；但不可否认的是，作为一门新技术也遇上了许多挑战：

• **缺乏专业人才：**新技术、新思想多，涉及到的运维范围广且技术深，整个IT界均极度缺乏掌握相关内部经验和专业知识的人才。
• **固有的复杂性和陡峭的学xi曲线增大推广的难度：**任何一个新技术的出现和推广，均需要时间自我证明、让人熟悉和接受，Kubernetes也不例外。除此之外，较小的公司缺乏成功管理Kubernetes技术的运营专业知识和资源，较大的企业也面临着“新技术与遗留基础架构、现有系统整合”工作量大、风险高等困难。
• 安全、存储和网络是最大的技术技术挑战/困难：
  • 相较于广泛关注的网络攻击，IT 人员最为担心的也还是错误配置所造成的风险。Kubernetes 是高度可定制的，具有可以影响应用程序安全状态的各种配置选项。因此，如何在Kubernetes环境中正确配置容器，规避风险的同时又能让容器能按设计运行，是一项很有技术挑战的工作。
  • 存算分离的架构，使得Kubernetes只能采用网络存储。相比于本地存储，网络存储除了带来性能的损耗之外，还会面临网络传输带来的波动、不稳定性等新问题。
  • Kubernetes集群内是基于由软件定义的虚拟网络，而Kubernetes集群外是传统意义上的真实网络，分属两个不同的网络技术，Kubernetes集群内外通讯不光需要专门配置，还会面临性能损耗。

然而尽管有着新技术带来的许多挑战，但Kubernetes独特价值：智能运维带来的运维高质量和高效率、资源利用率提高带来的资源节省、可全面推广的CICD方案带给业务的敏捷交付、敏捷迭代，已为市场所认可。随着Kubernetes技术本身的持续迭代、以及整个IT界的技术进步，目前Kubernetes推广所面临的挑战也必然会获得缓解或解决。