Kubernetes基础概念

Kubernetes基础概念

什么是Kubernetes

Kubernetes是Google开源的容器集群管理系统，其提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用，其主要功能如下：

1. 使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。
2. 以集群的方式运行、管理跨机器的容器。
3. 解决Docker跨机器容器之间的通讯问题。
4. Kubernetes的自我修复机制使得容器集群总是运行在用户期望的状态。

当前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure、Mesos等平台，除此之外，也可以直接运行在物理机上。

Kubernetes组件及架构

一个正在运行的kubernetes集群是基于分布式存储之上的，包括节点代理(kubelet)、Master组件(APIs, scheduler, 等)，如下架构图是kubernetes期望的状态：

Kubernetes节点

从架构图可以看出，根据服务划分kubernetes集群由从节点与控制面板组成。
Kubernetes节点包含容器运行的必须服务与master的管理系统。
每个节点都运行Docker服务，Docker服务负责下载镜像与运行容器。

Kubelet

Kubelet管理Pod的镜像、容器、数据卷等。

Kubelet是Kubernetes集群中每个Minion和Master API Server的连接点，Kubelet运行在每个Minion上，是Master API Server和Minion之间的桥梁，接收Master API Server分配给它的commands和work，与持久性键值存储etcd、file、server和http进行交互，读取配置信息。Kubelet的主要工作是管理Pod和容器的生命周期，其包括Docker Client、Root Directory、Pod Workers、Etcd Client、Cadvisor Client以及Health Checker组件，具体工作如下:

1. 通过Worker给Pod异步运行特定的Action
2. 设置容器的环境变量
3. 给容器绑定Volume
4. 给容器绑定Port
5. 根据指定的Pod运行一个单一容器
6. 杀死容器
7. 给指定的Pod创建network容器
8. 删除Pod的所有容器
9. 同步Pod的状态
10. 从Cadvisor获取container info、 pod info、root info、machine info
11. 检测Pod的容器健康状态信息
12. 在容器中运行命令

Kube-Proxy

Proxy是为了解决外部网络能够访问跨机器集群中容器提供的应用服务而设计的.
每个从节点都运行一个简单的网络代理与负载均衡服务，能够映射通过Kubernetes API定义在每个节点上的服务，并且能够通过一系列的后台服务进行一些简单的TCP与UDP的流转发

目前主要是通过DNS或者环境变量来做服务发现，这些变量是通过服务代理托管的端口来解决的。

Proxy服务也运行在每个Minion上。Proxy提供TCP/UDP sockets的proxy，每创建一种Service，Proxy主要从etcd获取Services和Endpoints的配置信息，或者也可以从file获取，然后根据配置信息在Minion上启动一个Proxy的进程并监听相应的服务端口，当外部请求发生时，Proxy会根据Load Balancer将请求分发到后端正确的容器处理。

Kubernetes控制面板（即Master）

Kubernetes控制面板由一系列的组件构成。目前所有的主节点都运行在一个主节点之上，为支持master的高可用这一状况将很快会改变。这些运行在一起的组件提供一个统一的集群预览。

Etcd

所有的Master状态都存储在Etcd实体中。Etcd提供了可靠的方法来存储配置信息，以及其对watch的支持，当数据发生变化时各组件能够及时地得到通知。

Kubernetes API Server

apiserver serves通过REST方式提供了在插件或组件中实现的所有业务逻辑的CURD操作。

Scheduler

Scheduler通过/bindingAPI绑定未编排的pods到节点上。Scheduler是一个插件，设计者计划在将来支持多种集群编排，甚至包括用户自定义的调度器。

Scheduler收集和分析当前Kubernetes集群中所有Minion节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。由于一旦Minion节点的资源被分配给Pod，那这些资源就不能再分配给其他Pod， 除非这些Pod被删除或者退出， 因此，Kubernetes需要分析集群中所有Minion的资源使用情况，保证分发的工作负载不会超出当前该Minion节点的可用资源范围。具体来说，Scheduler做以下工作:

1. 实时监测Kubernetes集群中未分发的Pod.
2. 实时监测Kubernetes集群中所有运行的Pod，Scheduler需要根据这些Pod的资源状况安全地将未分发的Pod分发到指定的Minion节点上.
3. Scheduler也监测Minion节点信息，由于会频繁查找Minion节点，Scheduler会缓存一份最新的信息在本地.
4. 最后，Scheduler在分发Pod到指定的Minion节点后，会把Pod相关的信息Binding写回apiserver.

Kubernetes Controller Manager Server

所有其他集群级功能都是通过控制管理器(Controller Manager)来操作的。例如：Endpoints对象通过Endpoints Controller来进行创建与更新，节点的发现、管理与监控都是通过Node Controller进行。这些最终都将被分成单独的组件使其插件化。
replicationcontroller的机制是基于简单的pod API之上。最终也将实现成为插件机制。

Master工作流程

Master的工作流主要分以下步骤：

