---

一、Pod 控制器的概念

1. Pod 控制器及其功用

??Pod控制器，又稱之為工作負載（workload），是用于實現管理pod的中間層，確保pod資源符合預期的狀態，pod的資源出現故障時，會嘗試進行重啟，當根據重啟策略無效，則會重新新建pod的資源。

2. Pod 控制器有多種類型

2.1 ReplicaSet

?? ReplicaSet是代用戶創建指定數量的pod副本，確保pod副本數量符合預期狀態，并且支持滾動式自動擴容和縮容功能。

??ReplicaSet主要三個組件組成：

• 用戶期望的pod副本數量；
• 標簽選擇器，判斷哪個pod歸自己管理；
• 當現存的pod數量不足，會根據pod資源模板進行新建。

??幫助用戶管理無狀態的pod資源，精確反應用戶定義的目標數量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。

2.2 Deployment

??工作在ReplicaSet之上，用于管理無狀態應用，目前來說最好的控制器。支持滾動更新和回滾功能，還提供聲明式配置。

??ReplicaSet 與Deployment 這兩個資源對象逐步替換之前RC的作用。

2.3 DaemonSet

??用于確保集群中的每一個節點只運行特定的pod副本，通常用于實現系統級后臺任務。比如ELK服務。

??特性：服務是無狀態的。

??服務必須是守護進程。

2.4 StatefulSet

??管理有狀態應用。

2.5 Job

??只要完成就立即退出，不需要重啟或重建。

2.6 Cronjob

??周期性任務控制，不需要持續后臺運行。

3. Pod 與控制器之間的關系

??controllers：在集群上管理和運行容器的 pod 對象， pod 通過 label-selector 相關聯。

??Pod 通過控制器實現應用的運維，如伸縮，升級等。

二、Pod 控制器的使用

1. Deployment

• 部署無狀態應用；
• 管理Pod和ReplicaSet；
• 具有上線部署、副本設定、滾動升級、回滾等功能；
• 提供聲明式更新，例如只更新一個新的image；
• 應用場景：web服務。

vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx	
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.15.4ports:- containerPort: 80

kubectl create -f nginx-deployment.yamlkubectl get pods,deploy,rs

#查看控制器配置
apiVersion: apps/v1
kind: Deployment
metadata:creationTimestamp: "2023-08-15T06:21:40Z"generation: 1labels:app: nginx							#Deployment資源的標簽name: nginx-deploymentnamespace: defaultresourceVersion: "37601"selfLink: /apis/apps/v1/namespaces/default/deployments/nginx-deploymentuid: d74be008-0bd5-4d0e-b064-0828d7b5b790
spec:progressDeadlineSeconds: 600replicas: 3							#期望的pod數量，默認是1revisionHistoryLimit: 10selector:matchLabels:app: nginxstrategy:rollingUpdate:maxSurge: 25%						#升級過程中會先啟動的新Pod的數量不超過期望的Pod數量的25%，也可以是一個絕對值maxUnavailable: 25%				#升級過程中在新的Pod啟動好后銷毀的舊Pod的數量不超過期望的Pod數量的25%，也可以是一個絕對值type: RollingUpdate					#滾動升級template:metadata:creationTimestamp: nulllabels:app: nginx						#Pod副本關聯的標簽spec:containers:- image: nginx:1.15.4				#鏡像名稱imagePullPolicy: IfNotPresent	#鏡像拉取策略name: nginxports:- containerPort: 80				#容器暴露的監聽端口protocol: TCPresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: Always				#容器重啟策略schedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 30

#查看歷史版本
kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>

2. SatefulSet

• 部署有狀態應用；
• 穩定的持久化存儲，即Pod重新調度后還是能訪問到相同的持久化數據，基于PVC來實現；
• 穩定的網絡標志，即Pod重新調度后其PodName和HostName不變，基于Headless Service（即沒有Cluster IP的Service）來實現；
• 有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次進行（即從0到N-1，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態），基于init containers來實現；
• 有序收縮，有序刪除（即從N-1到0）。

??常見的應用場景：數據庫 （https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/）

apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: web
spec:selector:matchLabels:app: nginx # has to match .spec.template.metadata.labelsserviceName: "nginx"replicas: 3 # by default is 1template:metadata:labels:app: nginx # has to match .spec.selector.matchLabelsspec:terminationGracePeriodSeconds: 10containers:- name: nginximage: k8s.gcr.io/nginx-slim:0.8ports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ]storageClassName: "my-storage-class"resources:requests:storage: 1Gi

