k8s几种pod的控制器

Posted 2020-11-16 zhming26

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