k8s之Pod控制器使用及說明
k8s之Pod控制器
一、Pod控制器
- Pod控制器,又稱之為工作負載(workload),是用于實現(xiàn)管理pod的中間層,確保pod資源符合預期的狀態(tài),pod的資源出現(xiàn)故障時,會嘗試進行重啟,當根據(jù)重啟策略無效,則會重新新建pod的資源。
1、pod控制器類型
1.1 ReplicaSet
- 代用戶創(chuàng)建指定數(shù)量的pod副本,確保pod副本數(shù)量符合預期狀態(tài),并且支持滾動式自動擴容和縮容功能。
ReplicaSet主要三個組件組成
- 用戶期望的pod副本數(shù)量
- 標簽選擇器,判斷哪個pod歸自己管理
- 當現(xiàn)存的pod數(shù)量不足,會根據(jù)pod資源模板進行新建
幫助用戶管理無狀態(tài)的pod資源,精確反應用戶定義的目標數(shù)量,但是RelicaSet不是直接使用的控制器,而是使用Deployment。
1.2 Deployment
- Deployment是最常用的Pod控制器之一,建立在ReplicaSet之上,它用于部署無狀態(tài)應用程序。Deployment定義了Pod的期望副本數(shù),并通過滾動更新和回滾機制來管理Pod的升級和降級。
- 工作在ReplicaSet之上,用于管理無狀態(tài)應用,目前來說最好的控制器。支持滾動更新和回滾功能,還提供聲明式配置。
1.3 DaemonSet
- 用于確保集群中的每一個節(jié)點運行一個pod副本,通常用于實現(xiàn)系統(tǒng)級后臺任務。比如ELK服務。
1.4 StatefulSet
- 部署有狀態(tài)的應用,每個pod的名稱是唯一不變的,每個pod擁有自己專屬的持久化的存儲(pv/pvc)。
1.5 Job
- Job用于運行一次性任務,如批處理作業(yè)或短生命周期的應用程序。Job會創(chuàng)建Pod來執(zhí)行任務,并在任務完成后刪除Pod。
- 只要完成就立即退出,不需要重啟或重建。
1.6 Cronjob
- 周期性任務控制,不需要持續(xù)后臺運行
2、Pod與控制器之間的關(guān)系
- controllers:在集群上管理和運行容器的 pod 對象, pod 通過 label-selector 相關(guān)聯(lián)。
- Pod 通過控制器實現(xiàn)應用的運維,如伸縮,升級等。
二、使用POD控制器
1、Deployment
- 部署無狀態(tài)應用
- 管理Pod和ReplicaSet
- 具有上線部署、副本設定、滾動升級、回滾等
- 提供聲明式更新,例如只更新一個新的image
- 應用場景:Web服務、微服務
1.1 創(chuàng)建控制器
kubectl create deployment deploy --image=nginx:1.18 --port=80 --replicas=1 --dry-run=client -oyaml > deploy.yaml
#生成yaml配置文件模板
#修改yaml配置文件
vim deploy.yaml
apiVersion: apps/v1
#指定API版本
kind: Deployment
#指定創(chuàng)建資源類型為Deployment
metadata:
#定義資源的元數(shù)據(jù)信息
name: nginx-deploy
#指定資源的名稱
labels:
#設置標簽
app: nginx
#標簽以鍵值表示,標簽鍵為app,標簽值為nginx
spec:
#定義資源的規(guī)格
replicas: 1
#指定創(chuàng)建pod數(shù)量為1個
selector:
#選擇由Deployment管理的Pod的標簽選擇器
matchLabels:
#指定用于匹配的標簽
app: nginx
#設置標簽需要與模板標簽一致
template:
#創(chuàng)建pod的模板,deployment管理的pod實例,都由此模板定義
metadata:
#模板的元數(shù)據(jù)信息
labels:
#定義pod的標簽
app: nginx
#此處需要與deployment管理pod的標簽選擇器一致
spec:
#pod的規(guī)格信息
containers:
#定義pod中運行的容器列表
- name: nginx
#指定容器名稱
image: nginx:1.18.0
#指定鏡像版本
ports:
#定義端口
- containerPort: 80
#定義容器內(nèi)部的監(jiān)聽端口
kubectl apply -f deploy.yaml
#創(chuàng)建資源
kubectl get pods,deploy,rs
#查看pod資源信息


