共计 13009 个字符，预计需要花费 33 分钟才能阅读完成。
放弃 pod 衰弱 P84
只有 pod 调度到某个节点，该节点上的 Kubelet 就会运行 pod 的容器，从此只有该 pod 存在，就会放弃运行。如果容器的主过程奔溃，Kubelet 就会主动重启容器；如果应用程序奔溃，Kubelet 就会主动重启应用程序。P84
应用程序也可能因为有限循环或死锁等状况而进行响应。为确保利用在这种状况下能够重新启动，必须从内部查看应用程序的运行状况，而不是依赖于利用的外部检测。P84
介绍存活探测器 P84
Kubernetes 能够通过存活探测器 (liveness probe) 查看容器是否还在运行。能够为 pod 中的每个容器独自指定存活探测器。Kubernetes 将定期执行探测器，如果探测失败，就会主动重启容器。P84
留神 ：Kubernetes 还反对就绪探测器 (readiness probe)，两者实用于两种不同的场景。P84
Kubernetes 有三种探测容器的机制：P84
HTTP GET探测器：对容器的 IP 地址（指定的端口和门路）执行HTTP GET申请。如果探测器收到响应，并且响应状态码不代表谬误（状态码为 2xx 或 3xx），则认为探测胜利。如果服务器返回谬误响应状态码或者没有响应，那么探测就被认为是失败的，容器将被重启。TCP Socket探测器：尝试与容器指定端口建设 TCP 连贯。如果连贯胜利建设，则探测胜利。否则，容器将被重启。Exec探测器：在容器内执行任意命令，并查看命令的退出状态码。如果状态码是 0，则探测胜利。所有其余状态码都被认为失败，容器将被重启。
创立基于 HTTP 的存活探测器 P85
为了让 HTTP GET 探测器探测失败，咱们须要批改 kubia 源码，使得其从第五次拜访之后开始始终返回 500 状态码 (Internal Server Error)。P85
而后咱们能够通过以下形容文件 kubia-liveness-probe.yaml 创立一个蕴含 HTTP GET 存活探测器的 pod。P85
# 遵循 v1 版本的 Kubernetes API
apiVersion: v1
# 资源类型为 Pod
kind: Pod
metadata:
# pod 的名称
name: kubia-liveness
spec:
containers:
# 创立容器所应用的镜像
- image: idealism/kubia-unhealthy
# 容器的名称
name: kubia
ports:
# 利用监听的端口
- containerPort: 8080
protocol: TCP
# 开启一个存活探测器
livenessProbe:
# 存活探测器的类型为 HTTP GET
httpGet:
# 探测器连贯的网络端口
port: 8080
# 探测器申请的门路
path: / 应用存活探测器 P86
应用 kubectl create -f kubia-liveness-probe.yaml 创立完 pod 后，期待一段时间后，容器将会重启。能够通过 kubectl get pod kubia-liveness 看到容器会重启，并且有限循环上来：86
NAME READY STATUS RESTARTS AGE
kubia-liveness 1/1 Running 2 4m9skubectl logs kubia-liveness --previous: 查看前一个容器的日志，能够理解前一个容器进行的起因。P86
kubectl describe pod kubia-liveness: 查看 pod 详情。能够发现在 Containers 和 Events 外面有终止的相干信息。P86
...
Containers:
kubia:
...
State: Running # 容器目前失常运行
Started: Sun, 07 Jun 2020 17:59:35 +0800
Last State: Terminated # 前一个容器因为谬误被终止，错误码是 137
Reason: Error
Exit Code: 137
Started: Sun, 07 Jun 2020 17:57:44 +0800
Finished: Sun, 07 Jun 2020 17:59:27 +0800
Ready: True
Restart Count: 2 # 该容器已被重启 2 次
Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled <unknown> default-scheduler Successfully assigned default/kubia-liveness to minikube-m02
Warning Unhealthy 48s (x6 over 2m58s) kubelet, minikube-m02 Liveness probe failed: HTTP probe failed with statuscode: 500 # 发现容器不衰弱
Normal Killing 48s (x2 over 2m38s) kubelet, minikube-m02 Container kubia failed liveness probe, will be restarted # 终止该容器
... 错误码 137 是两个数字的总和：128 + x，x 是终止过程的信号编号。P86
- x=9 示意是
SIGKILL的信号编号，意味着这个过程被强行终止，这个信号不能被捕捉或疏忽，并且在接管过程中不能执行任何清理在接管到该信号 - x=15 示意是
SIGTERM的信号编号，意味着这个过程被终止，先进行询问过程终止，让其清理文件和敞开，能够被捕捉和解释或疏忽
底部列出的事件显示了 Kubernetes 发现容器不衰弱，所以终止并从新创立。P86
留神 ：当容器被强行终止时，会创立一个全新的容器，而不是重启原来的容器。P86
配置存活探测器的附加属性 P87
能够应用 kubectl explain pod.spec.containers.livenessProbe 查看存活探测器能应用的自定义附加参数。
基于 kubia-liveness-probe.yaml 创立一个新的形容文件 kubia-liveness-probe-initial-delay.yaml，并增加 pod.spec.containers.livenessProbe.initialDelaySeconds 属性，值为 15，示意在第一次探测器期待 15 秒。
...
spec:
containers:
# 创立容器所应用的镜像
- image: idealism/kubia-unhealthy
...
# 开启一个存活探测器
livenessProbe:
...
# 第一次探测前期待 15 秒
initialDelaySeconds: 15这样能够在应用程序筹备好之后再进行探测，免得应用程序启动工夫过长导致始终探测失败而有限重启。
创立无效的存活探测器 P88
-
存活探测器应该查看什么：繁难的存活探测器能够仅查看服务器是否响应，但为了更好地进行存活查看，须要将探测器配置为申请特定的 URL 门路（如
/health），并让利用从外部对外部运行的所有重要组件执行状态查看，以确保它们都没有终止或进行响应。P88- 确保
/health不须要认证，否则探测会始终失败，导致容器有限重启 - 查看利用的外部，查看后果不能受任何内部因素的影响。例如数据库连不上时，存活探测器不应该返回失败，如果问题在数据库，那么重启容器不会解决问题。
- 确保
-
放弃探测器轻量
P89- 不应耗费太多计算资源
- 运行不应花太长时间。默认状况下，探测器执行的频率绝对较高，必须在一秒之内执行结束
- 毋庸在探测器中实现重试：探测器的失败阈值是可配置的，并且通常在容器被终止之前探测器必须失败屡次
P89 - 存活探测器小结：存活探测由 pod 上的 Kubelet 执行，Kubernetes 控制面板不会参加。因而节点奔溃时，控制面板会为所有随节点进行运行的 pod 创立替代者，但不会为间接创立的 pod 创立替代者，因为这些 pod 只被节点上的 Kubelet 治理。为了防止这种状况产生，咱们应该应用控制器或相似机制治理 pod。
P89
理解 Deployment P89
注 ：本节中提到的 pod 受 Deployment 治理等说法为简化说法，实际上 pod 由受 Deployment 治理创立的 ReplicaSet 进行治理创立。
Deployment 是一种 Kubernetes 资源，可确保它的 pod 始终保持运行状态。如果 pod 因为任何起因隐没（例如节点从集群中隐没或因为该 pod 已从节点中逐出），则 Deployment 会留神到短少了 pod 并创立替代者。P89
上图的节点 1 有两个节点，Pod A 是被间接创立的，而 Pod B 由 Deployment 治理。节点异样退出后，Deployment 会创立一个新的 Pod B2 来替换缩小的 Pod B，而 Pod A 因为没有货色负责重建而齐全失落。P89
Deployment 的操作 P90
Deployment 会继续监控正在运行的 pod 列表，并保障匹配标签选择器（03. pod: 运行于 Kubernetes 中的容器 中介绍过标签选择器及应用形式）的 pod 数目与冀望相符。P90
介绍控制器的协调流程 P91
Deployment 的工作是确保 pod 数量始终与其标签选择器匹配。P91
理解 Deployment 的三局部 P91
- 标签选择器 (label selector)：用于确定
Deployment作用域中有哪些 pod - 正本个数 (replica count)：指定应运行的 pod 数量
- pod 模版 (pod template)：用于创立新的 pod 正本
Deployment 的正本个数、标签选择器和 pod 模版都能够随时批改，但只有正本数目但变更会影响现有的 pod。P92
更改控制器的标签选择器或 pod 模版的成果 P92
更改标签选择器和 pod 模版对现有的 pod 没有影响。更改标签选择器会使现有的 pod 脱离 Deployment 的范畴，因而控制器会进行关注它们。更改模版仅影响由此 Deployment 创立的新 pod。P92
应用 Deployment 的益处 P92
- 确保 pod 继续运行：在现有 pod 失落时启动一个新 pod
- 集群节点产生故障时，为故障节点上运行的受
Deployment治理的所有 pod 创立代替正本 - 轻松实现 pod 程度伸缩——手动和主动都能够
留神 ：pod 实例永远不会从新安置到另一个节点。Deployment 会创立一个全新的 pod 实例，它与正在替换的实例无关。P92
创立一个 Deployment P92
咱们能够通过以下形容文件 kubia-deployment.yaml 创立一个 Deployment，它确保合乎标签选择器 app=kubia 的 pod 实例始终是三个。
# 遵循 v1 版本的 Kubernetes API
apiVersion: apps/v1
# 资源类型为 Deployment
kind: Deployment
metadata:
# Deployment 的名称
name: kubia
spec:
# 指定与标签选择器匹配的 pod 数目为 3
replicas: 3
# 指定 Deployment 操作对象
selector:
# 须要匹配以下指定的标签
matchLabels:
app: kubia
# 启动 pod 应用的模版（能够发现模版内容与 kubia-manual.yaml 对应局部统一）template:
metadata:
# 指定标签为 app=kubia
labels:
app: kubia
spec:
containers:
# 容器的名称
- name: kubia
# 创立容器所应用的镜像
image: idealism/kubia
# 利用监听的端口
ports:
- containerPort: 8080
protocol: TCP 模版中的 pod 标签必须和 Deployment 的标签选择器匹配，API 服务器会校验 Deployment 的定义，不会承受谬误配置。P93
若不指定选择器，它会主动依据 pod 模版中的标签主动配置，这样能够让形容文件更简洁。P93
应用 Deployment P94
kubectl create -f kubia-deployment.yaml 会创立一个名为 kubia 的 Deployment，它会依据 pod 模版启动三个新 pod。P94
kubectl get pods 能够查看以后创立的所有 pod：
NAME READY STATUS RESTARTS AGE
kubia-9495d9bf5-5dwj7 1/1 Running 0 3m53s
kubia-9495d9bf5-5j6zr 1/1 Running 0 3m53s
kubia-9495d9bf5-w98f6 1/1 Running 0 3m53s 查看 Deployment 对已删除的 pod 的响应 P94
kubectl delete pod kubia-9495d9bf5-5dwj7 会删除一个 pod，而后再次查看以后所有 pod，能够发现会有 4 个 pod，因为删除的 pod 正在终止，并且正在创立一个新的 pod：P94
NAME READY STATUS RESTARTS AGE
kubia-9495d9bf5-5dwj7 1/1 Terminating 0 24m
kubia-9495d9bf5-5j6zr 1/1 Running 0 24m
kubia-9495d9bf5-kxcw5 0/1 ContainerCreating 0 9s
kubia-9495d9bf5-w98f6 1/1 Running 0 24m 控制器如何创立新的 pod P95
控制器通过创立一个新的代替 pod 来响应 pod 的删除操作。但它并没有对删除自身作出反应，而是针对由此产生对状态—— pod 数量有余作出反应。P95
应答节点故障 P96
接下来咱们将敞开一个节点的网络接口来模仿节点故障。P96
minikube ssh --node='m02': 进入节点外部sudo ifconfig eth0 down: 敞开该节点的网络接口kubectl get nodes: 发现节点minikube-m02的状态为未就绪 (NotReady)kubectl get pods: 可能依然会看到与之前雷同的三个 pod，因为 Kubernetes 在从新调度 pod 之前会期待一段时间（如果节点因长期网络故障或 Kubelet 重启而无法访问）。如果节点在几分钟内无法访问，Deployment会立刻启动一个新的 pod。
将 pod 移入 / 移出 Deployment 的作用域 P97
由 Deployment 创立的 pod 并不是绑定到 Deployment。在任何时刻，Deployment 治理与标签选择器匹配的 pod。通过更改 pod 的标签，能够将它从 Deployment 的作用域中增加或删除。P97
只管一个 pod 没有绑定到一个 Deployment 领有的 ReplicaSet，但该 pod 在 metadata.ownerReferences 中存储它属于哪一个 ReplicaSet。P98
给 Deployment 治理的 pod 加标签 P98
kubectl label pod kubia-9495d9bf5-5mmhb type=special: 给 pod 增加其余标签不会影响 Deployment 的治理范畴，它只关怀该 pod 是否具备标签选择器中援用的所有标签。P98
更改已托管的 pod 的标签 P98
kubectl label pod kubia-9495d9bf5-5mmhb app=foo --overwrite: 更改其中一个 pod 的标签将使其不再与 Deployment 的标签选择器相匹配，并不再由 Deployment 治理，只剩下两个匹配的 pod。因而，Deployment 会启动一个新的 pod，将数目复原为三。P98
更改 Deployment 的标签选择器 P100
更改 Deployment 的标签选择器会让所有的 pod 脱离 Deployment 的治理，导致它创立三个新的 pod。你永远不会批改控制器的标签选择器，但会时不时地更改它的 pod 模版。P100
批改 pod 模版 P100
Deployment 的 pod 模版能够随时批改，能够应用 kubectl edit deployment kubia 编辑 Deployment。更改后会从新创立一个新的 ReplocaSet，并使原有的 ReplocaSet 的正本数变为 0。因而，应用 kubectl get pods 将发现有 6 个 pod，pod 的前缀是对应的 ReplocaSet 的名称。
NAME READY STATUS RESTARTS AGE
kubia-9495d9bf5-kxcw5 1/1 Terminating 0 78m
kubia-9495d9bf5-w98f6 1/1 Terminating 0 102m
kubia-9495d9bf5-xn67d 1/1 Terminating 0 29m
kubia-bc974964b-bp4l2 1/1 Running 0 22s
kubia-bc974964b-r29j2 1/1 Running 0 39s
kubia-bc974964b-xl677 1/1 Running 0 14s 若通过 kubectl edit replicaset kubia-bc974964b 间接批改 Deployment 领有的 ReplicaSet 实例。这样成果和间接批改 Deployment 相似，也会创立一个新的 ReplicaSet，并使原有的 ReplocaSet 的正本数变为 0。这样批改不会将新的 pod 模版同步回原有的 Deployment，但删除 Deployment 时依然会删除所有相干的 ReplocaSet 及其治理的 pod。
程度缩放 pod P101
kubectl scale deployment kubia --replicas=10: 能够批改 Deployment 须要放弃的 pod 实例的数量（02. 开始应用 Kubernetes 和 Docker 中介绍过应用该命令进行伸缩）。P101
也能够通过 kubectl edit deployment kubia 批改 spec.replicas 的数量，从而更改须要放弃的 pod 实例的数量。P102
删除一个 Deployment
当通过 kubectl delete deployment kubia 删除 Deployment 时，对应的 ReplicaSet 和 pod 都会被删除。
而通过 kubectl delete replicaset kubia-bc974964b 删除 ReplicaSet 时，对应的 pod 会被删除，但因为 Deployment 会从新创立一个 Replicaset，所以又会主动创立对应数量的 pod。
当通过 kubectl delete deployment kubia --cascade=false 删除 Deployment 时，会保留对应的 ReplicaSet 和 pod，这样 ReplicaSet 不再受治理，然而 pod 依然受 ReplicaSet 治理。当从新创立符合要求的 Deployment 时，ReplicaSet 又会受到治理。
同样地，通过 kubectl delete replicaset kubia-bc974964b --cascade=false 删除 ReplicaSet 时，也会保留对应的 pod。这样 pod 不再受治理。当创立符合要求的 ReplicaSet 时，这些 pod 又会受到治理。
应用 ReplicaSet P104
注 ：书中本来上一节讲得是 ReplicationController，但我间接应用 Deployment 进行实际，并按照当初的后果进行了批改。目前举荐应用 Deployment，并且 ReplicaSet 是受 Deployment 治理的，所以不再具体实际本节内容。
应用更富裕表达力的标签选择器 P106
基于 kubia-deployment.yaml 创立一个新的形容文件 kubia-deployment-matchexpressions.yaml，并将 spec.selector.matchLabels 属性替换为 spec.selector.matchExpressions：P107
...
spec:
...
# 指定 Deployment 操作对象
selector:
# 须要匹配满足以下要求的标签
matchExpressions:
# 标签名为 app 的值在 ["kubia"] 中
- app: app
operator: In
values:
- kubia
...matchExpressions 运行给选择器增加额定的表达式。每个表达式都必须蕴含一个 key、一个 operator，并且可能还有一个 values 的列表（取决于 operator）。共有四个无效的运算符：P107
In: 标签的值必须与其中一个指定的 values 匹配NotIn: 标签的值与任何指定的 values 都不匹配Exists: pod 必须蕴含一个指定名称的标签（不关怀值）。应用此运算符时，不应指定 values 字段DoesNotExist: pod 不得蕴含指定名称的标签。应用此运算符时，不应指定 values 字段
如果指定了多个表达式，则所有这些表达式都必须为 true 能力使选择器与 pod 匹配。如果同时指定 matchLabels 和 matchExpressions，则所有标签都必须匹配，且所有表达式都必须为 true 能力使选择器与 pod 匹配。P107
应用 DaemonSet 在每个节点上运行一个 pod P107
DaemonSet 能够让 pod 在集群中的每个节点上运行，并且每个节点正好有一个运行的 pod 实例。P107
应用 DaemonSet 在每个节点上运行一个 pod P108
DaemonSet 没有正本数的概念，它确保创立足够的 pod，并在每一个节点上部署一个 pod。如果节点下线，DaemonSet 不会从新创立 pod；但新节点增加到集群中，它会立即部署一个新的 pod 实例到该节点。P108
应用 DaemonSet 只在特定的节点上运行 pod P109
DaemonSet 将 pod 部署到集群的所有节点上，除非通过 pod 模版中的 spec.nodeSelector 属性指定这些 pod 只在局部节点上运行。P109
留神 ：节点能够被设置为不可调度，避免 pod 被部署到节点上。但 DaemonSet 会将 pod 部署到这些节点上，因为无奈调度但属性只会被调度器应用，而 DaemonSet 的目标是运行零碎服务，即便在不可调度的节点上，零碎服务通常也须要运行。P109
用一个例子来解释 DaemonSet P109
假如有一个名为 ssd-monitor 的守护过程，它须要在蕴含 SSD 的所有节点上运行。蕴含 SSD 的节点已被增加了 disk=ssd 标签，所以咱们须要创立一个 DaemonSet，它只在领有上述标签的节点上运行守护过程。P109
创立一个 DaemonSet 形容文件 P110
为了模仿 ssd-monitor 的监控程序，咱们将应用以下 Dockerfile 创立一个每 5 秒中打印 SSD OK 的镜像。
FROM busybox
ENTRYPOINT while true; do echo 'SSD OK'; sleep 5; done 为了将 ssd-monitor 部署到符合要求的每个节点上，咱们还须要应用以下 ssd-monitor-daemonset.yaml 形容文件进行部署。
# 遵循 apps/v1 版本的 Kubernetes API
apiVersion: apps/v1
# 资源类型为 DaemonSet
kind: DaemonSet
metadata:
# DaemonSet 的名称
name: ssd-monitor
spec:
# 指定 DaemonSet 操作对象
selector:
# 须要匹配以下指定的标签
matchLabels:
app: ssd-monitor
# 启动 pod 应用的模版
template:
metadata:
# 指定标签为 app=ssd-monitor
labels:
app: ssd-monitor
spec:
# 指定抉择具备 disk=ssd 标签的节点部署
nodeSelector:
disk: ssd
containers:
# 容器的名称
- name: main
# 创立容器所应用的镜像
image: idealism/ssd-monitor 实际 P110
kubectl create -f ssd-monitor-daemonset.yaml: 依照指定的形容文件创建一个DaemonSetkubectl get daemonsets: 能够发现所有的值都是 0，因为目前还没有节点领有disk=ssd标签kubectl get pods: 能够发现目前还没有 podkubectl label node minikube-m03 disk=ssd: 给节点minikube-m03打上标签disk=ssd-
kubectl get pods: 能够发现刚刚启动了一个 podNAME READY STATUS RESTARTS AGE ssd-monitor-bbqbp 0/1 ContainerCreating 0 2s kubectl label node minikube-m03 disk=hdd --overwrite: 将节点minikube-m03的标签disk=ssd批改为disk=hdd-
kubectl get pods: 能够发现刚刚启动的 pod 正在终止NAME READY STATUS RESTARTS AGE ssd-monitor-bbqbp 1/1 Terminating 0 2m37s
运行执行单个工作的 pod P112
介绍 Job 资源 P112
Kubernetes 通过 Job 资源反对运行一种 pod，该 pod 子啊外部过程胜利完结时，不重启容器。一旦工作实现，pod 就被认为处于实现状态。P112
在节点产生故障时，该节点上由 Job 治理的 pod 将被重新安排到其余节点。如果过程自身异样退出（过程返回谬误退出码时），能够将 Job 配置为重新启动容器。P112
定义 Job 资源 P113
为了模仿耗时的工作，咱们将应用以下 Dockerfile 创立一个调用 sleep 120 命令的镜像。
FROM busybox
ENTRYPOINT echo "$(date) Batch job starting"; sleep 120; echo "$(date) Finished succesfully" 为了治理部署 batch-job，咱们还须要应用以下 batch-job.yaml 形容文件进行部署。
# 遵循 batch/v1 版本的 Kubernetes API
apiVersion: batch/v1
# 资源类型为 Job
kind: Job
metadata:
# Job 的名称
name: batch-job
spec:
# 启动 pod 应用的模版
template:
metadata:
# 指定标签为 app=batch-job
labels:
app: batch-job
spec:
# Job 不能应用 Always 为默认的重启策略
restartPolicy: OnFailure
containers:
# 容器的名称
- name: main
# 创立容器所应用的镜像
image: idealism/batch-job 设置 Job 的重启策略为 OnFailure 或 Never 能够避免容器在实现工作时重新启动。P114
Job 运行一个 pod P114
kubectl create -f batch-job.yaml: 依据形容文件创建指定的Job-
kubectl get jobs: 查看 job，能够发现刚刚创立的JobNAME COMPLETIONS DURATION AGE batch-job 0/1 5s 5s -
kubectl get pods: 查看 pod，能够发现Job创立的 pod 正在运行NAME READY STATUS RESTARTS AGE batch-job-d59js 1/1 Running 0 10s -
kubectl get pods: 等两分钟后再查看 pod，能够发现Job创立的 pod 状态曾经变为Completed，即工作曾经实现。pod 未被删除，所以咱们能够查看 pod 的日志NAME READY STATUS RESTARTS AGE batch-job-d59js 0/1 Completed 0 2m56s -
kubectl logs pod batch-job-d59js: 查看 pod 的日志Sun Jun 7 22:36:04 UTC 2020 Batch job starting Sun Jun 7 22:38:04 UTC 2020 Finished succesfully -
kubectl get jobs: 再次查看 job，能够发现须要运行的 1 个 pod 曾经实现NAME COMPLETIONS DURATION AGE batch-job 1/1 2m45s 6m25s
在 Job 中运行多个 pod 实例 P114
在 Job 配置中设置 spec.completions 和 spec.parallelism 能够让 Job 创立多个 pod 实例，并容许以并行的形式运行它们。P114
基于 batch-job.yaml 创立一个新的形容文件 multi-completion-parallel-batch-job.yaml，并增加 spec.completions 和 spec.parallelism 属性，指定须要胜利运行实现 5 个 pod，最多 2 个 pod 并行运行：P115
...
spec:
# 必须确保 5 个 pod 运行实现
completions: 5
# 最多 2 个 pod 能够并行运行
parallelism: 2
...kubectl create -f multi-completion-parallel-batch-job.yaml: 依据形容文件创建指定的Job-
kubectl get pods: 查看运行的 pod，能够发现共有两个 pod 正在运行。只有一个 pod 运行实现，Job将运行下一个 pod，直至 5 个 pod 都胜利实现NAME READY STATUS RESTARTS AGE multi-completion-parallel-batch-job-fpwv5 1/1 Running 0 37s multi-completion-parallel-batch-job-m4cqw 1/1 Running 0 37s
限度 Job pod 实现工作的工夫 P116
Pod.spec.activeDeadlineSeconds: 能够指定一个 pod 最长存活工夫，超时则终止 pod 并标记Job失败，能够用来限度 pod 实现工作的工夫Job.spec.backoffLimit: 能够配置一个Job在被标记为失败前最多尝试的次数，默认为 6 次
安顿 Job 定期运行或在未来运行一次 P116
创立一个 CronJob P116
为了每 15 分钟运行一次后面的工作，咱们须要创立以下 cronjob.yaml 形容文件：
# 遵循 batch/v1beta1 版本的 Kubernetes API
apiVersion: batch/v1beta1
# 资源类型为 CronJob
kind: CronJob
metadata:
# Job 的名称
name: batch-job-every-fifteen-minutes
spec:
# Cron 表达式表明当前任务在每天每小时的 0, 15, 30, 45 分运行
schedule: "0,15,30,45 * * * *"
# 指定最迟必须在预约工夫后 15 秒内开始运行，否则就标记为一次失败的 `Job`
startingDeadlineSeconds: 15
# 创立 Job 应用的模版（能够发现和 batch-job.yaml 的 spec 局部基本一致）jobTemplate:
spec:
# 启动 pod 应用的模版
template:
metadata:
# 指定标签为 app=periodic-batch-job
labels:
app: periodic-batch-job
spec:
# Job 不能应用 Always 为默认的重启策略
restartPolicy: OnFailure
containers:
# 容器的名称
- name: main
# 创立容器所应用的镜像
image: idealism/batch-jobkubectl get cronjobs: 能够查看所有的 CronJob
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
batch-job-every-fifteen-minutes 0,15,30,45 * * * * False 0 <none> 8sCronJob 总是为打算中配置的每个执行创立一个 Job，但可能会有以下两种问题：
- 同时创立两个
Job：保障工作是幂等的 - 没有创立
Job：保障下一个工作能运行实现错过的任何工作
本文首发于公众号：满赋诸机（点击查看原文）开源在 GitHub：reading-notes/kubernetes-in-action
