惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

G
Google Developers Blog
S
SegmentFault 最新的问题
Jina AI
Jina AI
D
DataBreaches.Net
人人都是产品经理
人人都是产品经理
罗磊的独立博客
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
爱范儿
爱范儿
大猫的无限游戏
大猫的无限游戏
C
Check Point Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
博客园 - 三生石上(FineUI控件)
B
Blog
博客园 - 【当耐特】
博客园 - Franky
M
MIT News - Artificial intelligence
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
L
LangChain Blog
MyScale Blog
MyScale Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
博客园 - 叶小钗
Last Week in AI
Last Week in AI
Engineering at Meta
Engineering at Meta

Mohuishou

如何实现支持多集群的 Kubernetes Operator? 第三方应用如何调用我们 kubebuilder 生成的自定义资源? Kubernetes 简明教程 k8s job 为何迟迟不能结束? Go 工程化(十一) 如何优雅的写出 repo 层代码 Go 工程化(十) 如何在整洁架构中使用事务? 给博客添加章节目录 使用 Notion Database 管理静态博客文章 一个普通 Go 开发的三年 4. localhost 就一定是 localhost 么? Go可用性(七) 总结: 一张图串联可用性知识点 Go可用性(六) 熔断 10. 总结 9. kubebuilder 进阶: 源码分析 8. kubebuilder 进阶: webhook 6. kubebuilder 实战: status & event 5. kubebuilder 实战: CRUD 4. kustomize 简明教程 3. KubeBuilder 简明教程 2. Kind: 如何快速搭建本地 K8s 开发环境? 1. Operator概述: 如何对 Kubernetes 进行扩展 Go可用性(五) 自适应限流 Go可用性(四) 漏桶算法 Go可用性(三) 令牌桶的实现 rate/limt Go可用性(二) 令牌桶原理及使用 Go可用性(一) 隔离设计 Go并发编程(十二) Singleflight Go工程化(九) 项目重构实践 Go工程化(八) 单元测试 Go工程化(七) Go Module
7. kubebuilder 进阶: 测试
Mohuishou · 2021-05-13 · via Mohuishou

注:本文已发布超过一年,请注意您所使用工具的相关版本是否适用

Operator 的测试是一个比较头疼的问题,在 kubernetes 资源是在不断变化的,并且想要在测试的时候跑一整套的 kubernetes 环境也不是一件容易的事情,今天我们大概看一下单元测试和集成测试怎么做。

单元测试

单元测试和 golang 的单元测试没有什么太大的区别,一般可以通过单元测试搞定的首先使用单元测试,因为单元测试写起来最容易,例如下面这一段对节点标签更新逻辑进行测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
func TestNodePoolSpec_ApplyNode(t *testing.T) {
type fields struct {
Taints []corev1.Taint
Labels map[string]string
Handler string
}
type args struct {
node v1.Node
}
tests := []struct {
name string
fields fields
args args
want *corev1.Node
}{
{
name: "label",
fields: fields{
Labels: map[string]string{
"node-pool.lailin.xyz/test": "",
},
},
args: args{
node: v1.Node{
ObjectMeta: metav1.ObjectMeta{
Name: "worker",
Labels: map[string]string{
"kubernetes.io/arch": "amd64",
"a": "b",
},
},
},
},
want: &v1.Node{
ObjectMeta: metav1.ObjectMeta{
Name: "worker",
Labels: map[string]string{
"kubernetes.io/arch": "amd64",
"node-pool.lailin.xyz/test": "",
},
},
},
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
s := &NodePoolSpec{
Taints: tt.fields.Taints,
Labels: tt.fields.Labels,
Handler: tt.fields.Handler,
}
assert.Equal(t, tt.want, s.ApplyNode(tt.args.node))
})
}
}

集成测试

controller-runtime 提供 envtest ,这个包可以帮助你为你在 etcd 和 Kubernetes API server 中设置并启动的 controllers 实例来写集成测试,不需要 kubelet,controller-manager 或者其他组件。

envtest

一个 envtest 的简单例子如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import sigs.k8s.io/controller-runtime/pkg/envtest

//指定 testEnv 配置
testEnv = &envtest.Environment{
CRDDirectoryPaths: []string{filepath.Join("..", "config", "crd", "bases")},
}

//启动 testEnv
cfg, err = testEnv.Start()

//编写测试逻辑

//停止 testEnv
err = testEnv.Stop()

envtest 在启动的时候需要设置一些环境变量来说明我们使用什么控制平面来进行测试

  • USE_EXISTING_CLUSTER表示使用一个已经存在的控制平面
  • KUBEBUILDER_ASSETS 本地控制平面二进制文件的文件夹路径,里面包含了 kubectl apiserveretcd
  • KUBEBUILDER_CONTROLPLANE_START_TIMEOUT控制平面启动的超时时间
  • KUBEBUILDER_CONTROLPLANE_STOP_TIMEOUT控制平面停止的超时时间

编写测试

kubebuilder 在生成代码的时候已经帮我们生成好了相关的脚手架,已经环境配置,我们只需要写具体的测试逻辑就行了

下面我们就以创建一个 NodePool 为例子看看集成测试怎么写

controllers/suite_test.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
var _ = Describe("node labels", func() {
pool := &nodesv1.NodePool{
ObjectMeta: metav1.ObjectMeta{
Name: "test",
},
Spec: nodesv1.NodePoolSpec{
Labels: map[string]string{
"node-pool.lailin.xyz/xxx": "",
},
Handler: "",
},
}

It("create pool", func() {
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
err := k8sClient.Create(ctx, pool)
Expect(err).NotTo(HaveOccurred())
})
})

使用 make test 执行测试

1
2
3
4
5
Using cached envtest tools from blog-code/k8s-operator/07-node-pool-operator/testbin
setting up env vars
? github.com/mohuishou/blog-code/k8s-operator/node-pool-operator [no test files]
ok github.com/mohuishou/blog-code/k8s-operator/node-pool-operator/api/v1 9.403s coverage: 24.5% of statements
ok github.com/mohuishou/blog-code/k8s-operator/node-pool-operator/controllers 10.390s coverage: 0.0% of statements

总结

今天这篇文章主要还是希望起一个抛砖引玉的作用,没有过多的去深入具体改如何写单元测试和集成测试,只是给了两个例子,关于集成测试如果感兴趣可以看看 https://onsi.github.io/ginkgoenvtest 的相关文档。

对于 Operator 来说建议能写单元测试的还是写单元测试,能够本地写集成测试的就写集成测试这样我们在实际上线的时候就会减少 bug 的概率,因为相对于业务代码来说 Operator 的测试实在是比较麻烦,对于测试同学的要求也比较高,一不小心就有可能遗漏一些问题。

下一篇我们来看看准入控制如何实现

关注我获取更新

猜你喜欢