​Kubernetes（k8s）工作负载

一、Workloads

什么是工作负载（Workloads）

• 工作负载是运行在 Kubernetes 上的一个应用程序。

• 一个应用很复杂，可能由单个组件或者多个组件共同完成。无论怎样我们可以用一组 Pod 来表示一个应用，也就是一个工作负载

• Pod 又是一组容器（Containers）

• 所以关系又像是这样

  工作负载（Workloads）控制一组 Pod

  Pod 控制一组容器（Containers）

  比如 Deploy（工作负载） 3 个副本的 nginx（3 个 Pod），每个 nginx 里面是真正的 nginx 容器（container）

​

二、Pod

关于 Pod 深入介绍已经在之前文章讲述过，有不了解的同学可以再看看以下文章

【云原生 | Kubernetes篇】深入了解Pod（六）_Lansonli的博客-CSDN博客

三、Deployment

关于 Deployment 深入介绍已经在上一篇文章讲述过，有不了解的同学可以看看以下文章

【云原生 | Kubernetes篇】深入了解Deployment_Lansonli的博客-CSDN博客

四、RC、RS、DaemonSet、StatefulSet

关于这块内容已经在之前文章讲述过，有不了解的同学可以再看看以下文章

【云原生 | Kubernetes篇】深入RC、RS、DaemonSet、StatefulSet（七）_Lansonli的博客-CSDN博客

五、Job、CronJob

1、Job

Kubernetes 中的 Job 对象将创建一个或多个 Pod，并确保指定数量的 Pod 可以成功执行到进程正常结束：

• 当 Job 创建的 Pod 执行成功并正常结束时，Job 将记录成功结束的 Pod 数量

• 当成功结束的 Pod 达到指定的数量时，Job 将完成执行

• 删除 Job 对象时，将清理掉由 Job 创建的 Pod

​

apiVersion: batch/v1kind: Jobmetadata:  name: pispec:  template:    spec:      containers:      - name: pi        image: perl        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]      restartPolicy: Never #Job情况下，不支持Always  backoffLimit: 4 #任务4次都没成，认为失败  activeDeadlineSeconds: 10

#默认这个任务需要成功执行一次。#查看job情况kubectl get job
#修改下面参数设置再试试#千万不要用阻塞容器。nginx。job由于Pod一直running状态。下一个永远得不到执行，而且超时了，当前running的Pod还会删掉kubectl api-resources

#参数说明kubectl explain job.specactiveDeadlineSeconds：10 总共维持10s#该字段限定了 Job 对象在集群中的存活时长，一旦达到 .spec.activeDeadlineSeconds 指定的时长，该 Job 创建的所有的 Pod 都将被终止。但是Job不会删除，Job需要手动删除，或者使用ttl进行清理backoffLimit：#设定 Job 最大的重试次数。该字段的默认值为 6；一旦重试次数达到了 backoffLimit 中的值，Job 将被标记为失败，且尤其创建的所有 Pod 将被终止；completions： #Job结束需要成功运行的Pods。默认为1manualSelector：parallelism： #并行运行的Pod个数，默认为1ttlSecondsAfterFinished：ttlSecondsAfterFinished: 0 #在job执行完时马上删除ttlSecondsAfterFinished: 100 #在job执行完后，等待100s再删除#除了 CronJob 之外，TTL 机制是另外一种自动清理已结束Job（Completed 或 Finished）的方式：#TTL 机制由 TTL 控制器 提供，ttlSecondsAfterFinished 字段可激活该特性#当 TTL 控制器清理 Job 时，TTL 控制器将删除 Job 对象，以及由该 Job 创建的所有 Pod 对象。	#job超时以后 已经完成的不删，正在运行的Pod就删除#单个Pod时，Pod成功运行，Job就结束了#如果Job中定义了多个容器，则Job的状态将根据所有容器的执行状态来变化。#Job任务不建议去运行nginx，tomcat，mysql等阻塞式的，否则这些任务永远完不了。#如果Job定义的容器中存在http server、mysql等长期的容器和一些批处理容器，则Job状态不会发生变化（因为长期运行的容器不会主动结束）。此时可以通过Pod的.status.containerStatuses获取指定容器的运行状态。

