這篇文章主要介紹“什么是Pod控制器”，在日常操作中，相信很多人在什么是Pod控制器問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”什么是Pod控制器”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

漳平網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián)公司,漳平網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為漳平1000多家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的漳平做網(wǎng)站的公司定做！

• ReplicaSet控制器

• 創(chuàng)建ReplicaSet

• ReplicaSet管控下的Pod對(duì)象

• 更新ReplicaSet

• Deployment控制器

• 創(chuàng)建Deployment

• 更新策略

• 升級(jí)Deployment

• 金絲雀發(fā)布

• 擴(kuò)容、縮容

• DaemonSet控制器

• Job控制器

• 串行、并行控制

• 刪除Job

• CornJob控制器

• Pod中斷預(yù)算

自主式Pod對(duì)象由調(diào)度器綁定至目標(biāo)工作節(jié)點(diǎn)后即由相應(yīng)節(jié)點(diǎn)上的kubelet負(fù)責(zé)監(jiān)控其容器的存活性，容器主進(jìn)程崩潰后，kubelet能夠自動(dòng)重啟相應(yīng)的容器，基于存活性探測(cè)，在容器出現(xiàn)其他問(wèn)題時(shí)也能作出響應(yīng)，但如果Pod被意外刪除、或者工作節(jié)點(diǎn)發(fā)生故障，kubelet就無(wú)能為力了。 Pod控制器可應(yīng)對(duì)這類情況。Pod控制器由master的kube-controller-manager組件提供。kube-controller-manager是一個(gè)獨(dú)立的單體守護(hù)進(jìn)程，它包含了眾多功能不同的控制器，除了Pod Controller，還有NodeLifecycle Controller、Namespace Controller、Service Controller等等。這些控制器不間斷地監(jiān)控著由其負(fù)責(zé)的資源，并在因故障、更新或其他原因?qū)е孪到y(tǒng)狀態(tài)發(fā)生變化時(shí)，嘗試讓資源的當(dāng)前狀態(tài)向期望狀態(tài)遷移和逼近。

ReplicaSet控制器

ReplicaSet替代了早期的ReplicationController，用于確保由其管控的Pod對(duì)象副本數(shù)在任一時(shí)刻都能精確滿足期望的數(shù)量

通過(guò)控制器創(chuàng)建的Pod與用戶手動(dòng)創(chuàng)建的Pod功能相同，但相比于手動(dòng)創(chuàng)建來(lái)說(shuō)，ReplicaSet能夠?qū)崿F(xiàn)以下功能：

• 確保Pod資源對(duì)象的數(shù)量精確反映期望值

• 確保Pod健康運(yùn)行，在探測(cè)到由其管控的Pod對(duì)象因其所在的工作節(jié)點(diǎn)故障而不可用時(shí)，自動(dòng)請(qǐng)求由調(diào)度器于其他工作節(jié)點(diǎn)創(chuàng)建缺失的Pod副本

• 彈性伸縮：在資源需求存在較大波動(dòng)時(shí)，可以通過(guò)ReplicaSet控制器動(dòng)態(tài)調(diào)整相關(guān)Pod資源對(duì)象的數(shù)量。還可以配合HPA（HroizontalPodAutoscaler）實(shí)現(xiàn)Pod資源規(guī)模的自動(dòng)伸縮。

創(chuàng)建ReplicaSet

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

• selector：標(biāo)簽選擇器，匹配并關(guān)聯(lián)Pod資源對(duì)象，并據(jù)此完成受其管控的Pod資源計(jì)數(shù)

• replicas：期望的副本數(shù)，期望在集群中精確運(yùn)行著的Pod資源的對(duì)象數(shù)量

• template：Pod模板，用于新建Pod資源對(duì)象的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查看，會(huì)看到有兩個(gè)容器，狀態(tài)從ContainerCreating轉(zhuǎn)為Running，兩個(gè)pod名稱以控制器的名稱rs-example為前綴，rs-example-j98fp、rs-example-wj8zg。 運(yùn)行kubectl get replicaset rs-example，配合-o json\wide等選項(xiàng)可查看控制器的詳細(xì)狀態(tài)。

