目錄

1.什么是POD控制器

2.POD控制器有幾種類型

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

4.示例

4.1?Deployment

4.2?SatefulSet

①為什么要有headless？

②為什么要有volumeClainTemplate？

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

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

4.3?安裝CoreDNS，僅二進制部署環境需要安裝CoreDNS

無狀態應用（Stateless Applications）：

有狀態應用（Stateful Applications）：

常規 Service 和無頭服務（Headless Service）的區別：

4.4?DaemonSet

4.5?Job

4.6?CronJob?

---

1.什么是POD控制器

Pod控制器是 Kubernetes 中用于管理和控制 Pod 的重要資源，包括 ReplicaSet 和 Deployment 等。它們通過定義 Pod 模板來創建和管理 Pod 副本，實現自動擴縮容、滾動更新、故障恢復等功能。Pod 控制器負責監控 Pod 的運行狀態，確保其符合用戶定義的規則和策略。

Pod 控制器是 Kubernetes 應用生命周期管理的關鍵組件，提供了豐富的功能和靈活的配置選項，幫助用戶輕松管理和運維應用程序的 Pod 資源。在 Pod 控制器中，用戶可以指定副本數量、滾動更新策略、健康檢查等參數，以確保應用程序的高可用性、伸縮性和穩定性。

總的來說，Pod 控制器是 Kubernetes 中實現工作負載管理的中間層，保證 Pod 資源處于預期狀態。當 Pod 出現故障時，Pod 控制器會嘗試重啟或重新創建 Pod 資源，根據配置的重啟策略進行相應的處理。這樣可以確保應用程序持續可用并按照用戶期望的方式運行。

---

2.POD控制器有幾種類型

• ReplicaSet：用于創建指定數量的 Pod 副本，確保 Pod 數量符合預期狀態。主要組成包括用戶定義的副本數量、標簽選擇器和根據 Pod 模板創建新的 Pod 資源。雖然 ReplicaSet 不是直接使用的控制器，但通常與 Deployment 結合使用。

• Deployment：在 ReplicaSet 的基礎上，用于管理無狀態應用程序，支持滾動更新、回滾功能，并提供聲明式配置。Deployment 是目前應用最廣泛的控制器，逐漸取代之前的 ReplicationController。

• DaemonSet：確保集群中每個節點運行特定的 Pod 副本，通常用于實現系統級后臺任務。適用于無狀態服務和守護進程類應用。

• StatefulSet：用于管理有狀態應用程序，為每個 Pod 分配唯一標識符，確保狀態的穩定性和持久性。

• Job：執行一次性任務，任務完成后立即退出，不需要重啟或重新創建。適用于一次性作業。

• CronJob：用于周期性任務控制，按照預定的時間表周期性地執行任務，不需要持續后臺運行。

---

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

Pod 控制器在 Kubernetes 集群中起著至關重要的作用，用于管理和運行容器化應用程序的 Pod 對象。Pod 通過標簽選擇器（label-selector）與控制器相關聯，控制器負責監控、調度和維護一組 Pod，確保它們符合用戶定義的期望狀態。

Pod 控制器為用戶提供了一種抽象層，通過控制器可以實現對應用程序的運維管理，包括但不限于：

• 伸縮：控制器可以根據用戶定義的策略自動擴展或縮減 Pod 的數量，以應對流量變化或負載情況。

• 升級：控制器支持滾動升級功能，可以逐步替換舊版本的 Pod 為新版本，確保應用程序的平穩升級。

• 故障恢復：當 Pod 發生故障或所在節點不可用時，控制器會重新調度 Pod 到其他可用節點上，確保應用程序的高可靠性。

• 負載均衡：控制器可以結合服務發現機制實現負載均衡，確保請求能夠均勻分布到各個 Pod 上。

Pod 控制器是 Kubernetes 中實現應用程序管理和運維的核心組件，通過控制器可以輕松實現對應用程序的自動化管理，減少人工干預，提高系統的穩定性和可靠性。

---

4.示例

4.1?Deployment

• 部署無狀態應用：Deployment 控制器通常用于部署無狀態應用程序，它通過管理 Pod 和 ReplicaSet 來確保應用程序的可用性和健康運行。

• 管理 Pod 和 ReplicaSet：Deployment 控制器負責創建并管理多個 Pod 的副本（ReplicaSet），以確保根據用戶定義的副本數來維持應用程序的運行狀態。