1.2 更新版本
curl 10.244.2.116 -I
#查看版本信息(nginx版本信息是1.80版本)
#修改yaml配置文件
vim deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx-deploy
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.20
#修改版本號
name: nginx
ports:
- containerPort: 80
kubectl apply -f deploy.yaml
#重新創(chuàng)建資源


1.3 查看更新的版本號
kubectl get pod -w #另開一個終端,追蹤查看pod更新過程 curl -I 10.244.1.104 #查看版本信息(nginx版本更新為1.20版本)


2、SatefulSet
StatefulSet 是 Kubernetes 中的一個資源控制器,它用于管理有狀態(tài)的應用。與 Deployment 和 ReplicaSet 這樣的無狀態(tài)工作負載不同,StatefulSet 為每個 Pod 提供了一個穩(wěn)定的、唯一的標識符,并且能夠保證 Pod 的部署順序和終止順序。
- 穩(wěn)定的標識符:每個Pod都有一個唯一的、持久的標識符,這個標識符在 Pod 的整個生命周期中都是不變的。這使得即使 Pod 被重新調(diào)度,其標識符也會保持不變。這一功能常?;贖eadless(無頭模式,即沒有Cluster IP的Service)實現(xiàn)
- 有序的部署和擴展:Pod 是按照特定的順序進行創(chuàng)建和擴展(0到N-1)的。這允許應用程序在部署時按照特定的順序進行初始化。
- 有序的終止和縮容:當縮容或刪除 StatefulSet 時,Pod 會按照相反的順序(N-1到0)進行終止。這允許應用程序在關(guān)閉時按照特定的順序進行清理。
- 穩(wěn)定的持久化存儲:StatefulSet 常常與 PersistentVolumeClaims(PVCs)一起使用,以提供穩(wěn)定的存儲。即使 Pod 被重新調(diào)度,其存儲卷也會被保留并重新附加到新的 Pod 上。
- 常見的應用場景:數(shù)據(jù)庫
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ #官方文檔
2.1 StatefulSet的三個關(guān)鍵組成部分以及其作用
StatefulSet 的設計是為了滿足有狀態(tài)應用的需求,這些應用通常需要持久化存儲和穩(wěn)定的網(wǎng)絡標識。
2.1.1 Headless Service(無頭服務)
- 目的:Headless Service 用于為 StatefulSet 中的每個 Pod 提供一個穩(wěn)定的 DNS 名稱。這樣,即使 Pod 被重新調(diào)度到其他節(jié)點,它的 DNS 名稱也不會改變,從而保證了網(wǎng)絡標識的穩(wěn)定性。
- 實現(xiàn):Headless Service 不分配 Cluster IP,而是直接將 DNS 請求解析到對應的 Pod IP。這樣,每個 Pod 都有一個基于 StatefulSet 名稱和 Pod 序號的 DNS 子域,例如 web-0.nginx.default.svc.cluster.local。
2.1.2 VolumeClaimTemplates
- 目的:VolumeClaimTemplates 用于為每個 Pod 提供獨立的持久化存儲。這樣,每個 Pod 都有自己的存儲空間,即使在 Pod 重新調(diào)度后,也能保持數(shù)據(jù)的連續(xù)性和一致性。
- 實現(xiàn):在 StatefulSet 的定義中,可以包含一個或多個 VolumeClaimTemplates。當 StatefulSet 創(chuàng)建 Pod 時,會為每個 Pod 創(chuàng)建相應的 PersistentVolumeClaim (PVC)。這些 PVC 會請求與 StatefulSet 關(guān)聯(lián)的 PersistentVolume (PV),從而為每個 Pod 提供專用的存儲卷。
2.1.3 StatefulSet 控制器
- 目的:StatefulSet 控制器負責管理 Pod 的生命周期,確保 Pod 的數(shù)量符合用戶的期望,并且按照順序進行部署、擴展和收縮。
- 實現(xiàn):StatefulSet 控制器會監(jiān)控 Pod 的狀態(tài),確保每個 Pod 都按照定義的順序運行。在進行滾動更新時,它會按照順序逐個更新 Pod,確保在更新下一個 Pod 之前,所有先前的 Pod 都已經(jīng)就緒。同樣,在刪除 Pod 時,也會按照相反的順序進行,以確保服務的平滑過渡。
總結(jié)
- Headless Service(無頭服務):用于為Pod資源標識符生成可解析的DNS記錄
- VolumeClaimTemplates(存儲卷申請模板):基于靜態(tài)或動態(tài)PV供給方式為Pod資源提供專有的固定存儲
- StatefulSet:用于管控Pod資源
這三個組件共同工作,使得 StatefulSet 能夠為有狀態(tài)應用提供所需的穩(wěn)定性和可靠性。Headless Service 解決了網(wǎng)絡標識的穩(wěn)定性問題,VolumeClaimTemplates 解決了持久化存儲的需求,而 StatefulSet 控制器則確保了 Pod 的有序管理和更新。這種設計使得 StatefulSet 成為部署和管理有狀態(tài)應用的理想選擇,如數(shù)據(jù)庫、消息隊列等。
為什么要有headless?
- 在deployment中,每一個pod是沒有名稱,是隨機字符串,是無序的。而statefulset中是要求有序的,每一個pod的名稱必須是固定的。當節(jié)點掛了,重建之后的標識符是不變的,每一個節(jié)點的節(jié)點名稱是不能改變的。pod名稱是作為pod識別的唯一標識符,必須保證其標識符的穩(wěn)定并且唯一。
- 為了實現(xiàn)標識符的穩(wěn)定,這時候就需要一個headless service 解析直達到pod,還需要給pod配置一個唯一的名稱。
為什么要有volumeClainTemplate?
- 大部分有狀態(tài)副本集都會用到持久存儲,比如分布式系統(tǒng)來說,由于數(shù)據(jù)是不一樣的,每個節(jié)點都需要自己專用的存儲節(jié)點。而在 deployment中pod模板中創(chuàng)建的存儲卷是一個共享的存儲卷,多個pod使用同一個存儲卷,而statefulset定義中的每一個pod都不能使用同一個存儲卷,由此基于pod模板創(chuàng)建pod是不適應的,這就需要引入volumeClainTemplate,當在使用statefulset創(chuàng)建pod時,會自動生成一個PVC,從而請求綁定一個PV,從而有自己專用的存儲卷。
服務發(fā)現(xiàn):就是應用服務之間相互定位的過程。
應用場景:
- 動態(tài)性強:Pod會飄到別的node節(jié)點
- 更新發(fā)布頻繁:互聯(lián)網(wǎng)思維小步快跑,先實現(xiàn)再優(yōu)化,老板永遠是先上線再慢慢優(yōu)化,先把idea變成產(chǎn)品掙到錢然后再慢慢一點一點優(yōu)化
- 支持自動伸縮:一來大促,肯定是要擴容多個副本
K8S里服務發(fā)現(xiàn)的方式—DNS,使K8S集群能夠自動關(guān)聯(lián)Service資源的“名稱”和“CLUSTER-IP”,從而達到服務被集群自動發(fā)現(xiàn)的目的。
實現(xiàn)K8S里DNS功能的插件
- skyDNS:Kubernetes 1.3之前的版本
- kubeDNS:Kubernetes 1.3至Kubernetes 1.11
- CoreDNS:Kubernetes 1.11開始至今
2.2 創(chuàng)建控制器
- 先清空之前創(chuàng)建的pod資源

