简介

Kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes 提供了应用部署，规划，更新，维护的一种机制。

Kubernetes 一个核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着（比如用户想让 apache 一直运行，用户不需要关心怎么去做，Kubernetes 会自动去监控，然后去重启，新建，总之，让 apache 一直提供服务），管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes 也系统提升工具以及人性化方面，让用户能够方便的部署自己的应用（就像 canary deployments）。

现在 Kubernetes 着重于不间断的服务状态（比如 web 服务器或者缓存服务器）和原生云平台应用（Nosql）, 在不久的将来会支持各种生产云平台中的各种服务，例如，分批，工作流，以及传统数据库。

在 Kubenetes 中，所有的容器均在 Pod 中运行, 一个 Pod 可以承载一个或者多个相关的容器，在后边的案例中，同一个 Pod 中的容器会部署在同一个物理机器上并且能够共享资源。一个 Pod 也可以包含 O 个或者多个磁盘卷组（volumes）, 这些卷组将会以目录的形式提供给一个容器，或者被所有 Pod 中的容器共享，对于用户创建的每个 Pod, 系统会自动选择那个健康并且有足够容量的机器，然后创建类似容器的容器, 当容器创建失败的时候，容器会被 node agent 自动的重启, 这个 node agent 叫 kubelet, 但是，如果是 Pod 失败或者机器，它不会自动的转移并且启动，除非用户定义了 replication controller。

用户可以自己创建并管理 Pod,Kubernetes 将这些操作简化为两个操作：基于相同的 Pod 配置文件部署多个 Pod 复制品；创建可替代的 Pod 当一个 Pod 挂了或者机器挂了的时候。而 Kubernetes API 中负责来重新启动，迁移等行为的部分叫做“replication controller”，它根据一个模板生成了一个 Pod, 然后系统就根据用户的需求创建了许多冗余，这些冗余的 Pod 组成了一个整个应用，或者服务，或者服务中的一层。一旦一个 Pod 被创建，系统就会不停的监控 Pod 的健康情况以及 Pod 所在主机的健康情况，如果这个 Pod 因为软件原因挂掉了或者所在的机器挂掉了，replication controller 会自动在一个健康的机器上创建一个一摸一样的 Pod, 来维持原来的 Pod 冗余状态不变，一个应用的多个 Pod 可以共享一个机器。

我们经常需要选中一组 Pod，例如，我们要限制一组 Pod 的某些操作，或者查询某组 Pod 的状态，作为 Kubernetes 的基本机制，用户可以给 Kubernetes Api 中的任何对象贴上一组 key:value 的标签，然后，我们就可以通过标签来选择一组相关的 Kubernetes Api 对象，然后去执行一些特定的操作，每个资源额外拥有一组（很多） keys 和 values, 然后外部的工具可以使用这些 keys 和 vlues 值进行对象的检索，这些 Map 叫做 annotations（注释）。

Kubernetes 支持一种特殊的网络模型，Kubernetes 创建了一个地址空间，并且不动态的分配端口，它可以允许用户选择任何想使用的端口，为了实现这个功能，它为每个 Pod 分配 IP 地址。

现代互联网应用一般都会包含多层服务构成，比如 web 前台空间与用来存储键值对的内存服务器以及对应的存储服务，为了更好的服务于这样的架构，Kubernetes 提供了服务的抽象，并提供了固定的 IP 地址和 DNS 名称，而这些与一系列 Pod 进行动态关联，这些都通过之前提到的标签进行关联，所以我们可以关联任何我们想关联的 Pod，当一个 Pod 中的容器访问这个地址的时候，这个请求会被转发到本地代理（kube proxy）, 每台机器上均有一个本地代理，然后被转发到相应的后端容器。Kubernetes 通过一种轮训机制选择相应的后端容器，这些动态的 Pod 被替换的时候,Kube proxy 时刻追踪着，所以，服务的 IP 地址（dns 名称），从来不变。

