Kubernetes筆記(5) - Pod控制器

• ReplicaSet控制器
  • 創建ReplicaSet
  • ReplicaSet管控下的Pod物件
  • 更新ReplicaSet
• Deployment控制器
  • 創建Deployment
  • 更新策略
  • 升級Deployment
  • 金絲雀發布
  • 擴容、縮容
• DaemonSet控制器
• Job控制器
  • 串行、并行控制
  • 洗掉Job
• CornJob控制器
• Pod中斷預算

自主式Pod物件由調度器系結至目標作業節點后即由相應節點上的kubelet負責監控其容器的存活性，容器主行程崩潰后，kubelet能夠自動重啟相應的容器，基于存活性探測，在容器出現其他問題時也能作出回應，但如果Pod被意外洗掉、或者作業節點發生故障，kubelet就無能為力了，
Pod控制器可應對這類情況，Pod控制器由master的kube-controller-manager組件提供，kube-controller-manager是一個獨立的單體守護行程，它包含了眾多功能不同的控制器，除了Pod Controller，還有NodeLifecycle Controller、Namespace Controller、Service Controller等等，這些控制器不間斷地監控著由其負責的資源，并在因故障、更新或其他原因導致系統狀態發生變化時，嘗試讓資源的當前狀態向期望狀態遷移和逼近，

ReplicaSet控制器

ReplicaSet替代了早期的ReplicationController，用于確保由其管控的Pod物件副本數在任一時刻都能精確滿足期望的數量

通過控制器創建的Pod與用戶手動創建的Pod功能相同，但相比于手動創建來說，ReplicaSet能夠實作以下功能：

• 確保Pod資源物件的數量精確反映期望值
• 確保Pod健康運行，在探測到由其管控的Pod物件因其所在的作業節點故障而不可用時，自動請求由調度器于其他作業節點創建缺失的Pod副本
• 彈性伸縮：在資源需求存在較大波動時，可以通過ReplicaSet控制器動態調整相關Pod資源物件的數量，還可以配合HPA（HroizontalPodAutoscaler）實作Pod資源規模的自動伸縮，

創建ReplicaSet

通常一個Pod控制器的資源清單的spec包含如下基本屬性：

• selector：標簽選擇器，匹配并關聯Pod資源物件，并據此完成受其管控的Pod資源計數
• replicas：期望的副本數，期望在集群中精確運行著的Pod資源的物件數量
• template：Pod模板，用于新建Pod資源物件的Pod模板資源

例如：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: rs-example
spec:
 replicas: 2
 selector:
   matchLabels:
     app: rs-demo
 template:
   metadata:
     labels:
       app: rs-demo
   spec:
     containers:
     - name: myapp
       image: ikubernetes/myapp:v2 
       imagePullPolicy: Never     
       ports:
       - name: http
         containerPort: 80
         protocol: TCP

將這份配置清單apply后，使用kubectl get pods -l app=rs-demo查看，會看到有兩個容器，狀態從ContainerCreating轉為Running，兩個pod名稱以控制器的名稱rs-example為前綴，rs-example-j98fp、rs-example-wj8zg，
運行kubectl get replicaset rs-example，配合-o json\wide等選項可查看控制器的詳細狀態，

ReplicaSet管控下的Pod物件

ReplicaSet之所以能對Pod物件數目的例外及時做出回應，是因為它向API Server注冊監聽了相關資源及其串列的變動資訊，于是API Server會在變動發生時立即通知給監聽方，

缺少、多出Pod副本

任何原因導致的相關Pod物件丟失，都會由ReplicaSet控制器自動補足，
手動洗掉一個Pod，ReplicaSet馬上會新建一個；之前創建的ReplicaSet依賴標簽app: rs-demo來管理Pod，那么強制修改這個標簽也會觸發副本的新建：
kubectl label pods rs-example-wj8zg app=others --overwrite
之前的Pod rs-example-wj8zg還存在，如果它能被別的控制器通過標簽選擇器選中，就會隸屬于這個控制器，否會成為自助式Pod，
多余的部分則會被控制器自動洗掉，經測驗Age最小的會被首先洗掉，

kubectl describe replicasets/rs-example命令可列印出ReplicaSet的詳細狀態以及Events，

更新ReplicaSet

更改template：升級應用

更改template對已經創建完成的活動物件無效，但可以逐個手動關閉其舊版本的Pod資源來實作滾動升級，
相比于ReplicaSet的手動操作方式，Deployment控制器能夠自動實作更完善的滾動更新和回滾，并為用戶提供自定義更新策略的介面，

更改replicas：擴容和縮容