ReplicaSet管控下的Pod對(duì)象

ReplicaSet之所以能對(duì)Pod對(duì)象數(shù)目的異常及時(shí)做出響應(yīng)，是因?yàn)樗駻PI Server注冊(cè)監(jiān)聽了相關(guān)資源及其列表的變動(dòng)信息，于是API Server會(huì)在變動(dòng)發(fā)生時(shí)立即通知給監(jiān)聽方。

缺少、多出Pod副本

任何原因?qū)е碌南嚓P(guān)Pod對(duì)象丟失，都會(huì)由ReplicaSet控制器自動(dòng)補(bǔ)足。 手動(dòng)刪除一個(gè)Pod，ReplicaSet馬上會(huì)新建一個(gè)；之前創(chuàng)建的ReplicaSet依賴標(biāo)簽app: rs-demo來(lái)管理Pod，那么強(qiáng)制修改這個(gè)標(biāo)簽也會(huì)觸發(fā)副本的新建： kubectl label pods rs-example-wj8zg app=others --overwrite 之前的Pod rs-example-wj8zg還存在，如果它能被別的控制器通過(guò)標(biāo)簽選擇器選中，就會(huì)隸屬于這個(gè)控制器，否會(huì)成為自助式Pod。 多余的部分則會(huì)被控制器自動(dòng)刪除，經(jīng)測(cè)試Age最小的會(huì)被首先刪除。

kubectl describe replicasets/rs-example命令可打印出ReplicaSet的詳細(xì)狀態(tài)以及Events。

更新ReplicaSet

更改template：升級(jí)應(yīng)用

更改template對(duì)已經(jīng)創(chuàng)建完成的活動(dòng)對(duì)象無(wú)效，但可以逐個(gè)手動(dòng)關(guān)閉其舊版本的Pod資源來(lái)實(shí)現(xiàn)滾動(dòng)升級(jí)。 相比于ReplicaSet的手動(dòng)操作方式，Deployment控制器能夠自動(dòng)實(shí)現(xiàn)更完善的滾動(dòng)更新和回滾，并為用戶提供自定義更新策略的接口。

更改replicas：擴(kuò)容和縮容

通過(guò)修改replicas屬性并apply，可實(shí)現(xiàn)應(yīng)用規(guī)模的水平伸縮；kubectl還提供了一個(gè)專用的子命令scale用于實(shí)現(xiàn)應(yīng)用規(guī)模的伸縮，比如: kubectl scale replicasets rs-example --replicas=2 使用--current-replicas選項(xiàng)還可實(shí)現(xiàn)在副本數(shù)量為指定值時(shí)才變更replicas，比如下面的命令，如果當(dāng)前副本數(shù)量不等于4就不會(huì)執(zhí)行成功： kubectl scale replicasets rs-example --current-replicas=4 --replicas=2

如果讓ReplicaSet管控有狀態(tài)應(yīng)用，例如主從架構(gòu)的redis集群，那么上述這些升降級(jí)、擴(kuò)縮容操作都需要精心編排和參與才能進(jìn)行，針對(duì)這類需求，可以使用K8S專門提供的StatefulSet，ReplicaSet通常僅用于管理無(wú)狀態(tài)的應(yīng)用，如HTTP服務(wù)程序等。

刪除ReplicaSet資源

刪除命令： kubectl delete -f ... 或者 kubectl delete replicaset ... 刪除ReplicaSet對(duì)象時(shí)默認(rèn)會(huì)一并刪除其管控的各Pod對(duì)象。但有時(shí)考慮到這些Pod資源未必由其創(chuàng)建，或者Pod資源后續(xù)可能會(huì)再次用到時(shí)，可以添加--cascade=false選項(xiàng)取消級(jí)聯(lián)刪除。

Deployment控制器

