Pod控制器詳解

Pod控制器介紹

Pod是kubernetes的最小管理單元，在kubernetes中，按照pod的創建方式可以將其分爲兩類：

自主式pod：kubernetes直接創建出來的Pod，這種pod刪除後就沒有了，也不會重建
控制器創建的pod：kubernetes通過控制器創建的pod，這種pod刪除了之後還會自動重建

什麼是Pod控制器

Pod控制器是管理pod的中間層，使用Pod控制器之後，只需要告訴Pod控制器，想要多少個什麼樣的Pod就可以了，它會創建出滿足條件的Pod並確保每一個Pod資源處於用戶期望的目標狀態。如果Pod資源在運行中出現故障，它會基於指定策略重新編排Pod。

在kubernetes中，有很多類型的pod控制器，每種都有自己的適合的場景，常見的有下面這些：

ReplicationController：比較原始的pod控制器，已經被廢棄，由ReplicaSet替代
ReplicaSet：保證副本數量一直維持在期望值，並支持pod數量擴縮容，鏡像版本升級
Deployment：通過控制ReplicaSet來控制Pod，並支持滾動升級、回退版本
Horizontal Pod Autoscaler：可以根據集羣負載自動水平調整Pod的數量，實現削峯填谷
DaemonSet：在集羣中的指定Node上運行且僅運行一個副本，一般用於守護進程類的任務
Job：它創建出來的pod只要完成任務就立即退出，不需要重啓或重建，用於執行一次性任務
Cronjob：它創建的Pod負責週期性任務控制，不需要持續後臺運行
StatefulSet：管理有狀態應用

ReplicaSet(RS)

ReplicaSet的主要作用是保證一定數量的pod正常運行，它會持續監聽這些Pod的運行狀態，一旦Pod發生故障，就會重啓或重建。同時它還支持對pod數量的擴縮容和鏡像版本的升降級。

ReplicaSet的資源清單文件：

apiVersion: apps/v1 # 版本號
kind: ReplicaSet # 類型       
metadata: # 元數據
  name: # rs名稱 
  namespace: # 所屬命名空間 
  labels: #標籤
    controller: rs
spec: # 詳情描述
  replicas: 3 # 副本數量
  selector: # 選擇器，通過它指定該控制器管理哪些pod
    matchLabels:      # Labels匹配規則
      app: nginx-pod
    matchExpressions: # Expressions匹配規則
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

在這裏面，需要新瞭解的配置項就是spec下面幾個選項：

replicas：指定副本數量，其實就是當前rs創建出來的pod的數量，默認爲1
selector：選擇器，它的作用是建立pod控制器和pod之間的關聯關係，採用的Label Selector機制

在pod模板上定義label，在控制器上定義選擇器，就可以表明當前控制器能管理哪些pod了
template：模板，就是當前控制器創建pod所使用的模板板，裏面其實就是前一章學過的pod的定義

創建ReplicaSet

創建pc-replicaset.yaml文件，內容如下：

apiVersion: apps/v1
kind: ReplicaSet   
metadata:
  name: pc-replicaset
  namespace: dev
spec:
  replicas: 3
  selector: 
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1

# 創建rs
kubectl create -f pc-replicaset.yaml

# 查看rs
# DESIRED:期望副本數量  
# CURRENT:當前副本數量  
# READY:已經準備好提供服務的副本數量
kubectl get rs pc-replicaset -n dev -o wide

# 查看當前控制器創建出來的pod
# 這裏發現控制器創建出來的pod的名稱是在控制器名稱後面拼接了-xxxxx隨機碼
kubectl get pod -n dev

擴縮容

# 編輯rs的副本數量，修改spec:replicas: 6即可
kubectl edit rs pc-replicaset -n dev

# 查看pod
kubectl get pods -n dev

# 當然也可以直接使用命令實現
# 使用scale命令實現擴縮容， 後面--replicas=n直接指定目標數量即可
kubectl scale rs pc-replicaset --replicas=2 -n dev

# 命令運行完畢，立即查看，發現已經有2個開始準備退出了
kubectl get pods -n dev

#稍等片刻，就只剩下2個了
kubectl get pods -n dev

編輯的方式

使用scale命令實現擴縮容

鏡像升降級

# 編輯rs的容器鏡像 - image: nginx:1.17.2
kubectl edit rs pc-replicaset -n dev

# 再次查看，發現鏡像版本已經變更了
kubectl get rs -n dev -o wide