• 具有上線部署、副本設定、滾動升級、回滾等功能：Deployment 控制器提供了豐富的功能，包括支持灰度發布（rolling updates）、副本數量配置、滾動升級（rolling upgrades）以及回滾到先前版本等操作。

• 提供聲明式更新：Deployment 控制器支持聲明式配置更新，用戶可以只更新一個新的容器鏡像（image），而不必關心具體的升級操作步驟，簡化了應用程序的更新流程。

• 應用場景：Deployment 控制器適用于部署需要水平擴展、自動恢復、靈活升級的應用場景，特別適合用于部署 Web 服務等無狀態應用程序。

Deployment 控制器是 Kubernetes 中用于管理應用程序部署和更新的關鍵組件，通過 Deployment 控制器，用戶可以方便地進行應用程序的部署、擴展、更新和回滾，提高了應用程序的可靠性和可管理性。

vim nginx-deployment.yamlapiVersion: 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

#查看控制器配置

kubectl edit deployment/nginx-deploymentapiVersion: apps/v1
kind: Deployment
metadata:annotations:deployment.kubernetes.io/revision: "1"creationTimestamp: "2021-04-19T08:13:50Z"generation: 1labels:app: nginx					#Deployment資源的標簽name: nginx-deploymentnamespace: defaultresourceVersion: "167208"selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deploymentuid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
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>

4.2?SatefulSet

• 部署有狀態應用：StatefulSet 適用于需要持久化數據和穩定標識的有狀態應用，如數據庫、消息隊列等。

• 穩定的持久化存儲：StatefulSet 可以通過 PersistentVolumeClaim（PVC）來實現穩定的持久化存儲，確保 Pod 在重新調度后仍能訪問相同的持久化數據。

• 穩定的網絡標志：通過 Headless Service（無 Cluster IP 的 Service）來實現穩定的網絡標志，確保 Pod 在重新調度后其 PodName 和 HostName 不變。

• 有序部署和擴展：StatefulSet 支持有序部署和擴展，即在部署或者擴展時，Pod 將按照定義的順序依次進行，init containers 可以用于確保有序性。

• 有序收縮和刪除：StatefulSet 還支持有序收縮和刪除，即在收縮或刪除時，Pod 也將按照相反的順序依次進行。

StatefulSet 提供了一種解決有狀態應用部署和管理中的一些復雜性的方法，使得在 Kubernetes 集群中部署和運行有狀態應用更加可靠和穩定。

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 在 Kubernetes 中的關鍵組成部分和作用：

• Headless Service（無頭服務）：

  • 用于為 StatefulSet 中每個 Pod 資源生成可解析的 DNS 記錄。
  • 每個 Pod 都具有唯一的標識符，并且可以通過 DNS 進行發現和通信。
  • 提供了穩定的網絡標識和服務發現機制，適用于需要直接訪問每個 Pod 的場景。

• volumeClaimTemplates（存儲卷申請模板）：

  • 基于靜態或動態 PV 供給方式為 StatefulSet 中的 Pod 資源提供專有的固定存儲。
  • 通過定義存儲卷申請模板，可以確保每個 Pod 都擁有獨立的持久化存儲，避免數據丟失和混亂。
  • 支持在 Pod 重啟或遷移時保持數據的持久性和一致性。

• StatefulSet：

  • 用于管控管理 StatefulSet 中的 Pod 資源，確保這些資源按照指定的順序和規則被創建、更新和刪除。
  • 提供了有狀態應用的部署和管理能力，適用于需要穩定標識、順序部署和有狀態數據處理的場景。
  • 與 Deployment 類似，但更適合管理有狀態應用，如數據庫、緩存等需要持久化存儲和穩定標識的服務。

通過組合使用 Headless Service、volumeClaimTemplates 和 StatefulSet，可以有效地部署和管理有狀態應用，確保數據的持久性、可靠性和穩定性，并提供強大的服務發現和通信機制，滿足不同場景下對有狀態應用的需求。

①為什么要有headless？

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

②為什么要有volumeClainTemplate？

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

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

應用場景：

• 自動關聯：Kubernetes 集群中的 Pod 可以通過 DNS 來解析 Service 的名稱，無需手動配置 IP 地址，從而實現自動關聯。
• 動態性強：由于 Pod 可能會在集群中的不同節點上飄移，使用 DNS 可以保證無論 Pod 在哪個節點上，都能夠通過 Service 名稱來訪問其他服務。
• 更新發布頻繁：由于互聯網應用的小步快跑特點，Service 的更新和發布頻繁，使用 DNS 可以確保服務在更新后仍然可以被其他服務發現和訪問。
• 支持自動伸縮：Kubernetes 中的自動伸縮功能可以根據負載情況動態調整 Pod 的數量，而使用 DNS 可以確保新增或減少的 Pod 能夠被自動發現并加入到服務發現機制中。

