Pod控制器

存活探针

存活探针（Liveness Probe）：检测Pod内的容器是否正常运行

1）可以为Pod内的每个容器单独指定存活探针；

2）若探测为不能运行，则Kubernetes将周期性执行探针并重建该容器；

3）存活探针由承载Pod的节点上的Kubelet执行，Master节点不参与该过程

//若承载节点崩溃了，则由Kubernetes Control Plane创建该节点的Pod替代品

创建存活探针格式（位于Pod的spec.containers字段下）：

livenessProbe：
  存活探针机制
  initialDelaySeconds： 第一次探针等待时间

存活探针分为以下3种机制：

（1）HTTP GET探针：针对容器的IP执行HTTP GET请求

1）探测响应为正常响应代码（2XX和3XX），则没有操作；

2）探测响应为错误响应代码或无响应，则重建容器；

（2）TCP套接字探针：针对容器指定的端口建立TCP连接

1）建立连接成功，则没有操作；

2）建立连接失败，则重建容器；

（3）Exec探针：指定容器运行时需执行的命令

1）执行命令的返回代码为0，则没有操作；

2）执行命令的返回代码为其他值，则重建容器；

如：建立带有HTTP GET探针的Pod

1）编写YAML文件

//务必设置探针的等待时间，以保证容器正常启动后再开启存活探针

2）调用create命令生成Pod，并查看状态

3）describe命令查看Pod中关于容器的信息

//退出代码137：为128+终止进程的信号编号（9是SIGKILL的信号编号）

delay代表在容器启动后多久开始探测

timeout代表探测响应的超时时间

period代表多长时间为一次探测周期

success代表探测成功几次，则在该周期时间内不再探测

failure代表探测失败几次，则重建容器

存活探针须知

（1）指明存活探针的探测方向

1）指明探针检测的具体资源；

//如：HTTP GET探针需指出请求的特定URL路径

2）保证探测过程中无外界因素的影响；

//应用从内部对内部运行的重要组件执行状态检查

（2）保证存活探针的轻量性

1）存活探针不能设计过于复杂（不能消耗过多资源）；

2）探测频率应该减少，且必须在一秒内执行完毕；

（3）确保存活探针中无过多重试循环

1）探测成功次数和探测失败次数应适当减少（减少资源消耗）；

//两个次数可分别通过success和failure指定

ReplicationController

ReplicationController（RC）：确保管理的1个或多个Pod始终保持运行状态

1）RC属于Kubernetes的一种资源类型；

2）RC会始终监控其管理的Pod，以确保运行的数量达到期望值；

//不论什么情况导致减少的Pod，RC都自动创建（反之则自动关闭）

如：当RC所管理的Pod所在的节点宕机时

如：ReplicationController工作流程

ReplicationController的优点：

1）确保1个或多个Pod持续运行；

//多个Pod一般指定的是1个Pod的副本（也可管理多个Pod）

2）当承载Pod运行的节点发送故障时，RC自动在其他节点创建新的Pod

//前提是Pod属于RC管理，负责Pod会随着节点一起下线

3）实现Pod的水平自动扩缩

如：ReplicationContronller控制副本数量的流程

//这些Pod可能并不运行在同一个Node节点上

创建ReplicationController

ReplicationController主要3部分组成：

1）replica（副本个数）：指定期望值；

2）selector（标签选择器）：确定RC的作用于的Pod；

3）template（Pod模板）：创建新Pod时所根据的模板

1）标签选择器和Pod模板可随时修改，不会影响当前正在运行的Pod；

2）修改标签选择器，可能会使当前运行的Pod脱离RC管理；

3）修改Pod模块，会使RC所创建新的Pod和原Pod不一致；

4）修改副本个数，可能会对当前运行的Pod产生影响；

创建ReplicationController格式：

apiVersion： v1
kind：ReplicationController
metadata：
  name：RC名称
spec：
  replicase：副本个数
  selector：
标签名1： 标签值1
标签名N： 标签值N
  template：
    Pod模板