通過修改replicas屬性并apply，可實作應用規模的水平伸縮；kubectl還提供了一個專用的子命令scale用于實作應用規模的伸縮，比如:
kubectl scale replicasets rs-example --replicas=2
使用--current-replicas選項還可實作在副本數量為指定值時才變更replicas，比如下面的命令，如果當前副本數量不等于4就不會執行成功：
kubectl scale replicasets rs-example --current-replicas=4 --replicas=2

如果讓ReplicaSet管控有狀態應用，例如主從架構的Redis集群，那么上述這些升降級、擴縮容操作都需要精心編排和參與才能進行，針對這類需求，可以使用K8S專門提供的StatefulSet，ReplicaSet通常僅用于管理無狀態的應用，如HTTP服務程式等，

洗掉ReplicaSet資源

洗掉命令：
kubectl delete -f ...
或者
kubectl delete replicaset ...
洗掉ReplicaSet物件時默認會一并洗掉其管控的各Pod物件，但有時考慮到這些Pod資源未必由其創建，或者Pod資源后續可能會再次用到時，可以添加--cascade=false選項取消級聯洗掉，

Deployment控制器

Deployment控制器構建于ReplicaSet控制器之上，可為Pod和ReplicaSet資源提供宣告式更新，Pod和ReplicaSet是較低級別的資源，很少被直接使用，
Deployment控制器在ReplicaSet的基礎上，添加了多種增強的功能：

• 事件和狀態查看：必要時可以查看Deployment物件升級的詳細進度和狀態
• 回滾：在升級發現問題時，可以使用回滾機制將應用回傳到前一個或由指定的歷史版本
• 版本記錄：保存每一次操作記錄，以供后續可能執行的回滾操作使用
• 暫停和啟動：對于每一次升級，都能夠隨時暫停和啟動
• 多種自動更新方案：
  • Recreate，重建更新機制，全面停止、洗掉舊有的Pod后用新版本替代
  • RollingUpdate，滾動升級機制，逐步替換舊有的Pod至新的版本，

創建Deployment

Deployment將ReplicaSet物件作為其二級資源，配置清單中除了kind、name，其它欄位與ReplicaSet的相同，示例：

kind: Deployment
metadata:
  name: myapp-deploy

創建完成后可用kubectl get deployments myapp-deploy查看其狀態:

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
myapp-deploy   2/2     2            2           15s

UP-TO-DATE表示已經達到期望狀態的Pod副本數量，AVAILABLE則表示當前處于可用狀態的應用程式的數量，
查看相關的ReplicaSet資源：

~ kubectl get replicasets -l app=myapp   
NAME                      DESIRED   CURRENT   READY   AGE
myapp-deploy-7cfbdc886d   2         2         2       2m53s

ReplicaSet資源的命名格式為[DEPLOYMENT-NAME]-[POD-TEMPLATE-HASH-VALUE]
查看相關的Pod資源：

~ kubectl get pods -l app=myapp          
NAME                            READY   STATUS    RESTARTS   AGE
myapp-deploy-7cfbdc886d-8lw6f   1/1     Running   0          4m55s
myapp-deploy-7cfbdc886d-xn7xp   1/1     Running   0          4m55s

Pod資源的名稱以ReplicaSet資源的名稱為前綴,加5位隨機字符，

更新策略

Deployment控制器支持RollingUpdate和Recreate兩種更新策略，默認為滾動更新，

Recreate

類似于使用ReplicaSet時一次性洗掉全部Pod物件，而后由控制器基于新模板重新創建出新版本資源物件，這種方式通常只應該在應用的新舊版本不兼容（如依賴的后端資料庫的schema不同且無法兼容）時才使用，因為它會導致應用替換期間暫時不可用，但好處在于它不存在中間狀態，

RollingUpdate

滾動升級是在洗掉一部分舊版本Pod資源的同時，補充創建一部分新版本的Pod物件，使用這種方式時，容器中應用提供的服務不會中斷，但要求應用程式能夠應對新舊版本同時作業的情形，例如新舊版本兼容同一個資料庫方案等，
滾動升級時會同時存在新舊版本的ReplicaSet，舊版ReplicaSet的Pod物件數量不斷減少的同時，新版ReplicaSet的Pod物件數量不斷增加，直到舊版ReplicaSet不再擁有Pod物件，而新版ReplicaSet的副本數量變得完全符合預期，
升級期間還要確保可用的Pod物件數量不低于某閾值以確保可以持續處理客戶端的服務請求，變動的方式和Pod物件的數量范圍將通過spec.strategy.rollingUpdate下的maxSurge和maxUnavailable兩個屬性協同定義：

• maxSurge：升級期間存在的總Pod物件數量最多可超出期望值的個數，其值可以是0或正整數，也可以是一個期望值的百分比
• maxUnavailable：升級期間正常可用的Pod副本數（包括新舊版本）最多不能低于期望數值的個數，其值可以是0或正整數，也可以是一個期望值的百分比，默認值為1，

