工作负载概述-九游平台

容器组（pod）

容器组（pod）是kubernetes创建或部署的最小单位。一个pod封装一个或多个容器（container）、存储资源（volume）、一个独立的网络ip以及管理控制容器运行方式的策略选项。

pod使用主要分为两种方式：

• pod中运行一个容器。这是kubernetes最常见的用法，您可以将pod视为单个封装的容器，但是kubernetes是直接管理pod而不是容器。
• pod中运行多个需要耦合在一起工作、需要共享资源的容器。通常这种场景下应用包含一个主容器和几个辅助容器（sidecar container），如图1所示，例如主容器为一个web服务器，从一个固定目录下对外提供文件服务，而辅助容器周期性的从外部下载文件存到这个固定目录下。
  图1 pod
  

实际使用中很少直接创建pod，而是使用kubernetes中称为controller的抽象层来管理pod实例，例如deployment和job。controller可以创建和管理多个pod，提供副本管理、滚动升级和自愈能力。通常，controller会使用pod template来创建相应的pod。

无状态负载（deployment）

pod是kubernetes创建或部署的最小单位，但是pod是被设计为相对短暂的一次性实体，pod可以被驱逐（当节点资源不足时）、随着集群的节点崩溃而消失。kubernetes提供了controller（控制器）来管理pod，controller可以创建和管理多个pod，提供副本管理、滚动升级和自愈能力，其中最为常用的就是deployment。

图2 deployment

一个deployment可以包含一个或多个pod副本，每个pod副本的角色相同，所以系统会自动为deployment的多个pod副本分发请求。

deployment集成了上线部署、滚动升级、创建副本、恢复上线的功能，在某种程度上，deployment实现无人值守的上线，大大降低了上线过程的复杂性和操作风险。

有状态负载（statefulset）

deployment控制器下的pod都有个共同特点，那就是每个pod除了名称和ip地址不同，其余完全相同。需要的时候，deployment可以通过pod模板创建新的pod；不需要的时候，deployment就可以删除任意一个pod。

但是在某些场景下，这并不满足需求，比如有些分布式的场景，要求每个pod都有自己单独的状态时，比如分布式数据库，每个pod要求有单独的存储，这时deployment无法满足业务需求。

分布式有状态应用的特点主要是应用中每个部分的角色不同（即分工不同），比如数据库有主备、pod之间有依赖，在kubernetes中部署有状态应用对pod有如下要求：

• pod能够被别的pod找到，要求pod有固定的标识。
• 每个pod有单独存储，pod被删除恢复后，必须读取原来的数据，否则状态就会不一致。

kubernetes提供了statefulset来解决这个问题，其具体如下：

1. statefulset给每个pod提供固定名称，pod名称增加从0-n的固定后缀，pod重新调度后pod名称和hostname不变。
2. statefulset通过headless service给每个pod提供固定的访问域名。
3. statefulset通过创建固定标识的pvc保证pod重新调度后还是能访问到相同的持久化数据。

   

守护进程集（daemonset）

daemonset（守护进程集）在集群的每个节点上运行一个pod，且保证只有一个pod，非常适合一些系统层面的应用，例如日志收集、资源监控等，这类应用需要每个节点都运行，且不需要太多实例，一个比较好的例子就是kubernetes的kube-proxy。

daemonset跟节点相关，如果节点异常，也不会在其他节点重新创建。

普通任务（job）和定时任务（cronjob）

job和cronjob是负责批量处理短暂的一次性任务（short lived one-off tasks），即仅执行一次的任务，它保证批处理任务的一个或多个pod成功结束。

• job：是kubernetes用来控制批处理型任务的资源对象。批处理业务与长期伺服业务（deployment、statefulset）的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。job管理的pod根据用户的设置把任务成功完成就自动退出（pod自动删除）。
• cronjob：是基于时间的job，就类似于linux系统的crontab文件中的一行，在指定的时间周期运行指定的job。

任务负载的这种用完即停止的特性特别适合一次性任务，比如持续集成。

工作负载生命周期说明