---

一、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、Job：只要完成就立即退出，不需要重啟或重建

6、Cronjob：周期性任務控制，不需要持續(xù)后臺運行

2.1 pod容器中的有狀態(tài)和無狀態(tài)的區(qū)別

• 有狀態(tài)實例
  實例之間有差別，每個實例都有自己的獨特性，元數據不同，例如etcd，zookeeper
  實例之間不對等的關系，以及依靠外部存儲的應用
• 無狀態(tài)實例
  deployment認為所有的pod都是一樣的
  不用考慮順序的要求
  不用考慮在哪個node節(jié)點上運行
  可以隨意擴容和縮容

三、Deployment 控制器

部署無狀態(tài)應用
管理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: 80kubectl create -f nginx-deployment.yamlkubectl get pods,deploy,rs

四、SatefulSet 控制器

StatefulSet 是用來管理有狀態(tài)應用的工作負載 API 對象。

StatefulSet 用來管理某 Pod 集合的部署和擴縮， 并為這些 Pod 提供持久存儲和持久標識符。

和 Deployment 類似， StatefulSet 管理基于相同容器規(guī)約的一組 Pod。但和 Deployment 不同的是， StatefulSet 為它們的每個 Pod 維護了一個有粘性的 ID。這些 Pod 是基于相同的規(guī)約來創(chuàng)建的， 但是不能相互替換：無論怎么調度，每個 Pod 都有一個永久不變的 ID。

如果希望使用存儲卷為工作負載提供持久存儲，可以使用 StatefulSet 作為解決方案的一部分。 盡管 StatefulSet 中的單個 Pod 仍可能出現故障， 但持久的 Pod 標識符使得將現有卷與替換已失敗 Pod 的新 Pod 相匹配變得更加容易。

StatefulSet 對于需要滿足以下一個或多個需求的應用程序很有價值：

• 穩(wěn)定的、唯一的網絡標識符。
• 穩(wěn)定的、持久的存儲。
• 有序的、優(yōu)雅的部署和擴縮。
• 有序的、自動的滾動更新。

在上面描述中，“穩(wěn)定的”意味著 Pod 調度或重調度的整個過程是有持久性的。 如果應用程序不需要任何穩(wěn)定的標識符或有序的部署、刪除或擴縮， 則應該使用由一組無狀態(tài)的副本控制器提供的工作負載來部署應用程序，比如 Deployment 或者 ReplicaSet可能更適用于你的無狀態(tài)應用部署需要。

//名為 svc-demo 的 Headless Service 用來控制網絡域名
kubectl create svc clusterip svc-demo --tcp=80:80 --dry-run=client -oyaml > svc-demo.yaml
vim svc-demo.yamlapiVersion: v1
kind: Service
metadata:creationTimestamp: nulllabels:app: svc-demoname: svc-demo
spec:ports:- name: httpport: 80protocol: TCPtargetPort: 80selector:app: sts-demo    //擁有此標簽的pod 都有此servicetype: ClusterIPclusterIP: None  //無頭服務的clusterIp為None

//名為 myapp-demo 的 StatefulSet 有一個 Spec，它表明將在獨立的4個 Pod 副本中啟動容器
vim stateful-demo.yaml apiVersion: apps/v1
kind: StatefulSet
metadata:labels:app: myapp-demoname: myapp-demo
spec:serviceName: svc-demoreplicas: 4selector:matchLabels:app: sts-demotemplate:metadata:labels:app: sts-demospec:containers:- image: soscscs/myapp:v1name: myappports:- containerPort: 80volumeClaimTemplates:- metadata:name: pvc-demospec:accessModes:- ReadWriteOnceresources:requests:storage: 2GistorageClassName: nfs-client-storageclass

4.1 StatefulSet由以下幾個部分組成

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

4.2 為什么要有headless？

在deployment中，每一個pod是沒有名稱，是隨機字符串，是無序的。而statefulset中是要求有序的，每一個pod的名稱必須是固定的。當節(jié)點掛了，重建之后的標識符是不變的，每一個節(jié)點的節(jié)點名稱是不能改變的。pod名稱是作為pod識別的唯一標識符，必須保證其標識符的穩(wěn)定并且唯一。
為了實現標識符的穩(wěn)定，這時候就需要一個headless service 解析直達到pod，還需要給pod配置一個唯一的名稱。

4.3 為什么要有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ā)布頻繁：互聯網思維小步快跑，先實現再優(yōu)化，老板永遠是先上線再慢慢優(yōu)化，先把idea變成產品掙到錢然后再慢慢一點一點優(yōu)化
●支持自動伸縮：一來大促，肯定是要擴容多個副本
K8S里服務發(fā)現的方式—DNS，使K8S集群能夠自動關聯Service資源的“名稱”和“CLUSTER-IP”，從而達到服務被集群自動發(fā)現的目的。

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-demoname: myapp-demo
spec:serviceName: svc-demoreplicas: 4selector:matchLabels:app: sts-demotemplate:metadata:labels:app: sts-demospec:containers:- image: soscscs/myapp:v1name: myappports:- containerPort: 80volumeMounts:- name: pvc-demomountPath: /datavolumeClaimTemplates:- metadata:name: pvc-demospec:accessModes:- ReadWriteOnceresources:requests:storage: 2GistorageClassName: nfs-client-storageclass

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

