k8s幾種pod的控制器

replicationcontroller

選擇器

模版

副本數

 

若是更改選擇器，則會建立新的pod

若是更改pod的標籤，那麼也會建立新的pod進行替換，可是老的pod不會被刪除

若是更改模版，好比給加入新標籤，那麼將在下次替換時用到新模版，這個能夠用於升級pod使用

 

kubectl edit rc kubia 這將在你的默認編輯器中打開Replicationcontroller 的YAML配置。

使用export KUBE_EDITOR="/usr/bin/nano"設置默認編輯器

 

kubectl delete rc kubia 這是刪除replicationcontroller命令，刪除rc的同時，pod也會被刪除。咱們知道rc只是pod的管理器，rc建立的pod不是rc的組成部分，因此咱們也能夠只刪除rc而不刪除pod，使用--cascade=false 參數、

kubectl delete rc kubia --cascade=false

 

最初replicationcontroller 是用於複製和在異常時從新調度節點的惟一kubernetes組建，後來被replicaSet代替了。如今基本上見不到replicationcontroller,可是有的環境仍是有可能會有，因此咱們仍是知道的好。

replicaset咱們一般也不會直接建立，而是在建立最高層級的deployment資源時自動建立。

replicaset 與replicationcontroller的區別

replicaset 標籤選擇器的能力更強。

replicationcontroller只能指定標籤名：標籤值

replicaset 能夠指定env=pro,env=devel ,也能夠指定只要包含env標籤就行，理解爲env=*

雖然說不用直接建立，爲了學習咱們手動建立。

定義replicaset

apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLables:
      app: kubia
template:
  metadata:
      lables:
        app:kubia
  spec:
      containers:
      - name:kubia
         image: luska/kubia

template部分和replicationController 同樣

selector處不同。replicationController 用selector ,replicaSet用 selector.matchLables選擇器 更簡單，更具備表達力

replicaSet 的簡寫 rs

kubectl get rs

kubectl describe rs

 

rs 的matchlables 是精確匹配，說rs支持更強表達能力的選擇器，是由於rs還有matchExpressions選擇器

selector:
    matchExpressions:
        - key: app
           operator: In 
           values:
               - kubia

operator（運算符）有四個

In

NotIn

Exists: 必須包含某個key，值不重要，values不該指定

DoesNotExists: 必須不包含某個key, values不該指定

 

當你的replicaSet 的選擇器同時定義了matchLables和 matchExpressions ，必須兩個同時知足才能是pod和選擇器匹配

 

kubectl delete rs kubia 刪除rs的同時pod也被刪除，刪除前建議列出pod進行確認

 

rc,rs 都用於在kubernetes集羣上運行指定數量的pod，但他們不關心在哪一個節點上運行。有種狀況是讓每一個節點都運行某一個pod好比日誌收集，和監控應用。這時候要用到另一個控制器了DaemonSet.

DaemonSet也使用Pod模版，默認是將模版中的pod，在每一個節點中建立pod,但也有特殊狀況，只在某特定節點上建立pod,好比不一樣的硬盤類型。這能夠用pod模版的nodeSelector屬性指定

apiVersion: apps/v1beta2
kind: DaemonSet
metadata:
    name: ssd-monitor
spec:
    selector:
        matchLables:
            app: ssd-monitor
    template:
        metadata:
            lables:
                app: ssd-monitor
        spec:
             nodeSelector:
                  disk: ssd
             containers:
                  - name: main
                     image: luksa/ssd-monitor

DaemonSet 的簡寫ds

kubectl get ds

一樣刪除ds，同時也會刪除pod

 

rc,rs,ds都是持續運行pod也就是pod執行結束或者手動刪除pod，這些控制器都會重啓pod,有些時候須要讓pod運行完成退出後不在重啓，而且保證pod若是在運行時異常退出了能夠重啓的狀況。這就須要用到job了。

job管理的pod,正常完成退出後不重啓，當節點故障時，會按照replicaSet的pod方式，從新安排到一個新節點。也能夠配置job,若是進程異常退出返回錯誤碼時，重啓容器。

 

apiVersion: batch/v1
kind: Job
metadata:
   name: batch-job
spec:
   template:
       metadata:
            lables:
                app: batch-job
       spec:
            restartPolicy: onFailure    Job不能使用Always爲默認的重啓策略
            containers:
                - name: main
                   image: luksa/batch-job

這裏麼有定義標籤選擇器，它將根據pod模版中的標籤自動建立標籤選擇器

onFailure 當容器出錯時重啓容器，若是時Never將永遠不重啓

 

kubectl get jobs

kubectl get po -a 查看被刪除的pod

 

能夠配置job 按順序運行幾回

apiVersion: batch/v1
kind: Job
metadata:
   name: batch-job
spec:
   completions: 5
   template:
      ... ...

也能夠聲明能夠並行的數量

apiVersion: batch/v1
kind: Job
metadata:
   name: batch-job
spec:
   completions: 5 共計運行5次
   parallelism: 2  能夠並行2個
   template:
      ... ...

parallelism也能夠像replicaSet同樣擴縮容

kubectl scale job batch-job --replicas 3

 

job是一次性任務，萬一運行卡住了，你永遠不知道它的狀態，因此你能夠限制它運行的時長。超過期長標記爲失敗，這就須要用到pod中activeDeadlineSeconds 屬性來定義運行時長。

同時能夠定義job 中spec.backoffLimit配置job被標記爲失敗以前能夠重試的次數。默認爲6.

 

job建立後，當即會運行，但有些時候咱們但願定時運行job，這就須要用到kubernetes的CronJob資源

apiVersion: batch/v1beta1
kind: CronJob
metadata:
    name: batch-job-every-fifteen-minutes
spec:
    schedule: "0,15,30,45 * * * *" 每15分鐘執行一次而且在0，15，30，45
    JobTemplate:
        spec:
            template:
                matedata:
                     lables:
                         app: periodic-batch-job
                spec:
                     restartPolicy: OnFailure
                     containers:
                        - name: main
                           image: luksa/batch-job

假如咱們的任務運行時間要求很是準確，不但願本來定在10:30:00運行的任務拖到10:30:16運行，可能超過15秒運行結果就有誤差了。這時能夠設置startingDeadlineSeconds。

apiVersion: batch/v1beta1
kind: CronJob
metadata:
    name: batch-job-every-fifteen-minutes
spec:
    schedule: "0,15,30,45 * * * *" 每15分鐘執行一次而且在0，15，30，45
    startingDeadlineSeconds: 15
    JobTemplate:

replicationController,replicaSet,DaemonSet, Job, CronJob 這幾種管理pod的控制器的基本內容就這些了。高級用法碰到在瞭解。