- 驗證dns是否可以使用
kubectl run busybox --image=busybox:1.28 -- sleep 36000 #創(chuàng)建一個busybox的pod,該容器提供一些基本的命令,主要用于測試環(huán)境 kubectl get pod busybox #查看pod資源 kubectl exec -it busybox sh #進入容器 / # nslookup kubernetes #測試svc能否正常解析,可以使用kubectl get svc查看有哪些svc(解析正常,解析kubernetes的地址為10.96.0.1) kubectl get svc #查看svc資源信息

2.2.1 創(chuàng)建svc資源
#編輯yaml配置文件
vim service.yaml
apiVersion: v1
#指定API版本
kind: Service
#創(chuàng)建資源類型為Service
metadata:
name: headless-svc
#指定service名稱
labels:
app: headless-svc
#設置service標簽
spec:
ports:
- port: 80
#service端口
name: web
#端口名稱
targetPort: 80
#指定流量轉(zhuǎn)發(fā)的目標端口,與pod暴露的端口一致
clusterIP: None
#將clusterIP地址的值設置為None,表示無IP地址,即無頭模式
selector:
#選擇管理的標簽
app: state
#此標簽需要與StatefulSet控制器管理的pod模板中定義的標簽一致
type: ClusterIP
#設置類型為ClusterIP,此為默認設置,可以省略
kubectl apply -f service.yaml
#創(chuàng)建資源
kubectl get svc headless-svc
#查看資源信息