# 同樣的道理，也可以使用命令完成這個工作
# kubectl set image rs rs名稱 容器=鏡像版本 -n namespace
kubectl set image rs pc-replicaset nginx=nginx:1.17.1  -n dev

# 再次查看，發現鏡像版本已經變更了
kubectl get rs -n dev -o wide

刪除ReplicaSet

# 使用kubectl delete命令會刪除此RS以及它管理的Pod
# 在kubernetes刪除RS前，會將RS的replicasclear調整爲0，等待所有的Pod被刪除後，在執行RS對象的刪除
kubectl delete rs pc-replicaset -n dev
kubectl get pod -n dev -o wide

# 如果希望僅僅刪除RS對象（保留Pod），可以使用kubectl delete命令時添加--cascade=false選項（不推薦）。
kubectl delete rs pc-replicaset -n dev --cascade=false
kubectl get pods -n dev

# 也可以使用yaml直接刪除(推薦)
kubectl delete -f pc-replicaset.yaml

Deployment(Deploy)

爲了更好的解決服務編排的問題，kubernetes在V1.2版本開始，引入了Deployment控制器。值得一提的是，這種控制器並不直接管理pod，而是通過管理ReplicaSet來間接管理Pod，即：Deployment管理ReplicaSet，ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加強大。

Deployment主要功能有下面幾個：

支持ReplicaSet的所有功能
支持發佈的停止、繼續
支持滾動升級和回滾版本

Deployment的資源清單文件：

apiVersion: apps/v1 # 版本號
kind: Deployment # 類型       
metadata: # 元數據
  name: # rs名稱 
  namespace: # 所屬命名空間 
  labels: #標籤
    controller: deploy
spec: # 詳情描述
  replicas: 3 # 副本數量
  revisionHistoryLimit: 3 # 保留歷史版本
  paused: false # 暫停部署，默認是false
  progressDeadlineSeconds: 600 # 部署超時時間（s），默認是600
  strategy: # 策略
    type: RollingUpdate # 滾動更新策略
    rollingUpdate: # 滾動更新
      maxSurge: 30% # 最大額外可以存在的副本數，可以爲百分比，也可以爲整數
      maxUnavailable: 30% # 最大不可用狀態的 Pod 的最大值，可以爲百分比，也可以爲整數
  selector: # 選擇器，通過它指定該控制器管理哪些pod
    matchLabels:      # Labels匹配規則
      app: nginx-pod
    matchExpressions: # Expressions匹配規則
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

創建deployment

創建pc-deployment.yaml，內容如下：

apiVersion: apps/v1
kind: Deployment      
metadata:
  name: pc-deployment
  namespace: dev
spec: 
  replicas: 3
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1

# 創建deployment
# --record=true 記錄每次版本的變化
kubectl create -f pc-deployment.yaml --record=true

# 查看deployment
# UP-TO-DATE 最新版本的pod的數量
# AVAILABLE  當前可用的pod的數量
kubectl get deploy pc-deployment -n dev

# 查看rs
# 發現rs的名稱是在原來deployment的名字後面添加了一個10位數的隨機串
kubectl get rs -n dev

# 查看pod
kubectl get pods -n dev

擴縮容

# 方式一 scale命令
# 變更副本數量爲5個
kubectl scale deploy pc-deployment --replicas=5  -n dev

# 查看deployment
kubectl get deploy pc-deployment -n dev

# 查看pod
kubectl get pods -n dev

# 方式二  編輯
# 編輯deployment的副本數量，修改spec:replicas: 4即可
kubectl edit deploy pc-deployment -n dev

# 查看pod
kubectl get pods -n dev

鏡像更新策略

deployment支持兩種更新策略:重建更新和滾動更新,可以通過strategy指定策略類型,支持兩個屬性:

strategy：指定新的Pod替換舊的Pod的策略， 支持兩個屬性：
  type：指定策略類型，支持兩種策略
    Recreate：在創建出新的Pod之前會先殺掉所有已存在的Pod
    RollingUpdate：滾動更新，就是殺死一部分，就啓動一部分，在更新過程中，存在兩個版本Pod
  rollingUpdate：當type爲RollingUpdate時生效，用於爲RollingUpdate設置參數，支持兩個屬性：
    maxUnavailable：用來指定在升級過程中不可用Pod的最大數量，默認爲25%。
    maxSurge： 用來指定在升級過程中可以超過期望的Pod的最大數量，默認爲25%。

重建更新