Deployment控制器構(gòu)建于ReplicaSet控制器之上，可為Pod和ReplicaSet資源提供聲明式更新。Pod和ReplicaSet是較低級(jí)別的資源，很少被直接使用。 Deployment控制器在ReplicaSet的基礎(chǔ)上，添加了多種增強(qiáng)的功能：

• 事件和狀態(tài)查看：必要時(shí)可以查看Deployment對(duì)象升級(jí)的詳細(xì)進(jìn)度和狀態(tài)

• 回滾：在升級(jí)發(fā)現(xiàn)問(wèn)題時(shí)，可以使用回滾機(jī)制將應(yīng)用返回到前一個(gè)或由指定的歷史版本

• 版本記錄：保存每一次操作記錄，以供后續(xù)可能執(zhí)行的回滾操作使用

• 暫停和啟動(dòng)：對(duì)于每一次升級(jí)，都能夠隨時(shí)暫停和啟動(dòng)

• 多種自動(dòng)更新方案：

• Recreate，重建更新機(jī)制，全面停止、刪除舊有的Pod后用新版本替代

• RollingUpdate，滾動(dòng)升級(jí)機(jī)制，逐步替換舊有的Pod至新的版本。

創(chuàng)建Deployment

Deployment將ReplicaSet對(duì)象作為其二級(jí)資源，配置清單中除了kind、name，其它字段與ReplicaSet的相同，示例：

kind: Deployment
metadata:
  name: myapp-deploy

創(chuàng)建完成后可用kubectl get deployments myapp-deploy查看其狀態(tài):

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

UP-TO-DATE表示已經(jīng)達(dá)到期望狀態(tài)的Pod副本數(shù)量，AVAILABLE則表示當(dāng)前處于可用狀態(tài)的應(yīng)用程序的數(shù)量。 查看相關(guān)的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] 查看相關(guān)的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位隨機(jī)字符。

更新策略

Deployment控制器支持RollingUpdate和Recreate兩種更新策略，默認(rèn)為滾動(dòng)更新。

Recreate

類似于使用ReplicaSet時(shí)一次性刪除全部Pod對(duì)象，而后由控制器基于新模板重新創(chuàng)建出新版本資源對(duì)象。這種方式通常只應(yīng)該在應(yīng)用的新舊版本不兼容（如依賴的后端數(shù)據(jù)庫(kù)的schema不同且無(wú)法兼容）時(shí)才使用，因?yàn)樗鼤?huì)導(dǎo)致應(yīng)用替換期間暫時(shí)不可用，但好處在于它不存在中間狀態(tài)。

RollingUpdate

滾動(dòng)升級(jí)是在刪除一部分舊版本Pod資源的同時(shí)，補(bǔ)充創(chuàng)建一部分新版本的Pod對(duì)象，使用這種方式時(shí)，容器中應(yīng)用提供的服務(wù)不會(huì)中斷，但要求應(yīng)用程序能夠應(yīng)對(duì)新舊版本同時(shí)工作的情形，例如新舊版本兼容同一個(gè)數(shù)據(jù)庫(kù)方案等。 滾動(dòng)升級(jí)時(shí)會(huì)同時(shí)存在新舊版本的ReplicaSet，舊版ReplicaSet的Pod對(duì)象數(shù)量不斷減少的同時(shí)，新版ReplicaSet的Pod對(duì)象數(shù)量不斷增加，直到舊版ReplicaSet不再擁有Pod對(duì)象，而新版ReplicaSet的副本數(shù)量變得完全符合預(yù)期。 升級(jí)期間還要確保可用的Pod對(duì)象數(shù)量不低于某閾值以確保可以持續(xù)處理客戶端的服務(wù)請(qǐng)求，變動(dòng)的方式和Pod對(duì)象的數(shù)量范圍將通過(guò)spec.strategy.rollingUpdate下的maxSurge和maxUnavailable兩個(gè)屬性協(xié)同定義：