2.2.2 創(chuàng)建StatefulSet
#編輯yaml配置文件
vim statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
#創(chuàng)建資源類型為StatefulSet
metadata:
name: state
#指定資源名稱
spec:
serviceName: headless-svc
#指定需要綁定的service名稱
replicas: 3
#創(chuàng)建pod數(shù)量為三個
selector:
#標簽選擇器,指定StatefulSet要管理哪些pod
matchLabels:
#指定標簽名稱
app: state
#必須與service中selector定義的標簽一致。pod含有此標簽的,都會去管理
template:
#指定pod創(chuàng)建模板
metadata:
labels:
app: state
#設置pod標簽,與上面標簽選擇器相同,StatefulSet才會管理
spec:
containers:
#定義pod中運行的容器
- name: nginx-pod
#應當設置有狀態(tài)的服務,在此以nginx為例,官方文檔有MySQL示例
image: nginx:1.18.0
#定義鏡像
ports:
- containerPort: 80
#定義容器監(jiān)聽端口
name: web
#端口名稱
volumeMounts:
#定義將存儲卷卷掛載到指定目錄
- name: html
#指定存儲卷名稱
mountPath: /usr/share/nginx/html
#掛載到此目錄,此目錄為nginx服務的站點目錄
volumeClaimTemplates:
#PVC的請求模板
- metadata:
name: html
#定義PVC的名稱
annotations:
volume.beta.kubernetes.io/storage-class: nfs-client-storageclass
#用于指定存儲類的注解。該存儲類定義了用于動態(tài)卷供應的后端存儲類型
spec:
accessModes: ["ReadWriteOnce"]
#指定訪問模式為RWO
resources:
requests:
storage: 2Gi
#指定存儲卷的使用大小
kubectl apply -f statefulset.yaml
#創(chuàng)建資源
長度、
kubectl get statefulsets.apps state
#查看資源信息
kubectl get pod -owide -w
#查看pod資源信息
#它會按照0到N-1的順序去指定pod名稱,一定建立,指定pod生命周期結(jié)束,否則IP地址改變,它的名稱也不會改變
kubectl get pv,pvc
#查看pv/pvc資源信息