??從上面的應用場景可以發現，StatefulSet由以下幾個部分組成：

• Headless Service（無頭服務）：用于為Pod資源標識符生成可解析的DNS記錄。
• volumeClaimTemplates（存儲卷申請模板）：基于靜態或動態PV供給方式為Pod資源提供專有的固定存儲。
• StatefulSet：用于管控Pod資源。

2.1 為什么要有headless？

??在deployment中，每一個pod是沒有名稱，是隨機字符串，是無序的。而statefulset中是要求有序的，每一個pod的名稱必須是固定的。當節點掛了，重建之后的標識符是不變的，每一個節點的節點名稱是不能改變的。pod名稱是作為pod識別的唯一標識符，必須保證其標識符的穩定并且唯一。

??為了實現標識符的穩定，這時候就需要一個headless service 解析直達到pod，還需要給pod配置一個唯一的名稱。

2.2 為什么要有 volumeClaimTemplate？

??大部分有狀態副本集都會用到持久存儲，比如分布式系統來說，由于數據是不一樣的，每個節點都需要自己專用的存儲節點。而在 deployment中pod模板中創建的存儲卷是一個共享的存儲卷，多個pod使用同一個存儲卷，而statefulset定義中的每一個pod都不能使用同一個存儲卷，由此基于pod模板創建pod是不適應的，這就需要引入volumeClaimTemplate，當在使用statefulset創建pod時，會自動生成一個PVC，從而請求綁定一個PV，從而有自己專用的存儲卷。

2.3 服務發現 和 應用場景

服務發現：就是應用服務之間相互定位的過程。

應用場景：

• 動態性強：Pod會飄到別的node節點；
• 更新發布頻繁：互聯網思維小步快跑，先實現再優化，老板永遠是先上線再慢慢優化，先把idea變成產品掙到錢然后再慢慢一點一點優化；
• 支持自動伸縮：一來大促，肯定是要擴容多個副本。

??K8S里服務發現的方式—DNS，使K8S集群能夠自動關聯Service資源的“名稱”和“CLUSTER-IP”，從而達到服務被集群自動發現的目的。

2.4 實現K8S里DNS功能的插件：

• skyDNS：Kubernetes 1.3之前的版本；
• kubeDNS：Kubernetes 1.3至Kubernetes 1.11；
• CoreDNS：Kubernetes 1.11開始至今。

#安裝CoreDNS，僅二進制部署環境需要安裝CoreDNS
#方法一：
下載鏈接：https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.basevim 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/gsed -f transforms2sed.sed coredns.yaml.base > coredns.yaml#方法二：上傳 coredns.yaml 文件kubectl create -f coredns.yamlkubectl get pods -n kube-system

2.5 示例

查看statefulset的定義

kubectl explain statefulset
KIND:     StatefulSet
VERSION:  apps/v1DESCRIPTION:StatefulSet represents a set of pods with consistent identities. Identitiesare defined as: - Network: A single stable DNS and hostname. - Storage: Asmany VolumeClaims as requested. The StatefulSet guarantees that a givennetwork 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/v1RESOURCE: 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-svclabels:app: myapp-svc
spec:ports:- port: 80name: webclusterIP: Noneselector:app: myapp-pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: myapp
spec:serviceName: myapp-svcreplicas: 3selector:matchLabels:app: myapp-podtemplate:metadata:labels:app: myapp-podspec:containers:- name: myappimage: ikubernetes/myapp:v1ports:- containerPort: 80name: webvolumeMounts:- name: myappdatamountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: myappdataannotations:          #動態PV創建時，使用annotations在PVC里聲明一個StorageClass對象的標識進行關聯spec:accessModes: ["ReadWriteOnce"]storageClassName: "nfs-client-storageclass"resources:requests:storage: 2Gi

??解析上例：由于 StatefulSet 資源依賴于一個實現存在的 Headless 類型的 Service 資源，所以需要先定義一個名為 myapp-svc 的 Headless Service 資源，用于為關聯到每個 Pod 資源創建 DNS 資源記錄。接著定義了一個名為 myapp 的 StatefulSet 資源，它通過 Pod 模板創建了 3 個 Pod 資源副本，并基于 volumeClaimTemplates 向前面創建的PV進行了請求大小為 2Gi 的專用存儲卷。