maxSurge和maxUnavailable相當于定義了pod數量的波動范圍，所以它們的值不可同時為0，兩者作用方式如下圖舉例：

此外，還可以設定spec.minReadySeconds屬性：

• ，控制應用升級的速度，滾動升級時默認新的Pod物件只要就緒探測成功就可用，于是開始開始下一輪的替換操作，而minReadySeconds能夠定義在新的Pod物件創建后至少要等待多久才會將其視作就緒，在此期間，更新操作會被阻塞，

升級Deployment

修改Pod模板相關的配置引數便能完成Deployment控制器資源的更新，可以通過apply和patch命令來修改；如果只是修改容器鏡像，可以直接使用set image命令，
為了使得升級程序更易于觀測，先使用“kubectl patch”命令指定minReadySeconds=6s：

kubectl patch deployments myapp-deploy -p '{"spec":{"minReadySeconds":6}}'

修改Deployment控制器的minReadySeconds、replicas和strategy等欄位的值并不會觸發Pod資源的更新操作，因為它們不會對現存的Pod物件不產生任何影響，
使用set image命令更新鏡像版本：

kubectl set image deployments myapp-deploy myapp=ikubernetes/myapp:v2

隨后使用如下命令可以觀察滾動升級的程序：

kubectl rollout status deployments myapp-deploy --watch

升級完成后，舊版本的ReplicaSet控制器會保留在歷史記錄中，但其此前的管控Pod物件將會被洗掉，

金絲雀發布

Deployment控制器支持更新操作的暫停、繼續，再結合maxSurge和maxUnavailable，可以實作金絲雀發布（Canary Release），即待第一批新的Pod資源創建完成后立即暫停更新程序，此時，僅存在一小部分新版本的應用，主體部分還是舊的版本，然后將一小部分流量導到新版本的Pod應用，并持續觀察其是否能穩定地按期望的方式運行，確定沒有問題后再繼續完成余下Pod資源的滾動更新，否則立即回滾更新操作，
為了盡可能地降低對現有系統的影響，金絲雀發布程序通常建議采用“先添加、再洗掉，且可用Pod資源物件總數不低于期望值”的方式進行，首次添加的Pod物件數量取決于其接入的第一批請求的規則及單個Pod的承載能力，
接下來的試驗中將maxSurge和maxUnavailable分別設定為1和0，并通過修改升級鏡像版本來觸發更新，但要在第一批更新啟動后就暫停，由于設定了minReadySeconds，可以在這個程序中發出暫停命令，對于kubectl來說，也可以直接以“&&”符號在Shell中連接兩個命令：

kubectl set image deployments myapp-deploy myapp=ikubernetes/myapp:v2 --record=true&& kubectl rollout pause deployments myapp-deploy

查看狀態可知更新操作已經暫停：

kubectl rollout status deployments myapp-deploy 

此時，通過Service或Ingress資源及相關路由策略等設定，即可將一部分用戶的流量引入到這些Pod之上進行發布驗證，確認沒有問題后即可繼續更新：

kubectl rollout resume deployments myapp-deploy

回滾

如果因各種原因導致滾動更新無法正常進行，如鏡像檔案獲取失敗、“金絲雀”遇險等，則應該將應用回滾到之前的版本或者指定的歷史記錄中的版本，直接回滾至上一版本：

kubectl rollout undo deployments myapp-deploy

加上--to-revision選項可以回滾至指定版本，如下命令可以查看保存的歷史版本：

kubectl rollout history deployments myapp-deploy

需要注意的是，只有回滾至被保存的歷史版本，spec.revisionHistoryLimit定義了保存的版本數量，默認為10個，另外rollout history顯示的CHANGE-CAUSE一列的內容默認為空，在執行命令時加上--record=true選項，可以記錄觸發更新的命令的內容，此外，處于暫停狀態的更新無法回滾，

擴容、縮容

直接修改配置清單中的spec.replicas并apply可以改變Pod資源的副本數量，也可以使用專用的命令kubectl scale:

kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)

比如在當前Pod副本數為4個時，調整為2個：

kubectl scale --current-replicas=4 --replicas=2 deployment/myapp-deploy  

DaemonSet控制器

DaemonSet用于在集群中的全部或指定節點上同時運行一份指定的Pod資源副本，后續新加入集群的作業節點也會自動創建一個相關的Pod物件，當從集群移除節點時，此類Pod物件也將被自動回收而無須重建，
DaemonSet是一種特殊的控制器，它有特定的應用場景，通常運行那些執行系統級操作任務的應用，如集群存盤的守護行程、日志收集守護行程、監控系統的代理守護行程等，

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-demo
spec:
  selector:
    matchLabels:
      app: daemonset-pod
  template:
    metadata:
      labels:
        app: daemonset-pod
    spec:
      nodeSelector:
        kubernetes.io/hostname: docker-desktop
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        imagePullPolicy: Never

