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