前言​

Kubernetes的成功少不了大量工程师的共同参与，而他们之间如何高效的协作，非常值得我们探究。最近研究和使用了他们的e2e测试和框架，还是挺有启发的。

怎样才是好的e2e测试？​

不同的人写出的测试用例千差万别，尤其在用例，可能由开发人员编写的情形下，其情形可想而知。要知道，绝大多数开发人员，可能并没有经历过大量测试用例场景的熏陶。所以如何持续输出高质量的e2e测试用例，确实是一个挑战。不过，Kubernetes社区非常聪明，他们抽象出来了一些共性的东西，来希望大家遵守。比如说

1. 拒绝“flaky”测试 - 也就是那些偶尔会失败，但是又非常难定位的问题。
2. 错误输出要详细，尤其是做断言时，相关信息要有。不过也不要打印太多无效信息，尤其是在case并未失败的情况。
3. make case run in anywhere。这一点很重要，因为你的case是提交到社区，可能在各种环境下，各种时间段内运行。面对着各种cloud provider，各种系统负载情况。所以你的case要尽可能稳定，比如APICall，能异步的，就不要假设是同步; 比如多用retry机制等。
4. 测试用例要执行的足够快。超过两分钟，就需要给这种测试打上[SLOW]标签。而有这种标签的测试用例，可以运行的场景就比较有限制了。谁又不希望自己写的用例都被尽可能的执行呢？很有激励性的一条规则。

另外，社区不过定下规则，还开发和维护了一系列的基础设施，来辅助上面规则的落地。我们接下来要讲的e2e框架就是其中之一。

e2e 验收测试​

搞过测试的应该都知道，在面对复杂系统测试时，我们通常有多套测试环境，但是测试代码通常只有一份。所以为了能更好的区分测试用例，通常采取打标签的方式来给用例分类。这在Kubernetes的e2e里，这也不例外。

Kubernetes默认将测试用例分为下面几类，需要开发者在实际开发用例时，合适的使用。

• 没标签的，默认测试用例是稳定的，支持并发，且运行足够快的
• [Slow] 执行比较慢的用例.(对于具体的时间阈值，Kubernetes不同的文档表示不一致，此处需要修复)
• [Serial] 不支持并发的测试用例，比如占用太多资源，还比如需要重启Node的
• [Disruptive] 会导致其他测试用例失败或者具有破坏性的测试用例
• [Flaky] 不稳定的用例，且很难修复。使用它要非常慎重，因为常规CI jobs并不会运行这些测试用例
• [Feature:.+] 围绕特定非默认Kubernetes集群功能或者非核心功能的测试用例，方便开发以及专项功能适配

当然除了以上标签，还有个比较重要的标签就是[Conformance], 此标签用于验收Kubernetes集群最小功能集，也就是我们常说的MAT测试。所以如果你有个私有部署的k8s集群，就可以通过这套用例来搞验收。方法也很简单，通过下面几步就可以执行：

# under kubernetes folder, compile test cases and ginkgo tool
make WHAT=test/e2e/e2e.test && make ginkgo

# setup for conformance tests
export KUBECONFIG=/path/to/kubeconfig
export KUBERNETES_CONFORMANCE_TEST=y
export KUBERNETES_PROVIDER=skeleton

# run all conformance tests
go run hack/e2e.go -v --test --test_args="--ginkgo.focus=\[Conformance\]"

注意，kubernetes的测试使用的镜像都放在GCR上了，如果你的集群在国内，且还不带翻墙功能，那可能会发现pod会因为下载不了镜像而启动失败。

Kubernetes e2e test framework​

研究Kubernetes的e2e测试框架,然后类比我们以往的经验，个人觉得，下面几点特性还是值得借鉴的:

All e2e compiled into one binary, 单一独立二进制​

在对服务端程序进行API测试时，我们经常会针对每个服务都创建一个ginkgo suite来框定测试用例的范围，这样做的好处是用例目标非常清晰，但是随着服务数量的增多，这样的suite会越来越来多。从组织上，看起来就稍显杂乱，而且不利于测试服务的输出。

比如，我们考虑这么一个场景，QA需要对新机房部署，或者私有机房进行服务验证。这时候，就通常需要copy所有代码到指定集群在运行了，非常的不方便，而且也容易造成代码泄露。

kubernetes显然也会有这个需求，所以他们改变写法，将所有的测试用例都编译进一个e2e.test的二进制，这样针对上面场景时，就可以直接使用这个可执行文件来操作，非常的方便。

当然可执行文件的方便少不了外部参数的自由注入，以及整体测试用例的精心标记。否则，测试代码写的不规范，需要频繁的针对特定环境修改，也是拒不方便的。

Each case has a uniqe namespace, 每个case拥有唯一的空间​

为每条测试用例创建一个独立的空间，是kubernetes e2e framework的一大精华。每条测试用例独享一个空间，彼此不冲突，从而根本上避免并发困扰，借助ginkgo的CLI来运行，会极大的提高执行效率。

