計算機系統(tǒng)
5G云計算
第三章 LINUX Kubernetes Pod控制器
一、Pod控制器及其功用
Pod控制器，又稱之為工作負載（workload），是用于實現管理pod的中間層，確保pod資源符合預期的狀態(tài)，pod的資源出現故障時，會嘗試進行重啟，當根據重啟策略無效，則會重新新建pod的資源
二.pod控制器有多種類型
1.ReplicaSet
代用戶創(chuàng)建指定數量的pod副本，確保pod副本數量符合預期狀態(tài)，并且支持滾動式自動擴容和縮容功能
ReplicaSet主要三個組件組成：
（1）用戶期望的pod副本數量
（2）標簽選擇器，判斷哪個pod歸自己管理
（3）當現存的pod數量不足，會根據pod資源模板進行新建
幫助用戶管理無狀態(tài)的pod資源，精確反應用戶定義的目標數量，但是RelicaSet不是直接使用的控制器，而是使用Deployment
2.Deployment
工作在ReplicaSet之上，用于管理無狀態(tài)應用，目前來說最好的控制器。支持滾動更新和回滾功能，還提供聲明式配置
ReplicaSet 與Deployment 這兩個資源對象逐步替換之前RC的作用
3.DaemonSet
用于確保集群中的每一個節(jié)點只運行特定的pod副本，通常用于實現系統(tǒng)級后臺任務。比如ELK服務
特性：服務是無狀態(tài)的
服務必須是守護進程
4.StatefulSet
管理有狀態(tài)應用
5.Cronjob
周期性任務控制，不需要持續(xù)后臺運行
三、Pod與控制器之間的關系
controllers：在集群上管理和運行容器的 pod 對象， pod 通過 label-selector 相關聯(lián)
Pod 通過控制器實現應用的運維，如伸縮，升級等
1.Deployment
部署無狀態(tài)應用
管理Pod和ReplicaSet
具有上線部署、副本設定、滾動升級、回滾等功能
提供聲明式更新，例如只更新一個新的image
應用場景：web服務
//示例：
vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
kubectl apply -f nginx-deployment.yaml
kubectl get pods,deploy,rs
//查看控制器配置
kubectl edit deployment/nginx-deployment
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: "2021-04-19T08:13:50Z"
generation: 1
labels:
app: nginx #Deployment資源的標簽
name: nginx-deployment
namespace: default
resourceVersion: "167208"
selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
uid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:
progressDeadlineSeconds: 600
replicas: 3 #期望的pod數量，默認是1
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 25% #升級過程中會先啟動的新Pod的數量不超過期望的Pod數量的25%，也可以是一個絕對值
maxUnavailable: 25% #升級過程中在新的Pod啟動好后銷毀的舊Pod的數量不超過期望的Pod數量的25%，也可以是一個絕對值
type: RollingUpdate #滾動升級
template:
metadata:
creationTimestamp: null
labels:
app: nginx #Pod副本關聯(lián)的標簽
spec:
containers:
- image: nginx:1.15.4 #鏡像名稱
imagePullPolicy: IfNotPresent #鏡像拉取策略
name: nginx
ports:
- containerPort: 80 #容器暴露的監(jiān)聽端口
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always #容器重啟策略
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
......
//查看歷史版本
kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
1 <none>
2.SatefulSet
部署有狀態(tài)應用
穩(wěn)定的持久化存儲，即Pod重新調度后還是能訪問到相同的持久化數據，基于PVC來實現
穩(wěn)定的網絡標志，即Pod重新調度后其PodName和HostName不變，基于Headless Service（即沒有Cluster IP的Service）來實現
有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次進行（即從0到N-1，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態(tài)），基于init containers來實現
有序收縮，有序刪除（即從N-1到0）
常見的應用場景：數據庫
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # has to match .spec.template.metadata.labels
serviceName: "nginx"
replicas: 3 # by default is 1
template:
metadata:
labels:
app: nginx # has to match .spec.selector.matchLabels
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
resources:
requests:
storage: 1Gi
從上面的應用場景可以發(fā)現，StatefulSet由以下幾個部分組成：
1）Headless Service（無頭服務）：用于為Pod資源標識符生成可解析的DNS記錄。
2）volumeClaimTemplates（存儲卷申請模板）：基于靜態(tài)或動態(tài)PV供給方式為Pod資源提供專有的固定存儲。
3）StatefulSet：用于管控Pod資源。
1）為什么要有headless
在deployment中，每一個pod是沒有名稱，是隨機字符串，是無序的。而statefulset中是要求有序的，每一個pod的名稱必須是固定的。當節(jié)點掛了，重建之后的標識符是不變的，每一個節(jié)點的節(jié)點名稱是不能改變的。pod名稱是作為pod識別的唯一標識符，必須保證其標識符的穩(wěn)定并且唯一
為了實現標識符的穩(wěn)定，這時候就需要一個headless service 解析直達到pod，還需要給pod配置一個唯一的名稱
2）為什么要有volumeClaimTemplate
大部分有狀態(tài)副本集都會用到持久存儲，比如分布式系統(tǒng)來說，由于數據是不一樣的，每個節(jié)點都需要自己專用的存儲節(jié)點。而在 deployment中pod模板中創(chuàng)建的存儲卷是一個共享的存儲卷，多個pod使用同一個存儲卷，而statefulset定義中的每一個pod都不能使用同一個存儲卷，由此基于pod模板創(chuàng)建pod是不適應的，這就需要引入volumeClaimTemplate，當在使用statefulset創(chuàng)建pod時，會自動生成一個PVC，從而請求綁定一個PV，從而有自己專用的存儲卷
服務發(fā)現：就是應用服務之間相互定位的過程。
應用場景：
●動態(tài)性強：Pod會飄到別的node節(jié)點
●更新發(fā)布頻繁：互聯(lián)網思維小步快跑，先實現再優(yōu)化，老板永遠是先上線再慢慢優(yōu)化，先把idea變成產品掙到錢然后再慢慢一點一點優(yōu)化
●支持自動伸縮：一來大促，肯定是要擴容多個副本
3）K8S里服務發(fā)現的方式—DNS
使K8S集群能夠自動關聯(lián)Service資源的“名稱”和“CLUSTER-IP”，從而達到服務被集群自動發(fā)現的目的
實現K8S里DNS功能的插件：
●skyDNS：Kubernetes 1.3之前的版本
●kubeDNS：Kubernetes 1.3至Kubernetes 1.11
●CoreDNS：Kubernetes 1.11開始至今
//安裝CoreDNS，僅二進制部署環(huán)境需要安裝CoreDNS
方法一：
下載鏈接：https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.base
vim transforms2sed.sed
s/__DNS__SERVER__/10.0.0.2/g
s/__DNS__DOMAIN__/cluster.local/g
s/__DNS__MEMORY__LIMIT__/170Mi/g
s/__MACHINE_GENERATED_WARNING__/Warning: This is a file generated from the base underscore template file: coredns.yaml.base/g
sed -f transforms2sed.sed coredns.yaml.base > coredns.yaml
方法二：上傳 coredns.yaml 文件
kubectl apply -f coredns.yaml
kubectl get pods -n kube-system
4）示例
//查看statefulset的定義
kubectl explain statefulset
KIND: StatefulSet
VERSION: apps/v1
DESCRIPTION:
StatefulSet represents a set of pods with consistent identities. Identities
are defined as: - Network: A single stable DNS and hostname. - Storage: As
many VolumeClaims as requested. The StatefulSet guarantees that a given
network identity will always map to the same storage identity.
FIELDS:
apiVersion <string>
kind <string>
metadata <Object>
spec <Object>
status <Object>
kubectl explain statefulset.spec
KIND: StatefulSet
VERSION: apps/v1
RESOURCE: spec <Object>
DESCRIPTION:
Spec defines the desired identities of pods in this set.
A StatefulSetSpec is the specification of a StatefulSet.
FIELDS:
podManagementPolicy <string> #Pod管理策略
replicas <integer> #副本數量
revisionHistoryLimit <integer> #歷史版本限制
selector <Object> -required- #選擇器，必選項
serviceName <string> -required- #服務名稱，必選項
template <Object> -required- #模板，必選項
updateStrategy <Object> #更新策略
volumeClaimTemplates <[]Object> #存儲卷申請模板，必選項
//清單定義StatefulSet
如上所述，一個完整的 StatefulSet 控制器由一個 Headless Service、一個 StatefulSet 和一個 volumeClaimTemplate 組成。如下資源清單中的定義：
vim stateful-demo.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp-svc
spec:
ports:
- port: 80
name: http
protocol: TCP
targetPort: 80
type: ClusterIP
clusterIP: None
selector:
app: myapp
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: myapp-sts
spec:
serviceName: myapp-svc
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: soscscs/myapp:v1
ports:
- containerPort: 80
volumeMounts:
- name: mypvc
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: mypvc
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: "nfs-client-storageclass" #動態(tài)PV創(chuàng)建時，在PVC里聲明一個StorageClass對象的標識進行關聯(lián)
resources:
requests:
storage: 2Gi
解析上例：由于 StatefulSet 資源依賴于一個實現存在的 Headless 類型的 Service 資源，所以需要先定義一個名為 myapp-svc 的 Headless Service 資源，用于為關聯(lián)到每個 Pod 資源創(chuàng)建 DNS 資源記錄。接著定義了一個名為 myapp 的 StatefulSet 資源，它通過 Pod 模板創(chuàng)建了 3 個 Pod 資源副本，并基于 volumeClaimTemplates 向前面創(chuàng)建的PV進行了請求大小為 2Gi 的專用存儲卷
//創(chuàng)建statefulset
kubectl apply -f stateful-demo.yaml
kubectl get svc #查看創(chuàng)建的無頭服務myapp-svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 4d19h
myapp-svc ClusterIP None <none> 80/TCP 93s
kubectl get sts #查看statefulset
NAME READY AGE
myapp-sts 3/3 19s
kubectl get pvc #查看pvc綁定
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mypvc-myapp-sts-0 Bound pvc-2bc50b0d-09f4-410d-890e-6d95344ab945 2Gi RWO nfs-client-storageclass 5m15s
mypvc-myapp-sts-1 Bound pvc-65162234-347e-4c07-8422-baa73ebd20ce 2Gi RWO nfs-client-storageclass 87s
mypvc-myapp-sts-2 Bound pvc-027ef87c-0764-4c20-9ac8-a20f6c9a7376 2Gi RWO nfs-client-storageclass 82s
kubectl get pv #查看pv綁定
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-027ef87c-0764-4c20-9ac8-a20f6c9a7376 2Gi RWO Delete Bound default/mypvc-myapp-sts-2 nfs-client-storageclass 2m4s
pvc-2bc50b0d-09f4-410d-890e-6d95344ab945 2Gi RWO Delete Bound default/mypvc-myapp-sts-0 nfs-client-storageclass 2m13s
pvc-65162234-347e-4c07-8422-baa73ebd20ce 2Gi RWO Delete Bound default/mypvc-myapp-sts-1 nfs-client-storageclass 2m9s
kubectl get pods #查看Pod信息
NAME READY STATUS RESTARTS AGE
myapp-sts-0 1/1 Running 0 2m11s
myapp-sts-1 1/1 Running 0 2m9s
myapp-sts-2 1/1 Running 0 2m8s
nfs-client-provisioner-55bbbfbb9f-bwrhm 1/1 Running 0 3m2s
//當刪除一個 StatefulSet 時，該 StatefulSet 不提供任何終止 Pod 的保證。為了實現 StatefulSet 中的 Pod 可以有序且體面地終止，可以在刪除之前將 StatefulSet 縮容到 0。
kubectl scale statefulset myappdata-myapp --replicas=0
kubectl delete -f stateful-demo.yaml
//此時PVC依舊存在的，再重新創(chuàng)建pod時，依舊會重新去綁定原來的pvc
kubectl apply -f stateful-demo.yaml
//滾動更新
//StatefulSet 控制器將在 StatefulSet 中刪除并重新創(chuàng)建每個 Pod。它將以與 Pod 終止相同的順序進行（從最大的序數到最小的序數），每次更新一個 Pod。在更新其前身之前，它將等待正在更新的 Pod 狀態(tài)變成正在運行并就緒。如下操作的滾動更新是按照2-0的順序更新。
vim stateful-demo.yaml #修改image版本為v2
.....
image: soscscs/myapp:v2
....
kubectl apply -f stateful-demo.yaml
kubectl get pods -w #查看滾動更新的過程
NAME READY STATUS RESTARTS AGE
myapp-sts-0 1/1 Running 0 18m
myapp-sts-1 1/1 Running 0 18m
myapp-sts-2 0/1 ContainerCreating 0 6s
nfs-client-provisioner-55bbbfbb9f-bwrhm 1/1 Running 0 19m
myapp-sts-2 1/1 Running 0 18s
myapp-sts-1 1/1 Terminating 0 18m
myapp-sts-1 0/1 Terminating 0 18m
myapp-sts-1 0/1 Terminating 0 19m
myapp-sts-1 0/1 Terminating 0 19m
myapp-sts-1 0/1 Pending 0 0s
myapp-sts-1 0/1 Pending 0 0s
myapp-sts-1 0/1 ContainerCreating 0 0s
myapp-sts-1 1/1 Running 0 1s
myapp-sts-0 1/1 Terminating 0 19m
myapp-sts-0 0/1 Terminating 0 19m
myapp-sts-0 0/1 Terminating 0 19m
myapp-sts-0 0/1 Terminating 0 19m
myapp-sts-0 0/1 Pending 0 0s
myapp-sts-0 0/1 Pending 0 0s
myapp-sts-0 0/1 ContainerCreating 0 0s
myapp-sts-0 1/1 Running 0 1s
//在創(chuàng)建的每一個Pod中，每一個pod自己的名稱都是可以被解析的
kubectl exec -it myapp-sts-0 sh
/ # nslookup myapp-sts-0.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve
Name: myapp-sts-0.myapp-svc.default.svc.cluster.local
Address 1: 10.244.1.18 myapp-sts-0.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-sts-1.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve
Name: myapp-sts-1.myapp-svc.default.svc.cluster.local
Address 1: 10.244.0.37 myapp-sts-1.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-sts-2.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve
Name: myapp-sts-2.myapp-svc.default.svc.cluster.local
Address 1: 10.244.1.19 myapp-sts-2.myapp-svc.default.svc.cluster.local
//從上面的解析，我們可以看到在容器當中可以通過對Pod的名稱進行解析到ip。其解析的域名格式如下：
(pod_name).(service_name).(namespace_name).svc.cluster.local
//擴展伸縮
kubectl scale sts myapp --replicas=4 #擴容副本增加到4個
kubectl get pods -w #動態(tài)查看擴容
kubectl get pv #查看pv綁定
kubectl patch sts myapp -p '{"spec":{"replicas":2}}' #打補丁方式縮容
kubectl get pods -w #動態(tài)查看縮容
5）總結
無狀態(tài)
1）deployment 認為所有的pod都是一樣的
2）不用考慮順序的要求
3）不用考慮在哪個node節(jié)點上運行
4）可以隨意擴容和縮容
有狀態(tài)
1）實例之間有差別，每個實例都有自己的獨特性，元數據不同，例如etcd，zookeeper
2）實例之間不對等的關系，以及依靠外部存儲的應用。
6）常規(guī)service和無頭服務區(qū)別
service：一組Pod訪問策略，提供cluster-IP群集之間通訊，還提供負載均衡和服務發(fā)現
Headless service：無頭服務，不需要cluster-IP，而是直接以DNS記錄的方式解析出被代理Pod的IP地址
vim pod6.yaml
apiVersion: v1
kind: Pod
metadata:
name: dns-test
spec:
containers:
- name: busybox
image: busybox:1.28.4
args:
- /bin/sh
- -c
- sleep 36000
restartPolicy: Never
vim sts.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: nginx-statefulset
namespace: default
spec:
serviceName: nginx
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
kubectl apply -f sts.yaml
kubectl apply -f pod6.yaml
kubectl get pods,svc
kubectl exec -it dns-test sh
/ # nslookup nginx-statefulset-0.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-1.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-2.nginx.default.svc.cluster.local
kubectl exec -it nginx-statefulset-0 bash
/# curl nginx-statefulset-0.nginx
/# curl nginx-statefulset-1.nginx
/# curl nginx-statefulset-2.nginx
四、DaemonSet
DaemonSet 確保全部（或者一些）Node 上運行一個 Pod 的副本。當有 Node 加入集群時，也會為他們新增一個 Pod 。當有 Node 從集群移除時，這些 Pod 也會被回收。刪除DaemonSet 將會刪除它創(chuàng)建的所有 Pod
使用 DaemonSet 的一些典型用法：
●運行集群存儲 daemon，例如在每個 Node 上運行 glusterd、ceph
●在每個 Node 上運行日志收集 daemon，例如fluentd、logstash
●在每個 Node 上運行監(jiān)控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond
應用場景：Agent
//官方案例（監(jiān)控）
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
示例：
vim ds.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-daemonSet
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
kubectl apply -f ds.yaml
//DaemonSet會在每個node節(jié)點都創(chuàng)建一個Pod
kubectl get pods -owide
五、Job
Job分為普通任務（Job）和定時任務（CronJob）
常用于運行那些僅需要執(zhí)行一次的任務
應用場景：數據庫遷移、批處理腳本、kube-bench掃描、離線數據處理，視頻解碼等業(yè)務
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
示例：
vim job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
//參數解釋
.spec.template.spec.restartPolicy該屬性擁有三個候選值：OnFailure，Never和Always。默認值為Always。它主要用于描述Pod內容器的重啟策略。在Job中只能將此屬性設置為OnFailure或Never，否則Job將不間斷運行。
.spec.backoffLimit用于設置job失敗后進行重試的次數，默認值為6。默認情況下，除非Pod失敗或容器異常退出，Job任務將不間斷的重試，此時Job遵循 .spec.backoffLimit上述說明。一旦.spec.backoffLimit達到，作業(yè)將被標記為失敗。
//在所有node節(jié)點下載perl鏡像，因為鏡像比較大，所以建議提前下載好
docker pull perl
kubectl apply -f job.yaml
kubectl get pods
pi-bqtf7 0/1 Completed 0 41s
//結果輸出到控制臺
kubectl logs pi-bqtf7
3.14159265......
//清除job資源
kubectl delete -f job.yaml
//backoffLimit
vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
template:
spec:
containers:
- name: busybox
image: busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
restartPolicy: Never
backoffLimit: 2
kubectl apply -f job-limit.yaml
kubectl get job,pods
NAME COMPLETIONS DURATION AGE
job.batch/busybox 0/1 4m34s 4m34s
NAME READY STATUS RESTARTS AGE
pod/busybox-dhrkt 0/1 Error 0 4m34s
pod/busybox-kcx46 0/1 Error 0 4m
pod/busybox-tlk48 0/1 Error 0 4m21s
kubectl describe job busybox
......
Warning BackoffLimitExceeded 43s job-controller Job has reached the specified backoff limit
六、CronJob
周期性任務，像Linux的Crontab一樣
周期性任務
應用場景：通知，備份
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/
示例：
//每分鐘打印hello
vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
imagePullPolicy: IfNotPresent
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
//cronjob其它可用參數的配置
spec:
concurrencyPolicy: Allow #聲明了 CronJob 創(chuàng)建的任務執(zhí)行時發(fā)生重疊如何處理（并發(fā)性規(guī)則僅適用于相同 CronJob 創(chuàng)建的任務）。spec僅能聲明下列規(guī)則中的一種:
●Allow (默認)：CronJob 允許并發(fā)任務執(zhí)行。
●Forbid：CronJob 不允許并發(fā)任務執(zhí)行；如果新任務的執(zhí)行時間到了而老任務沒有執(zhí)行完，CronJob 會忽略新任務的執(zhí)行。
●Replace：如果新任務的執(zhí)行時間到了而老任務沒有執(zhí)行完，CronJob 會用新任務替換當前正在運行的任務。
startingDeadlineSeconds: 15 #它表示任務如果由于某種原因錯過了調度時間，開始該任務的截止時間的秒數。過了截止時間，CronJob 就不會開始任務，且標記失敗.如果此字段未設置，那任務就沒有最后期限。
successfulJobsHistoryLimit: 3 #要保留的成功完成的任務數（默認為3）
failedJobsHistoryLimit：1 #要保留多少已完成和失敗的任務數（默認為1）
suspend：true #如果設置為 true ，后續(xù)發(fā)生的執(zhí)行都會被掛起。 這個設置對已經開始的執(zhí)行不起作用。默認是 false。
schedule: '*/1 * * * *' #必需字段，作業(yè)時間表。在此示例中，作業(yè)將每分鐘運行一次
jobTemplate: #必需字段，作業(yè)模板。這類似于工作示例
kubectl create -f cronjob.yaml
kubectl get cronjob
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 <none> 25s
kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-1621587180-mffj6 0/1 Completed 0 3m
hello-1621587240-g68w4 0/1 Completed 0 2m
hello-1621587300-vmkqg 0/1 Completed 0 60s
kubectl logs hello-1621587180-mffj6
Fri May 21 09:03:14 UTC 2021
Hello from the Kubernetes cluster
//如果報錯：Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54)
//解決辦法：綁定一個cluster-admin的權限
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous
E SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 25s
kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-1621587180-mffj6 0/1 Completed 0 3m
hello-1621587240-g68w4 0/1 Completed 0 2m
hello-1621587300-vmkqg 0/1 Completed 0 60s文章來源：http://www.zghlxwxcb.cn/news/detail-650565.html
kubectl logs hello-1621587180-mffj6
Fri May 21 09:03:14 UTC 2021
Hello from the Kubernetes cluster
//如果報錯：Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54)
//解決辦法：綁定一個cluster-admin的權限
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous文章來源地址http://www.zghlxwxcb.cn/news/detail-650565.html
到了這里，關于Linux6.39 Kubernetes Pod控制器的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