- 在nfs服務器上自定義web頁面
- nfs服務器
cd /nfs/k8s #切換目錄 echo "this is state-0" > default-html-state-0-pvc-5d4f3a8c-f5da-4aae-a244-1cfef9f328ec/index.html #編輯state-0訪問頁面 echo "this is state-1" > default-html-state-1-pvc-23363402-a920-471e-9a1b-da43af18620d/index.html #編輯state-1訪問頁面 echo "this is state-2" > default-html-state-2-pvc-754e992e-4573-408d-b78d-687f5dfd285f/index.html #編輯state-2訪問頁面

- 訪問驗證
由于沒有ClusterIP地址,想要通過IP地址訪問,只能在k8s集群中直接訪問podIP
curl 10.244.2.120 curl 10.244.2.121 curl 10.244.1.109 #訪問驗證

2.2.3 使用service訪問
- 創(chuàng)建的svc是可以進行解析的
kubectl exec -it busybox sh #進入容器 / # nslookup headless-svc #查看dns解析 #service會通過endpoint關(guān)聯(lián)到后端的pod

- 訪問驗證
由于pod的IP地址是k8s集群內(nèi)部的IP地址,且并沒有clusterIP去綁定podIP,只有域名管理,宿主機的DNS解析,無法解析k8s集群內(nèi)部的域名與地址,所以使用宿主機無法訪問pod。只能通過創(chuàng)建pod,在pod中進行訪問
kubectl run centos --image=centos:7 -- sleep 36000 #創(chuàng)建一個centos容器,訪問service kubectl exec -it centos sh #進入容器 curl headless-svc #訪問驗證

2.3 刪除與創(chuàng)建
- 當pod刪除時,會按照N-1到0的順序,倒序刪除
kubectl delete -f statefulset.yaml #刪除pod資源 kubectl get pod -w #另開一個終端,跟蹤查看pod資源信息

- 重新創(chuàng)建的時候,數(shù)據(jù)會持久化 ,而且創(chuàng)建的順序還是按照0到N-1的順序創(chuàng)建
kubectl apply -f statefulset.yaml #重新創(chuàng)建資源 kubectl exec -it centos sh #進入容器 curl headless-svc #訪問驗證(重新創(chuàng)建之后再次訪問,數(shù)據(jù)不會丟失)

- 重新創(chuàng)建之后再次訪問,數(shù)據(jù)不會丟失
kubectl exec -it busybox sh #進入測試容器 / # nslookup headless-svc #測試svc解析,后端ip地址發(fā)生變化 #不論后端的IP地址如何變化,只通過DNS來解析service,從而綁定后端的IP地址,得到數(shù)據(jù)

