Pod控制器
Pod控制器及其功用
Pod控制器，又稱之為工作負載（workload），是用於實現管理pod的中間層，確保pod資源符合預期的狀態，pod的資源出現故障時，會嘗試進行重啟，當根據重啟策略無效，則會重新新建pod的資源。
pod控制器有多種型別
1、ReplicaSet: 代使用者建立指定數量的pod副本，確保pod副本數量符合預期狀態，並且支援滾動式自動擴容和縮容功能。 ReplicaSet主要三個元件組成： （1）使用者期望的pod副本數量 （2）標籤選擇器，判斷哪個pod歸自己管理 （3）當現存的pod數量不足，會根據pod資源模板進行新建 幫助使用者管理無狀態的pod資源，精確反應使用者定義的目標數量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。 2、Deployment：工作在ReplicaSet之上，用於管理無狀態應用，目前來說最好的控制器。支援滾動更新和回滾功能，還提供宣告式配置。 ReplicaSet 與Deployment 這兩個資源物件逐步替換之前RC的作用。 3、DaemonSet：用於確保叢集中的每一個節點只執行特定的pod副本，通常用於實現系統級後臺任務。比如ELK服務 特性：服務是無狀態的 服務必須是守護程序 4、StatefulSet：管理有狀態應用 5、Job：只要完成就立即退出，不需要重啟或重建 6、Cronjob：週期性任務控制，不需要持續後臺執行
Pod與控制器之間的關係
controllers：在叢集上管理和執行容器的 pod 物件， pod 透過 label-selector 相關聯。
Pod 透過控制器實現應用的運維，如伸縮，升級等。
Deployment
部署無狀態應用
管理Pod和ReplicaSet
具有上線部署、副本設定、滾動升級、回滾等功能
提供宣告式更新，例如只更新一個新的image
應用場景：web服務
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 get pods,deploy,rs
kubectl edit deployment.apps/nginx-deployment
kubectl rollout history deployment/nginx-deployment
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: nginx
namespace: hanbao labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1 kind: StatefulSet metadata: name: web
namespace: hanbao 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: soscscs/myapp:v1 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "nfs-client-storageclass" resources: requests: storage: 1Gi
從上面的應用場景可以發現，StatefulSet由以下幾個部分組成： ●Headless Service（無頭服務）：用於為Pod資源識別符號生成可解析的DNS記錄。 ●volumeClaimTemplates（儲存卷申請模板）：基於靜態或動態PV供給方式為Pod資源提供專有的固定儲存。 ●StatefulSet：用於管控Pod資源。 為什麼要有headless？ 在deployment中，每一個pod是沒有名稱，是隨機字串，是無序的。而statefulset中是要求有序的，每一個pod的名稱必須是固定的。當節點掛了，重建之後的識別符號是不變的，每一個節點的節點名稱是不能改變的。pod名稱是作為pod識別的唯一識別符號，必須保證其識別符號的穩定並且唯一。 為了實現識別符號的穩定，這時候就需要一個headless service 解析直達到pod，還需要給pod配置一個唯一的名稱。 為什麼要有volumeClaimTemplate？ 大部分有狀態副本集都會用到持久儲存，比如分散式系統來說，由於資料是不一樣的，每個節點都需要自己專用的儲存節點。而在 deployment中pod模板中建立的儲存卷是一個共享的儲存卷，多個pod使用同一個儲存卷，而statefulset定義中的每一個pod都不能使用同一個儲存卷，由此基於pod模板建立pod是不適應的，這就需要引入volumeClaimTemplate，當在使用statefulset建立pod時，會自動生成一個PVC，從而請求繫結一個PV，從而有自己專用的儲存卷。 服務發現：就是應用服務之間相互定位的過程。 應用場景： ●動態性強：Pod會飄到別的node節點 ●更新發布頻繁：網際網路思維小步快跑，先實現再最佳化，老闆永遠是先上線再慢慢最佳化，先把idea變成產品掙到錢然後再慢慢一點一點最佳化 ●支援自動伸縮：一來大促，肯定是要擴容多個副本 K8S裡服務發現的方式---DNS，使K8S叢集能夠自動關聯Service資源的“名稱”和“CLUSTER-IP”，從而達到服務被叢集自動發現的目的。 實現K8S裡DNS功能的外掛： ●skyDNS：Kubernetes 1.3之前的版本 ●kubeDNS：Kubernetes 1.3至Kubernetes 1.11 ●CoreDNS：Kubernetes 1.11開始至今
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
#檢視statefulset的定義
kubectl explain statefulset
kubectl explain statefulset.spec
清單定義StatefulSet
如上所述，一個完整的 StatefulSet 控制器由一個 Headless Service、一個 StatefulSet 和一個 volumeClaimTemplate 組成。如下資源清單中的定義
apiVersion: v1 kind: Service metadata: labels: app: mysvc name: mysvc namespace: hanbao spec: selector: app: myapp type: ClusterIP clusterIP: None --- apiVersion: apps/v1 kind: StatefulSet metadata: labels: app: sts01 name: sts01 namespace: hanbao spec: serviceName: mysvc replicas: 2 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - image: soscscs/myapp:v1 name: nginx ports: - containerPort: 80 volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "nfs-client-storageclass" resources: requests: storage: 1Gi
解析上例：由於 StatefulSet 資源依賴於一個實現存在的 Headless 型別的 Service 資源，所以需要先定義一個名為 myapp-svc 的 Headless Service 資源，用於為關聯到每個 Pod 資源建立 DNS 資源記錄。接著定義了一個名為 myapp 的 StatefulSet 資源，它透過 Pod 模板建立了 3 個 Pod 資源副本，並基於 volumeClaimTemplates 向前面建立的PV進行了請求大小為 2Gi 的專用儲存卷。
定義PV
apiVersion: v1 kind: PersistentVolume metadata: name: pv002 labels: name: pv002 spec: nfs: path: /data/volumes/v2 server: 192.168.19.19 accessModes: ["ReadWriteOnce"] capacity: storage: 2Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv003 labels: name: pv003 spec: nfs: path: /data/volumes/v3 server: 192.168.19.19 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 2Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv004 labels: name: pv004 spec: nfs: path: /data/volumes/v4 server: 192.168.19.19 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 2Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv005 labels: name: pv005 spec: nfs: path: /data/volumes/v5 server: 192.168.19.19 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 2Gi
驗證資料持久化
#刪除後重建，poc名稱不會該
#資料還是會一直存在
驗證擴容的建立過程是升序序列執行，並且自動建立pv
kubectl edit -n hanbao statefulsets.apps sts01
#擴容 會根據現有的名稱，繼續建立新的Pod，有序執行，並且為序列
驗證滾動更新的時候也是升序執行，資料持久化還在
kubectl -n hanbao set image statefulset sts01 nginx=soscscs/myapp:v2
#倒序執行，pod的IP會變，但是Pod的名稱始終不變
滾動更新為先刪除1個pod 然後再建立一個新的pod
滾動更新後，資料還在
驗證縮容的時候是倒序執行
kubectl -n hanbao scale statefulset sts01 --replicas=2
#縮容，倒序刪除Pod
#縮容時候PV和PVC不會刪除
statefulset的特點
1、statefulset用於部署有狀態的應用（有實時資料需要儲存的應用） 2、部署statefulset之前，需要先建立一個headless service（表示clusterip為node的特殊service型別），statefulset的配置清單模板需要去指定servicename為headless service的名稱。 3、statefulset建立的pod名稱是固定不變的，且唯一的 4、statefulset的資源配置模板可以設定pvc模板，指定storageclassname欄位值，可以引用storageclass資源，呼叫儲存卷外掛，動態建立pv 5、statefulset管理的pod有滾動更新和擴容和縮容功能，擴容的時候為升序執行，滾動更新和縮容的時候為降序執行。 6、statefulset管理的pod可以在k8s叢集的pod中，基於headless service以及coredns實現對pod名稱解析出podIP
DaemonSet
DaemonSet 確保全部（或者一些）Node 上執行一個 Pod 的副本。當有 Node 加入叢集時，也會為他們新增一個 Pod 。當有 Node 從叢集移除時，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它建立的所有 Pod。
使用 DaemonSet 的一些典型用法：
●執行叢集儲存 daemon，例如在每個 Node 上執行 glusterd、ceph。
●在每個 Node 上執行日誌收集 daemon，例如fluentd、logstash。
●在每個 Node 上執行監控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。
應用場景：Agent
//官方案例（監控）
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節點都建立一個Pod
kubectl get pods
nginx-deployment-4kr6h 1/1 Running 0 35s
nginx-deployment-8jrg5 1/1 Running 0 35s
Job
Job分為普通任務（Job）和定時任務（CronJob） 常用於執行那些僅需要執行一次的任務 應用場景：資料庫遷移、批處理指令碼、kube-bench掃描、離線資料處理，影片解碼等業務 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達到，作業將被標記為失敗。 //在所有node節點下載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 建立的任務執行時發生重疊如何處理（併發性規則僅適用於相同 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> 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
總結
#Pod控制器 1）Deployment + ReplicaSet 部署無狀態應用(沒有實時的資料需要儲存) 負責建立和管理RepliacSet，維護Pod副本數與預期值保持一致 負責建立和刪除控制器管理的Pod資源，有多個Pod副本時是並行建立啟動的，升級策略預設為滾動更新的方式 2）StatefulSet 功能: 部署有狀態應用(有實時的資料需要儲存) 特性: 每個Pod名稱標識都是唯一且固定不變的 每個Pod都可以有自己專屬的持久化儲存(基於PVC模板volumeClaimTemplates實現的) 需要提前建立一個Headless Service資源(無頭服務，ClusterIP為Node的service資源)，並在StatefulSet資源配置中使用serviceName欄位指定Headless Service資源名稱 可以在K8S叢集的Pod中透過<Pod名稱>.<service名稱>.<名稱空間>格式解析出StatefulSet控制器管理的Pod資源的PodIP(基於Headless Service和CoreDNS實現的) 建立、滾動升級、擴容、縮容Pod副本時都是有序進行的(由spec.PodManagementPolicy欄位決定的，預設為OrderedReady，如果設定為Paralle1則並行的管理Pod) 建立、擴容是升序進行的(順序為Pod標識號從0到n-1) 滾動升級、縮容是倒序執行的(順序為Pod標識號從n-1到0) Service資源的型別:4個常規型別(ClusterIP NodePort LoadBalancer ExternalName) + 1個特殊型別(Headless Service) 3）DaemonSet 通常用於部署daemon(守護程序)級別的無狀態應用 理論上可在K8S叢集所有node節點上都建立一個相同的Pod副本，無論node節點何時加入到K8S叢集(需要考慮到汙點taint和cordon不可排程的影響) DaemonSet資源配置不需要設定Pod副本數字段replicas 4）Job 部署一次性的短期任務的Pod資源，Pod不會持續執行，並要求任務執行完畢後容器成功退出且不再重啟。 Job資源配置的容器重啟策略要求不能設定為Always，一般推薦設定為Never 如果任務執行失敗導致Pod容器異常退出，那麼Job會根據backoffLimit欄位的值決定重建Pod來重試任務的次數(預設為6) 5）Cronjob 部署週期性的短期任務的Pod資源，Pod不會持續執行，並要求任務執行完畢後容器成功退出且不再重啟。 Pod容器重啟策略要求不能設定為Always，一般推薦設定為Never 要配置schedule欄位設定任務執行的週期表，格式為"分 時 日 月 周"