使用 DNS 服務進行服務發現可以極大地簡化應用程序的部署和擴展，并且適應了動態性強、更新發布頻繁和自動伸縮等場景的需求。

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

對于不同版本的 Kubernetes，有不同的 DNS 插件來實現服務發現功能：

• SkyDNS：適用于 Kubernetes 1.3 之前的版本。SkyDNS 基于 etcd 存儲 DNS 記錄，通過 Go 語言實現，是早期 Kubernetes 版本中用于服務發現的默認插件。
• kube-dns：適用于 Kubernetes 1.3 到 Kubernetes 1.11 的版本。kube-dns 包含 kube-dns、dns-masq 和 sidecar 三個組件，通過 etcd 存儲 DNS 記錄，并使用輕量級的 DNS 服務器 dns-masq 進行緩存。
• CoreDNS：適用于 Kubernetes 1.11 版本及以后。CoreDNS 是一個功能強大且可擴展的 DNS 服務器，支持多種協議和后端存儲，取代了 kube-dns 成為默認的 DNS 插件，具有更好的性能和可擴展性。

這些 DNS 插件都能夠實現將 Service 的名稱映射到 ClusterIP 地址，使得在 Kubernetes 集群中，應用服務可以通過使用 Service 的名稱來發現和相互通信，而無需直接暴露 IP 地址或進行復雜的手動配置。這樣便于管理和維護整個集群的服務發現機制。

4.3?安裝CoreDNS，僅二進制部署環境需要安裝CoreDNS

#上傳 coredns.yaml 文件

kubectl create -f coredns.yamlkubectl get pods -n kube-systemvim nginx-service.yamlapiVersion: v1  
kind: Service  
metadata:name: nginx-servicelabels:app: nginx  
spec:type: NodePort  ports:- port: 80targetPort: 80  selector:app: nginxkubectl create -f nginx-service.yamlkubectl get svc

vim pod6.yaml apiVersion: v1
kind: Pod
metadata:name: dns-test
spec:containers:- name: busyboximage: busybox:1.28.4args:- /bin/sh- -c- sleep 36000restartPolicy: Neverkubectl create -f pod6.yaml 

#解析kubernetes和nginx-service名稱

kubectl exec -it dns-test sh
/ # nslookup kubernetes
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local
/ # nslookup nginx-service
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName:      nginx-service
Address 1: 10.96.173.115 nginx-service.default.svc.cluster.local

#查看statefulset的定義

kubectl explain statefulset

kubectl explain statefulset.specKIND:     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對象的標識進行關聯volume.beta.kubernetes.io/storage-class: nfs-client-storageclassspec:accessModes: ["ReadWriteOnce"]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.yamlapiVersion: 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: 2Gikubectl apply -f pv-demo.yamlkubectl get pv

#創建statefulset

kubectl apply -f stateful-demo.yaml kubectl get svc  #查看創建的無頭服務myapp-svckubectl get sts    #查看statefulsetkubectl get pvc    #查看pvc綁定kubectl get pv    #查看pv綁定kubectl get pods   #查看Pod信息kubectl delete -f stateful-demo.yaml	

#當刪除的時候是從myapp-2開始進行刪除的，關閉是逆向關閉

kubectl get pods -w

#此時PVC依舊存在的，再重新創建pod時，依舊會重新去綁定原來的pvc

kubectl apply -f stateful-demo.yamlkubectl get pvc

#滾動更新

#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   #查看滾動更新的過程

#在創建的每一個Pod中，每一個pod自己的名稱都是可以被解析的

kubectl exec -it myapp-0 /bin/sh

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

(pod_name).(service_name).(namespace_name).svc.cluster.local

無狀態應用（Stateless Applications）：

• Deployment?視所有的 Pod 都是相同的，可以隨意創建和銷毀。
• 無需考慮執行順序或特定節點上的運行。
• 可以隨意擴展和縮減副本數量，適用于橫向擴展。
• 適合處理請求和響應，對數據的持久性要求不高。

有狀態應用（Stateful Applications）：

