我来了~~ 我回答一下楼主：

关于第一个问题

其实不管是 K8S 还是其他技术， 这些技术对于测试的主要意义在于产品是否用到了这些技术，产品用到了这些技术那么就需要去学习它，熟悉它，这样才能设计出更完善的测试场景，才能执行相关的测试方案。如果测试人员希望能够测试的更加深入，那么就需要学习产品中使用到的主要技术栈，这是通往高阶测试职位的必经之路。 尤其对于 K8S 这种基础的底座平台，如果对它完全不了解， 那么在产品出现什么问题的时候， 测试人员连日志都不懂得要怎么看， 这就是非常尴尬的。 当然如果是外包同学，我们对他们的要求就是在 UI 上点点点就可以了，出了任何问题都直接扔给研发。如果是这样的话，是不用学 K8S 的。

我再举几个测试需要用到 k8s 的例子，通常在 k8s 场景中会有一些比较独特的测试类型：

• 容量测试（性能测试的一个分支），这跟 k8s 的资源模型有关系（limit 和 request），需要熟悉 k8s 在资源上面的设计和相关的监控手段。如果出现过度超卖要怎么办，软驱逐和硬驱逐应该怎么设置是合理的，评估容器的内存使用应该用 RSS 还是 working set。
• 混沌工程：如何在 k8s 环境中注入故障是一个需要研究的方法（当然现在有 chaos-mesh 这样的开源工具了）， k8s 在高可用上是如何设计的，业务应该如何配合 k8s 的特性完善自己的高可用场景，如果业务没有配合 k8s 会的高可用设计会发生什么行为， 应该向哪里注入故障，注入故障后又应该预期发生什么样的容灾行为。 这些也是要去了解后才能测试的。
• 稳定性测试：在不注入故障的前提下，长期运行自动化测试或性能测试，验证系统会不会稳定性运行。 这个测试方法和普通的场景是一样的。只是在 k8s 中常规监控工具无法满足这种测试类型的需要，需要根据 k8s 的 ListAndWatch 机制开发相关的监控工具。
• 云原生的测试：一般产品上了 k8s 就是云原生架构，那么 k8s 的一些特性可能会进入到产品里，比如云计算，边缘计算，AI 等等。

除了上述的测试类型， 我们也需要依赖 k8s 的特性开发一些测试工具，比如我之前写过的 mock server，故障注入工具，监控工具等等。 为了更形象说明一下， 我这里分享一个我在测试中发现的bug 总结

首先说一下 k8s 和 linux 在内存上的策略：

为了确保节点的可用性，不至于让用户进程把所有内存吃光。在每个 k8s 的节点上都会有 3 层内存回收机制的保障：

• K8S 驱逐策略: 由每台机器上的 kubelet 进程控制，用户可以根据自己的需要配置驱逐策略的阈值。当节点内存达到一定用量时，就会触发驱逐策略，按一定的优先级开始把 Pod 驱逐到其他节点上，这样可以保证节点不至于因为内存吃满而瘫痪，也可以保证系统的核心服务依然正常工作。

• Linux 内存回收：分为异步的 kswapd 和阻塞的 direct reclaim，当驱逐策略没有生效时，系统内存到达一定的阈值后，会开始触发 Linux 自己的内存回收策略。

• OOM Killer：当 Linux 内存回收的资源也无法满足进程需要时，就会触发 Linux 的 OOM Killer， Linux 也会给每个进程计算一个 oom score 来划分优先级。当内存不足时，就会强行杀死进程来释放内存。

Bug：产品服务没有设置合理的优先级

K8S 的 Pod 优先级策略

根据 CAP 和 BASE 理论， 当系统出现故障或者资源吃紧或者压力过高时，如果无法保证系统完全不受影响，那么可以牺牲部分非核心服务或者用户的可用性，来保证核心能力的可用，这也是架构设计中熔断和降级策略的来源。而 K8S 的驱逐策略就是这样的设计理念，当业务高峰期来临， 导致节点资源不足时， 为了保证核心模块的可用性，会把低优先级的服务驱逐到其他节点上释放资源。 而 K8S 在触发驱逐策略时，为了保证驱逐的是低优先级的服务，在 K8S 中专门设置了两种策略来让用户设置优先级。 这样驱逐策略才能保证按优先级进行驱逐。这两种优先级策略分别是由资源配额和抢占优先级两种配置来决定的。

资源配额的优先级

K8S 会按照资源参数 reqeust 和 limit 的设置把 Pod 分为三类优先级：

• Guaranteed(有保证的)：

  • Pod 中的每个容器都必须设置 CPU 和内存的 reqeust 以及 limit。
  • Pod 中每个容器的 CPU 和内存必须设置相同的 reqeust 和 limit。

• Burstable(不稳定的)：

  • Pod 不符合 Guaranteed 的标准。
  • Pod 中至少一个容器设置了内存/CPU 的 limit 或 request。

• Best-Effort(尽最大努力)：

  • Pod 中的容器没有设置内存/CPU 的 request 或 limit。

从这些定义就可以知道它们的优先级了，当驱逐策略触发时，k8s 会最先驱逐 Best-Effort 类型的 Pod，如果释放的资源仍然不足以满足要求，会开始驱逐 Burstable 类型的 Pod，最后是 Guaranteed 类型。

抢占优先级

除了通过资源配额推理出优先级外， k8s 也准许用户手动为 pod 设置优先级。在 Pod 中有一个字段叫 priorityClassName 专门负责此事。 用户可以定义名为 PriorityClass 的对象，事先约定更好一组优先级。比如：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "此优先级类应仅用于 XYZ 服务 Pod。"

bug 出现的原因

产品设计上并没有给服务设置合理的优先级， 导致在驱逐策略发生时，核心服务被驱逐掉导致产品在一段时间内不可用。

总结

所以要测试出这样的 bug， 前提就是需要把高可用设计原则（知道原则你才知道什么样的行为才是正确的，高可用没有需求文档，全靠测试人员和开发人员对高可用的理解）和 k8s 中的驱逐和优先级机制了解的门清才可以。 所以同学们想要有能力分析出这种 bug 么，想要拿金 bug 奖么， 那就更深入的学习吧。

关于第二个问题

K8S 要掌握到什么程度， 这当然是越深越好。 不过人的精力有限， 所以我的建议是如果不是专攻云原生方向的，那就把 K8S 的普通特性学习好就可以了。 就按自己可以在 k8s 中从 0 到 1 的部署一个高可用版本的服务为基准，自己来这么一遍就差不多把大多数常用的特性学的差不多了， 也可以在出问题的时候知道怎么查看日志和其他信息。 而如果是专攻这个方向或者有意深入了解 k8s 的， 还需要懂得 k8s 内的机制：比如 listandwatch，比如 operator，比如各种更复杂的内部机制，需要懂得根据 k8s 的 api 开发工具，总之学的越深越好。

关于第三个问题

• 极客时间上 k8s 的课程
• 我写过一本书《云原生测试实战》PS：我再一次无耻的推销一下自己的书