如：创建ReplicationController

1）编写YAML文件

//也可不指定标签选择器，Kubernetes会自动从Pod模板中自动生成标签选择器

2）调用create命令生成RC，并验证

3）删除其中一个Pod，观察RC如何处理

//由创建时间可知，在删除Pod后，RC自动创建新的Pod

如：续上，查看创建RC的详细信息

管理ReplicationController

（1）通过修改Pod的标签，实现将从RC的管理中添加/移出该Pod；

1）RC仅能通过标签选择器，找到属于其管理的Pod（作用域）；

2）Pod含有多个标签时只要有一个标签匹配RC标签选择器，则属于RC管理；

3）当Pod标签不与RC标签选择器匹配时，则该Pod从RC的管理中移出

如：添加和修改标签的不同情况

1）续上，对RC管理的其中一个Pod添加额外标签

2）修改添加标签的app标签

3）删除修改标签的app标签，观察RC是否自动重建

（2）通过修改Pod模板，实现滚动升级Pod

1）修改Pod模板后，RC不会删除正在运行的Pod；

2）当旧Pod因其他因素消失，会根据Pod模板创建新Pod；

3）Pod模板实现滚动升级的原理在于手动删除旧Pod，自动生成新Pod

如：通过修改Pod模板实现滚动升级流程

如：修改Pod模板，并删除旧Pod验证

1）续上，通过edit命令修改RC的配置文件

2）删除两个Pod验证

（3）通过修改RC的配置文件实现Pod的扩缩容

1）效果等同于scale命令

如：续上，扩容Pod的副本到5个

1）通过edit命令修改RC的配置文件

2）验证

//缩容同理，只需修改spec.replicas字段的数值即可

删除ReplicationController

通过调用delete命令删除指定的ReplicationController

1）默认删除RC时，其管理的Pod会随之一起删除；

2）通过“–cascade=false”选项可单独删除RC，保留Pod

如：调用delete命令删除RC，并带有–cascade=false选项

如：续上，删除RC，并保留Pod

ReplicaSet

ReplicaSet（RS）：新一代的ReplicationController

1）RS属于Kubernetes的一种资源类型；

2）RS的管理和功能几乎和RC是相同的（创建、管理和删除）；

3）RS会始终监控其管理的Pod，以确保运行的数量达到期望值；

对比ReplicaSet和ReplicationController：

（1）RS的标签选择器具有更强的表达能力；

1）RC仅能匹配包含某个标签的Pod，无法实现基于标签名匹配；

2）RS可匹配缺少某个标签的Pod，或包含特定标签名的Pod（忽略其值）；

//可理解为RS仅比RC多了丰富的标签选择器，其操作完全相同

创建ReplicaSet

ReplicaSet主要3部分组成：

1）replica（副本个数）：指定期望值；

2）selector（标签选择器）：确定RS的作用于的Pod；

3）template（Pod模板）：创建新Pod时所根据的模板

创建ReplicaSet格式：

apiVersion： apps/v1beta2
kind： ReplicaSet
metadata：
  name： RS名称
spec：
  replicase： 副本个数
  selector：
标签选择器
  template：
    Pod模板

标签选择器分为两种：

（1）matchLabels选择器，格式：

matchLabels：
  标签名1： 标签值1
  标签名N： 标签值N

（2）matchExpressions选择器，格式：

matchExpressions：
  -  key： 标签名
     operator：  运算符
     values：
     -  标签值1
        标签值N

运算符分为以下4种：

1）In运算符：标签值与values字段指定的其中一个标签值匹配，则匹配成功；

2）NotIn运算符：标签值不与values字段指定的任何值匹配，则匹配成功；

3）Exists运算符：Pod包含指定的标签名，则匹配成功；

4）DoesNotExist运算符：Pod不包含指定的标签名，则匹配成功；

//In和NotIn必须含有values字段，Exists和DoesNotExist不含有values字段

//同时指定matchLabels和matchExpressions，则两者之间默认进行“与运算”

