Job 失败了怎么办?- 每天5分钟玩转 Docker 容器技术(133)

上一节讨论了 Job 执行成功的情况,如果失败了会怎么样呢?

修改 myjob.yml,故意引入一个错误:

先删除之前的 Job:

如果将 restartPolicy 设置为 OnFailure 会怎么样?下面我们实践一下,修改 myjob.yml 后重新启动。

运行新的 Job 并查看状态:

当前 SUCCESSFUL 的 Pod 数量为 0,查看 Pod 的状态:

可以看到有多个 Pod,状态均不正常。kubectl describe pod 查看某个 Pod 的启动日志:

日志显示没有可执行程序,符合我们的预期。

下面解释一个现象:为什么 kubectl get pod 会看到这么多个失败的 Pod?

原因是:当第一个 Pod 启动时,容器失败退出,根据 restartPolicy: Never,此失败容器不会被重启,但 Job DESIRED 的 Pod 是 1,目前 SUCCESSFUL 为 0,不满足,所以 Job controller 会启动新的 Pod,直到 SUCCESSFUL 为 1。对于我们这个例子,SUCCESSFUL 永远也到不了 1,所以 Job controller 会一直创建新的 Pod。为了终止这个行为,只能删除 Job。

如果将 restartPolicy 设置为 OnFailure 会怎么样?下面我们实践一下,修改 myjob.yml 后重新启动。

Job 的 SUCCESSFUL Pod 数量还是为 0,看看 Pod 的情况:

这里只有一个 Pod,不过 RESTARTS 为 3,而且不断增加,说明 OnFailure 生效,容器失败后会自动重启。

下一节我们讨论提高 Job 执行效率的方法。

书籍:

1.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

2.《每天5分钟玩转OpenStack》
https://item.jd.com/12086376.html

原文地址:http://blog.51cto.com/cloudman/2072259

时间: 2024-11-02 15:03:58

Job 失败了怎么办?- 每天5分钟玩转 Docker 容器技术(133)的相关文章

如何滚动更新 Service?- 每天5分钟玩转 Docker 容器技术(102)

在前面的实验中,我们部署了多个副本的服务,本节将讨论如何滚动更新每一个副本. 滚动更新降低了应用更新的风险,如果某个副本更新失败,整个更新将暂停,其他副本则可以继续提供服务.同时,在更新的过程中,总是有副本在运行的,因此也保证了业务的连续性. 下面我们将部署三副本的服务,镜像使用 httpd:2.2.31,然后将其更新到 httpd:2.2.32. 创建服务: docker service create --name my_web --replicas=3 httpd:2.2.31 将 serv

验证 Swarm 数据持久性 - 每天5分钟玩转 Docker 容器技术(104)

上一节我们成功将 Rex-Ray Volume 挂载到了 Service.本节验证?Failover 时,数据不会丢失. Scale Up 增加一个副本: docker?service?update?--replicas?2?my_web 运行之前我们先推测一下,理想的结果应该是:swarm 在?swarm-worker2?上启动第二个副本,同时也将挂载 volume?my_web. 对比一下实际的运行结果: 出现了一点复杂的状况: swarm 首先尝试在?swarm-worker2?上启动第二

如何配置 Health Check?- 每天5分钟玩转 Docker 容器技术(107)

容器状态是 UP 的,应用就是健康的吗? 还真不一定!Docker 只能从容器启动进程的返回代码判断其状态,而对于容器内部应用的运行情况基本没有了解. 执行 docker run 命令时,通常会根据 Dockerfile 中的 CMD 或 ENTRYPOINT 启动一个进程,这个进程的状态就是 docker ps STATUS 列显示容器的状态. 命令显示: 有的容器正在运行,状态为 UP. 有的容器已经正常停止了,状态是 Exited (0). 有的则因发生故障停止了,退出代码为非 0,例如 

部署 k8s Cluster(下)- 每天5分钟玩转 Docker 容器技术(119)

上节我们通过 kubeadm 在 k8s-master 上部署了 Kubernetes,本节安装 Pod 网络并添加 k8s-node1 和 k8s-node2,完成集群部署. 安装 Pod 网络 要让 Kubernetes Cluster 能够工作,必须安装 Pod 网络,否则 Pod 之间无法通信. Kubernetes 支持多种网络方案,这里我们先使用 flannel,后面还会讨论 Canal. 执行如下命令部署 flannel: kubectl apply -f https://raw.

用 k8s 运行一次性任务 - 每天5分钟玩转 Docker 容器技术(132)

容器按照持续运行的时间可分为两类:服务类容器和工作类容器. 服务类容器通常持续提供服务,需要一直运行,比如 http server,daemon 等.工作类容器则是一次性任务,比如批处理程序,完成后容器就退出. Kubernetes 的 Deployment.ReplicaSet 和 DaemonSet 都用于管理服务类容器:对于工作类容器,我们用 Job. 先看一个简单的 Job 配置文件 myjob.yml: ① batch/v1 是当前 Job 的 apiVersion. ② 指明当前资源

定时执行 Job - 每天5分钟玩转 Docker 容器技术(135)

Linux 中有 cron 程序定时执行任务,Kubernetes 的 CronJob 提供了类似的功能,可以定时执行 Job.CronJob 配置文件示例如下: ① batch/v2alpha1 是当前 CronJob 的 apiVersion. ② 指明当前资源的类型为 CronJob. ③ schedule 指定什么时候运行 Job,其格式与 Linux cron 一致.这里 */1 * * * * 的含义是每一分钟启动一次. ④ jobTemplate 定义 Job 的模板,格式与前面

Liveness 探测 - 每天5分钟玩转 Docker 容器技术(143)

Liveness 探测让用户可以自定义判断容器是否健康的条件.如果探测失败,Kubernetes 就会重启容器. 还是举例说明,创建如下 Pod: 启动进程首先创建文件 /tmp/healthy,30 秒后删除,在我们的设定中,如果 /tmp/healthy 文件存在,则认为容器处于正常状态,反正则发生故障. livenessProbe 部分定义如何执行 Liveness 探测: 探测的方法是:通过 cat 命令检查 /tmp/healthy 文件是否存在.如果命令执行成功,返回值为零,Kube

Readiness 探测 - 每天5分钟玩转 Docker 容器技术(144)

除了 Liveness 探测,Kubernetes Health Check 机制还包括 Readiness 探测. 用户通过 Liveness 探测可以告诉 Kubernetes 什么时候通过重启容器实现自愈:Readiness 探测则是告诉 Kubernetes 什么时候可以将容器加入到 Service 负载均衡池中,对外提供服务. Readiness 探测的配置语法与 Liveness 探测完全一样,下面是个例子: 这个配置文件只是将前面例子中的 liveness 替换为了 readine

在 Scale Up 中使用 Health Check - 每天5分钟玩转 Docker 容器技术(

对于多副本应用,当执行 Scale Up 操作时,新副本会作为 backend 被添加到 Service 的负责均衡中,与已有副本一起处理客户的请求.考虑到应用启动通常都需要一个准备阶段,比如加载缓存数据,连接数据库等,从容器启动到正真能够提供服务是需要一段时间的.我们可以通过 Readiness 探测判断容器是否就绪,避免将请求发送到还没有 ready 的 backend. 下面是示例应用的配置文件. 重点关注 readinessProbe 部分.这里我们使用了不同于 exec 的另一种探测方