編輯pc-deployment.yaml,在spec節點下添加更新策略

vi pc-deployment.yaml

# 加入策略
spec:
  strategy: # 策略
    type: Recreate # 重建更新
    
# 應用
kubectl apply -f pc-deployment.yaml

創建deploy進行驗證

# 變更鏡像
kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev

# 觀察升級過程
kubectl get pods -n dev -w

重建更新過程

滾動更新

編輯pc-deployment.yaml,在spec節點下添加更新策略

vi pc-deployment.yaml

spec:
  strategy: # 策略
    type: RollingUpdate # 滾動更新策略
    rollingUpdate:
      maxSurge: 25% 
      maxUnavailable: 25%
      
# 應用
kubectl apply -f pc-deployment.yaml

創建deploy進行驗證

# 變更鏡像
kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -n dev 

# 觀察升級過程
kubectl get pods -n dev -w

# 至此，新版本的pod創建完畢，就版本的pod銷燬完畢
# 中間過程是滾動進行的，也就是邊銷燬邊創建

滾動更新過程

滾動更新的過程：

鏡像更新中rs的變化

# 查看rs,發現原來的rs的依舊存在，只是pod數量變爲了0，而後又新產生了一個rs，pod數量爲3
# 其實這就是deployment能夠進行版本回退的奧妙所在
kubectl get rs -n dev

版本回退

deployment支持版本升級過程中的暫停、繼續功能以及版本回退等諸多功能，下面具體來看.

kubectl rollout：版本升級相關功能，支持下面的選項：

status 顯示當前升級狀態
history 顯示升級歷史記錄
pause 暫停版本升級過程
resume 繼續已經暫停的版本升級過程
restart 重啓版本升級過程
undo 回滾到上一級版本（可以使用--to-revision回滾到指定版本）

# 查看當前升級版本的狀態
kubectl rollout status deploy pc-deployment -n dev

# 查看升級歷史記錄
kubectl rollout history deploy pc-deployment -n dev
# 可以發現有三次版本記錄，說明完成過兩次升級

# 版本回滾
# 這裏直接使用--to-revision=2回滾到了2版本， 如果省略這個選項，就是回退到上個版本，就是3版本
kubectl rollout undo deployment pc-deployment --to-revision=2 -n dev

# 查看發現，通過nginx鏡像版本可以發現到了第二版
kubectl get deploy -n dev -o wide
  
# 查看rs，發現第一個rs中有4個pod運行，後面兩個版本的rs中pod爲運行
# 其實deployment之所以可是實現版本的回滾，就是通過記錄下歷史rs來實現的，
# 一旦想回滾到哪個版本，只需要將當前版本pod數量降爲0，然後將回滾版本的pod提升爲目標數量就可以了
kubectl get rs -n dev

金絲雀發佈

Deployment控制器支持控制更新過程中的控制，如“暫停(pause)”或“繼續(resume)”更新操作。

比如有一批新的Pod資源創建完成後立即暫停更新過程，此時，僅存在一部分新版本的應用，主體部分還是舊的版本。然後，再篩選一小部分的用戶請求路由到新版本的Pod應用，繼續觀察能否穩定地按期望的方式運行。確定沒問題之後再繼續完成餘下的Pod資源滾動更新，否則立即回滾更新操作。這就是所謂的金絲雀發佈。

# 更新deployment的版本，並配置暫停deployment
kubectl set image deploy pc-deployment nginx=nginx:1.17.4 -n dev && kubectl rollout pause deployment pc-deployment  -n dev

#觀察更新狀態
kubectl rollout status deploy pc-deployment -n dev　

# 監控更新的過程，可以看到已經新增了一個資源，但是並未按照預期的狀態去刪除一箇舊的資源，就是因爲使用了pause暫停命令
kubectl get rs -n dev -o wide  
kubectl get pods -n dev

# 確保更新的pod沒問題了，繼續更新
kubectl rollout resume deploy pc-deployment -n dev

# 查看最後的更新情況
kubectl get rs -n dev -o wide
kubectl get pods -n dev

更新並暫停，觀察更新狀態

監控更新的過程

繼續更新

查看最後的更新情況

刪除Deployment

# 刪除deployment，其下的rs和pod也將被刪除
kubectl delete -f pc-deployment.yaml

Horizontal Pod Autoscaler(HPA)

