閱讀本文約花費: 11 (分鐘)

英文链接：https://en.wikipedia.org/wiki/Kubernetes

Kubernetes（通常写成“k8s”）是最开始由google设计开发最后贡献给Cloud Native Computing Foundation的开源容器集群管理项目。它的设计目标是在主机集群之间提供一个能够自动化部署、可拓展、应用容器可运营的平台。Kubernetes通常结合docker容器工具工作，并且整合多个运行着docker容器的主机集群。

历史

Kubernetes（ 来自希腊语κυβερνήτης:，意思为 “操舵员” 或者 “飞行员”）由Joe Beda, Brendan Burns 和Craig McLuckie建立，并在2014年被google公司首次对外公布。它的发展和设计受到google的Borg系统的严重影响。Kubernetes项目的许多主要贡献者来自Borg项目。在Google内部Kubernetes最开始的名字叫Serven of Nine，引用了电影“星际迷航”中通常被认为“更加友好”的“博格人”这个角色。由于google律师的反对，它的名字被重命名为Kubernetes。从Kubernetes的logo上面那车轮上的七个幅条就能在一定程度上推断出Kubernets最开始的名字是什么。

2015年七月21日Kubernetes发布了v1.0版本。随着Kubernetes v1.0版本的发布，Google和Linux基金会合作成立Cloud Native Computing Foundation（CNCF）并提议使Kubernetes成为种子技术。

Kubernetes还被RedHat使用于OpenShift产品。

设计

Kubernetes定义了一套堆积木，这些堆积木统一提供部署、维护和扩展应用的机制。构成Kubernetes的这些组件让Kubernetes变得一个松耦合可延伸的，因此它能满足各种不同的工作负载。Kubernetes的延展性在很大程度上是由Kubernetes的API提供的，这些API被运行在Kubernetes的内部组件、延伸组件和容器使用。

Pods（豆荚）

Kubernetes中的基本调度单位叫“pod”。它增加了更高层的抽象来容纳各种组件。一个pod由一个或者多个容器组成，这些容器能够部署在同一台物理主机上面，并能够共享资源。Kubernetes中集群内部的每一个pod被指定了唯一的IP地址，用户程序可以通过相应的端口号无冲突地连接各个pod。pod能够定义一个卷（volume），比如一个本地磁盘目录或者一个网络磁盘，然后把它暴露给pod中的容器。用户可以通过Kubernetes API手动管理pod，或者把管理工作交给一个管理器。

标签和选择器

Kubernetes可以让客户端（用户或者内部组件）把被称之为标签的键值对依附在系统的任何API对象上，比如pods和“nodes”。相应地，”标签选择器”是针对标签的查询，这些标签用于解决匹配对象问题。

标签和选择器是Kubernetes中的主要分组机制，用来决定哪个操作应用于哪个组件。

比如，如果一个应用的pod有一个系统标签为：tier (“front-end“, “back-end“,) 和 release_track (“canary“, “production“)， 然后所有 “back-end” 和”canary“节点 上的操作都可以使用如下所示的标签选择器：

tier=back-end AND release_track=canary

控制器

一个控制器是一个调节回路，通过管理一系列pod来驱动实际的集群状态变成所需的集群状态。一种控制器叫”复制控制器“，通过运行指定数目的跨集群的pod副本来进行复制和扩展操作。如果底层的节点失败了，它还能处理和创建用于替换的pod。其他的控制器是核心Kubernetes系统的一部分，包括一个运行在所有机器（或者所有机器的一些子集）但恰好一个pod上的”DaemonSet“控制器，以及一个运行pod直到结束的”Job“控制器（比如，作为批作业的一部分）。控制器所管理的那一系列pod由定义在控制器里的部分标签选择器决定。

服务

一个Kubernetes服务是一系列工作在一起的pod，比如多层应用中其中的一层。这一系列pod构成了由标签选择器所定义的一个服务。Kubernetes提供了服务发现和请求路由的功能。请求路由是通过分配固定IP地址和DNS名字给服务。默认的，一个服务会在一个集群内暴露（比如，后台的pod会被分到一个服务中，来自前端的pods负载平衡他们之间的请求），但是，它也可以在一个集群外暴露（比如，为客户端访问前端的pod）。

架构

Kubernetes采用了主从架构。Kubernetes的组件可以被分为那些管理单个节点和那些控制平面（control plane）的部分。

Kubernetes控制平面（plane）

Kubernetes的master主要是在不同系统之间负责管理工作负载和指导通信的控制单元。Kubernetes的控制平面由不同的组件组成，它们自己的进程可以运行在一个单独的master节点上，或者运行在由多个master所支持的高可用集群中。Kubernetes控制平面的不同组件如下所示：

etcd

etcd 是一个由CoreOS开发的轻量级的、分布式的key-value数据存储器。它能够可靠地存储集群的配置数据和展现整个集群在某一时间点的状态。其他的组件监视着这个存储器的变化情况以便更新所需的状态。

API server

API Server是一个关键组件，它在HTTP协议上使用JSON为Kubernetes对内外提供kubernetes API服务。API server处理和验证REST请求和更新etcd中API对象的状态，因此，这使得客户端能够在各个worker节点上配置工作负载和容器。