manualSelector：

• job 同样可以指定 selector 来关联 pod。需要注意的是 job 目前可以使用两个 API 组来操作，batch/v1 和 extensions/v1beta1。当用户需要自定义 selector 时，使用两种 API 组时定义的参数有所差异。

• 使用 batch/v1 时，用户需要将 jod 的 spec.manualSelector 设置为 true，才可以定制 selector。默认为 false。

• 使用 extensions/v1beta1 时，用户不需要额外的操作。因为 extensions/v1beta1 的 spec.autoSelector 默认为 false，该项与 batch/v1 的 spec.manualSelector 含义正好相反。换句话说，使用 extensions/v1beta1 时，用户不想定制 selector 时，需要手动将 spec.autoSelector 设置为 true。

2、CronJob

CronJob 按照预定的时间计划（schedule）创建 Job（注意：启动的是 Job 不是 Deploy，rs）。一个 CronJob 对象类似于 crontab (cron table) 文件中的一行记录。该对象根据 Cron 格式定义的时间计划，周期性地创建 Job 对象。

Schedule

所有 CronJob 的 schedule 中所定义的时间，都是基于 master 所在时区来进行计算的。

一个 CronJob 在时间计划中的每次执行时刻，都创建 大约 一个 Job 对象。这里用到了 大约 ，是因为在少数情况下会创建两个 Job 对象，或者不创建 Job 对象。尽管 K8S 尽最大的可能性避免这种情况的出现，但是并不能完全杜绝此现象的发生。因此，Job 程序必须是幂等的。

当以下两个条件都满足时，Job 将至少运行一次：

• startingDeadlineSeconds 被设置为一个较大的值，或者不设置该值（默认值将被采纳）

• concurrencyPolicy 被设置为 Allow
  

# kubectl explain cronjob.spec

   concurrencyPolicy：并发策略     "Allow" (允许，default):      "Forbid"(禁止): forbids；前个任务没执行完，要并发下一个的话，下一个会被跳过     "Replace"(替换): 新任务，替换当前运行的任务

   failedJobsHistoryLimit：记录失败数的上限，Defaults to 1.   successfulJobsHistoryLimit： 记录成功任务的上限。 Defaults to 3.   #指定了 CronJob 应该保留多少个 completed 和 failed 的 Job 记录。将其设置为 0，则 CronJob 不会保留已经结束的 Job 的记录。

   jobTemplate： job 怎么定义（与前面我们说的 job 一样定义法）

   schedule： cron 表达式；

   startingDeadlineSeconds： 表示如果 Job 因为某种原因无法按调度准时启动，在 spec.startingDeadlineSeconds 时间段之内，CronJob 仍然试图重新启动 Job，如果在.spec.startingDeadlineSeconds 时间之内没有启动成功，则不再试图重新启动。如果 spec.startingDeadlineSeconds 的值没有设置，则没有按时启动的任务不会被尝试重新启动。

   

   suspend    暂停定时任务，对已经执行了的任务，不会生效； Defaults to false.

apiVersion: batch/v1beta1kind: CronJobmetadata:  name: hellospec:  schedule: "*/1 * * * *"    #分、时、日、月、周  jobTemplate:    spec:      template:        spec:          containers:          - name: hello            image: busybox            args:            - /bin/sh            - -c            - date; echo Hello from the Kubernetes cluster          restartPolicy: OnFailure

六、GC

什么是垃圾回收

Kubernetes garbage collector（垃圾回收器）的作用是删除那些曾经有 owner，后来又不再有 owner 的对象。

垃圾收集器如何删除从属对象

当删除某个对象时，可以指定该对象的从属对象是否同时被自动删除，这种操作叫做级联删除（cascading deletion）。级联删除有两种模式：后台（background）和前台（foreground）

如果删除对象时不删除自动删除其从属对象，此时，从属对象被认为是孤儿（或孤立的 orphaned）

通过参数 --cascade，kubectl delete 命令也可以选择不同的级联删除策略：

• --cascade=true 级联删除

• --cascade=false 不级联删除 orphan

#删除rs，但不删除级联Podkubectl delete replicaset my-repset --cascade=false