一、Pod控制器及其功用
Pod控制器，又稱之為工作負(fù)載（workload），是用于實(shí)現(xiàn)管理pod的中間層，確保pod資源符合預(yù)期的狀態(tài)，pod的資源出現(xiàn)故障時(shí)，會(huì)嘗試進(jìn)行重啟，當(dāng)根據(jù)重啟策略無效，則會(huì)重新新建pod的資源。
二、pod控制器的多種類型
1、ReplicaSet: 代用戶創(chuàng)建指定數(shù)量的pod副本，確保pod副本數(shù)量符合預(yù)期狀態(tài)，并且支持滾動(dòng)式自動(dòng)擴(kuò)容和縮容功能。
ReplicaSet主要三個(gè)組件組成：
（1）用戶期望的pod副本數(shù)量
（2）標(biāo)簽選擇器，判斷哪個(gè)pod歸自己管理
（3）當(dāng)現(xiàn)存的pod數(shù)量不足，會(huì)根據(jù)pod資源模板進(jìn)行新建
幫助用戶管理無狀態(tài)的pod資源，精確反應(yīng)用戶定義的目標(biāo)數(shù)量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。
2、Deployment：工作在ReplicaSet之上，用于管理無狀態(tài)應(yīng)用，目前來說最好的控制器。支持滾動(dòng)更新和回滾功能，還提供聲明式配置。
ReplicaSet 與Deployment 這兩個(gè)資源對(duì)象逐步替換之前RC的作用。
3、DaemonSet：用于確保集群中的每一個(gè)節(jié)點(diǎn)只運(yùn)行特定的pod副本，通常用于實(shí)現(xiàn)系統(tǒng)級(jí)后臺(tái)任務(wù)。比如ELK服務(wù)
特性：服務(wù)是無狀態(tài)的
服務(wù)必須是守護(hù)進(jìn)程
4、StatefulSet：管理有狀態(tài)應(yīng)用
5、Job：只要完成就立即退出，不需要重啟或重建
6、Cronjob：周期性任務(wù)控制，不需要持續(xù)后臺(tái)運(yùn)行
2.1 pod容器中的有狀態(tài)和無狀態(tài)的區(qū)別
- 有狀態(tài)實(shí)例
實(shí)例之間有差別，每個(gè)實(shí)例都有自己的獨(dú)特性，元數(shù)據(jù)不同，例如etcd，zookeeper
實(shí)例之間不對(duì)等的關(guān)系，以及依靠外部存儲(chǔ)的應(yīng)用 - 無狀態(tài)實(shí)例
deployment認(rèn)為所有的pod都是一樣的
不用考慮順序的要求
不用考慮在哪個(gè)node節(jié)點(diǎn)上運(yùn)行
可以隨意擴(kuò)容和縮容
三、Deployment 控制器
部署無狀態(tài)應(yīng)用
管理Pod和ReplicaSet
具有上線部署、副本設(shè)定、滾動(dòng)升級(jí)、回滾等功能
提供聲明式更新，例如只更新一個(gè)新的image
應(yīng)用場(chǎng)景：web服務(wù)
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 create -f nginx-deployment.yaml
kubectl get pods,deploy,rs
四、SatefulSet 控制器
StatefulSet 是用來管理有狀態(tài)應(yīng)用的工作負(fù)載 API 對(duì)象。
StatefulSet 用來管理某 Pod 集合的部署和擴(kuò)縮， 并為這些 Pod 提供持久存儲(chǔ)和持久標(biāo)識(shí)符。
和 Deployment 類似， StatefulSet 管理基于相同容器規(guī)約的一組 Pod。但和 Deployment 不同的是， StatefulSet 為它們的每個(gè) Pod 維護(hù)了一個(gè)有粘性的 ID。這些 Pod 是基于相同的規(guī)約來創(chuàng)建的， 但是不能相互替換：無論怎么調(diào)度，每個(gè) Pod 都有一個(gè)永久不變的 ID。
如果希望使用存儲(chǔ)卷為工作負(fù)載提供持久存儲(chǔ)，可以使用 StatefulSet 作為解決方案的一部分。 盡管 StatefulSet 中的單個(gè) Pod 仍可能出現(xiàn)故障， 但持久的 Pod 標(biāo)識(shí)符使得將現(xiàn)有卷與替換已失敗 Pod 的新 Pod 相匹配變得更加容易。
StatefulSet 對(duì)于需要滿足以下一個(gè)或多個(gè)需求的應(yīng)用程序很有價(jià)值：
- 穩(wěn)定的、唯一的網(wǎng)絡(luò)標(biāo)識(shí)符。
- 穩(wěn)定的、持久的存儲(chǔ)。
- 有序的、優(yōu)雅的部署和擴(kuò)縮。
- 有序的、自動(dòng)的滾動(dòng)更新。
在上面描述中，“穩(wěn)定的”意味著 Pod 調(diào)度或重調(diào)度的整個(gè)過程是有持久性的。 如果應(yīng)用程序不需要任何穩(wěn)定的標(biāo)識(shí)符或有序的部署、刪除或擴(kuò)縮， 則應(yīng)該使用由一組無狀態(tài)的副本控制器提供的工作負(fù)載來部署應(yīng)用程序，比如 Deployment 或者 ReplicaSet可能更適用于你的無狀態(tài)應(yīng)用部署需要。
//名為 svc-demo 的 Headless Service 用來控制網(wǎng)絡(luò)域名
kubectl create svc clusterip svc-demo --tcp=80:80 --dry-run=client -oyaml > svc-demo.yaml
vim svc-demo.yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
labels:
app: svc-demo
name: svc-demo
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
selector:
app: sts-demo //擁有此標(biāo)簽的pod 都有此service
type: ClusterIP
clusterIP: None //無頭服務(wù)的clusterIp為None
//名為 myapp-demo 的 StatefulSet 有一個(gè) Spec，它表明將在獨(dú)立的4個(gè) Pod 副本中啟動(dòng)容器
vim stateful-demo.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app: myapp-demo
name: myapp-demo
spec:
serviceName: svc-demo
replicas: 4
selector:
matchLabels:
app: sts-demo
template:
metadata:
labels:
app: sts-demo
spec:
containers:
- image: soscscs/myapp:v1
name: myapp
ports:
- containerPort: 80
volumeClaimTemplates:
- metadata:
name: pvc-demo
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
storageClassName: nfs-client-storageclass
4.1 StatefulSet由以下幾個(gè)部分組成
●Headless Service（無頭服務(wù)）：用于為Pod資源標(biāo)識(shí)符生成可解析的DNS記錄。
●volumeClaimTemplates（存儲(chǔ)卷申請(qǐng)模板）：基于靜態(tài)或動(dòng)態(tài)PV供給方式為Pod資源提供專有的固定存儲(chǔ)。
●StatefulSet：用于管控Pod資源。
4.2 為什么要有headless？
在deployment中，每一個(gè)pod是沒有名稱，是隨機(jī)字符串，是無序的。而statefulset中是要求有序的，每一個(gè)pod的名稱必須是固定的。當(dāng)節(jié)點(diǎn)掛了，重建之后的標(biāo)識(shí)符是不變的，每一個(gè)節(jié)點(diǎn)的節(jié)點(diǎn)名稱是不能改變的。pod名稱是作為pod識(shí)別的唯一標(biāo)識(shí)符，必須保證其標(biāo)識(shí)符的穩(wěn)定并且唯一。
為了實(shí)現(xiàn)標(biāo)識(shí)符的穩(wěn)定，這時(shí)候就需要一個(gè)headless service 解析直達(dá)到pod，還需要給pod配置一個(gè)唯一的名稱。
4.3 為什么要有volumeClaimTemplate？
大部分有狀態(tài)副本集都會(huì)用到持久存儲(chǔ)，比如分布式系統(tǒng)來說，由于數(shù)據(jù)是不一樣的，每個(gè)節(jié)點(diǎn)都需要自己專用的存儲(chǔ)節(jié)點(diǎn)。而在 deployment中pod模板中創(chuàng)建的存儲(chǔ)卷是一個(gè)共享的存儲(chǔ)卷，多個(gè)pod使用同一個(gè)存儲(chǔ)卷，而statefulset定義中的每一個(gè)pod都不能使用同一個(gè)存儲(chǔ)卷，由此基于pod模板創(chuàng)建pod是不適應(yīng)的，這就需要引入volumeClaimTemplate，當(dāng)在使用statefulset創(chuàng)建pod時(shí)，會(huì)自動(dòng)生成一個(gè)PVC，從而請(qǐng)求綁定一個(gè)PV，從而有自己專用的存儲(chǔ)卷。
服務(wù)發(fā)現(xiàn)：就是應(yīng)用服務(wù)之間相互定位的過程。
應(yīng)用場(chǎng)景：
●動(dòng)態(tài)性強(qiáng)：Pod會(huì)飄到別的node節(jié)點(diǎn)
●更新發(fā)布頻繁：互聯(lián)網(wǎng)思維小步快跑，先實(shí)現(xiàn)再優(yōu)化，老板永遠(yuǎn)是先上線再慢慢優(yōu)化，先把idea變成產(chǎn)品掙到錢然后再慢慢一點(diǎn)一點(diǎn)優(yōu)化
●支持自動(dòng)伸縮：一來大促，肯定是要擴(kuò)容多個(gè)副本
K8S里服務(wù)發(fā)現(xiàn)的方式—DNS，使K8S集群能夠自動(dòng)關(guān)聯(lián)Service資源的“名稱”和“CLUSTER-IP”，從而達(dá)到服務(wù)被集群自動(dòng)發(fā)現(xiàn)的目的。
kubectl get pods -A
kubectl delete pods coredns-54d67798b7-rl5wc -n kube-system
kubectl delete pods coredns-54d67798b7-qbvr5 -n kube-system
kubectl delete statefulsets.apps myapp-demo
vim stateful.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app: myapp-demo
name: myapp-demo
spec:
serviceName: svc-demo
replicas: 4
selector:
matchLabels:
app: sts-demo
template:
metadata:
labels:
app: sts-demo
spec:
containers:
- image: soscscs/myapp:v1
name: myapp
ports:
- containerPort: 80
volumeMounts:
- name: pvc-demo
mountPath: /data
volumeClaimTemplates:
- metadata:
name: pvc-demo
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
storageClassName: nfs-client-storageclass
解析上例：由于 StatefulSet 資源依賴于一個(gè)實(shí)現(xiàn)存在的 Headless 類型的 Service 資源，所以需要先定義一個(gè)名為 svc-demo 的 Headless Service 資源，用于為關(guān)聯(lián)到每個(gè) Pod 資源創(chuàng)建 DNS 資源記錄。接著定義了一個(gè)名為 myapp 的 StatefulSet 資源，它通過 Pod 模板創(chuàng)建了 4 個(gè) Pod 資源副本，并基于 volumeClaimTemplates 向前面創(chuàng)建的PV進(jìn)行了請(qǐng)求大小為 2Gi 的專用存儲(chǔ)卷。
4.4 滾動(dòng)更新
StatefulSet 控制器將在 StatefulSet 中刪除并重新創(chuàng)建每個(gè) Pod。它將以與 Pod 終止相同的順序進(jìn)行（從最大的序數(shù)到最小的序數(shù)），每次更新一個(gè) Pod。在更新其前身之前，它將等待正在更新的 Pod 狀態(tài)變成正在運(yùn)行并就緒。
kubectl edit statefulsets.apps myapp-demo
kubectl get pods -w //查看滾動(dòng)更新的過程
4.5 擴(kuò)容及縮容
kubectl scale statefulset myapp-demo --replicas=6
kubectl scale statefulset myapp-demo --replicas=3
擴(kuò)展伸縮
kubectl scale sts myapp --replicas=4 //擴(kuò)容副本增加到4個(gè)
kubectl get pods -w //動(dòng)態(tài)查看擴(kuò)容
kubectl get pv //查看pv綁定
kubectl patch sts myapp -p '{"spec":{"replicas":2}}' //打補(bǔ)丁方式縮容
kubectl get pods -w //動(dòng)態(tài)查看縮容
當(dāng)刪除一個(gè) StatefulSet 時(shí)，該 StatefulSet 不提供任何終止 Pod 的保證。為了實(shí)現(xiàn) StatefulSet 中的 Pod 可以有序且體面地終止，可以在刪除之前將 StatefulSet 縮容到 0。
示例：
kubectl scale statefulset myappdata-myapp --replicas=0
kubectl delete -f stateful-demo.yaml
4.6 小結(jié)
常規(guī)service和無頭服務(wù)區(qū)別
service：一組Pod訪問策略，提供cluster-IP群集之間通訊，還提供負(fù)載均衡和服務(wù)發(fā)現(xiàn)。
Headless service：無頭服務(wù)，不需要cluster-IP，而是直接以DNS記錄的方式解析出被代理Pod的IP地址。
注意：使用普通的 service 也可以解析出被代理Pod的IP地址
五、DaemonSet 控制器
DaemonSet 確保全部（或者一些）Node 上運(yùn)行一個(gè) Pod 的副本。當(dāng)有 Node 加入集群時(shí)，也會(huì)為他們新增一個(gè) Pod 。當(dāng)有 Node 從集群移除時(shí)，這些 Pod 也會(huì)被回收。刪除 DaemonSet 將會(huì)刪除它創(chuàng)建的所有 Pod。
使用 DaemonSet 的一些典型用法：
●運(yùn)行集群存儲(chǔ) daemon，例如在每個(gè) Node 上運(yùn)行 glusterd、ceph。
●在每個(gè) Node 上運(yùn)行日志收集 daemon，例如fluentd、logstash。
●在每個(gè) Node 上運(yùn)行監(jiān)控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。
應(yīng)用場(chǎng)景：Agent
官方案例（監(jiān)控）：https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
示例：
vim daemon-demo.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
app: myapp-ds
name: myapp-ds
spec:
selector:
matchLabels:
app: myapp-ds
template:
metadata:
labels:
app: myapp-ds
spec:
containers:
- image: soscscs/myapp:v1
name: myapp
ports:
- containerPort: 80
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
六、Job 控制器
Job分為普通任務(wù)（Job）和定時(shí)任務(wù)（CronJob）
常用于運(yùn)行那些僅需要執(zhí)行一次的任務(wù)
應(yīng)用場(chǎng)景：數(shù)據(jù)庫遷移、批處理腳本、kube-bench掃描、離線數(shù)據(jù)處理，視頻解碼等業(yè)務(wù)
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
vim job-demo.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: myapp-job
spec:
template:
spec:
containers:
- name: myapp
image: soscscs/myapp:v1
command: ["/bin/sh","-c","echo zhangsan like singing ; sleep 10; date; exit 0"]
restartPolicy: Never
backoffLimit: 4
kubectl describe pods myapp-job-gnk6c
kubectl logs myapp-job-gnk6c
注意：job的重啟策略要么 Never ， 要么 OnFailure ，絕對(duì)不能為 Always
七、CronJob 控制器
周期性任務(wù)，像Linux的Crontab一樣。
周期性任務(wù)
應(yīng)用場(chǎng)景：通知，備份
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/
cronjob其它可用參數(shù)的配置
spec:
concurrencyPolicy: Allow #聲明了 CronJob 創(chuàng)建的任務(wù)執(zhí)行時(shí)發(fā)生重疊如何處理（并發(fā)性規(guī)則僅適用于相同 CronJob 創(chuàng)建的任務(wù)）。spec僅能聲明下列規(guī)則中的一種:
●Allow (默認(rèn))：CronJob 允許并發(fā)任務(wù)執(zhí)行。
●Forbid：CronJob 不允許并發(fā)任務(wù)執(zhí)行；如果新任務(wù)的執(zhí)行時(shí)間到了而老任務(wù)沒有執(zhí)行完，CronJob 會(huì)忽略新任務(wù)的執(zhí)行。
●Replace：如果新任務(wù)的執(zhí)行時(shí)間到了而老任務(wù)沒有執(zhí)行完，CronJob 會(huì)用新任務(wù)替換當(dāng)前正在運(yùn)行的任務(wù)。
startingDeadlineSeconds: 15 #它表示任務(wù)如果由于某種原因錯(cuò)過了調(diào)度時(shí)間，開始該任務(wù)的截止時(shí)間的秒數(shù)。過了截止時(shí)間，CronJob 就不會(huì)開始任務(wù)，且標(biāo)記失敗.如果此字段未設(shè)置，那任務(wù)就沒有最后期限。
successfulJobsHistoryLimit: 3 #要保留的成功完成的任務(wù)數(shù)（默認(rèn)為3）
failedJobsHistoryLimit：1 #要保留多少已完成和失敗的任務(wù)數(shù)（默認(rèn)為1）
suspend：true #如果設(shè)置為 true ，后續(xù)發(fā)生的執(zhí)行都會(huì)被掛起。 這個(gè)設(shè)置對(duì)已經(jīng)開始的執(zhí)行不起作用。默認(rèn)是 false。schedule: '*/1 * * * *' #必需字段，作業(yè)時(shí)間表。在此示例中，作業(yè)將每分鐘運(yùn)行一次
jobTemplate: #必需字段，作業(yè)模板。這類似于工作示例
vim cronjob-demo.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
八、總結(jié)
8.1 Deployment
1）部署無狀態(tài)應(yīng)用
2）創(chuàng)建和管理 ReplicaSet 和 Pod 資源，并維護(hù)Pod副本數(shù)量與期望值相同
3）創(chuàng)建和刪除Pod是并行執(zhí)行的，升級(jí)策略默認(rèn)為滾動(dòng)更新的方式
8.2 StatefulSet
1）部署有狀態(tài)應(yīng)用
2）每個(gè)Pod的名稱都是唯一且固定不變的
3）每個(gè)Pod都可以有自己專屬的持久化存儲(chǔ)（基于PVC模板volumeClaimTemplates綁定PV實(shí)現(xiàn)的）
4）需要提前創(chuàng)建并關(guān)聯(lián)一個(gè)Headless Service資源（ClusterIP可以為None），在K8S集群內(nèi)部的Pod應(yīng)用可以通過 <pod_name>.<svc_name>.<namespace_name>.svc.cluster.local 格式解析出 PodIP（基于無頭服務(wù)Headless Service和CoreDNS實(shí)現(xiàn)的）
5）創(chuàng)建、滾動(dòng)升級(jí)、擴(kuò)容、縮容Pod都是有序進(jìn)行的（默認(rèn)為串行執(zhí)行的，podManagementPolicy: OrderedReady(默認(rèn))|Parallel）
創(chuàng)建、擴(kuò)容是升序執(zhí)行的（順序?yàn)镻od標(biāo)識(shí)號(hào)從0到n-1）
滾動(dòng)升級(jí)、縮容是倒序執(zhí)行的（順序?yàn)镻od標(biāo)識(shí)號(hào)從n-1到0）
Service資源的類型 4+1
ClusterIP NodePort LoadBalancer ExternalName + Headless Service
8.3 DaemonSet
1）理論上可以在K8S所有Node節(jié)點(diǎn)上創(chuàng)建相同的Pod資源（無論Node節(jié)點(diǎn)什么時(shí)候加入到K8S集群）
2）調(diào)度時(shí)會(huì)受到Node節(jié)點(diǎn)上的污點(diǎn)或者節(jié)點(diǎn)設(shè)置了cordon不可調(diào)度的影響，而不會(huì)在上述的Node節(jié)點(diǎn)中創(chuàng)建Pod
設(shè)置容忍 kubectl node xxx uncordon
3）資源清單配置中不需要設(shè)置副本數(shù) replicas
8.4 Job
1）部署一次性短期任務(wù)的資源，Pod不會(huì)持久運(yùn)行
2）任務(wù)正常完成后Pod容器會(huì)正常退出并不會(huì)再重啟（restartPolicy通常設(shè)置為Nerver或OnFailure），且也不會(huì)重建Pod
3）如果任務(wù)執(zhí)行異常導(dǎo)致Pod容器異常退出，會(huì)重建Pod重試任務(wù)，重試次數(shù)受 backoffLimit 配置影響（默認(rèn)為任務(wù)失敗后重試 6 次）文章來源：http://www.zghlxwxcb.cn/news/detail-642688.html
8.5 CronJob
1）部署周期性短期任務(wù)的資源，Pod不會(huì)持久運(yùn)行
2）任務(wù)正常完成后Pod容器會(huì)正常退出并不會(huì)再重啟（restartPolicy通常設(shè)置為Nerver或OnFailure），且也不會(huì)重建Pod
3）使用必配字段 schedule 設(shè)置任務(wù)執(zhí)行的周期表，格式為 分 時(shí) 日 月 周文章來源地址http://www.zghlxwxcb.cn/news/detail-642688.html
到了這里，關(guān)于k8s之Pod控制器的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
![[云原生] K8s之pod控制器詳解](https://imgs.yssmx.com/Uploads/2024/03/838367-1.png)