而且这处代码的方式也非常优美，很有借鉴价值:

func NewFramework(baseName string, options FrameworkOptions, client clientset.Interface) *Framework {
   f := &Framework{
      BaseName:                 baseName,
      AddonResourceConstraints: make(map[string]ResourceConstraint),
      Options:                  options,
      ClientSet:                client,
   }

   BeforeEach(f.BeforeEach)
   AfterEach(f.AfterEach)

   return f
}

利用ginkgo 的BeforeEach的嵌套特定，虽然在Describe下就定义framework的初始化(如下)，但是在每个It执行前，上面的BeforeEach才会真正执行，所以并不会有冲突:

var _ = framework.KubeDescribe("GKE local SSD [Feature:GKELocalSSD]", func() {
   f := framework.NewDefaultFramework("localssd")
   It("should write and read from node local SSD [Feature:GKELocalSSD]", func() {
   ...
   })
})

当然e2e框架还负责case执行完的环境清理，并且是按需灵活配置。比如你希望，case失败保留现场,不删除namespace，那么就可以设置flag 参数 delete-namespace-on-failure为false来实现。

Asynchronous wait，异步等待​

几乎所有的Kubernetes操作都是异步的，所以不管是产品代码还是测试用例，都广泛的使用了这个异步等待库：kubernetes/vendor/k8s.io/apimachinery/pkg/util/wait。这个库，实现简单，精悍，非常值得学习。

另外，针对测试的异步验证，其实ginkgo(gomega)本身提供的Eventualy，也是非常好用的。

Suitable logs，打印合适的log​

Kubernetes e2e 主要使用两种方式输出log，一个是使用glog库，另一个则是framework.Logf方法。glog本身是golang官方提供的log库，使用比较灵活。但是这里主要推荐的还是Framework.Logf。因为使用此方法的log会输出到GinkgoWriter里面，这样当我们使用ginkgo.RunSpecsWithDefaultAndCustomReporters方法时，log不光输出到控制台，也会保存在junit格式的xml文件里，非常方便在jenkins里展示测试结果。

Clean code, 测试代码也可以很干净，优美​

很多时候大家会觉得测试代码比较low，其实却不然。代码无所谓优劣，好坏还是依赖写代码的人。而且我想说，测试代码也是可以，并且应该写的很优美的，不然如何提升逼格？!。

我们从Kubernetes e2e能看到很多好的借鉴，比如：

• 抽取主干方法，以突出测试用例主体
• 采用数据驱动方式书写共性测试用例
• 注释工整，多少适宜
• 不输出低级别log
• 代码行长短适宜
• 方法名定义清晰，可读性强

Kubernetes环境普适性的e2e测试框架​

现实中，如果需要围绕k8s工作，你可能需要一套，自己的测试框架。不管是测试各种自定义的controller or watcher，还是测试运行在k8s里运行的私有服务。这套框架都适用于你:

https://github.com/CarlJi/golearn/tree/master/src/carlji.com/experiments/k8s_e2e_mat_framework

逻辑改动很小，只是在原有kubernetes e2e 框架基础上抽取了最小集合。以方便快速使用。

是不是很贴心？

前言​

并发编程一直是Golang区别与其他语言的很大优势，也是实际工作场景中经常遇到的。近日笔者在组内分享了我们常见的并发场景，及代码示例，以期望大家能在遇到相同场景下，能快速的想到解决方案，或者是拿这些方案与自己实现的比较，取长补短。现整理出来与大家共享。

简单并发场景​

很多时候，我们只想并发的做一件事情，比如测试某个接口的是否支持并发。那么我们就可以这么做：

func RunScenario1() {
       count := 10
       var wg sync.WaitGroup

       for i := 0; i < count; i++ {
              wg.Add(1)
              go func(index int) {
                     defer wg.Done()
                     doSomething(index)
              }(i)
       }

       wg.Wait()
}

使用goroutine来实现异步，使用WaitGroup来等待所有goroutine结束。这里要注意的是要正确释放WaitGroup的counter(在goroutine里调用Done()方法)。

但此种方式有个弊端，就是当goroutine的量过多时，很容易消耗完客户端的资源，导致程序表现不佳。

规定时间内的持续并发模型​

我们仍然以测试某个后端API接口为例，如果我们想知道这个接口在持续高并发情况下是否有句柄泄露，这种情况该如何测试呢？

这种时候，我们需要能控制时间的高并发模型：

func RunScenario2() {
	timeout := time.Now().Add(time.Second * time.Duration(10))
	n := runtime.NumCPU()

	waitForAll := make(chan struct{})
	done := make(chan struct{})
	concurrentCount := make(chan struct{}, n)

	for i := 0; i < n; i++ {
		concurrentCount <- struct{}{}
	}

	go func() {
		for time.Now().Before(timeout) {
			<-done
			concurrentCount <- struct{}{}
		}

		waitForAll <- struct{}{}
	}()

	go func() {
		for {
			<-concurrentCount
			go func() {
				doSomething(rand.Intn(n))
				done <- struct{}{}
			}()
		}
	}()

	<-waitForAll
}