在前面，我們已經可以實現通過手工執行kubectl scale命令實現Pod擴容或縮容，但是這顯然不符合Kubernetes的定位目標--自動化、智能化。 Kubernetes期望可以實現通過監測Pod的使用情況，實現pod數量的自動調整，於是就產生了Horizontal Pod Autoscaler（HPA）這種控制器。

HPA可以獲取每個Pod利用率，然後和HPA中定義的指標進行對比，同時計算出需要伸縮的具體值，最後實現Pod的數量的調整。其實HPA與之前的Deployment一樣，也屬於一種Kubernetes資源對象，它通過追蹤分析RC控制的所有目標Pod的負載變化情況，來確定是否需要針對性地調整目標Pod的副本數，這是HPA的實現原理。

接下來，我們來做一個實驗

安裝metrics-server

metrics-server可以用來收集集羣中的資源使用情況

# 安裝git
yum install git -y

# 獲取metrics-server, 注意使用的版本
git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
# 如果訪問github403，可能是本地賬戶沒配置的原因，注意配置用戶信息和ssh-key
# 參考：https://www.cnblogs.com/makalochen/p/12651921.html#%E9%85%8D%E7%BD%AE%E6%9C%AC%E5%9C%B0%E5%BA%93%E7%94%A8%E6%88%B7%E4%BF%A1%E6%81%AF
# 如果出現
# fatal: unable to access 'https://github.com/kubernetes-incubator/metrics-server/': TCP connection reset by peer
# 這是網絡的原因，重新執行一下clone

# 修改deployment, 注意修改的是鏡像和初始化參數
cd /root/metrics-server/deploy/1.8+/
vi metrics-server-deployment.yaml
# 按圖中添加下面選項
hostNetwork: true
image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
args:
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP

# 安裝metrics-server
# 注意此時的目錄 /root/metrics-server/deploy/1.8+/
kubectl apply -f ./

# 查看pod運行情況
kubectl get pod -n kube-system

# 使用kubectl top node 查看資源使用情況
kubectl top node
kubectl top pod -n kube-system
# 至此,metrics-server安裝完成

準備deployment和servie

方式一

創建pc-hpa-pod.yaml文件，內容如下：

vi pc-hpa-pod.yaml

內容

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: dev
spec:
  strategy: # 策略
    type: RollingUpdate # 滾動更新策略
  replicas: 1
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        resources: # 資源配額
          limits:  # 限制資源（上限）
            cpu: "1" # CPU限制，單位是core數
          requests: # 請求資源（下限）
            cpu: "100m"  # CPU限制，單位是core數

創建deployment

kubectl create -f pc-hpa-pod.yaml

創建server

kubectl expose deployment nginx --type=NodePort --port=80 -n dev

方式二

# 創建deployment
kubectl run nginx --image=nginx:1.17.1 --requests=cpu=100m -n dev
# 創建service
kubectl expose deployment nginx --type=NodePort --port=80 -n dev

這裏使用方式一

# 查看
kubectl get deployment,pod,svc -n dev

部署HPA

創建pc-hpa.yaml文件，內容如下：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: pc-hpa
  namespace: dev
spec:
  minReplicas: 1  #最小pod數量
  maxReplicas: 10 #最大pod數量
  targetCPUUtilizationPercentage: 3 # CPU使用率指標，cpu使用達到3%
  scaleTargetRef:   # 指定要控制的nginx信息
    apiVersion:  apps/v1
    kind: Deployment
    name: nginx

# 創建hpa
kubectl create -f pc-hpa.yaml

# 查看hpa
kubectl get hpa -n dev

測試

檢測變化

hpa變化

kubectl get hpa -n dev -w

deployment變化

kubectl get deployment -n dev -w

pod變化

kubectl get pods -n dev -w

壓測

使用壓測工具對service地址http://192.168.176.100:31587進行壓測，然後通過控制檯查看hpa和pod的變化

我這裏使用postman，不專業但是已經滿足測試需求了

測試結果

hpa

deployment

pod

DaemonSet(DS)

DaemonSet類型的控制器可以保證在集羣中的每一臺（或指定）節點上都運行一個副本。一般適用於日誌收集、節點監控等場景。也就是說，如果一個Pod提供的功能是節點級別的（每個節點都需要且只需要一個），那麼這類Pod就適合使用DaemonSet類型的控制器創建。

DaemonSet控制器的特點：

每當向集羣中添加一個節點時，指定的 Pod 副本也將添加到該節點上
當節點從集羣中移除時，Pod 也就被垃圾回收了

