四、k8s之资源控制器

原创
2020/10/12 13:25
阅读数 502

Pod分类

  • 自主式Pod:Pod退出了,此类型的Pod不会被创建。
  • 控制器管理的Pod:在控制器的生命周期里,始终维持Pod的副本数。

控制器

k8s中内建了很多Controller,这些相当于一个状态机,用来控制Pod的具体状态和行为。

###控制器类型

  • ReplicationController(RC) 和 ReplicaSet(RS)
  • Deployment
  • DaemonSet
  • StateFulSet
  • Job/CronJob
  • Horizontal Pod Autoscaling

详解:https://kubernetes.io/zh/docs/concepts/workloads/controllers/

ReplicationController 和 ReplicaSet

k8s内通过标签去管理资源。

Deployment

Deployment 创建 RS,RS创建Pod;Deployment通过RS间接管理Pod。

DaemonSet

Job

Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束。

CronJob

在特定的时间循环创建Job。

典型用法:

  • 在给定的时间调度Job运行
  • 创建周期性运行的Job,例如:数据库备份、发送邮件

StatefulSet

Horizontal Pod Autoscaling(HPA)

RS & RC & Deployment

RC(ReplicationController)主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收。

Kubernetes官方建议使用RS(ReplicaSet)替代RC进行部署,RS和RC没有本质的不同,只是名字不一样,并且RS支持集合式的 selector。

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      cotainers:
      - name: myapp
        image: hub.adaixuezhang.cn/library/myapp:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

查看/修改pod标签:

$ kubectl get pod --show-labels

$ kubectl label pod PodName LabelName=LabelValue --overwrite=True

更改便签后发现原有标签的pod数量会自动增加为3,即pod 监控和管理都是以 标签 作为控制标识的

RS 与 Deployment 的关联

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义方法,用来替代以前的RC来方便管理应用。典型的应用场景包括:

  • 定义Deployment来创建Pod和ReplicaSet
  • 滚动升级
  • 扩容和缩容
  • 暂停和继续Deployment

用Deployment部署一个简单的Nginx应用

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
      spec:
        containers:
          - name: nginx
            image: nginx:1.7.6
            ports:
              - cotainerPort: 80

Tips:在进行应用部署前要规划好pod标签。

创建Deployment
$ kubectl apply -f nginx-deployment.yaml --record
# --record:可以记录命令,我们可以很方便的查看每次reversion的
扩容
$ kubectl scale deployment nginx-deployment --replicas 10
弹性扩/缩容

如果集群支持Horizontal pod autoscaling 的话,还可以为 Deployment 设置自动扩展

$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
更新镜像
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
回滚
$ kubectl rollout undo deployment/nginx-deployment

Deployment更新策略

Deployment可以保证在升级时只有一定数量的Pod是down的。默认的,它会确保至少有比期望的pod数量少一个是up状态(最多1个不可用)。

Deployment同时也可以确保只创建超出期望数量的一定数量的Pod。默认的,它会确保最多比预期的Pod数量多一个的Pod是up的(最多1个surge)

未来的Kubernetes版本中,将1-1变成25%-25%

$ kubectl describe deployments

Rollover(多个rollout并行)

假如您创建了一个有5个 nginx:1.7.9 replica的Deployment,但是当还只有3个 nginx:1.7.9 的replica创建出来的时候您就开始更新含有5个 nignx:1.9.1 replica的Deployment。在这种情况下,Deployment会立即kill已创建的3个 nginx:1.7.9 的Pod,并开始创建 nignx:1.9.1 的Pod。它不会等到所有的5个 nignx:1.9.1 的Pod都创建完再开始改变航道。

回退Deployment

只要 Deployment的rollout被触发就会创建一个reversion。也就是说当且仅当Deployment的Pod template(如 .spec.template)被更改,例如更新 template中的label和容器镜像时,就会创建出一个新的reversion。其他的更新,比如扩容 Deployment 不会创建 reversion——因此我们可以很方便的手动或者自动扩容。这意味着当您回退到历史 reversion 时,只有Deployment 中的Pod template部分才会回退。

命令:

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
$ kubectl rollout status deployments nginx-deployment
$ kubectl get pods
$ kubectl rollout history deployment/nginx-deployment
$ kubectl rollout undo deployment/nginx-deployment
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2 # 可以使用--reversion指定某个历史版本
$ kubectl rollout pause deployment/nginx-deployment # 暂停Deployment的更新

