批处理使命编列

初学者简单误以为容器的使命只在于部署行为－－将软件在容器中部署以供给继续的服务。但其实容器也相同许多的被应用于批处理程序的运转上。

比方测验行为是典型的批处理使命范畴， 它不供给继续安稳的服务， 它仅仅一段特定的程序，而一但这段测验程序完毕后就应该毁掉一切，包含履行环境和所占用的资源，容器比照于传统的虚拟机的优势也在于除了容器愈加的轻量级外， 容器的创立和毁掉都很便利，经过 K8S 的才能能够很便利的在需求时创立，完毕时毁掉回收资源以到达更好的资源利用率（就如上篇文章中介绍的 Jenkins 与 K8S 打通后的运作形式）。

而现在预备的测验事例会愈加特别， 它需求重复运转 N 次，因为本次履行的是安稳性测验（也有人叫它浸泡测验或者长时间高压测验），这种测验类型的特别之处就在于它的意图是验证被测系统在长时间的高压下是否仍能够供给安稳的服务。所以它的测验方法是长时间的（1 天，1 周甚至更长时刻）不间断的运转自动化测验。而自动化测验的数量是有限的，它不或许继续的运转那么长时刻，所以才需求重复运转。在不改造测验结构的前提下 K8S 能经过什么样的方法来协助完结这个测验需求。首先看一段 K8S 提交使命的装备文件。

yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: stable-test
spec:
  template:
    spec:
      containers:
        - name: stable
          image: registry.gaofei.com/stable_test
          imagePullPolicy: Always
          volumeMounts:
            - name: stableconfig
              mountPath: '/home/work/configs'
              readOnly: false
      restartPolicy: Never
      volumes:
        - name: 'stableconfig'
          configMap:
            name: stableconfig
  backoffLimit: 4
  parallelism: 1
  completions: 1000

上面定义的是向 K8S 提交一个 job 类型的也便是批处理程序恳求的装备文件， 将这个装备文件保存为 yaml 文件后就能够经过 kubectl 指令行将使命提交到 K8S 集群中运转了， job 会协助创立相应的 POD 来完结使命。虽然我已经对这段装备做了必定程度的删减，但仍然有不少的字段类型简单让新手眼花缭乱。不过本次事例只需重视几个要点的当地，第一个是在文件中的 template 字段， 它代表了 POD 的模板， job 经过此模板来动态的创立 POD，它定义了本次履行测验的运转环境， 也就是测验是在 POD 中的容器中履行的。K8S 会根据用户填写的内容来发动 POD。第二个需求注意的当地是装备中最下面的 3 个字段：

  • backoffLimit：可容忍的失利次数。安稳性测验是要长时间履行的，而任何长时间履行的使命都无法保证在运转过程中 100% 的不出问题，有些时分网络卡顿或者公司内的一些基础设施的暂时中止都或许形成测验的失利。所以 K8S 会在使命失利时测验进行重试（当整个节点出现异常时，K8S 能够将容器调度到其他节点上重试履行，具有更好的容错才能），而这个字段能够理解为重试的次数
  • parallelism：并行的数量。假如你的批处理使命需求并发才能，那么 K8S 会按照这个字段的数字一起发动多个容器来并发的履行。因为大部分的测验并发才能来源于测验结构而不是外部软件， 所以本次测验在这里填写为 1 就能够。
  • completions：使命成功履行 N 次后完毕使命。即便是像安稳性测验这种需求长时间运转的测验类型，它也有完毕测验的时分。所以把这个参数设定为 1000 代表当测验重复运转了 1000 次后就完毕本次的批处理使命。

注意：每次测验运转完毕后，K8S 会毁掉当前的容器，并发动一个一模一样的新容器来履行新的使命。也就是在的事例里假如不出意外的话，前后会发动 1000 个容器来完结本次的安稳性测验。经过这样一个事例的解说能够体会一下相比于原生的 Docker 容器，K8S 带来了多少额外的才能。在 K8S 中容器只不过是程序的运转时环境而已，除了程序能运转起来，K8S 更重视的是程序怎样更好的运转。

经过上面针对装备文件最后 3 个字段的解说能够看出来 K8S 在测验协助用户解决更杂乱的程序运转问题。在本事例中假如不运用 K8S，用户需求编写自己的模块来操控测验用例的重复履行，并发，容错和重试机制，也就是说用户需求自己编写代码来对测验用例进行＂编列＂。

在传统的容器场景中，许多人都会把容器作为一个小型的虚拟机来运用–只要程序能在容器里跑起来就能够了。这种形式并不具备＂编列＂的思维才能，真实的企业场景下要求的不仅仅是把程序跑起来就能够了，还关心容器调度到什么节点，什么时分触发和完毕使命，当使命出现异常时要怎么处理，容器和容器之前怎么合作以便完结更大的使命等等。这便是 K8S 供给的＂容器编列＂了。希望读者能够用心体会”容器编列”这 4 个字的含义。

接下来再看一下，假如希望使命能够守时触发该怎么办呢？K8S 中相同供给了 CronJob 类型的使命，能够看到在 schedule 字段中能够填写 cron 表达式来守时发动容器完结的批处理使命。

yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: k8scleaner
spec:
  schedule: '0 * */1 * *'
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: k8scleaner
              image: reg.gaofei.com/qa/k8s-cleaner:v2
              imagePullPolicy: Always
          restartPolicy: Never

实际上，现在看到的编列才能仍然是 K8S 的冰山一角，K8S 现在已经成为了分布式核算渠道，支撑许多大数据和机器学习的核算结构比方 Spark 和 Flink。下面是将 Spark 使命调度到 K8S 中履行的 Demo。

bash
./bin/spark-submit \
  --deploy-mode cluster \
  --class org.apache.spark.examples.SparkPi \
  --master k8s://https://172.27.130.144:6443 \
  --kubernetes-namespace spark-cluster \
  --conf spark.kubernetes.authenticate.driver.serviceAccountName=spark \
  --conf spark.executor.instances=5 \
  --conf spark.app.name=spark-pi \
  --conf spark.kubernetes.driver.docker.image=kubespark/spark-driver:v2.2.0-kubernetes-0.5.0 \
  --conf spark.kubernetes.executor.docker.image=kubespark/spark-executor:v2.2.0-kubernetes-0.5.0 \
local:///opt/spark/examples/jars/spark-examples_2.11-2.2.0-k8s-0.5.0.jar

了解大数据范畴的人都知道 Hadoop 是分布式核算范畴中最盛行的调度渠道。提交的 Spark 使命都会被调度到 Hadoop 集群中进行调度，运转。但是 K8S 也相同具备这样的才能，经过下载支撑 K8S 的 Spark 安装包就能够运用 spark-submit 指令将使命提交到 K8S 上以容器的形状履行，在参数中能够指定运用多少个 executor，每个 executor 申请多少资源等等。这便是 K8S 的魅力，假如你深入了解 K8S 会发现更多有趣又好用的功用。

总结

实际上除了上面讲的才能外，K8S 还包含了非常多的容器编列才能，尤其对于在线服务的编列才能上尤为强壮， 但这部分内容留待后续解说。最后附上一个最简单的 K8S 流程图协助我们理解。究竟 K8S 还是一个集群管理软件，上述说明的所有事例在提交给 K8S 后， K8S 都会按照自己的调度战略将 POD 调度到一个合适的节点上履行。

一文带你了解K8S 容器编排（下）

获取更多相关材料：

qrcode.ceba.ceshiren.com/link?name=a…