所有 Kubernetes 中的资源，比如 Pod, 都通过一个叫 URI 的东西来区分，这个 URI 有一个 UID,URI 的重要组成部分是：对象的类型（比如 pod），对象的名字，对象的命名空间，对于特殊的对象类型，在同一个命名空间内，所有的名字都是不同的，在对象只提供名称，不提供命名空间的情况下，这种情况是假定是默认的命名空间。UID 是时间和空间上的唯一。
起源

大规模容器集群管理工具，从 Borg 到 Kubernetes

在 Docker 作为高级容器引擎快速发展的同时，Google 也开始将自身在容器技术及集群方面的积累贡献出来。在 Google 内部，容器技术已经应用了很多年，Borg 系统运行管理着成千上万的容器应用，在它的支持下，无论是谷歌搜索、Gmail 还是谷歌地图，可以轻而易举地从庞大的数据中心中获取技术资源来支撑服务运行。

Borg 是集群的管理器，在它的系统中，运行着众多集群，而每个集群可由成千上万的服务器联接组成，Borg 每时每刻都在处理来自众多应用程序所提交的成百上千的 Job, 对这些 Job 进行接收、调度、启动、停止、重启和监控。正如 Borg 论文中所说，Borg 提供了 3 大好处:

1）隐藏资源管理和错误处理，用户仅需要关注应用的开发。

2) 服务高可用、高可靠。

3) 可将负载运行在由成千上万的机器联合而成的集群中。

作为 Google 的竞争技术优势，Borg 理所当然的被视为商业秘密隐藏起来，但当 Tiwtter 的工程师精心打造出属于自己的 Borg 系统（Mesos）时， Google 也审时度势地推出了来源于自身技术理论的新的开源工具。

2014 年 6 月，谷歌云计算专家埃里克·布鲁尔（Eric Brewer）在旧金山的发布会为这款新的开源工具揭牌，它的名字 Kubernetes 在希腊语中意思是船长或领航员，这也恰好与它在容器集群管理中的作用吻合，即作为装载了集装箱（Container）的众多货船的指挥者，负担着全局调度和运行监控的职责。

虽然 Google 推出 Kubernetes 的目的之一是推广其周边的计算引擎（Google Compute Engine）和谷歌应用引擎（Google App Engine）。但 Kubernetes 的出现能让更多的互联网企业可以享受到连接众多计算机成为集群资源池的好处。

Kubernetes 对计算资源进行了更高层次的抽象，通过将容器进行细致的组合，将最终的应用服务交给用户。Kubernetes 在模型建立之初就考虑了容器跨机连接的要求，支持多种网络解决方案，同时在 Service 层次构建集群范围的 SDN 网络。其目的是将服务发现和负载均衡放置到容器可达的范围，这种透明的方式便利了各个服务间的通信，并为微服务架构的实践提供了平台基础。而在 Pod 层次上，作为 Kubernetes 可操作的最小对象，其特征更是对微服务架构的原生支持。

Kubernetes 项目来源于 Borg，可以说是集结了 Borg 设计思想的精华，并且吸收了 Borg 系统中的经验和教训。

Kubernetes 作为容器集群管理工具，于 2015 年 7 月 22 日迭代到 v 1.0 并正式对外公布，这意味着这个开源容器编排系统可以正式在生产环境使用。与此同时，谷歌联合 Linux 基金会及其他合作伙伴共同成立了 CNCF 基金会 (Cloud Native Computing Foundation)，并将 Kuberentes 作为首个编入 CNCF 管理体系的开源项目，助力容器技术生态的发展进步。Kubernetes 项目凝结了 Google 过去十年间在生产环境的经验和教训，从 Borg 的多任务 Alloc 资源块到 Kubernetes 的多副本 Pod，从 Borg 的 Cell 集群管理，到 Kubernetes 设计理念中的联邦集群，在 Docker 等高级引擎带动容器技术兴起和大众化的同时，为容器集群管理提供独了到见解和新思路。