2.4 deployment與statefulset的區(qū)別
2.4.1 應用場景
Deployment:主要用于部署無狀態(tài)服務,即服務實例之間可以相互替換且不需要保留特定的網(wǎng)絡標識或存儲數(shù)據(jù)。它適用于那些不需要關(guān)心Pod具體身份且可任意替換的彈性 服務。
StatefulSet:適用于部署有狀態(tài)的服務,比如數(shù)據(jù)庫集群、消息隊列等。這些服務需要穩(wěn)定的持久化存儲和唯一、有序的網(wǎng)絡標識。StatefulSet為Pod分配的網(wǎng)絡標識符和存儲都是穩(wěn)定的,使得應用能夠維持跨重啟或再調(diào)度的持久狀態(tài)。
2.4.2 Pod管理
Deployment:通過ReplicaSet確保指定數(shù)量的Pod副本始終運行,提供水平擴展和滾動更新能力。Pod由Deployment創(chuàng)建時,雖然可以自定義名稱,但通常由系統(tǒng)生成,并在重建或擴展時可能會發(fā)生變化。
StatefulSet:Pods在創(chuàng)建、更新和刪除時按照順序進行,以滿足那些依賴于嚴格順序啟動或停止的應用場景需求。每個Pod都有一個固定的、唯一的網(wǎng)絡標識符,并且其持久卷聲明(PVC)會綁定到持久化的存儲,即使Pod被刪除后重新創(chuàng)建,存儲的數(shù)據(jù)也會保留。
2.4.3 存儲與網(wǎng)絡
Deployment:通常不直接管理Pod的存儲和網(wǎng)絡,而是依賴于其他Kubernetes資源(如PersistentVolume和Service)來實現(xiàn)這些功能。
StatefulSet:為Pod提供穩(wěn)定的存儲和網(wǎng)絡標識,確保有狀態(tài)應用能夠正常運行。StatefulSet通常與Headless Service和volumeClaimTemplate一起使用,以提供可解析的DNS資源記錄和專有且固定的存儲。
2.4.4 升級與回滾
Deployment:支持多種升級策略,如滾動更新和回滾,確保服務在整個升級過程中具有高可用性。通過更新Deployment的PodTemplateSpec字段來聲明Pod的新狀態(tài),并逐步替換舊的Pod。
StatefulSet:也支持有序而自動的滾動更新,但由于涉及到有狀態(tài)應用,更新過程可能更加復雜和嚴格。同時,StatefulSet也支持回滾到之前的版本。
2.4.5 擴展性
Deployment:可以根據(jù)系統(tǒng)負載進行水平擴展和縮容,通過調(diào)整ReplicaSet的副本數(shù)來實現(xiàn)。
StatefulSet:雖然也支持擴展和縮容操作,但由于涉及到有狀態(tài)應用和數(shù)據(jù)一致性等問題,擴展性可能相對較弱。
3、DaemonSet
- DaemonSet 是 Kubernetes 中的一種工作負載控制器,它確保在集群中的所有(或指定的)節(jié)點上運行一個 Pod 的副本。這使得 DaemonSet 成為運行集群級服務的理想選擇,如日志收集、監(jiān)控代理、存儲守護進程等。
3.1 關(guān)鍵特性
- 節(jié)點覆蓋:DaemonSet 確保在集群中的每個節(jié)點上都有一個 Pod 副本運行,或者根據(jù)需要在特定節(jié)點上運行。
- 自動管理:當新節(jié)點加入集群時,DaemonSet 會自動在這些節(jié)點上創(chuàng)建 Pod。當節(jié)點被移除時,相應的 Pod 也會被清理。
- 刪除行為:刪除 DaemonSet 會刪除它創(chuàng)建的所有 Pod,這有助于維護集群的整潔。
3.2 應用場景
- 集群存儲守護進程:在每個節(jié)點上運行如 GlusterFS 的 glusterd 或 Ceph 的守護進程,以提供分布式存儲服務。
- 日志收集:部署如 Fluentd、Logstash 等日志收集代理,以便在每個節(jié)點上收集日志并將其發(fā)送到中央日志存儲。
- 監(jiān)控代理:在每個節(jié)點上運行監(jiān)控代理,如 Prometheus 的 Node Exporter、Collectd、Datadog 代理、New Relic 代理或 Ganglia 的 gmond,以收集節(jié)點的監(jiān)控數(shù)據(jù)。
- 網(wǎng)絡插件:在每個節(jié)點上運行如Calico、Cilium或Flannel等
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/ #官方案例(監(jiān)控)
3.3 創(chuàng)建控制器
#編輯yaml配置文件
vim daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
#創(chuàng)建資源類型為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.18.0
ports:
- containerPort: 80
kubectl apply -f daemonset.yaml
#創(chuàng)建資源
kubectl get pod -owide
#查看詳細信息(DaemonSet會在每個node節(jié)點都創(chuàng)建一個Pod)