創建pv

#stor01節點
mkdir -p /data/volumes/v{1,2,3,4,5}vim /etc/exports
/data/volumes/v1 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.80.0/24(rw,no_root_squash)systemctl restart rpcbind
systemctl restart nfsexportfs -arvshowmount -e

定義PV

vim pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:name: pv001labels:name: pv001
spec:nfs:path: /data/volumes/v1server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv002labels:name: pv002
spec:nfs:path: /data/volumes/v2server: stor01accessModes: ["ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv003labels:name: pv003
spec:nfs:path: /data/volumes/v3server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv004labels:name: pv004
spec:nfs:path: /data/volumes/v4server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv005labels:name: pv005
spec:nfs:path: /data/volumes/v5server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi

kubectl apply -f pv-demo.yamlkubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
pv001     1Gi        RWO,RWX        Retain           Available                                      7s
pv002     2Gi        RWO            Retain           Available                                      7s
pv003     2Gi        RWO,RWX        Retain           Available                                      7s
pv004     2Gi        RWO,RWX        Retain           Available                                      7s
pv005     2Gi        RWO,RWX        Retain           Available                           			7s

創建statefulset

kubectl apply -f stateful-demo.yaml kubectl get svc  #查看創建的無頭服務myapp-svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP             50d
myapp-svc    ClusterIP   None             <none>        80/TCP              38skubectl get sts    #查看statefulset
NAME      DESIRED   CURRENT   AGE
myapp     3         3         55skubectl get pvc    #查看pvc綁定
NAME                STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
myappdata-myapp-0   Bound     pv002     2Gi        RWO                           1m
myappdata-myapp-1   Bound     pv003     2Gi        RWO,RWX                       1m
myappdata-myapp-2   Bound     pv004     2Gi        RWO,RWX                       1mkubectl get pv    #查看pv綁定
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                       STORAGECLASS   REASON    AGE
pv001     1Gi        RWO,RWX        Retain           Available                                                        6m
pv002     2Gi        RWO            Retain           Bound       default/myappdata-myapp-0                            6m
pv003     2Gi        RWO,RWX        Retain           Bound       default/myappdata-myapp-1                            6m
pv004     2Gi        RWO,RWX        Retain           Bound       default/myappdata-myapp-2                            6m
pv005     2Gi        RWO,RWX        Retain           Available                                                        6mkubectl get pods   #查看Pod信息
NAME                     READY     STATUS    RESTARTS   AGE
myapp-0                  1/1       Running   0          2m
myapp-1                  1/1       Running   0          2m
myapp-2                  1/1       Running   0          2m

#當刪除一個 StatefulSet 時，該 StatefulSet 不提供任何終止 Pod 的保證。為了實現 StatefulSet 中的 Pod 可以有序且體面地終止，可以在刪除之前將 StatefulSet 縮容到 0。
kubectl scale statefulset myappdata-myapp --replicas=0
kubectl delete -f stateful-demo.yaml	#此時PVC依舊存在的，再重新創建pod時，依舊會重新去綁定原來的pvc
kubectl apply -f stateful-demo.yamlkubectl get pvc
NAME                STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
myappdata-myapp-0   Bound     pv002     2Gi        RWO                           5m
myappdata-myapp-1   Bound     pv003     2Gi        RWO,RWX                       5m
myappdata-myapp-2   Bound     pv004     2Gi        RWO,RWX

滾動更新

#StatefulSet 控制器將在 StatefulSet 中刪除并重新創建每個 Pod。它將以與 Pod 終止相同的順序進行（從最大的序數到最小的序數），每次更新一個 Pod。在更新其前身之前，它將等待正在更新的 Pod 狀態變成正在運行并就緒。如下操作的滾動更新是按照2-0的順序更新。
vim stateful-demo.yaml  		#修改image版本為v2
.....
image: ikubernetes/myapp:v2
....kubectl apply -f stateful-demo.yamlkubectl get pods -w   #查看滾動更新的過程
NAME      READY   STATUS        RESTARTS   AGE
myapp-0   1/1     Running       0          29s
myapp-1   1/1     Running       0          27s
myapp-2   0/1     Terminating   0          26s
myapp-2   0/1     Terminating   0          30s
myapp-2   0/1     Terminating   0          30s
myapp-2   0/1     Pending       0          0s
myapp-2   0/1     Pending       0          0s
myapp-2   0/1     ContainerCreating   0          0s
myapp-2   1/1     Running             0          31s
myapp-1   1/1     Terminating         0          62s
myapp-1   0/1     Terminating         0          63s
myapp-1   0/1     Terminating         0          66s
myapp-1   0/1     Terminating         0          67s
myapp-1   0/1     Pending             0          0s
myapp-1   0/1     Pending             0          0s
myapp-1   0/1     ContainerCreating   0          0s
myapp-1   1/1     Running             0          30s
myapp-0   1/1     Terminating         0          99s
myapp-0   0/1     Terminating         0          100s
myapp-0   0/1     Terminating         0          101s
myapp-0   0/1     Terminating         0          101s
myapp-0   0/1     Pending             0          0s
myapp-0   0/1     Pending             0          0s
myapp-0   0/1     ContainerCreating   0          0s
myapp-0   1/1     Running             0          1s

#在創建的每一個Pod中，每一個pod自己的名稱都是可以被解析的
kubectl exec -it myapp-0 /bin/sh
Name:      myapp-0.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.27 myapp-0.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-1.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolveName:      myapp-1.myapp-svc.default.svc.cluster.local
Address 1: 10.244.1.14 myapp-1.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-2.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolveName:      myapp-2.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.26 myapp-2.myapp-svc.default.svc.cluster.local

#從上面的解析，我們可以看到在容器當中可以通過對Pod的名稱進行解析到ip。其解析的域名格式如下：
(pod_name).(service_name).(namespace_name).svc.cluster.local

總結

無狀態：

1. deployment 認為所有的pod都是一樣的;
2. 不用考慮順序的要求;
3. 不用考慮在哪個node節點上運行;
4. 可以隨意擴容和縮容 .

有狀態

1. 實例之間有差別，每個實例都有自己的獨特性，元數據不同，例如etcd，zookeeper
2. 實例之間不對等的關系，以及依靠外部存儲的應用。

常規service和無頭服務區別

service：一組Pod訪問策略，提供cluster-IP群集之間通訊，還提供負載均衡和服務發現。
Headless service：無頭服務，不需要cluster-IP，而是直接以DNS記錄的方式解析出被代理Pod的IP地址。

2.6 擴展伸縮

kubectl scale sts myapp --replicas=4  #擴容副本增加到4個kubectl get pods -w  #動態查看擴容kubectl get pv  #查看pv綁定kubectl patch sts myapp -p '{"spec":{"replicas":2}}'  #打補丁方式縮容kubectl get pods -w  #動態查看縮容

3. DaemonSet

??DaemonSet 確保全部（或者一些）Node 上運行一個 Pod 的副本。當有 Node 加入集群時，也會為他們新增一個 Pod 。當有 Node 從集群移除時，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它創建的所有 Pod。

3.1 用法

使用 DaemonSet 的一些典型用法：

• 運行集群存儲 daemon，例如在每個 Node 上運行 glusterd、ceph。
• 在每個 Node 上運行日志收集 daemon，例如fluentd、logstash。
• 在每個 Node 上運行監控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。

3.2 應用場景

??應用場景：Agent

??官方案例（監控）：https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

3.3 示例

vim ds.yaml 
apiVersion: apps/v1
kind: DaemonSet 
metadata:name: nginx-daemonSetlabels:app: nginx
spec:selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.15.4ports:- containerPort: 80

kubectl apply -f ds.yaml#DaemonSet會在每個node節點都創建一個Pod
kubectl get pods
nginx-deployment-4kr6h   1/1     Running     0          35s
nginx-deployment-8jrg5   1/1     Running     0          35s

4. Job

??Job分為普通任務（Job）和定時任務（CronJob）。

??常用于運行那些僅需要執行一次的任務。

??應用場景：數據庫遷移、批處理腳本、kube-bench掃描、離線數據處理，視頻解碼等業務。

?&emsphttps://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: piimage: perlcommand: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]restartPolicy: NeverbackoffLimit: 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達到，作業將被標記為失敗。

#在所有node節點下載perl鏡像，因為鏡像比較大，所以建議提前下載好
docker pull perlkubectl 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: busyboximage: busyboximagePullPolicy: IfNotPresentcommand: ["/bin/sh", "-c", "sleep 10;date;exit 1"]restartPolicy: NeverbackoffLimit: 2kubectl apply -f job-limit.yamlkubectl get job,pods
NAME                COMPLETIONS   DURATION   AGE
job.batch/busybox   0/1           4m34s      4m34sNAME                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          4m21skubectl describe job busybox
......
Warning  BackoffLimitExceeded  43s    job-controller  Job has reached the specified backoff limit

5. CronJob

??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: helloimage: busyboximagePullPolicy: IfNotPresentargs:- /bin/sh- -c- date; echo Hello from the Kubernetes clusterrestartPolicy: OnFailure  

#cronjob其它可用參數的配置
spec:concurrencyPolicy: Allow			#聲明了 CronJob 創建的任務執行時發生重疊如何處理（并發性規則僅適用于相同 CronJob 創建的任務）。spec僅能聲明下列規則中的一種:●Allow (默認)：CronJob 允許并發任務執行。●Forbid：CronJob 不允許并發任務執行；如果新任務的執行時間到了而老任務沒有執行完，CronJob 會忽略新任務的執行。●Replace：如果新任務的執行時間到了而老任務沒有執行完，CronJob 會用新任務替換當前正在運行的任務。startingDeadlineSeconds: 15		#它表示任務如果由于某種原因錯過了調度時間，開始該任務的截止時間的秒數。過了截止時間，CronJob 就不會開始任務，且標記失敗.如果此字段未設置，那任務就沒有最后期限。successfulJobsHistoryLimit: 3		#要保留的成功完成的任務數（默認為3）failedJobsHistoryLimit：1         #要保留多少已完成和失敗的任務數（默認為1）suspend：true                     #如果設置為 true ，后續發生的執行都會被掛起。 這個設置對已經開始的執行不起作用。默認是 false。schedule: '*/1 * * * *'			#必需字段，作業時間表。在此示例中，作業將每分鐘運行一次jobTemplate:						#必需字段，作業模板。這類似于工作示例

kubectl create -f cronjob.yaml kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        <none>          25skubectl 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          60skubectl 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

總結

1. Pod 的 5 種 控制器

#Deployment
部署無狀態應用
負責創建和管理 ReplicaSet，維護 Pod 副本數量與預期值相同
負責創建和創建 Pod 資源，多個 Pod副本時并行執行的，升級策略默認為滾動更新的方式

#DaemnoSet
部署無狀態應用
理論上可以在K8S所有Node節點上創建相同的Pod資源，無論 Node 節點什么時候加入到 K8S 集群（需要考慮到污點和cordon不可調度的影響）
在DaemnoSet資源清單配置中不需要設置Pod副本數

#StatefuleSet
部署有狀態應用
每個 Pod 名稱都是唯一且固定不變的
每個 Pod 都可以有自己專屬的持久化存儲（基于PVC模板vulumeClaimTemplates 綁定PV實現）
需要提前創建并關聯一個 headless service 資源（無頭服務， ClustertIP可以為None），并在 Statement 資源清單配置其中使用 servicename 字段關聯 headless service
可以實現在 Pod 內通過 <Pod名稱>.<svc名稱>.<命名空間>[.srv.cluster.local] 格式解析出 PodIP。（基于 Headless Service 和 CoreDNS 實現的）
創建、滾動升級、擴容、縮容 Pod 都是有序進行的（默認為穿行執行，基于字段 .spec.podManagemntPolicy：OrderedReady 實現，字段值若設置為 Parallel，則為并行執行）
創建、擴容 是升序執行（順序為 Pod 標識為 0 到 n-1）
滾動升級、縮容 是倒序執行的（順序為 Pod 標識從 n-1 到 0）————————————————————————————————————————————————————————————————————
#service 資源的類型：4個常規類型+1個特殊類型
ClusterIp NodePort LoadBalancer ExternaName	 + Headless Service

#Jod
部署一次性的短期任務的Pod資源，Pod不會持久運行
任務正常完成后Pod容器會正常退出并不會再重啟（restarPolicy需要設置為Never或OnFailure），且也不會重建Pod
如果任務執行異常導致Pod容器異常退出，會重建Pod重試任務，重試次數受 backoffLimit 字段配置影響（默認在任務失敗后重試6次）

#CronJob
部署一次性的短期任務的Pod資源，Pod不會持久運行
任務正常完成后Pod容器會正常退出并不會再重啟（restarPolicy需要設置為Never或OnFailure），且也不會重建Pod
使用必配字段 schedule 設置任務執行的周期表，格式為“分 時 日 月 周”