4.4 滾動更新

StatefulSet 控制器將在 StatefulSet 中刪除并重新創(chuàng)建每個 Pod。它將以與 Pod 終止相同的順序進行（從最大的序數到最小的序數），每次更新一個 Pod。在更新其前身之前，它將等待正在更新的 Pod 狀態(tài)變成正在運行并就緒。

 kubectl edit statefulsets.apps myapp-demo kubectl get pods -w   //查看滾動更新的過程

4.5 擴容及縮容

kubectl scale statefulset myapp-demo --replicas=6

kubectl scale statefulset myapp-demo --replicas=3

擴展伸縮
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)查看縮容

當刪除一個 StatefulSet 時，該 StatefulSet 不提供任何終止 Pod 的保證。為了實現 StatefulSet 中的 Pod 可以有序且體面地終止，可以在刪除之前將 StatefulSet 縮容到 0。

示例：
kubectl scale statefulset myappdata-myapp --replicas=0
kubectl delete -f stateful-demo.yaml	

4.6 小結

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

注意：使用普通的 service 也可以解析出被代理Pod的IP地址

五、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 daemon-demo.yamlapiVersion: apps/v1
kind: DaemonSet
metadata:labels:app: myapp-dsname: myapp-ds
spec:selector:matchLabels:app: myapp-dstemplate:metadata:labels:app: myapp-dsspec:containers:- image: soscscs/myapp:v1name: myappports:- containerPort: 80tolerations:- key: node-role.kubernetes.io/masteroperator: Existseffect: NoSchedule

六、Job 控制器

Job分為普通任務（Job）和定時任務（CronJob）
常用于運行那些僅需要執(zhí)行一次的任務
應用場景：數據庫遷移、批處理腳本、kube-bench掃描、離線數據處理，視頻解碼等業(yè)務
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

vim job-demo.yamlapiVersion: batch/v1
kind: Job
metadata:name: myapp-job
spec:template:spec:containers:- name: myappimage: soscscs/myapp:v1command: ["/bin/sh","-c","echo zhangsan like singing ; sleep 10; date; exit 0"]restartPolicy: NeverbackoffLimit: 4

kubectl describe pods myapp-job-gnk6c

kubectl logs myapp-job-gnk6c 

注意：job的重啟策略要么 Never ， 要么 OnFailure ，絕對不能為 Always

七、CronJob 控制器

周期性任務，像Linux的Crontab一樣。
周期性任務
應用場景：通知，備份
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

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è)模板。這類似于工作示例

vim cronjob-demo.yamlapiVersion: 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

八、總結

8.1 Deployment

1）部署無狀態(tài)應用
2）創(chuàng)建和管理 ReplicaSet 和 Pod 資源，并維護Pod副本數量與期望值相同
3）創(chuàng)建和刪除Pod是并行執(zhí)行的，升級策略默認為滾動更新的方式

8.2 StatefulSet

1）部署有狀態(tài)應用
2）每個Pod的名稱都是唯一且固定不變的
3）每個Pod都可以有自己專屬的持久化存儲（基于PVC模板volumeClaimTemplates綁定PV實現的）
4）需要提前創(chuàng)建并關聯一個Headless Service資源（ClusterIP可以為None），在K8S集群內部的Pod應用可以通過 <pod_name>.<svc_name>.<namespace_name>.svc.cluster.local 格式解析出 PodIP（基于無頭服務Headless Service和CoreDNS實現的）
5）創(chuàng)建、滾動升級、擴容、縮容Pod都是有序進行的（默認為串行執(zhí)行的，podManagementPolicy: OrderedReady(默認)|Parallel）
創(chuàng)建、擴容是升序執(zhí)行的（順序為Pod標識號從0到n-1）
滾動升級、縮容是倒序執(zhí)行的（順序為Pod標識號從n-1到0）

Service資源的類型 4+1
ClusterIP NodePort LoadBalancer ExternalName + Headless Service

8.3 DaemonSet

1）理論上可以在K8S所有Node節(jié)點上創(chuàng)建相同的Pod資源（無論Node節(jié)點什么時候加入到K8S集群）
2）調度時會受到Node節(jié)點上的污點或者節(jié)點設置了cordon不可調度的影響，而不會在上述的Node節(jié)點中創(chuàng)建Pod
設置容忍 kubectl node xxx uncordon
3）資源清單配置中不需要設置副本數 replicas

8.4 Job

1）部署一次性短期任務的資源，Pod不會持久運行
2）任務正常完成后Pod容器會正常退出并不會再重啟（restartPolicy通常設置為Nerver或OnFailure），且也不會重建Pod
3）如果任務執(zhí)行異常導致Pod容器異常退出，會重建Pod重試任務，重試次數受 backoffLimit 配置影響（默認為任務失敗后重試 6 次）

8.5 CronJob

1）部署周期性短期任務的資源，Pod不會持久運行
2）任務正常完成后Pod容器會正常退出并不會再重啟（restartPolicy通常設置為Nerver或OnFailure），且也不會重建Pod
3）使用必配字段 schedule 設置任務執(zhí)行的周期表，格式為 分 時 日 月 周