下面先來看下DaemonSet的資源清單文件

apiVersion: apps/v1 # 版本號
kind: DaemonSet # 類型       
metadata: # 元數據
  name: # rs名稱 
  namespace: # 所屬命名空間 
  labels: #標籤
    controller: daemonset
spec: # 詳情描述
  revisionHistoryLimit: 3 # 保留歷史版本
  updateStrategy: # 更新策略
    type: RollingUpdate # 滾動更新策略
    rollingUpdate: # 滾動更新
      maxUnavailable: 1 # 最大不可用狀態的 Pod 的最大值，可以爲百分比，也可以爲整數
  selector: # 選擇器，通過它指定該控制器管理哪些pod
    matchLabels:      # Labels匹配規則
      app: nginx-pod
    matchExpressions: # Expressions匹配規則
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

創建pc-daemonset.yaml，內容如下：

apiVersion: apps/v1
kind: DaemonSet      
metadata:
  name: pc-daemonset
  namespace: dev
spec: 
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1

# 創建daemonset
kubectl create -f  pc-daemonset.yaml

# 查看daemonset
kubectl get ds -n dev -o wide
   
# 查看pod,發現在每個Node上都運行一個pod
# 注意：如果某個節點有污點，是不會創建ds的
# 查看污點 kubectl describe nodes
# 去除所有污點 例：kubectl taint nodes node1 tag-
kubectl get pods -n dev -o wide
     
# 刪除daemonset
kubectl delete -f pc-daemonset.yaml

Job

Job，主要用於負責批量處理(一次要處理指定數量任務)短暫的一次性(每個任務僅運行一次就結束)任務。Job特點如下：

當Job創建的pod執行成功結束時，Job將記錄成功結束的pod數量
當成功結束的pod達到指定的數量時，Job將完成執行

Job的資源清單文件：

apiVersion: batch/v1 # 版本號
kind: Job # 類型       
metadata: # 元數據
  name: # rs名稱 
  namespace: # 所屬命名空間 
  labels: #標籤
    controller: job
spec: # 詳情描述
  completions: 1 # 指定job需要成功運行Pods的次數。默認值: 1
  parallelism: 1 # 指定job在任一時刻應該併發運行Pods的數量。默認值: 1
  activeDeadlineSeconds: 30 # 指定job可運行的時間期限，超過時間還未結束，系統將會嘗試進行終止。
  backoffLimit: 6 # 指定job失敗後進行重試的次數。默認是6
  manualSelector: true # 是否可以使用selector選擇器選擇pod，默認是false
  selector: # 選擇器，通過它指定該控制器管理哪些pod
    matchLabels:      # Labels匹配規則
      app: counter-pod
    matchExpressions: # Expressions匹配規則
      - {key: app, operator: In, values: [counter-pod]}
  template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本
    metadata:
      labels:
        app: counter-pod
    spec:
      restartPolicy: Never # 重啓策略只能設置爲Never或者OnFailure
      containers:
      - name: counter
        image: busybox:1.30
        command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;done"]

關於重啓策略設置的說明：
    如果指定爲OnFailure，則job會在pod出現故障時重啓容器，而不是創建pod，failed次數不變
    如果指定爲Never，則job會在pod出現故障時創建新的pod，並且故障pod不會消失，也不會重啓，failed次數加1
    如果指定爲Always的話，就意味着一直重啓，意味着job任務會重複去執行了，當然不對，所以不能設置爲Always

創建pc-job.yaml，內容如下：

apiVersion: batch/v1
kind: Job      
metadata:
  name: pc-job
  namespace: dev
spec:
  manualSelector: true
  selector:
    matchLabels:
      app: counter-pod
  template:
    metadata:
      labels:
        app: counter-pod
    spec:
      restartPolicy: Never
      containers:
      - name: counter
        image: busybox:1.30
        command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]

# 創建job
kubectl create -f pc-job.yaml

# 查看job
kubectl get job -n dev -o wide  -w

# 通過觀察pod狀態可以看到，pod在運行完畢任務後，就會變成Completed狀態
kubectl get pods -n dev -w

# 接下來，調整下pod運行的總數量和並行數量 即：在spec下設置下面兩個選項
#  completions: 6 # 指定job需要成功運行Pods的次數爲6
#  parallelism: 3 # 指定job併發運行Pods的數量爲3
#  然後重新運行job，觀察效果，此時會發現，job會每次運行3個pod，總共執行了6個pod