您可以用 kubectl rollout status 命令产看Deployment是否完成。如果rollout成功完成, kubectl rollout status 将返回一个0值的Exit Code。

清理Policy

通过设置 .spec.revisionHistoryLimit 来指定Deployment最多保留多少 revision历史记录。默认会保留所有的revision;乳沟将该项设置为0,Deployment就不允许回退了。

DaemonSet & Job & CronJob

DaemonSet

DaemonSet确保每个(或者一些)Node上运行一个Pod的副本。当有Node加入集群时,也会为 他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。

DaemonSet的一些典型用法:

  • 运行集群存储Daemon,例如在每个Node上运行 glusterdceph
  • 在每个Node上运行日志收集Daemon,例如 fluentdlogstash
  • 在每个Node上运行监控Daemon,例如 Prometheus Node ExpotercollectdDatadog代理、New relic代理,或Ganglia gmond

示例:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemon-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: daemonset-example
  template:
    metadata:
      labels:
        name: daemonset-example
    spec:
      containers:
        - name: daemonset-example
          image: hub.adaixuezhang.cn/library/myapp:v1

创建:

$ kubectl create -f daemonset.yaml

Job

Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束。

特殊说明:

  • spec.template 格式同 Pod
  • RestartPolicy 仅支持Never或OnFailure
  • 单个Pod时,默认Pod成功运行后Job即结束
  • .spec.completions 标志Job结束需要成功运行的Pod个数,默认为1
  • .spec.parallelism 标志并行运行的Pod个数,默认为1
  • .spce.activeDeadlineSeconds 标志失败Pod的重试最大时间,超过这个时间不会继续重试

示例:

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
        - name: perl
          command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

创建:

$ kubectl create -f job.yaml
$ kubectl get job

查看日志,可以显示出答应的 2000 位 n 值。

CronJob

CronJob管理基于时间的Job,即:

  • 在给定时间点只运行一次
  • 周期性地在给定时间点运行

使用条件:当前使用的k8s集群,版本 >= 1.8 (对CronJob)

典型用法:

  • 在给定是啊金调度Job运行
  • 创建周期性运行的Job,例如:数据库备份、发送邮件

CronJob Spec

  • spec.template格式同Pod
  • RestartPolicy 紧支持Never或OnFailure
  • 单个Pod时,默认Pod成功运行后Job即结束
  • .spec.completions 标志Job结束需要成功运行的Pod个数,默认为1
  • .spec.parallisn 标志并行运行的Pod个数,默认为1
  • .spce.activeDeadlineSeconds 标志失败Pod的重试最大时间,超过这个时间不会继续重试

CronJob Spec2

  • .spec.schedule:调度,必需字段,指定任务运行周期,格式通Cron;

  • .spec.jobTemplate:Job模板,必须字段,指定需要运行的任务,格式同Job;

  • .spec.startingDeadlineSeconds:启动Job的期限(秒级),该字段是可选的。如果因为任何原因错过了被调度的时间,那么错过执行时间的Job将被认为是失败的。如果没有指定,则没有期限

  • .spec.concurrencyPolicy:并发策略,可选字段。指定如何处理CronJob创建的Job的并发执行。只允许指定下面策略中的一种:

    • Allow(默认):允许并发运行Job
    • Forbid:禁止并发运行,如果前一个还没有完成,则直接跳过下一个
    • Replace:取消当前正在运行的Job,用一个新的来替换

    注意,当前策略只能应用于同一个CronJob创建的Job。如果存在多个CronJob,它们创建的Job之间总是允许并发运行。

  • .spec.suspend:挂起,可选字段,默认为false。如果设置为true,后续所有执行都会被挂起。它对已经开始的Job不起作用。

  • .spec.successfulJobHistoryLimit.spec.failedJobHistoryLimit:历史限制,可选字段。指定保留多少完成和失败的Job。默认情况它们分别为3和1,设置为0,相关类型的Job完成后将不会被保留。

示例:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: hello
              image: busybox
              args:
                - /bin/sh
                - -c
                - date; echo Hello from the k8s cluster
            restartPolicy: OnFailure

创建/查看/删除CronJob:

$ kubectl create -f cronjob.yaml
$ kubectl get cronjob
$ kubectl get jobs
# 注意:删除CronJob事不会自动删除job,这些job可以用 kubectl delete job 来删除
$ kubectl delete cronjob CronJobName

CronJob本身的一些限制

创建Job操作应该是幂等的

展开阅读全文
加载中

作者的其它热门文章

打赏
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部