1. kubectl将特定的请求，比如创建Pod，发送给apiserver.
2. apiserver根据请求的类型，比如创建Pod时storage类型是pods，然后依此选择何种REST Storage API对请求作出处理.
3. REST Storage API对的请求作相应的处理.
4. 将处理的结果存入高可用键值存储系统Etcd或其他的存储系统中.
5. 在apiserver响应Kubectl的请求后，Scheduler会根据apiserver获取集群中运行Pod及Minion信息.
6. 依据从apiserver获取的信息，Scheduler将未分发的Pod分发到可用的Minion节点上.

Kubernetes主要概念

节点(Node)

一个节点为一台运行Kubernetes的物理机或者虚拟机，在这之上可以调度容器。

Pods

Pod是Kubernetes的基本操作单元，把相关的一个或多个容器构成一个Pod，通常Pod里的容器运行相同的应用。Pod包含的容器运行在同一个Minion(Host)上，看作一个统一管理单元，共享相同的volumes和network namespace/IP和Port空间。

Labels

Labels是用于区分Pod、Service、Replication Controller的key/value键值对，Pod、Service、 Replication Controller可以有多个label，但是每个label的key只能对应一个value。Labels是Service和Replication Controller运行的基础，为了将访问Service的请求转发给后端提供服务的多个容器，正是通过标识容器的labels来选择正确的容器。同样，Replication Controller也使用labels来管理通过pod 模板创建的一组容器，这样Replication Controller可以更加容易，方便地管理多个容器，无论有多少容器。

选择器(Selector)

选择器是一个匹配labels的表达式，用于辨别资源之间的联系，如哪一个pods是load-balanced服务的目标。

Replication Controllers

Replication Controller确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行， 如果少于指定数量的pod副本(replicas)，Replication Controller会启动新的Container，反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods，一旦创建成功，pod 模板和创建的pods没有任何关联，可以修改pod 模板而不会对已创建pods有任何影响，也可以直接更新通过Replication Controller创建的pods。对于利用pod 模板创建的pods，Replication Controller根据label selector来关联，通过修改pods的label可以删除对应的pods。Replication Controller主要有如下用法：

1) Rescheduling
如上所述，Replication Controller会确保Kubernetes集群中指定的pod副本(replicas)在运行， 即使在节点出错时。

2) Scaling
通过修改Replication Controller的副本(replicas)数量来水平扩展或者缩小运行的pods。

3) Rolling updates
Replication Controller的设计原则使得可以一个一个地替换pods来rolling updates服务

服务(Services)

Services也是Kubernetes的基本操作单元，是真实应用服务的抽象，每一个服务后面都有很多对应的容器来支持，通过Proxy的port和服务selector决定服务请求传递给后端提供服务的容器，对外表现为一个单一访问接口，外部不需要了解后端如何运行，这给扩展或维护后端带来很大的好处。

数据卷/存储(Volume)

数据卷为可能存在数据的一个目录，是容器可访问的文件系统的一部分。Kubernetes的数据卷构建于Docker的数据卷之上，为提供数据卷目录或设备装置的添加。数据卷大致分为如下几类：

• emptyDir
  如果Pod配置了emptyDir类型Volume， Pod 被分配到Node上时候，会创建emptyDir，只要Pod运行在Node上，emptyDir都会存在（容器挂掉不会导致emptyDir丢失数据），但是如果Pod从Node上被删除（Pod被删除，或者Pod发生迁移），emptyDir也会被删除，并且永久丢失。
• hostPath
  hostPath允许挂载Node上的文件系统到Pod里面去。如果Pod有需要使用Node上的东西，可以使用hostPath，不过不过建议使用，因为理论上Pod不应该感知Node的。

emptyDir和hostPat很多场景是无法满足持久化需求，因为在Pod发生迁移的时候，数据都无法进行转移的，这就需要分布式文件系统的支持。

• nfs
  NFS 是Network File System的缩写，即网络文件系统。Kubernetes中通过简单地配置就可以挂载NFS到Pod中，而NFS中的数据是可以永久保存的，同时NFS支持同时写操作。

• glusterfs
  GlusterFS是一个开源的分布式文件系统，具有强大的横向扩展能力，通过扩展能够支持数PB存储容量和处理数千客户端。同样地，Kubernetes支持Pod挂载到GlusterFS，这样数据将会永久保存。

• 其他类似ceph

参考关于存储相关例子

Secret

Secret存储一些如：容器发送有效请求的验证令牌等一些敏感数据。

Name

用户或客户端提供的资源名称。

命名空间(Namespace)

命名空间类似资源名称的前缀。命名空间可为不同的项目、团队或客户共享一个集群，如防止不相关的两个团队之间资源名字的冲突。

注解(Annotation)

一个能够包含比较大的（相对label而言）、可能不是人能够阅读的、非识别辅助数据、尤其工具与系统操作数据的key/value键值对，不支持有效过滤注释的值。

部署

参考：基于Vagrant CoreOS的kubernetes一键部署