# 刪除
kubectl delete -f pc-job.yaml
# 觀察
kubectl get pods -n dev -w
kubectl get job -n dev -o wide  -w
# 重新運行job
kubectl create -f pc-job.yaml
# 刪除job
kubectl delete -f pc-job.yaml

修改參數

觀測結果

CronJob(CJ)

CronJob控制器以 Job控制器資源爲其管控對象，並藉助它管理pod資源對象，Job控制器定義的作業任務在其控制器資源創建之後便會立即執行，但CronJob可以以類似於Linux操作系統的週期性任務作業計劃的方式控制其運行時間點及重複運行的方式。也就是說，CronJob可以在特定的時間點(反覆的)去運行job任務。

CronJob的資源清單文件：

apiVersion: batch/v1beta1 # 版本號
kind: CronJob # 類型       
metadata: # 元數據
  name: # rs名稱 
  namespace: # 所屬命名空間 
  labels: #標籤
    controller: cronjob
spec: # 詳情描述
  schedule: # cron格式的作業調度運行時間點,用於控制任務在什麼時間執行
  concurrencyPolicy: # 併發執行策略，用於定義前一次作業運行尚未完成時是否以及如何運行後一次的作業
  failedJobHistoryLimit: # 爲失敗的任務執行保留的歷史記錄數，默認爲1
  successfulJobHistoryLimit: # 爲成功的任務執行保留的歷史記錄數，默認爲3
  startingDeadlineSeconds: # 啓動作業錯誤的超時時長
  jobTemplate: # job控制器模板，用於爲cronjob控制器生成job對象;下面其實就是job的定義
    metadata:
    spec:
      completions: 1
      parallelism: 1
      activeDeadlineSeconds: 30
      backoffLimit: 6
      manualSelector: true
      selector:
        matchLabels:
          app: counter-pod
        matchExpressions: 規則
          - {key: app, operator: In, values: [counter-pod]}
      template:
        metadata:
          labels:
            app: counter-pod
        spec:
          restartPolicy: Never 
          containers:
          - name: counter
            image: busybox:1.30
            command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 20;done"]

需要重點解釋的幾個選項：
schedule: cron表達式，用於指定任務的執行時間
    */1    *      *    *     *
    <分鐘> <小時> <日> <月份> <星期>

    分鐘 值從 0 到 59.
    小時 值從 0 到 23.
    日 值從 1 到 31.
    月 值從 1 到 12.
    星期 值從 0 到 6, 0 代表星期日
    多個時間可以用逗號隔開； 範圍可以用連字符給出；*可以作爲通配符； /表示每...
concurrencyPolicy:
    Allow:   允許Jobs併發運行(默認)
    Forbid:  禁止併發運行，如果上一次運行尚未完成，則跳過下一次運行
    Replace: 替換，取消當前正在運行的作業並用新作業替換它

創建pc-cronjob.yaml，內容如下：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: pc-cronjob
  namespace: dev
  labels:
    controller: cronjob
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    metadata:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: counter
            image: busybox:1.30
            command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]

# 查看cronjob
kubectl get cronjobs -n dev -w

# 查看job
kubectl get jobs -n dev -w

# 查看pod
kubectl get pods -n dev -w

# 創建cronjob
kubectl create -f pc-cronjob.yaml

# 刪除cronjob
kubectl  delete -f pc-cronjob.yaml

Pod控制器詳解

Pod控制器介紹

ReplicaSet(RS)

創建ReplicaSet

擴縮容

鏡像升降級

刪除ReplicaSet

Deployment(Deploy)

創建deployment

擴縮容

鏡像更新策略

重建更新

滾動更新

版本回退

金絲雀發佈

刪除Deployment

Horizontal Pod Autoscaler(HPA)

安裝metrics-server

準備deployment和servie

方式一

方式二

部署HPA

測試

檢測變化

壓測

測試結果

DaemonSet(DS)

Job

CronJob(CJ)

自學編程兩個月，現在我月入 4 萬元

百度安全多篇議題入選Blackhat Asia以硬技術發現“芯”問題

「實戰應用」如何用圖表控件LightningChart創建2D氣泡圖

Google Chrome驅動程序 124.0.6367.62（正式版本）去哪下載？

ue 切換像素流分辨率

UE 像素流點擊模型發送消息從虛幻引擎到前端播放器頁面

UE 多人像素流配置

UE 像素流通信

UE 修改材質顏色和 UV紋理拉伸問題

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結