• maxSurge：升級(jí)期間存在的總Pod對(duì)象數(shù)量最多可超出期望值的個(gè)數(shù)，其值可以是0或正整數(shù)，也可以是一個(gè)期望值的百分比

• maxUnavailable：升級(jí)期間正常可用的Pod副本數(shù)（包括新舊版本）最多不能低于期望數(shù)值的個(gè)數(shù)，其值可以是0或正整數(shù)，也可以是一個(gè)期望值的百分比，默認(rèn)值為1。

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

此外，還可以設(shè)置spec.minReadySeconds屬性：

• ，控制應(yīng)用升級(jí)的速度，滾動(dòng)升級(jí)時(shí)默認(rèn)新的Pod對(duì)象只要就緒探測(cè)成功就可用，于是開始開始下一輪的替換操作。而minReadySeconds能夠定義在新的Pod對(duì)象創(chuàng)建后至少要等待多久才會(huì)將其視作就緒，在此期間，更新操作會(huì)被阻塞。

升級(jí)Deployment

修改Pod模板相關(guān)的配置參數(shù)便能完成Deployment控制器資源的更新，可以通過(guò)apply和patch命令來(lái)修改；如果只是修改容器鏡像，可以直接使用set image命令。 為了使得升級(jí)過(guò)程更易于觀測(cè)，先使用“kubectl patch”命令指定minReadySeconds=6s：

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

修改Deployment控制器的minReadySeconds、replicas和strategy等字段的值并不會(huì)觸發(fā)Pod資源的更新操作，因?yàn)樗鼈儾粫?huì)對(duì)現(xiàn)存的Pod對(duì)象不產(chǎn)生任何影響。 使用set image命令更新鏡像版本：

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

隨后使用如下命令可以觀察滾動(dòng)升級(jí)的過(guò)程：

kubectl rollout status deployments myapp-deploy --watch

升級(jí)完成后，舊版本的ReplicaSet控制器會(huì)保留在歷史記錄中，但其此前的管控Pod對(duì)象將會(huì)被刪除。

金絲雀發(fā)布

Deployment控制器支持更新操作的暫停、繼續(xù)，再結(jié)合maxSurge和maxUnavailable，可以實(shí)現(xiàn)金絲雀發(fā)布（Canary Release），即待第一批新的Pod資源創(chuàng)建完成后立即暫停更新過(guò)程，此時(shí)，僅存在一小部分新版本的應(yīng)用，主體部分還是舊的版本。然后將一小部分流量導(dǎo)到新版本的Pod應(yīng)用，并持續(xù)觀察其是否能穩(wěn)定地按期望的方式運(yùn)行，確定沒有問(wèn)題后再繼續(xù)完成余下Pod資源的滾動(dòng)更新，否則立即回滾更新操作。 為了盡可能地降低對(duì)現(xiàn)有系統(tǒng)的影響，金絲雀發(fā)布過(guò)程通常建議采用“先添加、再刪除，且可用Pod資源對(duì)象總數(shù)不低于期望值”的方式進(jìn)行，首次添加的Pod對(duì)象數(shù)量取決于其接入的第一批請(qǐng)求的規(guī)則及單個(gè)Pod的承載能力。 接下來(lái)的試驗(yàn)中將maxSurge和maxUnavailable分別設(shè)置為1和0，并通過(guò)修改升級(jí)鏡像版本來(lái)觸發(fā)更新，但要在第一批更新啟動(dòng)后就暫停，由于設(shè)置了minReadySeconds，可以在這個(gè)過(guò)程中發(fā)出暫停命令，對(duì)于kubectl來(lái)說(shuō)，也可以直接以“&&”符號(hào)在Shell中連接兩個(gè)命令：

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

查看狀態(tài)可知更新操作已經(jīng)暫停：

kubectl rollout status deployments myapp-deploy

此時(shí)，通過(guò)Service或Ingress資源及相關(guān)路由策略等設(shè)定，即可將一部分用戶的流量引入到這些Pod之上進(jìn)行發(fā)布驗(yàn)證，確認(rèn)沒有問(wèn)題后即可繼續(xù)更新：

