4. 抽象对象

>Kubernetes对集群中的资源进行了不同级别的抽象，每个资源都是一个REST对象，通过API进行操作，通过json或yaml格式的模板文件进行定义。

# 一、抽象资源对象

## 容器组/Pod

在Kubernetes中，并不直接操作容器，最小的管理单位是容器组（Pod）。容器组由一个或多个容器组成，Kubernetes围绕容器组进行创建、调度、停止等生命周期管理。

同一个容器组中，各个容器共享命名空间（包括网络、IPC、文件系统等容器支持的命名空间）、cgroups限制和存储卷。这意味着同一个容器组中，各个应用可以很方便地相互进行访问，比如通过localhost地址进行网络访问，通过信号量和共享内存进行进程间通信等，类似经典场景中运行在同一个操作系统中的一组进程。可以简单地将一个Pod当作是一个抽象的“虚拟机”，里面运行若干个不同的进程（每个进程实际上就是一个容器）。

实现上，是先创建一个`gcr.io/google_containers/pause`容器，创建相关命名空间，然后创建Pod中的其他应用容器，并共享pause容器的命名空间。

组成容器组的若干容器往往是存在共同的应用目的，彼此关联十分紧密，例如一个Web应用与对应的日志采集应用、状态监控应用。如果单纯把这些相关的应用放一个容器里面，又会造成过度耦合，管理、升级都不方便。

容器组既保持了容器轻量解耦的特性，又提供了调度操作的便利性，在实践中提供了比单个容器更为灵活和更有意义的抽象。

## 服务/Service

服务（Service）的提出，主要是要解决Pod地址可变的问题。由于Pod随时可能发生故障，并可能在其他节点上被重启，它的地址是不能保持固定的。因此，用一个服务来代表提供某一类功能（可以通过标签来筛选）的一些Pod，并分配不随Pod位置变化而改变的虚拟访问地址（Cluster IP）。

典型情况是，比如网站的后端服务，可能有多个Pod都运行了后端处理程序，它们可以组成一个服务。前端只需通过服务的唯一虚拟地址来访问即可，而无须关心具体是访问到了哪个Pod。可见，服务跟负载均衡器实现的功能很相似。

根据访问方式的不同，服务可以分为如下几种类型：

- ClusterIP：提供一个集群内部的地址，该地址只能在集群内解析和访问。ClusterIP是默认的服务类型；

- NodePort：在每个集群节点上映射服务到一个静态的本地端口（默认范围为30000～32767）。从集群外部可以直接访问，并自动路由到内部自动创建的ClusterIP；

- LoadBalancer：使用外部的路由服务，自动路由访问到自动创建的NodePort和ClusterIP；

- ExternalName：将服务映射到externalName域指定的地址，需要1.7以上版本kube-dns的支持。

组成一个服务的Pod可能是属于不同复制控制器的，但服务自身是不知道复制控制器的存在的。

## 存储卷/Volume

即容器挂载的数据卷，跟Pod有一致的生命周期，Pod生存过程（包括重启）中，数据卷跟着存在；Pod退出，则数据卷跟着退出。

几个比较常见的数据卷类型包括：emptyDir、hostPath、gcePersistentDisk、awsElastic-BlockStore、nfs、gitRepo、secret。

- **emptyDir**
当Pod创建的时候，在节点上创建一个空的挂载目录，挂载到容器内。当Pod从节点离开（例如删除掉）的时候，自动删除挂载目录内数据。节点上的挂载位置可以为物理硬盘或内存。这一类的挂载适用于非持久化的存储，例如与Pod任务相关的临时数据等。除此之外，其他存储格式大都是持久化的；

- **hostPath**
将节点上某已经存在的目录挂载到Pod中，Pod退出后，节点上的数据将保留；

- **gcePersistentDisk**
使用GCE的Persistent Disk服务，Pod退出后，会保留数据；

- **awsElasticBlockStore**
使用AWS的EBS Volume服务，数据也会持久化保留；

- **nfs**
使用NFS协议的网络存储，也是持久化数据存储；

- **gitRepo**
挂载一个空目录到Pod，然后clone指定的git仓库代码到里面，适用于直接从仓库中给定版本的代码来部署应用；

- **secret**
用来传递敏感信息（如密码等），基于内存的tmpfs，挂载临时秘密文件。
持久化的存储以插件的形式提供为PersistentVolume资源，用户通过请求某个类型的PersistentVolumeClaim资源，来从匹配的持久化存储卷上获取绑定的存储。

# 二、控制器抽象对象

控制器抽象对象是基于对所操控对象的进一步抽象，附加了各种资源的管理功能，目前主要包括副本集、部署、状态集、Daemon集、任务等。

## 副本集/ReplicaSet

在Kubernetes看来，Pod资源是可能随时发生故障的，并不需要保证Pod的运行，而是在发生失败后重新生成。Kubernetes通过复制控制器来实现这一功能。

用户申请容器组后，复制控制器将负责调度容器组到某个节点上，并保证它的给定份数（replica）正常运行。当实际运行Pod份数超过数目，则终止某些Pod；当不足，则创建新的Pod。一般建议，即使Pod份数是1，也要使用复制控制器来创建，而不是直接创建Pod。

可以将副本集类比为进程的监管者（supervisor）的角色，只不过它不光能保持Pod的持续运行，还能保持集群中给定类型Pod同时运行的个数为指定值。Pod是临时性的，可以随时由副本集创建或者销毁，这意味着要通过Pod自身的地址访问应用是不能保证一致性的。Kubernetes通过服务的概念来解决这个问题。

## 部署/Deployment

