Kubernetes技术与架构-14

1     前言

2     Kubernetes定义

3     Kubernetes架构

4     Kubernetes技术

4.1   容器化技术

4.1.1 cgroups技术

4.1.2 Docker容器运行环境

4.1.3 containerd容器运行环境

4.1.4 Pod的基本概念

4.1.5 Pod的调度策略

4.1.6 Pod的资源编排

4.1.6.1Deployments

4.1.6.2ReplicaSet

4.1.6.3StatefulSets

4.1.6.4DaemonSet

4.1.6.5Jobs

可变调度指令

Job的调度指令是通过修改配置域实现的，一般情况下，Job是在约束的条件下并行地执行Pod任务，例如，在指定的节点区域中执行指定的任务、在特定的硬件资源中（不同的GPU模型或者不同的GPU组合模型）执行特定的任务。如前面的内容所述，Job提供暂停指令（配置域），队列调度控制器可以使用该指令决定何时暂停任务的执行、何时恢复任务的执行，但是队列调度控制器不能决定在什么节点中执行恢复的Pod任务，与该功能特性相关的集群开关是：JobMutableNodeSchedulingDirectives。

因此，在任务启动之前或者在任务恢复之前，用户可以修改调度指令涉及到的配置域，在Job对应的Pod模板中，这些配置域包括节点关系匹配、节点选择器、容忍度、标签以及注解。

指定Pod选择器

如果用户在创建一个Job的时候，没有指定配置域.spec.selector，则系统默认地在Job中增加该配置域，该配置域的值在所有Job中保持唯一性。用户也可以自行指定该配置域，而且该配置域的值必须保持唯一性，因为，如果与其他Job的选择器相同，则Job控制器认为是相同的选择器而作为相同的Pod任务进行统计，当指定的Pod任务被删除的时候，所有相同选择器的Pod任务都将会被删除，所以，这些操作会引起误删的结果。

如上图所示，假如old对应的Job目前处于运行的状态，用户的需求是保留这些已经运行的Pod任务，使用新命名的Job、新定义的Pod模板执行剩余的任务，如前面所述，因为Pod任务在运行的状态下其配置域是不能被修改更新的，所以，现在的做法是，只删除Job对象，而保留已经运行的Pod任务，再创建新的Job继续执行剩余的任务，如下所示，创建一个新Job：

如上图所示，新创建的Job，其配置域controller-uid保持与旧Job的相等，同时，增加配置域manualSelector: true，当Job控制器运行新Job的时候，会自动地更新配置域controller-uid的值为新的唯一的标签值。

Pod失败应对策略

用户可以使用配置域.spec.podFailurePolicy指定Pod在失败异常的情况下的应对策略，与该功能特性相关的集群开关是：JobPodFailurePolicy、PodDisruptionConditions。在Job执行Pod任务的过程中，如果发生失败异常的情况，则Job控制器会根据运行在Pod中的容器的异常码或者Pod的当前状况做出恰当的应对措施。如前面所述，配置域.spec.backoffLimit可以设置Pod失败补偿措施，而使用配置域.spec.podFailurePolicy可以设置更加灵活、更多细节的失败补偿措施，其优点如下所示：

如上图所示，定义了Pod失败的应对策略，其描述如下所示：

其中，配置域的值DisruptionTarget表示该Pod异常情况不参与backoffLimit机制的统计。如前面所述，不管Job发生的是何种异常情况，Job控制器都会终止所有运行中、或者等待中的Pod任务。

此外，如下所示提供与配置域.spec.podFailurePolicy相关的要求与语义：

Job的追踪与终结

该功能特性对应的集群开关是：JobTrackingWithFinalizers，控制器使用该功能特性追踪新创建Job的执行情况，统计状态为成功（succeeded）、失败（failed）的Job，与该统计信息相关的行为包括：

（未完待续）