4、Job
- Job控制器是Kubernetes中的一個核心組件,主要用于在集群中運行一次性或批處理任務。Job確保在集群中運行獨立的任務,并在任務成功完成后自動終止,不會重啟。
4.1 主要特點
- 任務執(zhí)行:Job控制器主要負責批量處理短暫的一次性任務。當任務執(zhí)行完畢后,Job會自動將Pod的可用數(shù)設置為0,并將Pod的狀態(tài)置為Complete。
- 任務記錄:當Job創(chuàng)建的Pod成功執(zhí)行完任務后,Job會記錄成功結(jié)束的Pod數(shù)量。當成功結(jié)束的Pod數(shù)量達到指定的數(shù)量時,Job完成執(zhí)行。
- 任務重試:Job支持定義任務的重試策略,通過backoffLimit字段指定Job失敗后進行重試的次數(shù)。
- 并行任務:Job允許定義多個并行執(zhí)行的任務,通過parallelism字段指定在任一時刻應該并發(fā)運行的Pod數(shù)量
4.2 應用場景
- Job常用于運行那些僅需要執(zhí)行一次的任務
批處理作業(yè)
- Kubernetes Job主要被用于執(zhí)行一次性批處理作業(yè),如每日數(shù)據(jù)分析、事務處理等。
數(shù)據(jù)遷移和清理
- Job可以用來定時遷移大量數(shù)據(jù),以及維護數(shù)據(jù)庫
后臺任務
- Job可以用來執(zhí)行后臺任務,如計算任務、日志采集等
日志打包和壓縮
- 例如按時間段打包日志文件、將多個日志文件壓縮成一個文件等。
備份和恢復操作
- 例如備份數(shù)據(jù)庫、配置文件等,并將其存儲到云存儲服務中以便后續(xù)恢復
其它應用場景
- kube-bench掃描、離線數(shù)據(jù)處理,視頻解碼等業(yè)務
4.3 創(chuàng)建控制器
#編輯yaml配置文件
vim job.yaml
apiVersion: batch/v1
#Batch API的第一個穩(wěn)定版
kind: Job
#指定創(chuàng)建的資源類型是Job
metadata:
name: job
#資源名稱
spec:
template:
spec:
#spec.template.spec 定義了 Pod 的規(guī)格,包括容器的名稱、鏡像和執(zhí)行的命令
containers:
- name: busybox
#容器名稱
image: busybox:1.28
#鏡像名稱
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
#perl解釋器,-Mbignum=bpi模塊中的子進程,使用計算功能,計算結(jié)果輸出圓周率2000位的結(jié)果
restartPolicy: Never
#表示 Pod 失敗后不會重啟。
backoffLimit: 4
#表示 Job 在失敗后最多重試 4 次
kubectl apply -f job.yaml
#創(chuàng)建資源
kubectl get job
#查看job資源信息
kubectl get pod -w
#追蹤查看pod資源信息


4.4 清除job資源
kubectl get job
#查看job資源信息
kubectl delete -f job.yaml
#刪除job資源
kubectl get job
#查看job資源信息
#編輯yaml配置文件
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
#創(chuàng)建資源
kubectl get job,pods
#查看資源信息
kubectl get pod -w
#追蹤查看資源信息