Scheduler

Scheduler是一个可插拔的组件，它能够根据资源的可用性决定一个还没被调度的pod应该运行在哪个节点上面。Scheduler追踪每个节点的资源使用情况，确保将调度的资源不超出剩下可用的资源。为了达到这个目的，scheduler必须知道可用资源的情况和在各个服务器上已经分配的资源情况。

Controller manager

controller manager是核心Kubernetes控制器（比如DaemonSet控制器、复制控制器）所运行的进程。这些控制器跟API服务器通信来创建、更新和删除它们所管理的资源（pod、service端点等等）

Kubernetes node

节点（Node）（也叫worker或者minion）是部署着容器的单个机器（或者虚拟机）。集群中的每一个节点必须运行着容器运行时（runtime）（比如Docker）以及下面所提到的组件，用来和master通信以便让这些容器进行网络配置

Kubelet

Kubelet负责每个节点的运行状态，也就是说确保节点中的所有容器正常运行。它会按照控制平面（plane）的指示启动、停止和维护容器（组织成pods）。

Kubelet监视一个pod的状态，如果没有看到想要的状态，那么这个pod会被重新部署到同一个节点上。节点的状态依赖于每几秒所发送给master的心跳信息。当master侦测到一个节点失败了，复制控制（Replication Controller）就会知道这个状态改变了，然后会在另一个正常的节点上启动相应的pod。

Kube-proxy

kube-proxy是网络代理和负载均衡的实现。它和其他的网络操作提供了服务抽象。它负责根据ip地址和端口号来路由外部请求到相应的容器。

cAdvisor

cAdvisor是监听和收集资源使用情况和性能指标（比如每个节点中容器的CPU、内存和网络使用情况）的代理者。

引用：

1. “First GitHub commit for Kubernetes”. github.com. 2014-06-07.
2. Jump up^ “GitHub Releases page”. github.com. 2016-10-16.
3. Jump up^ “What is Kubernetes”. Kubernetes. Retrieved 28 August 2015.
4. Jump up^ “Google Made Its Secret Blueprint Public to Boost Its Cloud”. Retrieved 2016-06-27.
5. Jump up^ “Google Open Sources Its Secret Weapon in Cloud Computing”. Wired. Retrieved 24 September 2015.
6. Jump up^ Abhishek Verma; Luis Pedrosa; Madhukar R. Korupolu; David Oppenheimer; Eric Tune; John Wilkes (April 21–24, 2015). “Large-scale cluster management at Google with Borg”. Proceedings of the European Conference on Computer Systems (EuroSys).
7. Jump up^ “Borg, Omega, and Kubernetes – ACM Queue”. queue.acm.org. Retrieved 2016-06-27.
8. Jump up^ “Early Stage Startup Heptio Aims to Make Kubernetes Friendly”. Retrieved 2016-12-06.
9. Jump up^ “As Kubernetes Hits 1.0, Google Donates Technology To Newly Formed Cloud Native Computing Foundation”. TechCrunch. Retrieved 24 September 2015.
10. Jump up^ “Cloud Native Computing Foundation”.
11. ^ Jump up to:*a* *b* *c* *d* *e* *f* *g* *h* *i* “An Introduction to Kubernetes”. DigitalOcean. Retrieved 24 September 2015.
12. ^ Jump up to:*a* *b* Langemak, Jon (2015-02-11). “Kubernetes 101 – Networking”. Das Blinken Lichten. Retrieved 2015-11-02.
13. Jump up^ Strachan, James (2015-05-21). “Kubernetes for Developers”. Medium (publishing platform). Retrieved 2015-11-02.
14. Jump up^ Surana, Ramit (2015-09-16). “Containerizing Docker on Kubernetes”. LinkedIn. Retrieved 2015-11-02.
15. ^ Jump up to:*a* *b* “Intro: Docker and Kubernetes training – Day 2”. Red Hat. 2015-10-20. Retrieved 2015-11-02.
16. ^ Jump up to:*a* *b* “Overview of a Replication Controller”. Documentation. CoreOS. Retrieved 2015-11-02.
17. Jump up^ Sanders, Jake (2015-10-02). “Kubernetes: Exciting Experimental Features”. Livewyer. Retrieved 2015-11-02.
18. Jump up^ Langemak, Jon (2015-02-15). “Kubernetes 101 – External Access Into The Cluster”. Das Blinken Lichten. Retrieved 2015-11-02.
19. Jump up^ Mahajan, Rakesh (August 30, 2016). “Getting started with Kubernetes”. TO THE NEW. Retrieved September 2, 2016.
20. ^ Jump up to:*a* *b* *c* “Kubernetes Infrastructure”. OpenShift Community Documentation. OpenShift. Retrieved 24 September 2015.
21. ^ Jump up to:*a* *b* Marhubi, Kamal (2015-09-26). “Kubernetes from the ground up: API server”. kamalmarhubi.com. Retrieved 2015-11-02.
22. Jump up^ Marhubi, Kamal (2015-08-27). [“What ..] is a Kubelet?”. kamalmarhubi.com. Retrieved 2015-11-02.