kubectl rollout resume deployments myapp-deploy

回滾

如果因各種原因?qū)е聺L動(dòng)更新無(wú)法正常進(jìn)行，如鏡像文件獲取失敗、“金絲雀”遇險(xiǎn)等，則應(yīng)該將應(yīng)用回滾到之前的版本或者指定的歷史記錄中的版本，直接回滾至上一版本：

kubectl rollout undo deployments myapp-deploy

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

kubectl rollout history deployments myapp-deploy

需要注意的是，只有回滾至被保存的歷史版本，spec.revisionHistoryLimit定義了保存的版本數(shù)量，默認(rèn)為10個(gè)。另外rollout history顯示的CHANGE-CAUSE一列的內(nèi)容默認(rèn)為空，在執(zhí)行命令時(shí)加上--record=true選項(xiàng)，可以記錄觸發(fā)更新的命令的內(nèi)容。此外，處于暫停狀態(tài)的更新無(wú)法回滾。

擴(kuò)容、縮容

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

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

比如在當(dāng)前Pod副本數(shù)為4個(gè)時(shí)，調(diào)整為2個(gè)：

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

DaemonSet控制器

DaemonSet用于在集群中的全部或指定節(jié)點(diǎn)上同時(shí)運(yùn)行一份指定的Pod資源副本，后續(xù)新加入集群的工作節(jié)點(diǎn)也會(huì)自動(dòng)創(chuàng)建一個(gè)相關(guān)的Pod對(duì)象，當(dāng)從集群移除節(jié)點(diǎn)時(shí)，此類Pod對(duì)象也將被自動(dòng)回收而無(wú)須重建。 DaemonSet是一種特殊的控制器，它有特定的應(yīng)用場(chǎng)景，通常運(yùn)行那些執(zhí)行系統(tǒng)級(jí)操作任務(wù)的應(yīng)用，如集群存儲(chǔ)的守護(hù)進(jìn)程、日志收集守護(hù)進(jìn)程、監(jiān)控系統(tǒng)的代理守護(hù)進(jìn)程等。

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控制器用于調(diào)配Pod對(duì)象運(yùn)行一次性任務(wù)，容器中的進(jìn)程在正常運(yùn)行結(jié)束后，Pod對(duì)象會(huì)被置于Completed狀態(tài)。Job控制器的配置清單相對(duì)簡(jiǎn)單：

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默認(rèn)為“Always”,但對(duì)Job控制器來(lái)說(shuō)只支持“Never”或“OnFailure”，因此必須顯式設(shè)定restartPolicy屬性的值。 apply資源清單后，job便開始執(zhí)行，如果順利執(zhí)行完畢，會(huì)處于Succeed狀態(tài)，job資源會(huì)被自動(dòng)添加標(biāo)簽job-name='name',如job-name=job-example，可據(jù)此使用標(biāo)簽選擇器查看job狀態(tài)

串行、并行控制

spec.completions表示總?cè)蝿?wù)數(shù)，spec.parallelism表示并行度，默認(rèn)都是1，所以job在執(zhí)行一次后即完成，如果parallelism設(shè)為1，completions設(shè)為5，則job會(huì)以串行的方式運(yùn)行5次，如果parallelism也設(shè)為5，則會(huì)并行運(yùn)行5個(gè)job實(shí)例。如果completions大于parallelism，Job控制器就會(huì)以串行方式運(yùn)行多任務(wù)。 可以使用--watch選項(xiàng)監(jiān)控job的運(yùn)行狀態(tài)

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

刪除Job

