kubernetes设计概要

概述

        kubernetes是一个用来管理运行在多个主机上的容器的管理系统。为部署、维护、横向扩展应用提供了基础设施。kubernetes的API是作为一个为开放的生态系统、自动化系统、更高层次API服务的基础工具。kubernetes使用docker实例来运行集装箱式的应用。kubernetes是否可以看做docker组合而成的系统，可以说是，也可以说不是。

        kubernets建立稳定的声明原语用来维护用户的请求状态。这些声明原语是kubernetes中的主要数据值。自动修复机制，例如自动重启、重复调度、复制容器等等都需要主动控制，而不仅仅是一些必要的编制，kubernetes的一个主要应用是针对应用APP包含多个容器的状况，例如弹性的、分布式的服务。它被设计成可以容易的在kubernetes上进行容器的迁移。因此包括由松散耦合和紧密耦合组成的抽象容器分组，而且提供了一种方法来让容器可以互相查找，并使用互相熟悉的方法进行通讯。

        kubernetes使用户可以访问集群运行的一组容器，系统自动选择主机运行这些容器，目前kubernetes的调度系统非常简单，我们希望它变得强大。调度是策略丰富、拓扑感知、特定工作负载的一个功能，可以显著的影响可用性、性能、容量等等。调度需要考虑个人和集体的资源需求、服务质量需求、硬件/软件/策略约束、亲和力、数据局部性、内部工作负载、最后期限等等。特定工作负载需求会通过API暴露出来。

         在架构上，我们希望kubernetes作为一个可插入式的插件，可以选择调度器、存储系统、分布式机器等等。kubernetes的目的是运行在多个云服务提供商上，就像运行在物理机上一样。一个kubernetes集群并不打算跨越多个可用的区域，我们建议在高可用应用部署在跨多个区域时建立一个高层级的完整部署。kubernetes目前还不支持多用户。

集群架构

        一个运行的kubernetes集群包含代理节点(kubelet)和控制组件(API、调度器等等)，运行在一个分布式的存储方案之上。如下图：

关键思想

        Docker本身是作为一个独立的容器工作的，kubernetes提供了一个在更高层次的组织架构，用来支持普通集群级别的使用。当前只要把焦点集中在应用服务上。

        1    Pod是一组相对紧密耦合的被安排到相同主机节点上的容器。pods服务作为调度、部署、水平扩展、共享资源的基本单位。pod中的容器使用相同的网络命名空间/ip，并且定义了一组存储卷。端口则基于每个pod进行部署。

        2    Labels，松散耦合的pods使用一个K/V标签来组织，单个标签可以用于指定元数据和表示pods中容器的目的/角色。比如一个典型的pod标签的key包含service、env(dev、qa)，tier(fronted、backed)，你可以自己定义自己的约定。通过标签选择器，用户可以识别出pods。kubernetes目前提供两个对象使用标签选择器来跟踪它们的成员，service和replicationController。service是一个为代理服务的可配置单元，运行在所有的工作节点上，它被命名并且指向到一个或者多个pods。replicationController，复制控制器需要一个模板，并确保在任意时刻有指定数目的副本运行这个模板，如果运行的多了，则会自动kill一些，如果运行的少了，则会自动启动一些。为了管理的方便和一致性，services和 replicationControllers可以有他们自己的标签，通常会携带pods上的公共标签。

kubernetes节点

        我们来看看这个系统的架构，我们把服务解耦，分别为运行在工作节点的服务和集群级别的控制服务。kubernetes节点上包含了运行docker的所有必须的服务，并且可以从控制节点上进行管理。kubernetes节点被设计成可扩展的，每个节点都运行docker。

        1    kubelet是节点上运行的第二个组件，kubelet是容器代理的逻辑继承者，也是CE镜像的一部分。kubelet在容器清单的范围内工作，容器清单是一个描述pod的YAML文件。kubelet需要一整套清单用来提供各种机制，用来确保在YAML中描述的容器正常启动并持续运行。kubelet提供了四种访问容器清单的方式：

1    file：在命令行传递文件路径，每间隔20s检查一次
2    http endpoint：在命令行传递endpoint，每间隔20s检查一次
3    etcd server：kubelet访问etcd服务器并监视etcd服务，所有的变动会被很快监视到并采取相关行动。
4    http server：kubelet也能监听http并响应简单的API请求

        2    kubernetes proxy，每个节点上还运行着一个简单的网络代理，它在每个节点上映射了定义在kubernetes API中的服务，并且可以通过简单的TCP流转发或者TCP轮训来访问后端，服务endpoint目前可以通过环境变量来发现。

kubernetes控制平台

        kubernetes控制平台被划分成一系列组件，但是他们都运行在一个控制节点上。这些组件一起提供了整个集群的视图。

        1    etcd，所有的持久化控制状态都是存储在etcd实例中的，它提供了一个可靠地方式来存储配置数据的方法，而且有watch支持，协调组件可以快速的发现变更。

        2    kubernetes API，这个服务提供kubernetes API的主要服务，它验证配置3种对象类型的数据：

1    pod，每一个pod在kubernetes API级别都有一个描述
2    service，在每个工作节点上有一个代理配置单元，它被命名并指向一个或者多个pods
3    replicationController，复制控制器需要一个模板，并确保在任意时刻有指定数目的副本运行这个模板，如果运行的多了，则会自动kill一些，如果运行的少了，则会自动启动一些

               除了提供REST服务在etcd中来操作、验证、存储信息外，API服务器还做其他两件事：

1    调度pods到工作节点上
2    与服务配置同步pod信息

        3    kubernetes 管理控制服务，对于kubernetes的使用来说，replicationController类型的描述并非必须的，它实际上是一个基于pod API上的简单服务，在这一层上执行，replicationController的逻辑定义实际上被分配到其他服务器上，这个服务watch etcd，是为了改变replicationController对象，并且使用公共kubernetes API去响应复制算法

GCE集群配置

        1    在cluster目录下的脚本和数据可以自动创建一组GCE VMs，并且自动安装所有kubernetes组件，组成一个单控制节点和工作节点的集群。