前言
在上文Kubernetes Pod操作篇介紹了kubernetes的核心組件Pod，本文繼續介紹kubernetes的副本機制，正是因為副本機制你的部署能自動保待運行，並且保持健康，無須任何手動干預。
探針
kubernetes可以通過存活探針(liveness probe)檢查容器是否還在運行。可以為pod中的每個容器單獨指定存活探針；如果探測失敗，kubernetes將定期執行探針並重新啟動容器；
kubernetes有以下三種探測容器的機制：
- HTTP GET探針對容器的IP地址執行HTTP GET請求；
- TCP套接字探針嘗試與容器指定端口建立TCP連接；
- Exec探針在容器內執行任意命令，並檢查命令的退出狀態碼。
1.準備鏡像
1.1 準備App.js
為了測試探針的作用，需要準備新的鏡像；在之前的服務中稍作改動，在第五個請求之後，給每個請求返回HTTP狀態碼500(Internal Server Error)，app.js做如下改動：
<code>const http = require('http');
const os = require('os');
console.log("kubia server is starting...");
var requestCount = 0;
var handler = function(request,response){
console.log("Received request from " + request.connection.remoteAddress);
requestCount++;
if (requestCount > 5) {
response.writeHead(500);
response.end("I'm not well. Please restart me!");
return;
}
response.writeHead(200);
response.end("You've hit " + os.hostname()+"\n");
};
var www = http.createServer(handler);
www.listen(8080);/<code>requestCount記錄請求的次數，大於5次直接返回500狀態碼，這樣探針可以捕獲狀態碼進行服務器重啟；
1.2 構建鏡像
<code>[root@localhost unhealthy]# docker build -t kubia-unhealthy . Sending build context to Docker daemon 3.584kB Step 1/3 : FROM node:7 ---> d9aed20b68a4 Step 2/3 : ADD app.js /app.js ---> e9e1b44f8f54 Step 3/3 : ENTRYPOINT ["node","app.js"] ---> Running in f58d6ff6bea3 Removing intermediate container f58d6ff6bea3 ---> d36c6390ec66 Successfully built d36c6390ec66 Successfully tagged kubia-unhealthy:latest/<code>
通過docker build構建kubia-unhealthy鏡像
1.3 推送鏡像
<code>[root@localhost unhealthy]# docker tag kubia-unhealthy ksfzhaohui/kubia-unhealthy [root@localhost unhealthy]# docker login Authenticating with existing credentials... WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded [root@localhost unhealthy]# docker push ksfzhaohui/kubia-unhealthy The push refers to repository [docker.io/ksfzhaohui/kubia-unhealthy] 40d9e222a827: Pushed ...... latest: digest: sha256:5fb3ebeda7f98818bc07b2b1e3245d6a21014a41153108c4dcf52f2947a4dfd4 size: 2213/<code>
首先給鏡像附加標籤，然後登錄docker hub，最後推送到docker hub：
2.探針實戰
2.1 Http探針YAML文件
創建YAML描述文件，指定了一個Http Get存活探針，告訴Kubernetes定期在端口路徑下執行Http Get請求，以確定容器是否健康；
<code>apiVersion: v1
kind: Pod
metadata:
name: kubia-liveness
spec:
containers:
- image: ksfzhaohui/kubia-unhealthy
name: kubia
livenessProbe:
httpGet:
path: /
port: 8080/<code>2.2 創建Pod
<code>[d:\k8s]$ kubectl create -f kubia-liveness-probe.yaml pod/kubia-liveness created [d:\k8s]$ kubectl get pods NAME READY STATUS RESTARTS AGE kubia-liveness 0/1 ContainerCreating 0 3s/<code>
創建名稱為kubia-liveness的Pod，查看的RESTARTS為0，隔一段時間再次觀察：
<code>[d:\k8s]$ kubectl get pods NAME READY STATUS RESTARTS AGE kubia-liveness 1/1 Running 2 4m/<code>
觀察可以發現此時的RESTARTS=2，表示重啟了2次，因為每次探測都會發送http請求，而服務在接收5次請求之後會返回500狀態碼，Kubernetes探測之後就會重啟容器；
2.3 Pod探針描述
<code>[d:\k8s]$ kubectl describe po kubia-liveness
Name: kubia-liveness
......
State: Running
Started: Mon, 23 Dec 2019 15:42:45 +0800
Last State: Terminated
Reason: Error
Exit Code: 137
Started: Mon, 23 Dec 2019 15:41:15 +0800
Finished: Mon, 23 Dec 2019 15:42:42 +0800
Ready: True
Restart Count: 2
Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
......
Warning Unhealthy 85s (x9 over 5m5s) kubelet, minikube Liveness probe failed: HTTP probe failed with statuscode: 500
Normal Killing 85s (x3 over 4m45s) kubelet, minikube Container kubia failed liveness probe, will be restarted
....../<code>State：當前狀態是運行中；
Last State：最後的狀態是終止，原因是出現了錯誤，退出代碼為137有特殊的含義：表示該進程由外部信號終止，數字137是兩個數字的總和：128+x, 其中x是終止進程的信號編號，這裡x=9是SIGKILL的信號編號，意味著這個進程被強行終止；
Restart Count：重啟的次數；
Liveness：存活探針的附加信息，delay(延遲）、timeout(超時）、period(週期）；大致意思就是開始探測延遲為0秒，探測超時時間為1秒，每隔10秒檢測一次，探測連續失敗三次重啟容器；定義探針時可以自定義這些參數，比如initialDelaySeconds設置初始延遲等；
Events：列出了發生的事件，比如探測到失敗，殺進程，重啟容器等；
3.探針總結
首先生產環境運行的pod一定要配置探針；其次探針一定要檢查程序的內部，不受外部因數影響比如外部服務，數據庫等；最後就是探針應該足夠輕量。
以上方式創建的pod，kubernetes在使用探針發現服務不可能就會重啟服務，這項任務由承載pod的節點上的Kubelet執行，在主服務器上運行的Kubernetes Control Plane組件不會參與此過程；但如果節點本身崩潰，由於Kubelet本身運行在節點上，所以如果節點異常終止，它將無法執行任何操作，這時候就需要ReplicationController或類似機制管理pod。
ReplicationController
ReplicationController是一種kubernetes資源，可確保它的pod始終保持運行狀態；如果pod因任何原因消失(包括節點崩潰)，則ReplicationController會重新創建Pod；
ReplicationController會持續監控正在運行的pod列表，是確保pod的數量始終與其標籤選擇器匹配，一個ReplicationController有三個主要部分：
- label selector(標籤選擇器)，用於確定ReplicationController作用域中有哪些pod；
- replica count(副本個數)，指定應運行的pod數量；
- pod template(pod模板)，用於創建新的pod副本。
以上三個屬性可以隨時修改，但是隻有副本個數修改對當前pod會有影響，比如當前副本數量減少了，那當前pod有可能會被刪除；ReplicationController提供的好處：
- 確保一個pod(或多個pod副本)持續運行，失敗重啟新pod；
- 集群節點發生故障時，它將為故障節點上運行的所有pod創建副本；
- 輕鬆實現pod的水平伸縮。
1.創建ReplicationController
<code>apiVersion: v1
kind: ReplicationController
metadata:
name: kubia
spec:
replicas: 3
selector:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: ksfzhaohui/kubia
ports:
- containerPort: 8080/<code>指定了類型為ReplicationController，名稱為kubia；replicas設置副本為3，selector為標籤選擇器，template為pod創建的模版，三個要素都指定了，執行創建命令：
<code>[d:\k8s]$ kubectl create -f kubia-rc.yaml replicationcontroller/kubia created [d:\k8s]$ kubectl get pods NAME READY STATUS RESTARTS AGE kubia-dssvz 1/1 Running 0 73s kubia-krlcr 1/1 Running 0 73s kubia-tg29c 1/1 Running 0 73s/<code>
創建完之後等一會執行獲取pod列表可以發現創建了三個容器，刪除其中一個，再次觀察：
<code>[d:\k8s]$ kubectl delete pod kubia-dssvz pod "kubia-dssvz" deleted [d:\k8s]$ kubectl get pods NAME READY STATUS RESTARTS AGE kubia-dssvz 1/1 Terminating 0 2m2s kubia-krlcr 1/1 Running 0 2m2s kubia-mgz64 1/1 Running 0 11s kubia-tg29c 1/1 Running 0 2m2s/<code>
被刪除的pod結束中，新的pod已經啟動，獲取有關ReplicationController的信息：
<code>[d:\k8s]$ kubectl get rc NAME DESIRED CURRENT READY AGE kubia 3 3 3 4m20s/<code>
期望3個副本，當前3個副本，準備好的也是3個，更詳細的可以使用describe命令：
<code>[d:\k8s]$ kubectl describe rc kubia Name: kubia Namespace: default Selector: app=kubia Labels: app=kubia Annotations: Replicas: 3 current / 3 desired Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: ...... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 5m20s replication-controller Created pod: kubia-dssvz Normal SuccessfulCreate 5m20s replication-controller Created pod: kubia-tg29c Normal SuccessfulCreate 5m20s replication-controller Created pod: kubia-krlcr Normal SuccessfulCreate 3m29s replication-controller Created pod: kubia-mgz64 Normal SuccessfulCreate 75s replication-controller Created pod: kubia-vwnmf/<code>
Replicas顯示副本期望數和當前數，Pods Status顯示每種狀態下的副本數，最後的Events為發生的事件，測試一共刪除2個pod，可以看到一個創建了5個pod；
注：因為使用的是Minikube，只有一個節點同時充當主節點和工作節點，節點故障無法模擬。
2.修改標籤
通過更改pod的標籤，可以將它從ReplicationController的作用域中添加或刪除：
<code>[d:\k8s]$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS kubia-mgz64 1/1 Running 0 27m app=kubia kubia-tg29c 1/1 Running 0 28m app=kubia kubia-vwnmf 1/1 Running 0 24m app=kubia [d:\k8s]$ kubectl label pod kubia-mgz64 app=foo --overwrite pod/kubia-mgz64 labeled [d:\k8s]$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS kubia-4dzw8 0/1 ContainerCreating 0 2s app=kubia kubia-mgz64 1/1 Running 0 27m app=foo kubia-tg29c 1/1 Running 0 29m app=kubia kubia-vwnmf 1/1 Running 0 25m app=kubia/<code>
可以發現初始創建的是三個Pod標籤都是app=kubia，當把kubia-mgz64的標籤設置為foo之後就脫離了當前ReplicationController的控制，這樣ReplicationController控制的副本就變成了2個，所以會里面重新創建一個Pod；脫離控制的Pod還是照常運行，除非我們手動刪除；
<code>[d:\k8s]$ kubectl delete pod kubia-mgz64 pod "kubia-mgz64" deleted [d:\k8s]$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS kubia-4dzw8 1/1 Running 0 20h app=kubia kubia-tg29c 1/1 Running 0 21h app=kubia kubia-vwnmf 1/1 Running 0 21h app=kubia/<code>
3.修改Pod模版
ReplicationController的pod模板可以隨時修改：
<code>[d:\k8s]$ kubectl edit rc kubia ...... replicationcontroller/kubia edited/<code>
使用如上命令即可，會彈出文本編輯器，修改Pod模版標籤，如下所示：
<code> template:
metadata:
creationTimestamp: null
labels:
app: kubia
type: special/<code>添加新的標籤type：special，保存退出即可；修改Pod模版之後並不影響現有的pod，只會影響重新創建的pod：
<code>[d:\k8s]$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS kubia-4dzw8 1/1 Running 0 21h app=kubia kubia-tg29c 1/1 Running 0 21h app=kubia kubia-vwnmf 1/1 Running 0 21h app=kubia [d:\k8s]$ kubectl delete pod kubia-4dzw8 pod "kubia-4dzw8" deleted [d:\k8s]$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS kubia-6qrxj 1/1 Running 0 2m12s app=kubia,type=special kubia-tg29c 1/1 Running 0 21h app=kubia kubia-vwnmf 1/1 Running 0 21h app=kubia/<code>
刪除一個pod，重新創建的pod有了新的標籤；
4.水平縮放pod
通過文本編輯器來修改副本數，修改spec.replicas為5
<code>[d:\k8s]$ kubectl edit rc kubia replicationcontroller/kubia edited [d:\k8s]$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS kubia-6qrxj 1/1 Running 0 9m49s app=kubia,type=special kubia-9crmf 0/1 ContainerCreating 0 4s app=kubia,type=special kubia-qpwbl 0/1 ContainerCreating 0 4s app=kubia,type=special kubia-tg29c 1/1 Running 0 21h app=kubia kubia-vwnmf 1/1 Running 0 21h app=kubia/<code>
可以發現自動創建了2個Pod，達到副本數5；通過kubectl scale重新修改為3：
<code>[d:\k8s]$ kubectl scale rc kubia --replicas=3 replicationcontroller/kubia scaled [d:\k8s]$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS kubia-6qrxj 1/1 Running 0 15m app=kubia,type=special kubia-tg29c 1/1 Running 0 22h app=kubia kubia-vwnmf 1/1 Running 0 21h app=kubia/<code>
5.刪除ReplicationController
通過kubectl delete刪除ReplicationController時默認會刪除pod，但是也可以指定不刪除：
<code>[d:\k8s]$ kubectl delete rc kubia --cascade=false replicationcontroller "kubia" deleted [d:\k8s]$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS kubia-6qrxj 1/1 Running 0 103m app=kubia,type=special kubia-tg29c 1/1 Running 0 23h app=kubia kubia-vwnmf 1/1 Running 0 23h app=kubia [d:\k8s]$ kubectl get rc kubia Error from server (NotFound): replicationcontrollers "kubia" not found/<code>
--cascade=false可以不刪除pod，只刪除ReplicationController
ReplicaSet
ReplicaSet是新一代ReplicationController，將完全替代ReplicationController；ReplicaSet的行為與ReplicationController完全相同，但pod選擇器的表達能力更強；
1.創建ReplicaSet
<code>apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: kubia
spec:
replicas: 3
selector:
matchLabels:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: ksfzhaohui/kubia/<code>apiVersion指定為apps/v1：apps表示API組，v1表示實際的API版本；如果是在核心的API組中，API是可以不用指定的，比如之前的ReplicationController只需要指定v1；
其他定義基本和ReplicationController類似，除了在selector下使用了matchLabels選擇器；
<code>[d:\k8s]$ kubectl create -f kubia-replicaset.yaml replicaset.apps/kubia created [d:\k8s]$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS kubia-6qrxj 1/1 Running 0 150m app=kubia,type=special kubia-tg29c 1/1 Running 0 24h app=kubia kubia-vwnmf 1/1 Running 0 24h app=kubia [d:\k8s]$ kubectl get rs NAME DESIRED CURRENT READY AGE kubia 3 3 3 49s/<code>
創建完ReplicaSet之後，重新接管了原來的3個pod；更詳細的可以使用describe命令：
<code>[d:\k8s]$ kubectl describe rs
Name: kubia
Namespace: default
Selector: app=kubia
Labels:
Annotations:
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=kubia
Containers:
kubia:
Image: ksfzhaohui/kubia
Port:
Host Port:
Environment:
Mounts:
Volumes:
Events: /<code>可以看到Events事件列表為空，當前的3個pod都是接管的原來已經創建的pod；
2.ReplicaSet標籤選擇器
ReplicaSet相對於ReplicationController的主要改進是它更具表達力的標籤選擇器；
<code> selector:
matchExpressions:
- key: app
operator: In
values:
- kubia/<code>ReplicaSet除了可以使用matchLabels，還可以使用功能更強大的matchExpressions；每個表達式都必須包含一個key、一個operator(運算符)、可能還有一個values的列表，運算符可以有：
- In：Label的值必須與其中一個指定的values匹配；
- Notln：Label的值與任何指定的values不匹配；
- Exists：pod必須包含一個指定名稱的標籤，使用此運算符時，不應指定values字段；
- DoesNotExist：pod不得包含有指定名稱的標籤，不應指定values字段；
3.刪除ReplicaSet
<code>[d:\k8s]$ kubectl delete rs kubia replicaset.apps "kubia" deleted [d:\k8s]$ kubectl get pods --show-labels No resources found in default namespace./<code>
刪除ReplicaSet的同時會刪除其管理的pod；
DaemonSet
Replicationcontroller和ReplicaSet都用於在kubernetes集群上運行部署特定數量的pod；而DaemonSet可以在所有集群節點上運行一個pod，比如希望在每個節點上運行日誌收集器和資源監控器；當然也可以通過節點選擇器控制只有哪些節點運行pod；
1.創建DaemonSet
<code>apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ssd-monitor
spec:
selector:
matchLabels:
app: ssd-monitor
template:
metadata:
labels:
app: ssd-monitor
spec:
nodeSelector:
disk: ssd
containers:
- name: main
image: ksfzhaohui/kubia/<code>準備如上創建DaemonSet的YAML文件，以上屬性基本和ReplicaSet類似，除了nodeSelector也就是節點選擇器，指定了選擇disk=ssd標籤；
的節點標籤；
<code>[d:\k8s]$ kubectl create -f ssd-monitor-daemonset.yaml daemonset.apps/ssd-monitor created [d:\k8s]$ kubectl get ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE ssd-monitor 0 0 0 0 0 disk=ssd 24s [d:\k8s]$ kubectl get pods --show-labels No resources found in default namespace./<code>
創建完之後，並沒有給當前節點創建pod，因為當前節點沒有指定disk=ssd標籤；
<code>[d:\k8s]$ kubectl get node NAME STATUS ROLES AGE VERSION minikube Ready master 8d v1.17.0 [d:\k8s]$ kubectl label node minikube disk=ssd node/minikube labeled [d:\k8s]$ kubectl get node --show-labels NAME STATUS ROLES AGE VERSION LABELS minikube Ready master 8d v1.17.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disk=ssd,gpu=true,kubernetes.io/arch=amd64,kubernetes.io/hostname=minikube,kubernetes.io/os=linux,node-role.kubernetes.io/master= [d:\k8s]$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS ssd-monitor-84hxd 1/1 Running 0 31s app=ssd-monitor,controller-revision-hash=5dc77f567d,pod-template-generation=1/<code>
首先獲取當前節點名稱為minikube，然後設置標籤disk=ssd，這時候會自動在當前節點創建一個pod，因為在minikube中只有一個節點不好在多個節點上模擬；
2.刪除pod和DaemonSet
<code>[d:\k8s]$ kubectl label node minikube disk=hdd --overwrite node/minikube labeled [d:\k8s]$ kubectl get pods --show-labels No resources found in default namespace./<code>
修改節點minkube的標籤，可以發現節點上的pod會自動刪除，因為不滿足節點選擇器；
<code>[d:\k8s]$ kubectl delete ds ssd-monitor daemonset.apps "ssd-monitor" deleted [d:\k8s]$ kubectl get ds No resources found in default namespace./<code>
刪除DaemonSet也會一起刪除這些pod；
Job
ReplicationController、ReplicaSet和DaemonSet會持續運行任務，永遠達不到完成態，這些pod中的進程在退出時會重新啟動；kubernetes通過Job資源允許你運行一種pod, 該pod在內部進程成功結束時，不重啟容器，一旦任務完成，pod就被認為處千完成狀態；
在發生節點故障時，該節點上由Job管理的pod，重新安排到其他節點；如果進程本身異常退出，可以將Job配置為重新啟動容器；
1.創建Job
在創建Job前先準備一個構建在busybox的鏡像，該容器將調用sleep 命令兩分鐘：
<code>FROM busybox ENTRYPOINT echo "$(date) Batch job starting"; sleep 120; echo "$(date) Finished succesfully"/<code>
此鏡像已經推送到docker hub：
<code>apiVersion: batch/v1
kind: Job
metadata:
name: batch-job
spec:
template:
metadata:
labels:
app: batch-job
spec:
restartPolicy: OnFailure
containers:
- name: main
image: ksfzhaohui/batch-job/<code>Job屬於batch API組，其中重要的屬性是restartPolicy默認為Always表示無限期運行，其他選項還有OnFailure或Never，表示進程失敗重啟和不重啟；
<code>[d:\k8s]$ kubectl create -f exporter.yaml job.batch/batch-job created [d:\k8s]$ kubectl get job NAME COMPLETIONS DURATION AGE batch-job 0/1 7s 8s [d:\k8s]$ kubectl get pod NAME READY STATUS RESTARTS AGE batch-job-7sw68 1/1 Running 0 25s/<code>
創建Job，會自動創建一個pod，pod中的進程運行2分鐘後會結束：
<code>[d:\k8s]$ kubectl get pod NAME READY STATUS RESTARTS AGE batch-job-7sw68 0/1 Completed 0 3m1s [d:\k8s]$ kubectl get job NAME COMPLETIONS DURATION AGE batch-job 1/1 2m11s 3m12s/<code>
可以發現pod狀態為Completed，同樣job的COMPLETIONS同樣為完成；
2.Job中運行多個pod實例
作業可以配置為創建多個pod實例，並以並行或串行方式運行它們；可以通過設置completions和parallelism屬性來完成；
2.1 順序運行Job pod
<code>apiVersion: batch/v1
kind: Job
metadata:
name: multi-completion-batch-job
spec:
completions: 3
template:
metadata:
labels:
app: multi-completion-batch-job
spec:
restartPolicy: OnFailure
containers:
- name: main
image: ksfzhaohui/batch-job/<code>completions設置為3，一個一個的運行3個pod，所有完成整個job完成；
<code>[d:\k8s]$ kubectl get pod NAME READY STATUS RESTARTS AGE multi-completion-batch-job-h75j8 0/1 Completed 0 2m19s multi-completion-batch-job-wdhnj 1/1 Running 0 15s [d:\k8s]$ kubectl get job NAME COMPLETIONS DURATION AGE multi-completion-batch-job 1/3 2m28s 2m28s/<code>
可以看到完成一個pod之後會啟動第二pod，所有都運行完之後如下所示：
<code>[d:\k8s]$ kubectl get pod NAME READY STATUS RESTARTS AGE multi-completion-batch-job-4vjff 0/1 Completed 0 2m7s multi-completion-batch-job-h75j8 0/1 Completed 0 6m16s multi-completion-batch-job-wdhnj 0/1 Completed 0 4m12s [d:\k8s]$ kubectl get job NAME COMPLETIONS DURATION AGE multi-completion-batch-job 3/3 6m13s 6m18s/<code>
2.2 並行運行Job pod
<code>apiVersion: batch/v1
kind: Job
metadata:
name: multi-completion-parallel-batch-job
spec:
completions: 3
parallelism: 2
template:
metadata:
labels:
app: multi-completion-parallel-batch-job
spec:
restartPolicy: OnFailure
containers:
- name: main
image: ksfzhaohui/batch-job/<code>同時設置了completions和parallelism，表示job可以同時運行兩個pod，其中任何一個執行完成可以運行第三個pod：
<code>[d:\k8s]$ kubectl create -f multi-completion-parallel-batch-job.yaml job.batch/multi-completion-parallel-batch-job created [d:\k8s]$ kubectl get pod NAME READY STATUS RESTARTS AGE multi-completion-parallel-batch-job-f7wn8 0/1 ContainerCreating 0 3s multi-completion-parallel-batch-job-h9s29 0/1 ContainerCreating 0 3s/<code>
2.3 限制Job pod完成任務的時間
在pod配置中設置activeDeadlineSeconds屬性，可以限制pod的時間；如果pod運行時間超過此時間，系統將嘗試終止pod, 並將Job標記為失敗；
<code>apiVersion: batch/v1
kind: Job
metadata:
name: time-limited-batch-job
spec:
activeDeadlineSeconds: 30
template:
metadata:
labels:
app: time-limited-batch-job
spec:
restartPolicy: OnFailure
containers:
- name: main
image: ksfzhaohui/batch-job/<code> 指定activeDeadlineSeconds為30秒，超過30秒自動失敗；
<code>[d:\k8s]$ kubectl create -f time-limited-batch-job.yaml job.batch/time-limited-batch-job created [d:\k8s]$ kubectl get job NAME COMPLETIONS DURATION AGE time-limited-batch-job 0/1 3s 3s [d:\k8s]$ kubectl get pod NAME READY STATUS RESTARTS AGE time-limited-batch-job-jgmm6 1/1 Running 0 29s [d:\k8s]$ kubectl get pod NAME READY STATUS RESTARTS AGE time-limited-batch-job-jgmm6 1/1 Terminating 0 30s [d:\k8s]$ kubectl get pod No resources found in default namespace. [d:\k8s]$ kubectl get job NAME COMPLETIONS DURATION AGE time-limited-batch-job 0/1 101s 101s/<code>
可以觀察AGE標籤下面的時間表示已經運行的時間，30秒之後pod狀態變成Terminating；
2.4 Job定期運行
job也支持定期執行，有點像quartz，也支持類似的quartz表達式：
<code>apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: corn-batch-job
spec:
schedule: "0-59 * * * *"
jobTemplate:
spec:
template:
metadata:
labels:
app: corn-batch-job
spec:
restartPolicy: OnFailure
containers:
- name: main
image: ksfzhaohui/batch-job/<code>指定schedule用來表示表達式分別是：分鐘，小時，每個月中的第幾天，月，星期幾；以上配置表示每分鐘運行一個job；
<code>[d:\k8s]$ kubectl create -f cronjob.yaml cronjob.batch/corn-batch-job created [d:\k8s]$ kubectl get pod NAME READY STATUS RESTARTS AGE corn-batch-job-1577263560-w2fq2 0/1 Completed 0 3m3s corn-batch-job-1577263620-92pc7 1/1 Running 0 2m2s corn-batch-job-1577263680-tmr8p 1/1 Running 0 62s corn-batch-job-1577263740-jmzqk 0/1 ContainerCreating 0 2s [d:\k8s]$ kubectl get job NAME COMPLETIONS DURATION AGE corn-batch-job-1577263560 1/1 2m5s 3m48s corn-batch-job-1577263620 1/1 2m4s 2m47s corn-batch-job-1577263680 0/1 107s 107s corn-batch-job-1577263740 0/1 47s 47s/<code>
每個一分鐘就運行一個job，可以刪除CronJob
<code>[d:\k8s]$ kubectl delete CronJob corn-batch-job cronjob.batch "corn-batch-job" deleted/<code>
總結
本文繼續在閱讀Kubernetes in Action過程中，實際操作的筆記；主要介紹了相關的副本機制探針，ReplicationController，ReplicaSet，DaemonSet以及Job相關知識點。
參考
Kubernetes in Action
博客地址
https://github.com/ksfzhaohui/blog
