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

posted @ 2019-10-22 13:57  zhming  阅读(5034)  评论(0编辑  收藏  举报