关于软件测试:一文带你了解K8S-容器编排下

1次阅读

共计 3362 个字符，预计需要花费 9 分钟才能阅读完成。

批处理工作编排
初学者容易误以为容器的工作只在于部署行为--将软件在容器中部署以提供继续的服务。但其实容器也同样大量的被利用于批处理程序的运行上。比方测试行为是典型的批处理工作领域，它不提供继续稳固的服务，它只是一段特定的程序，而一但这段测试程序完结后就应该销毁所有，包含执行环境和所占用的资源，容器比照于传统的虚拟机的劣势也在于除了容器更加的轻量级外，容器的创立和销毁都很不便，通过 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 调度到一个适合的节点上执行。

正文完