5、CronJob
- 在Kubernetes中,CronJob控制器用于運行定時任務,例如備份、生成報告等。這些任務在指定的時間周期上自動執(zhí)行。一個 CronJob 對象就像 linux 系統(tǒng)上的 crontab(cron table)文件中的一行,使用Cron格式進行編寫, 并周期性地在給定的調(diào)度時間執(zhí)行Job。它在Kubernetes集群上運行的,可以管理多個Pod。
5.1 創(chuàng)建控制器
- 創(chuàng)建 CronJob 配置文件 (cronjob.yaml) 每分鐘打印hello
#編輯yaml配置文件
vim cronjob.yaml
apiVersion: batch/v1beta1
#指定 Kubernetes API 的版本
kind: CronJob
#指定資源類型為 CronJob
metadata:
#包含 CronJob 的名稱
name: hello
spec:
#包含 CronJob 的規(guī)格
schedule: "*/1 * * * *"
#使用 Cron 表達式定義任務的執(zhí)行時間表。在這個例子中,"*/1 * * * *" 表示每分鐘執(zhí)行一次。
jobTemplate:
#定義了 Job 模板,它包含了執(zhí)行任務的 Pod 規(guī)格
spec:
template:
spec:
containers:
#定義了容器的名稱、鏡像和其他參數(shù)
- name: hello
image: busybox
imagePullPolicy: IfNotPresent
args:
#執(zhí)行的命令,這里使用 /bin/sh 打印當前日期和 "Hello" 消息
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
#設置為 OnFailure,表示只在容器失敗時重啟
kubectl apply -f cronjob.yaml
#創(chuàng)建資源
kubectl get cronjob
#查看cronjob資源
kubectl get pods
#查看pod資源
kubectl logs hello-1717340820-s8n4j
#我們查看了 hello-1717225740-8nlx7 Pod 的日志,可以看到打印的日期和 "Hello" 消息。
--------------------------------------------------------------------------------------------
#解決日志查看權(quán)限問題
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous
#如果在查看日志時遇到權(quán)限問題,可以通過創(chuàng)建一個 clusterrolebinding 來授予 system:anonymous 用戶 cluster-admin 權(quán)限。這通常不推薦,因為它會降低集群的安全性。在生產(chǎn)環(huán)境中,應該使用更細粒度的權(quán)限控制。
-------------------------------------------------------------------------------------------


Pod控制器
- Deployment:部署無狀態(tài)應用的管理RS和Pod,創(chuàng)建Pod,主要是維護Pod副本數(shù)量與期望狀態(tài)相同,創(chuàng)建和刪除Pod時并行執(zhí)行,升級時想創(chuàng)建一部分,再刪除一部分
- StatefulSet:部署有狀態(tài)的應用,每個Pod的唯一(名稱)且不變的,每個Pod擁有自己專屬的持久化的存儲(PVC和PV)在K8S集群內(nèi)部可以通過(Pod_name).(Service_name).{namespace}.svc.cluster.local 解析出Pod的IP(基于headless service 和CoreDNS)
- ? 創(chuàng)建和刪除Pod時有順序的(串行執(zhí)行的),升級時串行執(zhí)行的,會刪除舊的Pod,再創(chuàng)建和新Pod刪除和升級時逆序執(zhí)行的(先從標識符最大的n-1開始,一直到最小的0)
- Daemonset:理論上在K8S集群的所有Node節(jié)點上創(chuàng)建相同的Pod(無論Node節(jié)點什么時候加入到K8S集群),但是會受到Node節(jié)點上污點影響
- Job:部署一次性任務,正常完成后容器立即退出并且不重啟容器(RestartPolicy不設置Always),也不會重建異常完成后重試任務,重建次數(shù)根據(jù)backofflimit 配置指定(默認為6次)
用戶 cluster-admin 權(quán)限。這通常不推薦,因為它會降低集群的安全性。在生產(chǎn)環(huán)境中,應該使用更細粒度的權(quán)限控制。
總結(jié)
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關(guān)文章
K8s?ConfigMaps與Secret實現(xiàn)配置分離過程
本文介紹Kubernetes中ConfigMaps和Secret的創(chuàng)建方式及應用,涵蓋文件、literal、YAML方法,強調(diào)命名空間匹配與鍵名大小寫一致性,Secret類型如Opaque、dockerconfigjson用于加密配置,熱更新需注意envFrom等參數(shù)限制2025-08-08
詳解Rainbond內(nèi)置ServiceMesh微服務架構(gòu)
這篇文章主要為大家介紹了詳解Rainbond內(nèi)置ServiceMesh微服務架構(gòu),有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2022-04-04
解決k8s kubectl啟動失敗Unit kubelet.service entered
配置文件路徑錯誤導致kubelet未找到,檢查發(fā)現(xiàn)kubelet.service中WorkingDirectory指向錯誤目錄,重新創(chuàng)建目錄并重啟服務后,問題解決2025-08-08