上面的代码里，我们通过一个buffered channel来控制并发的数量(concurrentCount)，然后另起一个channel来周期性的发起新的任务，而控制的条件就是 time.Now().Before(timeout)，这样当超过规定的时间，waitForAll 就会得到信号，而使整个程序退出。

这是一种实现方式，那么还有其他的方式没？我们接着往下看。

基于大数据量的并发模型​

前面说的基于时间的并发模型，那如果只知道数据量很大，但是具体结束时间不确定，该怎么办呢？

比如，客户给了个几TB的文件列表，要求把这些文件从存储里删除。再比如，实现个爬虫去爬某些网站的所有内容。

而解决此类问题，最常见的就是使用工作池模式了(Worker Pool)。以删文件为例，我们可以简单这样来处理：

• Jobs - 可以从文件列表里读取文件，初始化为任务，然后发给worker
• Worker - 拿到任务开始做事
• Collector - 收集worker处理后的结果
• Worker Pool - 控制并发的数量

虽然这只是个简单Worker Pool模型，但已经能满足我们的需求：

func RunScenario3() {
       numOfConcurrency := runtime.NumCPU()
       taskTool := 10
       jobs := make(chan int, taskTool)
       results := make(chan int, taskTool)
       var wg sync.WaitGroup

       // workExample
       workExampleFunc := func(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {
              defer wg.Done()
              for job := range jobs {
                     res := job * 2
                     fmt.Printf("Worker %d do things, produce result %d \n", id, res)
                     time.Sleep(time.Millisecond * time.Duration(100))
                     results <- res
              }
       }

       for i := 0; i < numOfConcurrency; i++ {
              wg.Add(1)
              go workExampleFunc(i, jobs, results, &wg)
       }

       totalTasks := 100  // 本例就要从文件列表里读取

       wg.Add(1)
       go func() {
              defer wg.Done()
              for i := 0; i < totalTasks; i++ {
                     n := <-results
                     fmt.Printf("Got results %d \n", n)
              }
              close(results)
       }()

       for i := 0; i < totalTasks; i++ {
              jobs <- i
       }
       close(jobs)
       wg.Wait()
}

在Go里，分发任务，收集结果，我们可以都交给Channel来实现。从实现上更加的简洁。

仔细看会发现，本模型也是适用于按时间来控制并发。只要把totalTask的遍历换成时间控制就好了。

等待异步任务执行结果​

goroutine和channel的组合在实际编程时经常会用到，而加上Select更是无往而不利。

func RunScenario4() {
       sth := make(chan string)
       result := make(chan string)
       go func() {
              id := rand.Intn(100)
              for {
                     sth <- doSomething(id)
              }
       }()
       go func() {
              for {
                     result <- takeSomthing(<-sth)
              }
       }()

       select {
       case c := <-result:
              fmt.Printf("Got result %s ", c)
       case <-time.After(time.Duration(30 * time.Second)):
              fmt.Errorf("指定时间内都没有得到结果")
       }
}

在select的case情况，加上time.After()模型可以让我们在一定时间范围内等待异步任务结果，防止程序卡死。

定时反馈异步任务结果​

上面我们说到持续的压测某后端API，但并未实时收集结果。而很多时候对于性能测试场景，实时的统计吞吐率，成功率是非常有必要的。

func RunScenario5() {
	concurrencyCount := runtime.NumCPU()
	for i := 0; i < concurrencyCount; i++ {
		go func(index int) {
			for {
				doUploadMock()
			}
		}(i)
	}

	t := time.NewTicker(time.Second)
	for {
		select {
		case <-t.C:
			// 计算并打印实时数据
		}
	} 
}

这种场景就需要使用到Ticker，且上面的Example模型还能控制并发数量，也是非常实用的方式。

知识点总结​

上面我们共提到了五种并发模式：

• 简单并发模型
• 规定时间内的持续并发模型
• 基于大数据量的持续并发模型
• 等待异步任务结果模型
• 定时反馈异步任务结果模型

归纳下来其核心就是使用了Go的几个知识点：Goroutine, Channel, Select, Time, Timer/Ticker, WaitGroup. 若是对这些不清楚，可以自行Google之。

另完整的Example 代码可以参考这里：https://github.com/jichangjun/golearn/blob/master/src/carlji.com/experiments/concurrency/main.go

使用方式： go run main.go <场景>

比如 :

参考文档​

• https://github.com/golang/go/wiki/LearnConcurrency

这篇是Google官方推荐学习Go并发的资料，从初学者到进阶，内容非常丰富，且权威。