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的控制器的基本內容就這些了。高級用法碰到在了解。