Job控制器待其Pod資源運(yùn)行完成后，將不再占用系統(tǒng)資源。用戶可按需保留或使用資源刪除命令將其刪除。但如果某Job控制器的容器應(yīng)用總是無(wú)法正常結(jié)束運(yùn)行，而其restartPolicy又定為了重啟，則它可能會(huì)一直處于不停地重啟和錯(cuò)誤的循環(huán)當(dāng)中。下面兩個(gè)屬性用于抑制這種情況的發(fā)生： spec.activeDeadlineSeconds，用于指定job的最大執(zhí)行時(shí)長(zhǎng)，超出將被終止； spec.backoffLimit，最大重試次數(shù)，超出后被標(biāo)記為失敗，默認(rèn)值為6。 activeDeadlineSeconds要比backoffLimit優(yōu)先級(jí)高，如果時(shí)間到了，但是backoffLimit還未到，該Job也會(huì)被強(qiáng)制停止。

CornJob控制器

CronJob控制器用于管理Job控制器資源的運(yùn)行時(shí)間。Job控制器定義的作業(yè)任務(wù)在其控制器資源創(chuàng)建之后便會(huì)立即執(zhí)行，但CronJob可以以類似于Linux操作系統(tǒng)的周期性任務(wù)作業(yè)計(jì)劃（crontab）的方式控制其運(yùn)行的時(shí)間點(diǎn)及重復(fù)運(yùn)行的方式。

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"]

這個(gè)cronjob沒分鐘運(yùn)行一次，schedule的語(yǔ)法可參照這里，schedule的時(shí)間基于 kube-controller-manager的時(shí)區(qū)。

任務(wù)啟動(dòng)一段時(shí)間后，可使用log命令查看pod輸出：

kubectl logs cronjob-example-1620082920-vg7p8

Pod中斷預(yù)算

Pod中斷可大體分為兩種：

• 非自愿中斷，是指那些由不可控外界因素導(dǎo)致的Pod中斷退出操作，例如，硬件或系統(tǒng)內(nèi)核故障、網(wǎng)絡(luò)故障以及節(jié)點(diǎn)資源不足導(dǎo)致Pod對(duì)象被驅(qū)逐等；

• 自愿中斷，是指那些由用戶特地執(zhí)行的管理操作導(dǎo)致的Pod中斷，例如排空節(jié)點(diǎn)、人為刪除Pod對(duì)象、由更新操作觸發(fā)的Pod對(duì)象重建等。 盡管Deployment或ReplicaSet一類的控制器能夠確保相應(yīng)Pod對(duì)象的副本數(shù)量不斷逼近期望的數(shù)量，但它卻無(wú)法保證在某一時(shí)刻一定會(huì)存在指定數(shù)量或比例的Pod對(duì)象，然而這種需求在某些強(qiáng)調(diào)服務(wù)可用性的場(chǎng)景中卻是必備的。 Pod中斷預(yù)算（PodDisruptionBudget，PDB）可用于為自愿中斷做好預(yù)算方案（Budget），限制可自愿中斷的最大Pod副本數(shù)或確保最少可用的Pod副本數(shù)，以確保服務(wù)的高可用性。

定義PDB資源時(shí)，spec字段主要嵌套使用以下三個(gè)字段:

• selector，當(dāng)前PDB對(duì)象使用的標(biāo)簽選擇器，一般是與相關(guān)的Pod控制器使用同一個(gè)選擇器。

• minAvailable，Pod自愿中斷的場(chǎng)景中，至少要保證可用的Pod對(duì)象數(shù)量或比例，要阻止任何Pod對(duì)象發(fā)生自愿中斷，可將其設(shè)置為100%

• maxUnavailable，Pod自愿中斷的場(chǎng)景中，最多可轉(zhuǎn)換為不可用狀態(tài)的Pod對(duì)象數(shù)量或比例，0值意味著不允許Pod對(duì)象進(jìn)行自愿中斷，此字段與minAvailable互斥。

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

到此，關(guān)于“什么是Pod控制器”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！

分享題目：什么是Pod控制器
標(biāo)題來(lái)源：http://chinadenli.net/article48/gsghep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供響應(yīng)式網(wǎng)站、用戶體驗(yàn)、面包屑導(dǎo)航、網(wǎng)站改版、自適應(yīng)網(wǎng)站、虛擬主機(jī)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)