Job控制器

Job控制器用于調配Pod物件運行一次性任務，容器中的行程在正常運行結束后，Pod物件會被置于Completed狀態，Job控制器的配置清單相對簡單：

apiVersion: batch/v1
kind: Job
metadata:
  name: job-example
spec:
  completions: 5
  parallelism: 5
  template:
    metadata:
      labels:
        app: job1
    spec:
      restartPolicy: Never
      containers:
      - name: job1
        image: alpine
        command: ["/bin/sh", "-c", "sleep 5"] 

Pod模板中的spec.restartPolicy默認為“Always”,但對Job控制器來說只支持“Never”或“OnFailure”，因此必須顯式設定restartPolicy屬性的值，
apply資源清單后，job便開始執行，如果順利執行完畢，會處于Succeed狀態，job資源會被自動添加標簽job-name='name',如job-name=job-example，可據此使用標簽選擇器查看job狀態

串行、并行控制

spec.completions表示總任務數，spec.parallelism表示并行度，默認都是1，所以job在執行一次后即完成，如果parallelism設為1，completions設為5，則job會以串行的方式運行5次，如果parallelism也設為5，則會并行運行5個job實體，如果completions大于parallelism，Job控制器就會以串行方式運行多任務，
可以使用--watch選項監控job的運行狀態

kubectl get jobs -l job-name=job-example --watch

洗掉Job

Job控制器待其Pod資源運行完成后，將不再占用系統資源，用戶可按需保留或使用資源洗掉命令將其洗掉，但如果某Job控制器的容器應用總是無法正常結束運行，而其restartPolicy又定為了重啟，則它可能會一直處于不停地重啟和錯誤的回圈當中，下面兩個屬性用于抑制這種情況的發生：
spec.activeDeadlineSeconds，用于指定job的最大執行時長，超出將被終止；
spec.backoffLimit，最大重試次數，超出后被標記為失敗，默認值為6，
activeDeadlineSeconds要比backoffLimit優先級高，如果時間到了，但是backoffLimit還未到，該Job也會被強制停止，

CornJob控制器

CronJob控制器用于管理Job控制器資源的運行時間，Job控制器定義的作業任務在其控制器資源創建之后便會立即執行，但CronJob可以以類似于Linux作業系統的周期性任務作業計劃（crontab）的方式控制其運行的時間點及重復運行的方式，

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-example
  labels:
    app: cronjob1
spec:
  schedule: "* * * * *"
  jobTemplate:
    metadata:
      labels:
        app: cronjob1-job
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: job1
            image: alpine
            command: ["/bin/sh", "-c", "date; echo Hello from the kubernetes cluster; sleep 1"]

這個cronjob沒分鐘運行一次，schedule的語法可參照這里，schedule的時間基于 kube-controller-manager的時區，

任務啟動一段時間后，可使用log命令查看pod輸出：

kubectl logs cronjob-example-1620082920-vg7p8

Pod中斷預算

Pod中斷可大體分為兩種：

• 非自愿中斷，是指那些由不可控外界因素導致的Pod中斷退出操作，例如，硬體或系統內核故障、網路故障以及節點資源不足導致Pod物件被驅逐等；
• 自愿中斷，是指那些由用戶特地執行的管理操作導致的Pod中斷，例如排空節點、人為洗掉Pod物件、由更新操作觸發的Pod物件重建等，
  盡管Deployment或ReplicaSet一類的控制器能夠確保相應Pod物件的副本數量不斷逼近期望的數量，但它卻無法保證在某一時刻一定會存在指定數量或比例的Pod物件，然而這種需求在某些強調服務可用性的場景中卻是必備的，
  Pod中斷預算（PodDisruptionBudget，PDB）可用于為自愿中斷做好預算方案（Budget），限制可自愿中斷的最大Pod副本數或確保最少可用的Pod副本數，以確保服務的高可用性，

定義PDB資源時，spec欄位主要嵌套使用以下三個欄位:

• selector，當前PDB物件使用的標簽選擇器，一般是與相關的Pod控制器使用同一個選擇器，
• minAvailable，Pod自愿中斷的場景中，至少要保證可用的Pod物件數量或比例，要阻止任何Pod物件發生自愿中斷，可將其設定為100%
• maxUnavailable，Pod自愿中斷的場景中，最多可轉換為不可用狀態的Pod物件數量或比例，0值意味著不允許Pod物件進行自愿中斷，此欄位與minAvailable互斥，

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: pdb1
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

學習資料

《Kubernetes實戰進階》 馬永亮著

標籤：其他

上一篇：Kubernetes筆記(5) - Pod控制器

下一篇：關于DCT變換