从1.2.0版本开始，Kubernetes将正式引入部署机制来支持更灵活的Pod管理，从而用户无须直接跟复制控制器打交道了。部署代表用户对集群中应用的一次更新操作，在副本集的基础上还支持更新操作。每次滚动升级（rolling-update），会自动将副本集中旧版本的Pod逐渐替换为新的版本。

另外，副本集也可以支持成为“横向Pod扩展器”的操作对象。

## 状态集/StatefulSet

通常情况下，使用容器的应用都是不带状态的，意味着部署同一个应用的多个Pod彼此可以替换，而且生命周期可以是很短暂的。任何一个Pod退出后，Kubernetes在集群中可以自动创建一个并按照调度策略调度到节点上。无状态的应用时候，关心的主要是副本的个数，而不关心名称、位置等。

与此对应，某些应用需要关心Pod的状态（包括各种数据库和配置服务等），挂载独立的存储。一旦当某个Pod故障退出后，Kubernetes会创建同一命名的Pod，并挂载原来的存储，以便Pod中应用继续执行，实现了该应用的高可用性。

状态集正是针对这种需求而设计的，提供比副本集和部署更稳定可靠的运行支持。

## 守护集/DaemonSet

Daemon集适合于长期运行在后台的伺服类型应用，例如对节点的日志采集或状态监控等后台支持服务。

Daemon集的应用会确保在指定类型的每个节点上都运行一个该应用的Pod。可能是集群中所有节点，也可能是指定标签的一类节点。

## 任务/Job

不同于长期运行的应用，任务（Job）代表批处理类型的应用。任务中应用完成某一类的处理即可退出，有头有尾。例如，计算Pi到多少位，可以指定若干个Pod成功完成计算，即算任务成功执行。

## 横向Pod扩展器/HPA

横向Pod扩展器（Horizontal Pod Autoscaler, HPA）解决应用波动的情况。类似云里面的自动扩展组，扩展器根据Pod的使用率（典型如CPU、内存等）自动调整一个部署里面Pod的个数，保障服务在不同压力情况下保证平滑的输出效果。

控制管理器会定期检查性能指标，在满足条件时候触发横向伸缩。Kubernetes 1.6版本开始支持基于多个指标的伸缩。

# 三、其他抽象对象

## 标签/Label

另外，Label键支持通过/来添加前缀，可以用来标注资源的组织名称等。一般的，前缀不能超过253个字符，键名不能超过63个字符。

标签所定义的属性是不唯一的，这意味着不同资源可能带有相同的标签键值对。这些属性可以将业务的相关信息绑定到对象上，用来对资源对象进行分类和选择过滤。

## 注解/Annotation

注解（Annotation）跟标签很相似，也是键值对，但并非用来标识对象，同时可以存储更多更复杂的信息。

不同的是，注解并不是为了分类资源对象，而是为了给对象增加更丰富的描述信息。这些信息是任意的，数据量可以很大，可以包括各种结构化、非结构化的数据。

常见的注解包括时间戳、发行信息、开发者信息等，一般是为了方便用户查找相关线索。

## 选择器/Selector

基于资源对象上绑定的标签信息，选择器（Selector）可以通过指定标签键值对来过滤出一组特定的资源对象。

选择器支持的语法包括基于等式（Equality-based）的，和基于集合（Set-based）的。

基于等式的选择，即通过指定某个标签是否等于某个值，例如env=production或者tier!=frontend等。多个等式可以通过AND逻辑组合在一起。

基于集合的选择，即通过指定某个标签的值是否在某个集合内，例如env in (staging, production)。

## 秘密数据/Secret

秘密数据（Secret）资源用来保存一些敏感的数据，这些数据（例如密码）往往不希望别的用户看到，但是在启动某个资源（例如Pod）的时候需要提供。通过把敏感数据放到Secret里面，用户只需要提供Secret的别名即可使用。

在对应容器（secret-test-pod.test-container）内，通过环境变量$SECRET_USERNAME和$SECRET_PASSWORD即可获取到原始的用户名和密码信息。

此外，还可以采用数据卷的方式把秘密数据的值以文件形式放到容器内。通常，秘密数据不要超过1 MB。

在整个过程中，只有秘密数据的所有人和最终运行的容器（准确的说，需要是同一个服务账号下面的）能获取原始敏感数据，只接触到Pod定义模板的人是无法获取到的。

## UID和名字

Kubernetes用UID和名字（Name）来标识对象。其中，UID是全局唯一的，并且不能复用；而名字则仅仅要求对某种类型的资源（在同一个命名空间内）内是唯一的，并且当某个资源移除后，其名字可以被新的资源复用。

这意味着，可以创建一个Pod对象，命名为test，同样可以创建一个复制控制器，命名也为test。一般的，名字字符串的长度不要超过253个字符。

## 命名空间/NameSpace

命名空间（Namespace）用来隔离不同用户的资源，类似租户或项目的概念。默认情况下，相同命名空间中的对象将具有相同的访问控制策略。

同一个命名空间内，资源不允许重名，但不同命名空间之间，允许存在重名。用户在创建资源的时候可以通过`–namespace=<some_namespace>`来指定所属的命名空间。

Kubernetes集群启动后，会保留两个特殊的命名空间：

- default：资源未指定命名空间情况下，默认属于该空间；
- kube-system：由Kubernetes系统自身创建的资源。

另外，大部分资源都属于某个命名空间，但部分特殊资源，如节点、持久存储等不属于任何命名空间。

## 污点和容忍

污点（Taint）和容忍（Toleration）用于辅助管理Pod到工作节点的调度过程。具有某个污点的工作节点，在不容忍的Pod看来，要尽量避免调度到它上面去。

通常情况下，可以为一个工作节点注明若干污点，只有对这些污点容忍的Pod，才可以被调度到这些具有污点的节点上。