• 每個實例都有獨特的特性和元數據，如 etcd、ZooKeeper 等。
• 實例之間存在差異，依賴外部存儲，要求數據持久性和穩定性。
• 不同實例之間可能需要維護狀態或連接關系。

常規 Service 和無頭服務（Headless Service）的區別：

• Service：為一組 Pod 提供統一的訪問入口，提供負載均衡、服務發現和集群內通信。具有 ClusterIP，通過該 ClusterIP 可以訪問 Service 提供的服務。
• Headless Service：無頭服務，不分配 ClusterIP，而是通過 DNS 記錄直接暴露每個 Pod 的 IP 地址。適用于需要直接訪問 Pod IP 或進行 Pod 級別的服務發現的場景，不提供負載均衡功能。

vim pod6.yaml apiVersion: v1
kind: Pod
metadata:name: dns-test
spec:containers:- name: busyboximage: busybox:1.28.4args:- /bin/sh- -c- sleep 36000restartPolicy: Nevervim sts.yaml
apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---
apiVersion: apps/v1beta1  
kind: StatefulSet  
metadata:name: nginx-statefulset  namespace: default
spec:serviceName: nginx  replicas: 3  selector:matchLabels:  app: nginxtemplate:  metadata:labels:app: nginx  spec:containers:- name: nginximage: nginx:latest  ports:- containerPort: 80  kubectl apply -f sts.yamlkubectl apply -f pod6.yamlkubectl get pods,svc

kubectl exec -it dns-test shkubectl exec -it nginx-statefulset-0 bash

#擴展伸縮

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  #動態查看縮容

4.4?DaemonSet

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

• 自動部署和回收：當新的節點加入集群時，DaemonSet 會為其創建相應的 Pod，而當節點從集群移除時，DaemonSet 也會回收相應的 Pod。

• 全局部署：DaemonSet 確保在整個集群范圍內都有相同數量的 Pod 實例在運行，無論節點數量如何變化。

• 典型用途：DaemonSet 的典型應用場景包括運行集群存儲 daemon、日志收集 daemon、監控 daemon 等，這些都是需要在每個節點上運行一個實例的應用程序。

• 應用場景：在 Agent 場景下，DaemonSet 特別適合用來部署運行在每個節點上的代理程序，例如服務發現代理、監控代理、日志收集代理等，確保在整個集群范圍內都有這些代理程序的實例在運行。

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: 80kubectl apply -f ds.yaml

#DaemonSet會在每個node節點都創建一個Pod

kubectl get pods

4.5?Job

Job：Job 是 Kubernetes 中用于運行一次性任務的控制器。它確保一個或多個 Pod 成功完成任務后終止，并且能夠處理任務失敗時的重試和并行處理等情況。

CronJob：CronJob 是基于時間表達式的定時任務控制器，允許用戶在指定的時間間隔內運行 Job。通過 CronJob，用戶可以輕松地設置定時任務，例如每天凌晨執行一次備份任務。

應用場景：Job 和 CronJob 在很多場景下非常有用，包括數據庫遷移、批處理腳本的執行、安全掃描（如 kube-bench）、離線數據處理以及視頻解碼等業務需求。這些任務通常是一次性的、定時的或者需要在集群中定期執行的。

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

#結果輸出到控制臺

kubectl logs pi-bqtf7

#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,podskubectl describe job busybox

4.6?CronJob?

CronJob 是一種周期性任務控制器，類似于 Linux 中的 Crontab，允許用戶根據預定的時間表達式來執行作業。一些常見的應用場景包括發送通知、執行備份等需要定期執行的任務。

#每分鐘打印hello

vim cronjob.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

注意：cronjob其它可用參數的配置

spec:
? concurrencyPolicy: Allow?? ??? ??? ?#要保留的失敗的完成作業數（默認為1）
? schedule: '*/1 * * * *'?? ??? ??? ?#作業時間表。在此示例中，作業將每分鐘運行一次
? startingDeadlineSeconds: 15?? ??? ?#pod必須在規定時間后的15秒內開始執行，若超過該時間未執行，則任務將不運行，且標記失敗
? successfulJobsHistoryLimit: 3?? ??? ?#要保留的成功完成的作業數（默認為3）
? terminationGracePeriodSeconds: 30?? ?#job存活時間 默認不設置為永久
? jobTemplate:?? ??? ??? ??? ??? ??? ?#作業模板。這類似于工作示例

kubectl create -f cronjob.yaml kubectl get cronjobkubectl get pods