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