如：创建标签选择器为matchLabels的RS

1）编写YAML文件；

2）调用create命令生成RS，并验证

如：创建标签选择器为matchExpressions的RS

1）编写YAML文件

2）调用create命令生成RS，并验证

删除RS时，其管理的Pod会随之一起删除（同RC）

如：删除kubia1，并查看其管理的Pod

DaemonSet

DaemonSet（DS）：确保每个匹配成功的节点上运行一个Pod

1）DS属于Kubernetes的一种资源类型；

2）DS没有期望值概念，仅保证匹配成功的节点运行一个Pod；

3）若匹配成功的节点下线，DS不会在其他节点重建一个Pod；

4）若新添加匹配成功的节点，DS会自动在该节点根据Pod模板创建一个Pod；

5）若节点的标签被修改，则运行DaemonSet管理的Pod会自动停止；

6）DS管理的Pod完全绕开调度器（因为DS的目的是运行系统服务）

如：RS仅确保匹配成功的节点上运行一个Pod

创建DaemonSet

DaemonSet主要2部分组成：

1）selector（标签选择器）：确定DS的作用于的节点；

2）template（Pod模板）：创建新Pod时所根据的模板

创建DaemonSet格式：

apiVersion： apps/v1beta2
kind： DaemonSet
metadata：
  name： DS名称
spec：
  selector：
    标签选择器
  template：
    Pod模板

如：创建DaemonSet

1）编写YAML文件；

2）调用create命令生成DS，并验证

3）修改含有该标签的Node标签值

删除DS时，其管理的Pod会随之一起删除（同RC和RS）

Job

Job：运行Pod，以完成指定任务

1）Job属于Kubernetes的一种资源类型；

2）Job定义运行一类Pod，当Pod内的进程运行成功时，关闭Pod；

3）当Job定义的Pod所在节点宕机时，Pod将会在其他节点重建该Pod；

4）Job管理的Pod若不能正常运行，会一直被重建，直至完成指定任务；

5）完成任务后的Pod不会被删除

如：当节点宕机时，RS和Job会自动在其他节点创建新的Pod

//Job也可通过scale命令进行扩缩容

创建Job

创建Job格式：

apiVersion： apps/v1beta2
kind： Job
metadata：
  name： Job名称
spec：
  completions： Pod数量
  parallelism： Pod可并行运行数量
  backoffLimit： 被标为失败前的可尝试次数
  activeDeadlineSeconds： 运行Pod的超时时间
  template：
metadata：
  容器元数据
  spec：
restartPolicy：重启策略
容器相关配置

重启策略分为3种：

1）Always（默认）：容器被关闭后，总是重启；

//Job不能使用默认策略，会导致无限期地运行

2）OnFailure：当容器发生错误关闭后，重启容器；

3）Never：无论什么情况，容器被关闭后不进行重启

如：创建只含有单个Pod任务的Job

1）编写YAML文件；

//不指定selector，Kubernetes自动从Pod模板中自动生成标签选择器

2）调用create命令生成Job，并验证

3）待任务完成后，再次查询

如：创建含有多个Pod的Job，且限定每次Pod的并行运行数

1）编写YAML文件；

2）调用create命令生成Job，并验证

3）待一段时间后（第一次的并行Pod运行完成），再次查询

CronJob

CronJob：在指定时间创建Job，完成指定任务

1）默认Job在创建后，立即运行Pod；

2）schedule字段配置方式等同于Linux的cron命令配置方式；

3）到达指定时间时，CronJob会创建Job，再由Job创建Pod完成任务；

创建CronJob格式：

apiVersion： batch/v1beta1
kind： CronJob
metadata： 
  name： CronJob名称
spec：
  schedule： “分，时，日，月，周”
  startingDeadlineSeconds： 到达指定时间后，Pod最晚运行时间
  jobTemplata：
    Job模板

如：创建CronJob，在每15分钟运行一次Job

1）编写YAML文件

2）调用create命令生成CronJob，并验证

3）等待到达指定时间后，再次查询