背景

自己对于密码技术相关的知识一直都是零散的，刚接触 k8s 的时候遇到了好多证书问题都是靠临时搜索解决的，不成体系。

liqiang 同学推荐了《图解密码技术》，趁着中秋假期看完了做了读书笔记，记录一下。

密码

环游密码世界

口令：password, passcode, pin
编码：encode
密码：cryptography

对称密码是指在加密和解密时使用同一密钥的方式。

公钥密码是指在加密和解密时使用不同密钥的方式，又称为非对称加密。

将对称密码和公钥密码结合起来的密码方式称为混合密码系统。

单项散列函数，用于保证完整性：“数据时正确的而不是伪造的”，没有被篡改过。

数字签名能够保证数据不会被篡改，也防止发送者的否认。

伪随机数生成器是一种能够模拟产生随机数列的算法，同时承担着密钥生成的重要职责。

隐写术隐藏的是消息本身，而密码隐藏的是内容，应用场景：数字水印。

密码与信息安全常识：

1. 不要使用保密的密码算法
2. 使用低强度的密码比不进行任何加密更危险
3. 任何密码总有一天都会被破解
4. 密码只是信息安全的一部分

历史上的密码

凯撒密码，通过平移字母顺序达到加密效果，平移字母个数为密钥。
简单替换密码，通过维护字母对照表达到加密效果。

密钥空间，所有可用密钥的总数就是密钥空间的大小，空间越大，暴力破解越困难。

频率分析破译：通过分析语言中高频使用字母及单词达到破译效果。

Enigma ：通过增加通信密码的方式保证安全性。
问题：

1. 通信密码连续输入2词并加密
2. 通信密码是认为设定的
3. 必须有每日密码本

对称密码

将显示世界中的东西映射为比特序列的操作称为编码。

XOR，异或，相同为0 ，不同为1。

比特序列的异或，将明文 A 用密钥 B 进行加密，得到密文 A XOR B，将密文 A XOR B 用密钥 B 进行解密，得到明文 A。

一次性密码本，又称为维纳没密码，通过生成随机比特序列与明文异或加密。

理论上无法破解的原因：无法判断暴力破解的结果是否是争取的明文。
无法使用的原因：

1. 密钥的发送
2. 密钥的保存，密钥长度与明文长度相等。
3. 密钥的重用
4. 密钥的同步
5. 密钥的生成，需要真正的随机数

DES（Data Encryption Standard），可被短时间破译，不推荐使用。

DES 将64 比特的明文加密成64比特的密文，密钥长度是56比特，从规格上说，DES 的密钥长度是64 比特，但由于每隔7 比特会设置一个用于错误校验的比特，因此实质上密钥长度是56比特。

DES 以每 64 比特的明文为最小单位进行加密，属于分组密钥的一种。

DES 结构，又称为 Feistel 网络，在很多密码算法中都有应用。

加密步骤：

1. 将输入的数据等分为左右两部分
2. 将输入的右侧直接发送到输出的右侧
3. 将输入的右侧发送到轮函数
4. 轮函数根据右侧数据和子密钥，计算出一串看上去是随机的比特序列
5. 将上一步得到的比特序列与左侧数据进行 XOR 运算，并将结果作为加密后的左侧
6. 因为上述使用将右侧数据作为密钥的一部分，因此需要指定规则（如每两轮）对输入数据的左右进行数据对调

DES 加密时无论使用任何函数作为轮函数都可以正确解密，也就是说，轮函数无需考虑解密的问题，可以被设计的任意复杂。

三重 DES，为了增加 DES 的强度，将DES 重复3次所得到的一种密码算法。

加密过程为：加密，解密，加密，这么做的目的是为了能够让三重DES 兼容普通的 DES。

AES（Advanced Encryption Standard）取代DES。通过评选，最终选择 Rijndael。

Rijndael 分组成都为 128 比特，密钥长度可以以32比特为单位在128 比特到256 比特的范围内进行选择，在AES 规格中，密钥长度只有 128，192，256 比特三种。

AES 使用 SPN 结构。
加密过程：

1. SubBytes 处理，输入分组为 128 比特，16 字节，首先逐个字节的对16字节的输入数据进行SubBytes 处理，可以简单的理解为“简单替换密码” 中的 256 个字母的版本
2. ShiftRows 处理，将 SubBytes 的输出以字节为单位进行打乱处理，注意，打乱处理是有规律的
3. MixColumns 处理，对一个4字节的值进行比特运算，将其变为另一个4字节的值
4. AddRoundKey 处理，将 MixColumns 的输出与轮密钥进行XOR
5. 重复上述4步，需要重复 10 - 14 轮计算。

相比 Feistel 网络，SPN 优势：

• 加密锁需要的轮数更少
• 所有处理均按照字节为单位进行，速度更快

劣势：

• 无法使用同一种结构实现加密和解密

分组密码的模式

分组密码是每次只能处理特定长度的一块数据的一类密码算法，一个分组的比特书就称为分组长度。

例如 DES 和三重 DES 的分组长度都是 64 比特，也就是会所一次只能加密64 比特的明文，并生成64 比特的密文。

当对一段很长的明文进行加密时，的呆的方法就称为分组密钥的模式。
主要模式有以下5种：

• ECB 模式，电子密码本模式
• CBC 模式，密码分组链接模式
• CFB 模式，密文反馈模式
• OFB 模式，输出反馈模式
• CTR 模式，计数器模式

ECB 模式，将明文分组加密之后的结果直接称为密文分组，若分组内容小于分组长度时，则自动向上填充。

弱点：可以在步破译密文的情况下操纵明文。

CBC 模式，首先将明文分组与前一个密文分组进行 XOR 运算，然后再进行加密。

CFB 模式，前一个密文分组会被送回到密码算法的输入端，即初始化向量通过加密算法与明文分组进行异或运算，得到密文分组。

OFB 模式，密码算法的输出会反馈到密码算法的输入中，通过将明文分组和密码算法的输出进行异或运算来产生密文分组。

CTR 模式，通过将逐次累加的计数器进行加密来生成密钥流的流密码。每个分组对应一个逐次累加的计数器，并通过对计数器进行加密来生成密钥流，也就是说，最终的密钥分组时通过将计数器加密得到的比特序列与明文分组进行异或运算得到的。

公钥密码

公钥密码是密码学历史上最伟大的发明，是数学史上最伟大的发现。

公钥密码解决的问题：密钥发送。

在公钥密码中，密钥氛围加密密钥和解密密钥两种，发送者用加密密钥对消息进行加密，接收者用解密密钥对密文进行解密。

注意：

1. 发送者只需要加密密钥
2. 接收者值需要解密密钥
3. 解密密钥步可以被窃听者窃取
4. 加密密钥被窃听者获取也没问题

RSA 是一种公钥密码算法，被用于公钥密码和数字签名。
加密公式：对代表明文的数字的 E 次方球 mod N 的结果，结果就是密文。其中 E 和 N 是 RSA 加密的密钥，也就是E 和 N 的组合就是公钥。

解密公式：对代表密文的数字的 D 次方球 mod N 就可以得到明文，其中 N 与加密算法中的N 是相同的。

生成密钥对流程：

1. 求 N
   1. 准备两个很大的质数，假设为 p 和 q，并将其相乘，结果为 N
2. 求 L
   1. L 是 p-1 和 q-1 的最小公倍数
3. 求 E
   1. E 是一个比 1 大，比 L 小的数，E 和 L 的最大公约数必须为 1
4. 求 D
   1. 1 < D < L
   2. E * D mod L = 1

混合密码系统

公钥密码劣势：

1. 公钥密钥处理速度远远低于对称密码
2. 公钥密码难以抵御中间人攻击

混合密码主要解决上述问题 1。有以下机制：

1. 用对称密码加密消息
2. 通过伪随机数生成器生成对称密码加密中使用的会话密钥
3. 用公钥密码加密会话密钥
4. 从混合密码系统外部赋予公钥密码加密时使用的密钥

认证

单向散列函数

单向散列函数有一个输入和一个输出，输入称为消息，输出称为散列值，函数可以根据消息的内容计算出散列值，可以根据散列值来检查消息的完整性。

特性：

1. 根据任意长度的消息计算出固定长度的散列值
2. 能够快速计算出散列值
3. 消息不同散列值也不同
4. 具备单向性

实际应用：

1. 检测软件是否被篡改
2. 基于口令的加密
3. 消息认证码
4. 数字签名
5. 伪随机数生成器
6. 一次性口令

具体例子：

1. MD4，MD5
2. SHA-1，SHA-256，SHA-384，SHA-512
3. RIPEMD-160
4. AHS，SHA-3

单向散列函数能够辨别出篡改，但是无法辨别出伪装。当我们想要确定文件的所有者时谁，需要进行认证。用于认证的技术包括消息验证码和数字签名。消息认证码能够想通信对象保证消息没有被篡改，而数字签名不仅能够向通信对象保证消息没有被篡改，还能够向所有第三方作出这样的保证。

消息认证码

在消息传递时，需要关注完整性和认证两个性质。

消息认证码是一种确认完整性并进行认证的技术，简称 MAC。消息认证码的输入包括任意长度的消息和一个发送者与接收者之间共享的密钥，它可以输出固定长度的数据，这个数据称为 MAC 值。简单理解：消息认证码是一种与密钥相关联的单向散列函数。

无法解决的问题：

1. 对第三方证明
2. 防止否认

数字签名

为什么要使用数字签名：

• 消息认证码的局限性
• 消息认证码无法防止否认，发送者与接收者共享同一个密钥，对第三方来说，无法确认消息是谁发送的

签名的生成和验证

• 生成消息签名的行为
  • 由消息的发送者完成，意味着“发送者认可该消息的内容”
  • 发送者使用签名密钥生成消息的签名
  • 签名密钥只能由签名人持有
• 验证消息签名的行为
  • 一般由消息的接收者完成，也可以由需要验证消息的第三方来完成
  • 接收者使用验证密钥进行密钥的验证
  • 验证密钥无法生成签名
  • 验证密钥可以是任何由需要验证签名的人持有

公钥密钥使用公钥加密，使用私钥解密；

数字签名使用私钥签发，使用公钥验证。

缺点：

• 无法判断公钥是否属于签发者

证书

公钥证书与驾照类似，记录着姓名、组织、邮箱地址等个人信息以及属于此人的公钥，并由认证机构施加数字签名，公钥证书简称证书。

典型使用流程：

1. 接收者生成密钥对
2. 接收者在认证结构 Trent 注册自己的公钥
3. 认证结构 Trent 用自己的私钥对 Bob 的公钥施加数字签名并生成证书
4. 发送者得到带有认证机构 Trent 的数字签名的接收者的公钥（证书）
5. 发送者使用认证机构 Trent 的公钥验证数字签名，确认接收者公钥的合法性
6. 发送者使用接收者的公钥加密消息并发送到接收者
7. 接收者使用自己的私钥解密密文得到发送者的消息

公钥基础设施是为了能够更有效的运用公钥而指定的一系列规范和规格的总称，简称 PKI。

组成要素：

1. 用户—使用 PKI 的人
2. 认证机构—颁发证书的人
3. 仓库—保存证书的数据库

密钥、随机数与应用技术

密钥

密钥就是一个巨大的数字，数字本身不重要，重要的是密钥空间的大小，空间越大，暴力破解就越困难，空间的大小是由密钥长度决定的。

密钥与明文是等价的，明文的价值就是密钥的价值。

密钥的用途：

• 在对称密码中，由于发送者和接收者之间需要共享密钥，因此对称密钥又称为共享密钥密码。
• 在公钥密码中，加密和解密使用的是不同的密钥，加密的是公钥，解密的是私钥，私钥也称为私密密钥，公钥与私钥也称为密钥对。
• 对称密码和公钥密钥的密钥都是用于确保机密性的密钥，相对的，消息认证码和数字签名所使用的密钥，则是用于认证的密钥。

密钥的管理：

• 生成密钥
  • 用随机数生成密钥
  • 用口令生成密钥
• 配送密钥
  • 事先共享密钥
  • 使用公钥密码
  • Diffie-Hellman 密钥交换
• 更新密钥
  • 用当前密钥的散列值作为下一个密钥
• 保存密钥
  • 人类无法记住密钥
  • 保存在保险柜等安全的地方
  • 将密钥加密后保存
  • 减少需要保管的密钥数量
• 作废密钥
  • 删除密钥的同时，需要将对应的加密后文件一同删除

如何生成安全的口令

• 使用只有自己才能知道的信息
  • 不要使用对自己重要的事物的名字
  • 不要使用关于自己的信息
  • 不要使用别人见过的信息
• 将多个不同的口令分开使用
• 有效利用笔记
• 理解口令的局限性

随机数

为了不让攻击者看穿而使用随机数。

应用场景：

• 生成密钥
  • 用于对称密码和消息认证码
• 生成密钥对
  • 用于公钥密码和数字签名
• 生成初始化向量
  • 用于分组密码的 CBC、CFB、OFB 模式
• 生成 nonce
  • 用于防御重放攻击以及分组密码的 CTR 模式等
• 生成盐
  • 用于基于口令的密码等

随机数的性质：

• 随机性—不存在统计学偏差，完全杂乱的数列
• 不可预测行—不能从过去的数列推测出下一个出现的数
• 不可重现性—除非将数列本身保存下来，否则不能重现相同的数列

PGP

PGP（Pretty Good Privary）是一款密码软件，支持多平台。

功能列表：

1. 对称密码
2. 公钥密码
3. 数字签名
4. 单向散列函数
5. 证书
6. 压缩
7. 文本数据
8. 大文件的拆分和拼合
9. 钥匙串管理

加密流程：

解密流程：

SSL/TLS

SSL(Secure Socket Layer)
TLS(Transport Layer Security)

当 Web 浏览器发送请求时，请求的数据会作为客户端请求发送给服务器，如果通信内容被窃听者所窃取，那么窃听者就会得到请求数据。可以使用 SSL/TLS 作为对通信进行加密的协议，然后再次智商承载 HTTP。通过将两种协议进行叠加，我们就可以对HTTP 的通信进行加密，防止窃听。通过 SSL/TLS 进行通信时，URL 以 https 开头。

解决问题：

• 机密性问题
  • 解决方式：对称密码、伪随机数生成器、公钥密码
• 完整性问题
  • 解决方式：消息认证码
• 认证问题
  • 解决方式：数字签名

SSL 与 TLS 区别：
SSL 是 1994年由王晶公司设计的一种协议，于1995年发布了3.0 版本。
TLS 设市 IETF 基于 SSL 3.0 版本的基础上设计的协议，在 1999年发布了 TLS 1.0 版本，实际上相当于 SSL 3.1。2006 年发布 TLS 1.1 版本，在对称密码算法中加入了 AES 支持。

SSL/TLS 使用到的密码技术：

• 公钥密码
  • 加密预备主密码
• 单向散列函数
  • 构成伪随机数生成器
• 数字签名
  • 验证服务器和客户端的证书
• 伪随机数生成器
  • 生成预备主密码
  • 根据主密码生成密钥
  • 生成初始化向量
• 对称密码
  • 确保片段的机密性
• 消息认证码
  • 确保片段的完整性并进行认证

密码技术与现实社会

密码的作用是为了确保机密性，将明文转换为密文。转换之后，密文不需要保护了，需要保护的是加密时使用的密钥。通过保护较短的密钥来保护较长的明文，称为机密性的压缩。

单向散列函数时用于确认完整性的，不必检查较长的明文的完整性，只要检查散列值就能确认，这种做法称为完整性的压缩。

消息认证码和数字签名都是用于认证的技术，通过较短的认证富豪来对较长的消息进行认证，称为认证的压缩。

只有完美的密码，没有完美的人。

背景

最近在写 k8s Operator，在看示例的时候看到 controller 都会设置 Finalizers，今天来聊一聊 Finalizers 和相关实现。

Finalizers

Finalizers 允许 Operator 控制器实现异步的 pre-delete hook。比如你给 API 类型中的每个对象都创建了对应的外部资源，你希望在 k8s 删除对应资源时同时删除关联的外部资源，那么可以通过 Finalizers 来实现。

Finalizers 是由字符串组成的列表，当 Finalizers 字段存在时，相关资源不允许被强制删除。存在 Finalizers 字段的的资源对象接收的第一个删除请求设置 metadata.deletionTimestamp 字段的值， 但不删除具体资源，在该字段设置后， finalizer 列表中的对象只能被删除，不能做其他操作。

当 metadata.deletionTimestamp 字段非空时，controller watch 对象并执行对应 finalizers 的动作，当所有动作执行完后，需要清空 finalizers ，之后 k8s 会删除真正想要删除的资源。

Operator finalizers 使用

介绍了 Finalizers 概念，那么我们来看看在 Operator 中如何使用，在 Operator Controller 中，最重要的逻辑就是 Reconcile 方法，finalizers 也是在 Reconcile 中实现的。要注意的是，设置了 Finalizers 会导致 k8s 的 delete 动作转为设置 metadata.deletionTimestamp 字段，如果你通过 kubectl get 命令看到资源存在这个字段，则表示资源正在删除（deleting）。

有以下几点需要理解：

1. 如果资源对象未被删除且未设置 finalizers，则添加 finalizer并更新 k8s 资源对象；
2. 如果正在删除资源对象并且 finalizers 仍然存在于 finalizers 列表中，则执行 pre-delete hook并删除 finalizers ，更新资源对象；
3. 由于以上两点，需要确保 pre-delete hook是幂等的。

kuberbuilder 示例

我们来看一个 kubebuilder 官方示例：

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
56
57
58
59
60
61
62
63
64
65
66
67

func (r *CronJobReconciler) Reconcile(req ctrl.Request) (ctrl.Result, error) {
    ctx := context.Background()
    log := r.Log.WithValues("cronjob", req.NamespacedName)

    var cronJob batch.CronJob
    if err := r.Get(ctx, req.NamespacedName, &cronJob); err != nil {
        log.Error(err, "unable to fetch CronJob")
        return ctrl.Result{}, ignoreNotFound(err)
    }

    // 声明 finalizer 字段，类型为字符串
    myFinalizerName := "storage.finalizers.tutorial.kubebuilder.io"

    // 通过检查 DeletionTimestamp 字段是否为0 判断资源是否被删除
    if cronJob.ObjectMeta.DeletionTimestamp.IsZero() {
        // 如果为0 ，则资源未被删除，我们需要检测是否存在 finalizer，如果不存在，则添加，并更新到资源对象中
        if !containsString(cronJob.ObjectMeta.Finalizers, myFinalizerName) {
            cronJob.ObjectMeta.Finalizers = append(cronJob.ObjectMeta.Finalizers, myFinalizerName)
            if err := r.Update(context.Background(), cronJob); err != nil {
                return ctrl.Result{}, err
            }
        }
    } else {
        // 如果不为 0 ，则对象处于删除中
        if containsString(cronJob.ObjectMeta.Finalizers, myFinalizerName) {
            // 如果存在 finalizer 且与上述声明的 finalizer 匹配，那么执行对应 hook 逻辑
            if err := r.deleteExternalResources(cronJob); err != nil {
                // 如果删除失败，则直接返回对应 err，controller 会自动执行重试逻辑
                return ctrl.Result{}, err
            }

            // 如果对应 hook 执行成功，那么清空 finalizers， k8s 删除对应资源
            cronJob.ObjectMeta.Finalizers = removeString(cronJob.ObjectMeta.Finalizers, myFinalizerName)
            if err := r.Update(context.Background(), cronJob); err != nil {
                return ctrl.Result{}, err
            }
        }

        return ctrl.Result{}, err
    }
}

func (r *Reconciler) deleteExternalResources(cronJob *batch.CronJob) error {
    //
    // 删除 crobJob关联的外部资源逻辑
    //
    // 需要确保实现是幂等的
}

func containsString(slice []string, s string) bool {
    for _, item := range slice {
        if item == s {
            return true
        }
    }
    return false
}

func removeString(slice []string, s string) (result []string) {
    for _, item := range slice {
        if item == s {
            continue
        }
        result = append(result, item)
    }
    return
}

cluster-api-provider-vsphere 实现

看完了示例，我们来招一个具体项目看看，cluster-api-provider-vsphere 是 cluster-api 相关项目，用于提供 vsphere 相关资源创建的 Operator，采用 kubebuilder 来实现的。

vspheremachine_controller.go 中实现了 Reconcile 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// Reconcile ensures the back-end state reflects the Kubernetes resource state intent.
func (r *VSphereMachineReconciler) Reconcile(req ctrl.Request) (_ ctrl.Result, reterr error) {
	...
	// Always close the context when exiting this function so we can persist any VSphereMachine changes.
	defer func() {
		if err := machineContext.Patch(); err != nil && reterr == nil {
			reterr = err
		}
	}()

	// Handle deleted machines
	if !vsphereMachine.ObjectMeta.DeletionTimestamp.IsZero() {
		return r.reconcileDelete(machineContext)
	}

	// Handle non-deleted machines
	return r.reconcileNormal(machineContext)
}

在 Reconcile 中检测了 DeletionTimestamp 是否为0 ，如果不为0 ，则表示资源处于正在删除中，那么来看下 reconcileDelete 实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

func (r *VSphereMachineReconciler) reconcileDelete(ctx *context.MachineContext) (reconcile.Result, error) {
	ctx.Logger.Info("Handling deleted VSphereMachine")

	var vmService services.VirtualMachineService = &govmomi.VMService{}

    // 执行删除虚拟机逻辑
	vm, err := vmService.DestroyVM(ctx)
	if err != nil {
        // 如果删除失败，则直接返回错误，controller 会自动重试
		return reconcile.Result{}, errors.Wrapf(err, "failed to destroy VM")
	}

	// 重新调度删除虚拟机逻辑，直到虚拟机状态处于 notfound 状态
	if vm.State != infrav1.VirtualMachineStateNotFound {
		ctx.Logger.V(6).Info("requeuing operation until vm state is reconciled", "expected-vm-state", infrav1.VirtualMachineStateNotFound, "actual-vm-state", vm.State)
		return reconcile.Result{RequeueAfter: config.DefaultRequeue}, nil
	}

	// pre-delete hook执行成功，也就是上面的删除虚拟机逻辑执行成功，则清空 Finalizers
	ctx.VSphereMachine.Finalizers = clusterutilv1.Filter(ctx.VSphereMachine.Finalizers, infrav1.MachineFinalizer)

	return reconcile.Result{}, nil
}

可以看到整体逻辑与示例的使用是一致的，主要通过这种方式来达到 pre-delete hook 的效果。

k8s-initializer-finalizer-practice

在搜索相关资料的时候，看到有人在 SO 上问了如何使用的问题，其中有个回答中附上了一个练习项目，项目很小，很适合了解 Finalizers 概念。

相关逻辑如下：

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

}else{
	customdeployment:=obj.(*crdv1alpha1.CustomDeployment).DeepCopy()
	fmt.Println("Event..............................")
	if customdeployment.DeletionTimestamp != nil{
		// check if it has finalizer
		if customdeployment.GetFinalizers()!=nil{
			finalizers:=customdeployment.GetFinalizers()

			// check if first finalizer match with deletepod.crd.emruz.com
			if finalizers[0]=="deletepods.crd.emruz.com"{
				//
				_,err:=myutil.PatchCustomDeployment(c.clientset,customdeployment, func(deployment *crdv1alpha1.CustomDeployment) *crdv1alpha1.CustomDeployment {
					// delete pods under this deployment
					err:=myutil.DeletePods(c.kubeclient,c.podLabel)
					if err!=nil{
						fmt.Println("Failed to remove all pods. Reason: ",err)
						return nil
					}
					// pods sucessfully removed. remove the finalizer
					customdeployment.ObjectMeta=myutil.RemoveFinalizer(customdeployment.ObjectMeta)
					return customdeployment
				})
				if err!=nil{
					return err
				}
			}
           }

总结

在开发 Operator 时，pre-delete hook 是一个很常见的需求，目前只发现了 Finalizers 适合实现这个功能，需要好好掌握。

参考链接

• https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#finalizers
• https://book.kubebuilder.io/reference/using-finalizers.html
• https://stackoverflow.com/questions/53057185/kubernetes-crd-finalizer

背景

最近手头上的 Cluster-API 的项目要告一段落， Cluster-API 发布了 v0.2.1 版本 ，正式放出了 YAML 配置文件，看到了点有意思的事情，觉得需要记录一下。

K8S Leader

看过之前 K8S 实战系列的朋友应该记得我写过一篇 K8S 高可用部署的文章，在文章中只是讲了具体的操作步骤，没有提到 k8s 是如何保证自己多个组件之间协作的。

我们这里有一个 3 个master 节点的集群：

1
2
3
4
5

[root@node70 21:01:01 ~]$kubectl get node
NAME     STATUS   ROLES    AGE   VERSION
node70   Ready    master   64d   v1.15.0
node71   Ready    master   64d   v1.15.0
node72   Ready    master   64d   v1.15.0

我们都知道 k8s 核心组件，其中 apiserver 只用于接收 api 请求，不会主动进行各种动作，所以他们在每个节点都运行并且都可以接收请求，不会造成异常；kube-proxy 也是一样，只用于做端口转发，不会主动进行动作执行。

但是 scheduler, controller-manager 不同，他们参与了 Pod 的调度及具体的各种资源的管控，如果同时有多个 controller-manager 来对 Pod 资源进行调度，结果太美不敢看，那么 k8s 是如何做到正确运转的呢？

k8s 所有功能都是通过 services 对外暴露接口，而 services 对应的是具体的 endpoints ，那么来看下 scheduler 和 controller-manager 的 endpoints 是什么：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

[root@node70 21:04:46 ~]$kubectl -n kube-system describe endpoints kube-scheduler
Name:         kube-scheduler
Namespace:    kube-system
Labels:       <none>
Annotations:  control-plane.alpha.kubernetes.io/leader:
                {"holderIdentity":"node70_ed12bf09-7aa3-47d6-9546-97752bb589b5","leaseDurationSeconds":15,"acquireTime":"2019-09-11T05:31:58Z","renewTime"...
Subsets:
Events:  <none>
[root@node70 21:05:25 ~]$kubectl -n kube-system describe endpoints kube-controller-manager
Name:         kube-controller-manager
Namespace:    kube-system
Labels:       <none>
Annotations:  control-plane.alpha.kubernetes.io/leader:
                {"holderIdentity":"node71_c8deeaea-2d66-4459-90ee-65c28563062f","leaseDurationSeconds":15,"acquireTime":"2019-09-12T12:44:15Z","renewTime"...
Subsets:
Events:
  Type    Reason          Age   From                     Message
  ----    ------          ----  ----                     -------
  Normal  LeaderElection  22m   kube-controller-manager  node71_c8deeaea-2d66-4459-90ee-65c28563062f became leader

可以看到关键字 control-plane.alpha.kubernetes.io/leader ，这两个组件是通过 leader 选举来从集群中多个节点选择一个执行具体动作，如果我们去看 /etc/kubernetes/manifests/ 下的配置文件，会看到这行配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    component: kube-controller-manager
    tier: control-plane
  name: kube-controller-manager
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-controller-manager
    - --allocate-node-cidrs=true
...
    - --leader-elect=true

通过在 YAML 中添加 leader-elect=true 来决定是否进行选主逻辑。而这个参数也是在执行 kubeadm 部署集群时就自动配置好了，无需手动配置。

Deployment Leader

我们先来说说 Deployment，Deployment 是从 ReplicaSet 进化来的，主要增加的功能有滚动更新、回滚、扩容所容等，可以说是我们日常使用 K8S 最常见的资源类型了。

那么当我们通过创建 Deployment 间接创建 ReplicaSet 时，我们有时候并不想所有的 ReplicaSet 中的 Pod 运行统一的逻辑。这时候我们就需要一种方式来选择（通知）某一个 Pod ，来确定这个 Pod 提供特殊功能，其他的 Pod 提供普通功能，也就是跟上述 k8s 实现方式一样，通过Leader 选举完成需求。

Leader 选举有很多方式，或是代码中内嵌选举逻辑，或者通过第三方服务，但是有两个的特点：

1. Leader 在同一时间内是唯一的
2. 当 Leader 所在 Pod 发生异常时，其他 Pod 要可以随时变为 Leader 。

Leader 选举实现方式

代码内嵌选主逻辑

在 Golang 中，k8s client-go 这个package 针对 Leader 相关功能进行了封装，支持3种锁资源，endpoint，configmap，lease，方便使用。

代码仓库：https://github.com/kubernetes/client-go/tree/master/tools/leaderelection

因为这次主要不是说具体实现，再加上我也没看过代码，这里先掠过。

SideCar

相比于代码中内嵌选主逻辑，使用 sidecar 就不用担心跨语言的问题了，使用起来也简单许多，我们现在用的这个项目实现：https://github.com/kubernetes-retired/contrib/blob/master/election/README.md

使用方式：

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

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  creationTimestamp: "2019-07-12T07:35:32Z"
  generation: 6
  labels:
    app: yiran-test
  name: yiran-test
  namespace: default
spec:
  selector:
    matchLabels:
      app: yiran-test
  template:
    metadata:
      annotations:
        kubectl.kubernetes.io/restartedAt: "2019-09-09T10:58:51+08:00"
      creationTimestamp: null
      labels:
        app: yiran-test
    spec:
      containers:
      - args:
        - --election=elect-yiran-test
        - --http=0.0.0.0:4444
        image: leader-elector:0.5
        imagePullPolicy: IfNotPresent
        name: leader-elector
      - args:
        ...

在 Deployment 或 DaemonSet 中，添加 sidecar 指定端口，最终会在所有的 Pod 中选择一个 Leader 。
在业务代码中，只需要访问端口 4444 ，即可获取当前 Pod 中 Leader 信息，目前是通过 hostname 作为唯一标示的。

如果看了这个项目的代码，会发现它也是使用的 client go 中的实现，只是增加了一层 http server：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

func getCurrentLeader(electionId, namespace string, c client.Interface) (string, *api.Endpoints, error) {
	endpoints, err := c.Endpoints(namespace).Get(electionId)
	if err != nil {
		return "", nil, err
	}
	val, found := endpoints.Annotations[leaderelection.LeaderElectionRecordAnnotationKey]
	if !found {
		return "", endpoints, nil
	}
	electionRecord := leaderelection.LeaderElectionRecord{}
	if err := json.Unmarshal([]byte(val), &electionRecord); err != nil {
		return "", nil, err
	}
	return electionRecord.HolderIdentity, endpoints, err
}

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

func main() {
	flags.Parse(os.Args)
	validateFlags()

	kubeClient, err := makeClient()
	if err != nil {
		glog.Fatalf("error connecting to the client: %v", err)
	}

	fn := func(str string) {
		leader.Name = str
		fmt.Printf("%s is the leader\n", leader.Name)
	}

	e, err := election.NewElection(*name, *id, *namespace, *ttl, fn, kubeClient)
	if err != nil {
		glog.Fatalf("failed to create election: %v", err)
	}
	go election.RunElection(e)

	if len(*addr) > 0 {
		http.HandleFunc("/", webHandler)
		http.ListenAndServe(*addr, nil)
	} else {
		select {}
	}
}

是否开启选举参数

那么我们说了这么多，在实际使用中是否应该开启选举参数呢？
这里要说一下我在文章开头提到的有意思的事情，我们来看下cluster-api 的 YAML 文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

apiVersion: apps/v1
kind: Deployment
metadata:
  ...
spec:
  replicas: 1
  ...
  template:
    metadata:
      ...
    spec:
      containers:
      - args:
        - --enable-leader-election
        command:
        - /manager
        image: us.gcr.io/k8s-artifacts-prod/cluster-api/cluster-api-controller:v0.2.1
        name: manager
        ...

创建的资源类型是 Deployment，replicas 设置为1，传递了参数 --enable-leader-election，当时我觉得有些奇怪，replicas是1 啊，也就是说一共只有1个 Pod，为啥还要开启 Leader 选举逻辑呢？如果说是为了之后的扩容那可以理解，但是在这份配置文件里，应该完全没必要。把这段配置发给 liqiang同学 看，他也觉得有些怪怪的。

秉着不懂就问的精神，我去 Slack #cluster-api 中提出了我的疑问，得到了以下回复，我格式化一下：

1
2
3
4
5
6
7
8
9
10

@cha： 
it's mostly set for best practice. If you scale up the system will still work. If you don't enable leader election and scale up you will have race conditions


@cha：
but you're right. If you're running a single manager you don't need to enable leader election


@jdetiber:
With a Deployment you do, because on rolling out a change it will spin up the new RS in parallel with the other so there will be 2 pods running at the same time for a short while

其中 @cha 的回复跟我预想的差不多，主要处于之后的扩容考虑，需要防止竞争情况出现。但是 @jdetiber 提到了一点很关键，当 Deployment 进行滚动升级的时候，哪怕设置了 Replicas 为1，也会存在短时间同时存在 2 个 Pod 的情况，那么肯定会导致我们的代码逻辑错误，很重要（感叹号）。

总结

其实今天这篇文章主要是想记录下上面这段话的，自己在平时使用 k8s 过程中，貌似也仅仅是知道这些功能并使用，真正要开发部分功能时，考虑的边界条件太少了。虽然知道 Deployment 滚动升级会有同时存在 2 个 Pod 的情况，却完全没有想到需要配置 Leader 选举参数来保证代码正确运行，涨知识了。

参考链接

• https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

背景

最近工作上每天疲于应付各种事情，周末实在不想继续做工作相关的事情，想起一直想了解的自动化测试框架 httprunner，就阅读下。之前一直有关注作者 debugtalk 的博客，收获很多。

随着公司的发展，自己也做过很多的工作，其中就包含测试，但是自己当时大部分都是手工测试，虽然会针对其中的部分进行代码编写，但是不成体系。虽然后来就没有继续负责测试工作了，但是对于测试还是很感兴趣，平时开发过程中，最多也就是使用 unittest 或 pytest 来编写单测，这次通过阅读 httprunner 代码来感受下测试框架。

P.S. 在使用及了解 httprunner 之前，最好先了解下 unittest。

httprunner

HttpRunner 是一款面向 HTTP(S) 协议的通用测试框架，只需编写维护一份 YAML/JSON 脚本，即可实现自动化测试、性能测试、线上监控、持续集成等多种测试需求。

一句话总结就是 api 自动化测试，其中用到了以下的开源项目：

1. requests
2. locust
3. unittest
4. …

requests 和 unittest 可以说是 python 开发者用的比较多的两个项目。locust 是一个 api 压力测试，这个我们公司也有用到。

介绍完了项目，我们来跟着官方文档了解运行流程。

执行流程

文档中的 快速上手 章节与章节名称很配，真心是 快速上手 ，通过一个又一个的示例来了解具体的功能使用，循序渐进，简直完美。不过又一点不好的地方是 demo 示例的代码不再 httprunner 中，而是在 docs 项目中，使用起来不是很方便，如果有 Dockerfile 来支撑，就更好了。

在 httprunner 项目中，项目的包管理是通过 poetry 进行的，比 setuptools 要清晰很多。

首先来看命令，httprunner 随着项目的演进，支持的命令行有 4个，其中 3 个是重复的，1个是压力测试：

1
2
3
4
5

[tool.poetry.scripts]
hrun = "httprunner.cli:main_hrun"
ate = "httprunner.cli:main_hrun"
httprunner = "httprunner.cli:main_hrun"
locusts = "httprunner.cli:main_locust"

我们以 hrun 为例，从 argparse 接收到的参数均作为参数传递给 HttpRunner，然后执行实例化 HttpRunner，通过 HttpRunner.run 进行用例的执行：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

runner = HttpRunner(
    failfast=args.failfast,
    save_tests=args.save_tests,
    report_template=args.report_template,
    report_dir=args.report_dir,
    log_level=args.log_level,
    log_file=args.log_file
)
try:
    for path in args.testcase_paths:
        runner.run(path, dot_env_path=args.dot_env_path)
except Exception:
    color_print("!!!!!!!!!! exception stage: {} !!!!!!!!!!".format(runner.exception_stage), "YELLOW")
    raise

我们来看下 runner.run 做了啥：

1
2
3
4
5
6
7

def run(self, path_or_tests, dot_env_path=None, mapping=None):
    if validator.is_testcase_path(path_or_tests):
        return self.run_path(path_or_tests, dot_env_path, mapping)
    elif validator.is_testcases(path_or_tests):
        return self.run_tests(path_or_tests)
    else:
        raise exceptions.ParamsError("Invalid testcase path or testcases: {}".format(path_or_tests))

这里只是进行了一层判断，判断传入的参数是一个路径还是具体的用例，因为我们主要是了解整个执行流程，所以我们直接假设传入的是测试用例，来看看 self.run_tests ：

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

def run_tests(self, tests_mapping):
    """ run testcase/testsuite data
    """
    project_mapping = tests_mapping.get("project_mapping", {})
    if self.save_tests:
        utils.dump_logs(tests_mapping, project_mapping, "loaded")

    # parse tests
    self.exception_stage = "parse tests"
    parsed_testcases = parser.parse_tests(tests_mapping)

    if self.save_tests:
        utils.dump_logs(parsed_testcases, project_mapping, "parsed")

    # add tests to test suite
    self.exception_stage = "add tests to test suite"
    test_suite = self._add_tests(parsed_testcases)

    # run test suite
    self.exception_stage = "run test suite"
    results = self._run_suite(test_suite)

    # aggregate results
    self.exception_stage = "aggregate results"
    self._summary = self._aggregate(results)

    # generate html report
    self.exception_stage = "generate html report"
    report.stringify_summary(self._summary)

    if self.save_tests:
        utils.dump_logs(self._summary, project_mapping, "summary")

    report_path = report.render_html_report(
        self._summary,
        self.report_template,
        self.report_dir
    )

    return report_path

先来看下具体的执行函数 self._run_suite：

1
2
3
4
5
6
7
8
9
10
11

def _run_suite(self, test_suite):
    tests_results = []

    for testcase in test_suite:
        testcase_name = testcase.config.get("name")
        logger.log_info("Start to run testcase: {}".format(testcase_name))

        result = self.unittest_runner.run(testcase)
        tests_results.append((testcase, result))

    return tests_results

真正执行用例执行的是 self.unittest_runner ，而 self.unittest_runner = unittest.TextTestRunner(**kwargs)，也就是说这里的 testcase 其实是 unittest.suite.TestSuite 或者 unittest.case.TestCase。

这里跟预想中的出现了偏差，我以为这里是自己实现的测试执行及结果比对的方法，没想到调用的是 unittest，那么怎么从一个 testcase 变为 unittest 可执行对象的，应该就是在 self._add_tests 中实现的了：

1
2
3
4
5
6
7
8
9
10

def _add_tests(self, testcases):
    """ initialize testcase with Runner() and add to test suite.

    Args:
        testcases (list): testcases list.

    Returns:
        unittest.TestSuite()

    """

这个函数略长，这里分开说，从注释中可以知道，最终 unittest 执行的是 unittest.TestSuite ，看下具体的逻辑：

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

test_suite = unittest.TestSuite() #定义 test_suite 返回值
for testcase in testcases:
    config = testcase.get("config", {})
    test_runner = runner.Runner(config) # 实例化 Runner，后续主要执行逻辑都在 Runner 中
    TestSequense = type('TestSequense', (unittest.TestCase,), {}) # 通过 type 声明一个 `unittest.TestCase` 的子类

    tests = testcase.get("teststeps", [])
    for index, test_dict in enumerate(tests):
        times = test_dict.get("times", 1)
        try:
            times = int(times)
        except ValueError:
            raise exceptions.ParamsError(
                "times should be digit, given: {}".format(times))

        for times_index in range(times):
            # suppose one testcase should not have more than 9999 steps,
            # and one step should not run more than 999 times.
            test_method_name = 'test_{:04}_{:03}'.format(index, times_index)
            test_method = _add_test(test_runner, test_dict) 
            setattr(TestSequense, test_method_name, test_method) # 将上面的 test_method 定义为 TestSequense 属性

    loaded_testcase = self.test_loader.loadTestsFromTestCase(TestSequense) # 利用 TestLoader 来找到符合条件的方法，默认 TestLoader 寻找前缀为 `test` 
    setattr(loaded_testcase, "config", config)
    setattr(loaded_testcase, "teststeps", tests)
    setattr(loaded_testcase, "runner", test_runner)
    test_suite.addTest(loaded_testcase) # 将 `TestLoader.loadTestsFromTestCase` 找到的 testcase 添加到 `test_suite` 中，并最终返回

看完上面这里，有一个比较重要的就是 _add_test 做了啥：

1
2
3
4
5
6
7
8
9
10
11
12

def _add_test(test_runner, test_dict):
    """ add test to testcase.
    """
    def test(self):
        try:
            test_runner.run_test(test_dict)
        except exceptions.MyBaseFailure as ex:
            self.fail(str(ex))
        finally:
            self.meta_datas = test_runner.meta_datas
    ...
    return test

先忽略其他代码，可以看到 _add_test 最终返回的是一个函数，这个函数名称是 test ，结合上面的 self.test_loader.loadTestsFromTestCase ，可以知道这个函数就是最终执行的方法。

看完这里，回到 run_tests 中，在 self._run_suite 执行完之后，就进行结果汇总、生成报告了，那么具体的请求是怎么发送出去的，结果又是怎么校验的？猜测是在 runner.Runner 中实现的，接着来看。

用例请求及校验

在上面提到，最终 _add_test 返回的函数中，执行的内容只有一个，就是 test_runner.run_test ，那么我们来看看 run_test ：

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

def run_test(self, test_dict):
        """ run single teststep of testcase.
            test_dict may be in 3 types.

        Args:
            test_dict (dict):

                # teststep
                {
                    "name": "teststep description",
                    "variables": [],        # optional
                    "request": {
                        "url": "http://127.0.0.1:5000/api/users/1000",
                        "method": "GET"
                    }
                }

                # nested testcase
                {
                    "config": {...},
                    "teststeps": [
                        {...},
                        {...}
                    ]
                }

                # TODO: function
                {
                    "name": "exec function",
                    "function": "${func()}"
                }

        """
        self.meta_datas = None
        if "teststeps" in test_dict:
            # nested testcase
            test_dict.setdefault("config", {}).setdefault("variables", {})
            test_dict["config"]["variables"].update(
                self.session_context.session_variables_mapping)
            self._run_testcase(test_dict)
        else:
            # api
            try:
                self._run_test(test_dict)
            except Exception:
                # log exception request_type and name for locust stat
                self.exception_request_type = test_dict["request"]["method"]
                self.exception_name = test_dict.get("name")
                raise
            finally:
                self.meta_datas = self.__get_test_data()

这里的注释虽然很长，但是很清晰的告诉我们这个函数做了什么，他允许传递的参数是嵌套的，所以这里先做了层判断，我们以最简单的来假设，直接看 self._run_test ：

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

def _run_test(self, test_dict):
        # clear meta data first to ensure independence for each test
        self.__clear_test_data() # 清空测试结果及 session 信息

        # check skip
        self._handle_skip_feature(test_dict) # 根据测试用例关键字执行相应跳过逻辑

        ... # N 多准备工作

        # setup hooks
        setup_hooks = test_dict.get("setup_hooks", [])
        if setup_hooks:
            self.do_hook_actions(setup_hooks, "setup") # 与大部分框架一样，支持 pre hook

        ... # N 多准备工作

        # request
        resp = self.http_client_session.request( # 根据用例发出请求
            method,
            parsed_url,
            name=(group_name or test_name),
            **parsed_test_request
        )
        resp_obj = response.ResponseObject(resp)

        # teardown hooks
        teardown_hooks = test_dict.get("teardown_hooks", []) # 支持 post hook
        if teardown_hooks:
            self.session_context.update_test_variables("response", resp_obj)
            self.do_hook_actions(teardown_hooks, "teardown")

        # extract
        extractors = test_dict.get("extract", {})
        extracted_variables_mapping = resp_obj.extract_response(extractors)
        self.session_context.update_session_variables(extracted_variables_mapping)

        # validate
        validators = test_dict.get("validate") or test_dict.get("validators") or []
        try:
            self.session_context.validate(validators, resp_obj) # 结果校验
        except (exceptions.ParamsError, exceptions.ValidationFailure, exceptions.ExtractFailure):
            err_msg = "{} DETAILED REQUEST & RESPONSE {}\n".format("*" * 32, "*" * 32)
            ...

            raise

        finally:
            self.validation_results = self.session_context.validation_results

具体的 http 请求时通过 self.http_client_session.request 发送的，通过 self.session_context.validate 进行结果校验，来看下具体的校验方式：

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

for validator in validators:
    # validator should be LazyFunction object
    if not isinstance(validator, parser.LazyFunction):
        raise exceptions.ValidationFailure(
            "validator should be parsed first: {}".format(validators))

    # evaluate validator args with context variable mapping.
    validator_args = validator.get_args()
    check_item, expect_item = validator_args
    check_value = self.__eval_validator_check( # 准备参数
        check_item,
        resp_obj
    )
    expect_value = self.__eval_validator_expect(expect_item) # 准备参数
    validator.update_args([check_value, expect_value])

    comparator = validator.func_name
    ...

    try:
        validator.to_value(self.test_variables_mapping) # 执行校验
        validator_dict["check_result"] = "pass"
        validate_msg += "\t==> pass"
        logger.log_debug(validate_msg)
    except (AssertionError, TypeError):
        ...

    self.validation_results.append(validator_dict)

前面都是在准备参数，最终执行完 validator.to_value 如果没有异常，就直接标记 check_result 为 pass 了，那么我们需要看看这里的 to_value 做了什么，感觉这个方法名称不太好，跟实际做的事情感觉不匹配。

1
2
3
4
5
6
7
8
9

def to_value(self, variables_mapping=None):
    """ parse lazy data with evaluated variables mapping.
        Notice: variables_mapping should not contain any variable or function.
    """
    variables_mapping = variables_mapping or {}
    args = parse_lazy_data(self._args, variables_mapping)
    kwargs = parse_lazy_data(self._kwargs, variables_mapping)
    self.cache_key = self.__prepare_cache_key(args, kwargs)
    return self._func(*args, **kwargs)

看到这里可能会感觉迷糊下，咦，为什么这里执行了 self._func ，self._func 是什么时候定义的，它做了啥？
我们在编写测试用例的时候 validate 通常是eq,gt,lt 等字段，如果把他们直接当作函数执行肯定不行的，那么一定存在一个映射关系将这些关键字转换为对应的函数。

看到这里其实我们漏掉了一个比较重要的步骤，就是 run_tests 中的 parse_tests 。其实很多时候默认的配置是不足以支撑我们真正逻辑的运行的，往往我们需要根据已有配置来扩充信息，达到满足执行要求的状态，接下来我们来看下测试用例准备工作。

用例解析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

def parse_tests(tests_mapping):
    
    project_mapping = tests_mapping.get("project_mapping", {})
    testcases = []

    for test_type in tests_mapping:

        if test_type == "testsuites":
            ...

        elif test_type == "testcases":
            for testcase in tests_mapping["testcases"]:
                parsed_testcase = _parse_testcase(testcase, project_mapping)
                testcases.append(parsed_testcase)

        elif test_type == "apis":
            ...

    return testcases

这里同样对 test_type 进行了判断，如果不是 testcases ，则会进行处理，我们还是假设最简单的 testcases，可以看到调用了 _parse_testcase 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

def _parse_testcase(testcase, project_mapping, session_variables_set=None):
    testcase.setdefault("config", {})
    prepared_config = __prepare_config(
        testcase["config"],
        project_mapping,
        session_variables_set
    )
    prepared_testcase_tests = __prepare_testcase_tests(
        testcase["teststeps"],
        prepared_config,
        project_mapping,
        session_variables_set
    )
    return {
        "config": prepared_config,
        "teststeps": prepared_testcase_tests
    }

从官方文档可以知道，每个 testcase 中的 config 其实是全局配置，所以这里先解析了 config，然后将其作为参数传递给了 __prepare_testcase_tests 用来准备对应的 testcase，最终返回准备好的测试用例及配置，那么跟着看下 __prepare_testcase_tests，这个函数很长很长，先忽略其他部分，先来看这段：

1
2
3
4
5
6
7

# unify validators' format
if "validate" in test_dict:
    ref_raw_validators = test_dict.pop("validate", [])
    test_dict["validate"] = [
        validator.uniform_validator(_validator)
        for _validator in ref_raw_validators
    ]

如果存在 validate ，那么将其转换为 validator.uniform_validator 组成的列表，彷佛抓到了什么，我们来看下 validator.uniform_validator：

1
2
3
4
5
6
7
8
9
10

def uniform_validator(validator):
    ...
    # uniform comparator, e.g. lt => less_than, eq => equals
    comparator = get_uniform_comparator(comparator)

    return {
        "check": check_item,
        "expect": expect_value,
        "comparator": comparator
    }

最终返回的是一个字典，其中的 comparator 是 get_uniform_comparator 返回值，继续看：

1
2
3
4
5
6
7
8
9
10

def get_uniform_comparator(comparator):
    """ convert comparator alias to uniform name
    """
    if comparator in ["eq", "equals", "==", "is"]:
        return "equals"
    elif comparator in ["lt", "less_than"]:
        return "less_than"
    ...
    else:
        return comparator

终于找到了校验关键字的映射关键字，那么我们继续回头看 __prepare_testcase_tests：

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

# convert validators to lazy function
validators = test_dict.pop("validate", [])
prepared_validators = []
for _validator in validators:
    function_meta = {
        "func_name": _validator["comparator"],
        "args": [
            _validator["check"],
            _validator["expect"]
        ],
        "kwargs": {}
    }
    prepared_validators.append(
        LazyFunction(
            function_meta,
            functions,
            teststep_variables_set
        )
    )
test_dict["validate"] = prepared_validators

# convert variables and functions to lazy object.
# raises VariableNotFound if undefined variable exists in test_dict
prepared_test_dict = prepare_lazy_data(
    test_dict,
    functions,
    teststep_variables_set
)
prepared_testcase_tests.append(prepared_test_dict)

在这里针对刚刚得到的关键字对应函数名称又进行了一次封装，现在的 test_dict["validate"] 就是一个 LazyFunction 组成的列表了，回想最开始我们为啥要看用例解析这部分的代码，因为我们发现在函数校验那里没找到真正执行的函数，我们来看下 LazyFunction 的构造函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

def __init__(self, function_meta, functions_mapping=None, check_variables_set=None):
    """ init LazyFunction object with function_meta

    Args:
        function_meta (dict): function name, args and kwargs.
            {
                "func_name": "func",
                "args": [1, 2]
                "kwargs": {"a": 3, "b": 4}
            }

    """
    self.functions_mapping = functions_mapping or {}
    self.check_variables_set = check_variables_set or set()
    self.cache_key = None
    self.__parse(function_meta)

重点在最后一个行，self.__parse(function_meta)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

def __parse(self, function_meta):
    """ init func as lazy functon instance

    Args:
        function_meta (dict): function meta including name, args and kwargs
    """
    self._func = get_mapping_function(
        function_meta["func_name"],
        self.functions_mapping
    )
    self.func_name = self._func.__name__
    self._args = prepare_lazy_data(
        function_meta.get("args", []),
        self.functions_mapping,
        self.check_variables_set
    )
    self._kwargs = prepare_lazy_data(
        function_meta.get("kwargs", {}),
        self.functions_mapping,
        self.check_variables_set
    )

    ...

在这里找到了我们一直想找的 self._func 定义，看函数名是通过 func_name 从一个 map 中返回真正的函数，来看看是不是这样：

1
2
3
4
5
6
7
8
9
10
11
12

def get_mapping_function(function_name, functions_mapping):
    
    ...

    try:
        # check if HttpRunner builtin functions
        from httprunner import loader
        built_in_functions = loader.load_builtin_functions()
        return built_in_functions[function_name]
    except KeyError:
        pass
    ...

1
2
3
4
5

from httprunner import built_in, exceptions, logger, parser, utils, validator
def load_builtin_functions():
    """ load built_in module functions
    """
    return load_module_functions(built_in)

1
2
3
4
5
6
7
8

def load_module_functions(module):
    module_functions = {}

    for name, item in vars(module).items():
        if validator.is_function(item):
            module_functions[name] = item

    return module_functions

一路追下来，具体的实现应该在 built_in.py 没跑：

1
2
3
4
5
6
7

def equals(check_value, expect_value):
    assert check_value == expect_value

def less_than(check_value, expect_value):
    assert check_value < expect_value

...

Ok，到这里我们终于了解了用例的解析工作做了什么，同时也解答了我们上面遗留下来的疑问，结果校验执行的是什么。

总结

在公司内部同样有着测试框架，是基于 Robot Framework 进行开发的，但是我被 Robot 的代码量劝退了。。。httprunner 项目整体来看代码量不大，很适合作为初步了解自动化测试的框架来阅读。

根据作者自述，项目起源于大疆内部的测试需求，之后转为开源项目，不知道作者现在是否是因为离开了大疆还是其他原因，现在 httprunner 的社区感觉很差，明明是有公司使用的，但是并没有积极参与，作者一个人承担了几乎100% 的代码开发任务，感觉是一个不健康的社区。

希望自己有机会的话也参与进去，不希望这样一个项目 死 掉。

P.S.

其实这篇博客应该是在周五晚上完成的，但是写着写着发现自己对于项目中的整体流程无法理顺，今天又用了大半天的时间重新读了代码，一点一点记录下来。

嗯，写博客的好处之一。

背景

在日常开发时，有时候需要保证自己代码的健壮性，需要模拟各种故障测试，比如：磁盘、网络、端口等，今天来汇总一下平时使用最多的几种故障模拟方法

磁盘

插入拔出

服务器的存储控制器如果是直通模式，那么在 OS 中能够直接获取到磁盘插入与拔出事件，有时候我们需要检测到相应的事件来自动化的做某些动作，具体的实现方式见之前的文章 Linux 下磁盘设备自动发现方式 。

那么我们写完了代码想要测试，不想去机房物理操作，怎么模拟呢？

Hypervisor

如果你的代码部署的机器是一台虚拟机，那么在 Hypervisor 层面一般都会有对应的接口来完成相应的操作。

比如 Vsphere ESXi 中可以直接编辑虚拟机，在磁盘选项中有一个“移除”按钮，可以直接移除磁盘：

再比如 KVM 下，可以通过 Libvirt 接口来 detach 磁盘。

当然对于插入动作，Hypervisor 也会提供对应的功能。

物理服务器

如果 OS 不是在 Hypervisor 上，而是直接安装在了物理服务器上，我们怎么做呢？

通常我们服务器上的磁盘都是 SCSI 设备，会实现完整的 SCSI（接口），可以通过修改相应设备的标置文件来达到目的。

示例：
节点存在设备 /dev/sda ，修改标置文件，在系统中会发现磁盘已经被移除了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

[root@yiran ~]# lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0   10G  0 disk
sr0              11:0    1  4.3G  0 rom  /run/media/root/CentOS 7 x86_64
vda             252:0    0  100G  0 disk
├─vda1          252:1    0    1G  0 part /boot
└─vda2          252:2    0   99G  0 part
  ├─centos-root 253:0    0   50G  0 lvm  /
  ├─centos-swap 253:1    0  3.9G  0 lvm
  └─centos-home 253:2    0 45.1G  0 lvm  /home
[root@yiran ~]# ls /sys/block/sda/device/delete
/sys/block/sda/device/delete
[root@yiran ~]# echo 1 > /sys/block/sda/device/delete
[root@yiran ~]# lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0              11:0    1  4.3G  0 rom  /run/media/root/CentOS 7 x86_64
vda             252:0    0  100G  0 disk
├─vda1          252:1    0    1G  0 part /boot
└─vda2          252:2    0   99G  0 part
  ├─centos-root 253:0    0   50G  0 lvm  /
  ├─centos-swap 253:1    0  3.9G  0 lvm
  └─centos-home 253:2    0 45.1G  0 lvm  /home

如果我们新开一个终端，可以通过 udevadm 命令查看到设备移除过程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

[root@yiran ~]# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1255.635671] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/bsg/2:0:0:0 (bsg)
KERNEL[1255.636247] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_generic/sg1 (scsi_generic)
KERNEL[1255.636265] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_device/2:0:0:0 (scsi_device)
KERNEL[1255.636357] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_disk/2:0:0:0 (scsi_disk)
UDEV  [1255.637109] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/bsg/2:0:0:0 (bsg)
KERNEL[1255.638351] remove   /devices/virtual/bdi/8:0 (bdi)
UDEV  [1255.638369] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_device/2:0:0:0 (scsi_device)
KERNEL[1255.638385] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/block/sda (block)
UDEV  [1255.638397] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_disk/2:0:0:0 (scsi_disk)
KERNEL[1255.638417] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0 (scsi)
UDEV  [1255.639174] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_generic/sg1 (scsi_generic)
UDEV  [1255.639192] remove   /devices/virtual/bdi/8:0 (bdi)
UDEV  [1255.641850] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/block/sda (block)
UDEV  [1255.642914] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0 (scsi)
KERNEL[1255.643143] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0 (scsi)
UDEV  [1255.643608] remove   /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0 (scsi)

说完了拔出磁盘，那么该如何插入呢？最简单的办法肯定是重启 OS，毕竟我们不是真正的拔出了设备，重启 OS 之后设备肯定会重新发现。我们也可以通过修改对应的标置文件来手动重新执行设备扫描动作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

[root@yiran ~]# lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0              11:0    1  4.3G  0 rom  /run/media/root/CentOS 7 x86_64
vda             252:0    0  100G  0 disk
├─vda1          252:1    0    1G  0 part /boot
└─vda2          252:2    0   99G  0 part
  ├─centos-root 253:0    0   50G  0 lvm  /
  ├─centos-swap 253:1    0  3.9G  0 lvm
  └─centos-home 253:2    0 45.1G  0 lvm  /home
[root@yiran ~]# for i in `ls /sys/class/scsi_host/`;do echo "- - -" > /sys/class/scsi_host/$i/scan;done
[root@yiran ~]# lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0   10G  0 disk
sr0              11:0    1  4.3G  0 rom  /run/media/root/CentOS 7 x86_64
vda             252:0    0  100G  0 disk
├─vda1          252:1    0    1G  0 part /boot
└─vda2          252:2    0   99G  0 part
  ├─centos-root 253:0    0   50G  0 lvm  /
  ├─centos-swap 253:1    0  3.9G  0 lvm
  └─centos-home 253:2    0 45.1G  0 lvm  /home

同样，在另一个终端可以看到 udev 事件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

[root@yiran ~]# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1506.675351] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0 (scsi)
KERNEL[1506.675416] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0 (scsi)
KERNEL[1506.675523] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_disk/2:0:0:0 (scsi_disk)
KERNEL[1506.675562] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_device/2:0:0:0 (scsi_device)
KERNEL[1506.676417] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_generic/sg1 (scsi_generic)
KERNEL[1506.676555] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/bsg/2:0:0:0 (bsg)
UDEV  [1506.677524] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0 (scsi)
KERNEL[1506.677662] add      /devices/virtual/bdi/8:0 (bdi)
UDEV  [1506.682939] add      /devices/virtual/bdi/8:0 (bdi)
KERNEL[1506.682968] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/block/sda (block)
UDEV  [1506.683015] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0 (scsi)
UDEV  [1506.683036] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_disk/2:0:0:0 (scsi_disk)
UDEV  [1506.683053] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_device/2:0:0:0 (scsi_device)
UDEV  [1506.689442] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/scsi_generic/sg1 (scsi_generic)
UDEV  [1506.690861] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/bsg/2:0:0:0 (bsg)
UDEV  [1506.711146] add      /devices/pci0000:00/0000:00:07.0/virtio3/host2/target2:0:0/2:0:0:0/block/sda (block)

延迟

为了测试软件在高 IO 延迟下的表现，现在我们需要给一块磁盘设置指定的 IO 延迟（latency），可以使用 dm-delay 来实现：

dm-delay具体参数为：<device> <offset> <delay> [<write_device> <write_offset> <write_delay>]

1
2
3
4
5

[root@node90 10:45:54 ~]$modprobe brd rd_nr=1 rd_size=10485760 # 创建10G ram disk
[root@node90 10:46:23 ~]$blockdev --getsize /dev/ram0
20971520 
[root@node90 10:46:23 ~]$size=$(blockdev --getsize /dev/ram0) # Size in 512-bytes sectors
[root@node90 10:46:23 ~]$echo "0 $size delay /dev/ram0 0 500" | dmsetup create delayed # 设置读延迟 500

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[root@node90 10:45:54 ~]cat fio.conf
[random]
filename=/dev/dm-0
readwrite=randread
blocksize=4k
ioengine=sync
direct=1
time_based=1
runtime=10
[root@node90 10:45:54 ~]fio fio.conf
...
clat (usec): min=500769, max=502110, avg=501122.35, stdev=357.23 #写入延迟 500ms 
     lat (usec): min=500770, max=502111, avg=501123.45, stdev=357.20 
...

通过 dm-delay，我们可以来进行各种排列组合来模拟磁盘状态，如：读延迟高，写延迟正常；读延迟高，写延迟高；读延迟低，写延迟高等。

IO 中断

dm-delay 支持设置 IO 中断，具体命令为：

1
2

$ sudo dmsetup suspend /dev/dm-0
$ sudo dmsetup resume  /dev/dm-0

若在执行 fio 过程中设置 IO 中断， 会看到 iops 为0 的现象：

1
2
3

[root@node90 10:45:54 ~]fio fio.conf
Starting 1 process
Jobs: 1 (f=1): [r(1)] [0.0% done] [0KB/0KB/0KB /s] [0/0/0 iops] [eta 34d:09h:15m:48s]

IO Error

有时我们也要求验证磁盘突然出现 IO Error 情况，可以通过 dm-flakey 实现：

1
2
3
4
5
6
7
8

[root@node90 11:06:44 ~]$modprobe brd rd_nr=1 rd_size=10485760 #10G
[root@node90 11:06:58 ~]$size=$(blockdev --getsize /dev/ram0)
[root@node90 11:06:58 ~]$echo "0 $size flakey /dev/ram0 0 60 0" | dmsetup create flakey
[root@node90 11:06:59 ~]$size=$(blockdev --getsize /dev/ram0)
[root@node90 11:07:06 ~]$echo "0 $size flakey /dev/ram0 0 30 30"  | dmsetup reload flakey
[root@node90 11:07:06 ~]$dmsetup resume flakey
[root@node90 11:07:06 ~]$dmsetup table flakey
0 20971520 flakey 1:0 0 30 30 0

若在执行 fio 过程中设置 IO Error，则会看到以下错误：

1
2
3
4
5
6
7
8

[root@node90 10:45:54 ~]fio fio.conf
Starting 1 process
fio: io_u error on file /dev/dm-0: Input/output error: read offset=647606272, buflen=4096
fio: pid=24184, err=5/file:io_u.c:1708, func=io_u error, error=Input/output error

random: (groupid=0, jobs=1): err= 5 (file:io_u.c:1708, func=io_u error, error=Input/output error): pid=24184: Sat Aug 31 11:09:45 2019
  cpu          : usr=0.00%, sys=0.00%, ctx=0, majf=0, minf=69
...

网络

在故障场景中，最常见的应该就是网络故障，尤其是现在分布式应用的场景很多，另一点原因是网络相关的工具很多，可以很方便的使用。

故障

最简单的网络故障应该就是连接中断，也就是各个节点之间无法联通了，我们可以直接通过 ifdown <nic name> 来将网卡置为 down，或者如果不在意其他网卡状态的话，可以直接 systemctl stop network 停止网络服务，来模拟无法联通情况。

有时候我们不想模拟网卡故障，想要模拟固定节点之间的网络故障，那么可以通过 iptables 来实现：

1
2

iptables -I INPUT -s 172.11.30.14 -j DROP
iptables -I OUTPUT -d 172.11.30.14 -j DROP

将指定 IP 的所有连接都丢弃。

延迟

网络延迟模拟可以通过 tc 来实现，命令很简单，找到指定的网卡名称，并执行：

1

[root@yiran ~]# tc qdisc add dev eth0 root netem delay 8ms

新开终端，在其他节点 ping 设置了网络延迟的节点：

1
2
3
4
5
6
7
8
9
10
11

root@yiran-30-250:~
 $ ping 192.168.30.246
PING 192.168.30.246 (192.168.30.246) 56(84) bytes of data.
64 bytes from 192.168.30.246: icmp_seq=1 ttl=64 time=8.76 ms
64 bytes from 192.168.30.246: icmp_seq=2 ttl=64 time=8.40 ms
64 bytes from 192.168.30.246: icmp_seq=3 ttl=64 time=8.38 ms
64 bytes from 192.168.30.246: icmp_seq=4 ttl=64 time=8.38 ms
^C
--- 192.168.30.246 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 8.381/8.485/8.769/0.198 ms

可以看到延迟稳定在 8ms 左右。

除了 tc 工具外，前几天看到了一个 Golang 实现的 L4 网络代理项目，可以模拟延迟和丢包，具体关于故障模拟的代码如下：

1
2
3
4
5
6
7
8

func (t *TCPServer) doWrite(bytes []byte, conn goetty.IOSession, ctl *conf.CtlUnit) {
	if ctl.DelayMs > 0 {
		log.Infof("Delay <%d>ms write to <%s>", ctl.DelayMs, t.proxyUnit.Target)
		time.Sleep(time.Millisecond * time.Duration(ctl.DelayMs))
	}

	conn.WriteAndFlush(bytes)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

for {
		_, err = session.Read()
		if err != nil {
			log.Infof("Read from client<%s> failure.err=%+v", session.RemoteAddr(), err)
			break
		} else {
			// write to target
			ctl := t.proxyUnit.Ctl
			bytes := in.RawBuf()[in.GetReaderIndex():in.GetWriteIndex()]
			if 0 == ctl.Out.LossRate {
				log.Debugf("write %d bytes to <%s>", len(bytes), conn.RemoteAddr())
				t.doWrite(bytes, conn, ctl.Out)
			} else {
				if t.rnd.Intn(100) > ctl.Out.LossRate {
					log.Debugf("write %d bytes to <%s>", len(bytes), conn.RemoteAddr())
					t.doWrite(bytes, conn, ctl.Out)
				} else {
					log.Debugf("Loss write %d bytes to <%s>", len(bytes), conn.RemoteAddr())
				}
			}
		}

		in.SetReaderIndex(in.GetWriteIndex())
    }

端口

占用

在使用 Zookeeper 这类有状态应用时，除了通过 service 是否处于 running 来判断服务是否运行外，还需要判断节点的 zk 角色是否符合预期，如 leader 或 follower。

前几天又一个场景需要造出 Zookeeper 处于运行中，但是角色状态处于异常状态，我通过 nc 来实现的：

1

[root@yiran ~]# nc -kl 2181

现将端口占用，然后启动 Zookeeper，就可以了。

总结

故障模拟的主要使用场景是产品的自动化测试中，平时主要是辅助开发来自测，不需要记住具体参数，但是最好了解到什么场景下有什么工具可以使用，省时省力。

参考链接

• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_administration_guide/sect-managing_guest_virtual_machines_with_virsh-attaching_and_updating_a_device_with_virsh
• https://www.enodev.fr/posts/emulate-a-slow-block-device-with-dm-delay.html
• https://www.kernel.org/doc/Documentation/device-mapper/dm-flakey.txt
• https://github.com/fagongzi/netproxy

背景

今天继续来聊一聊 cluster-api，在上周看 cluster-api-provider-vsphere 代码的时候吐槽过，cluster-api 最近因为 v1alpha2 版本的开发，变化太快，几乎每天都在变，那么我们就来看看 v1alpha2 具体做了什么。

Cluster-API v1alpha2

虽然目前 v1alpha2 还没有正式的 release，但是已经趋于稳定，且两个主要的 provider：aws 和 vsphere 都在进行 v1alpha2 版本的适配（最近每天都有 pr 更新）。我们先来了解下为啥要进行 v1alpha2 改动，改动的目的是啥。

在 v1alpha1 版本中，cluster-api 要求 provider 实现从节点置备到 k8s 部署的全套流程，cluster-api 自身只负责具体的 API 定义及相关控制，在 provider 实现上也不是一个标准的 Operator，（至少）我从概念的理解上比较吃力，每个 provider 需要实现对应 cluster 与 machine 的 actuator ，开发起来要求对 cluster-api 项目本身很熟悉。

其次，每个 provider 都包含了 k8s 集群部署的流程，虽然大部分实现最终都是使用 kubeadm 工具，但是使用方式千差万别，有 cloud-init、有 ssh 配合密钥、有 ssh 配合密码等等。这部分 provider 中的代码完全都是重复的，可以复用的。

上面提到的一些缺点，在 v1alpha2 版本中进行了改进，对各个组件进行了拆分，现在使用 cluster-api 需要 3 个控制器：

1. Core(cluster-api)
2. Bootstrap(kubeadm)
3. Infrastructure(aws, gcp, azure, vsphere, etc)

下面来说说各个控制器负责什么。

Core(cluster-api)

核心控制器，也就是 cluster-api 项目自身，相比于 v1alpha1 版本 v1alpha2 各个方面简直可爱，来看看具体的改动：

clusterctl

在 v1alpha1 中，clusterctl 因为耦合了最终的 provider 项目，命令行是由对应的 provider 提供，在 v1alpha2 中完全由 cluster-api 维护。具体代码在 cmd/clusterctl 下，整体结构感觉跟 kubeadm 很像。

API

仍然包含两个主要的 CRD：cluster 和 machine，针对两个资源进行了阶段定义，根据注释就很好 cluster 和 machine 会处于哪些状态：

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

const (
	// MachinePhasePending is the first state a Machine is assigned by
	// Cluster API Machine controller after being created.
	MachinePhasePending = MachinePhase("pending")

	// MachinePhaseProvisioning is the state when the
	// Machine infrastructure is being created.
	MachinePhaseProvisioning = MachinePhase("provisioning")

	// MachinePhaseProvisioned is the state when its
	// infrastructure has been created and configured.
	MachinePhaseProvisioned = MachinePhase("provisioned")

	// MachinePhaseRunning is the Machine state when it has
	// become a Kubernetes Node in a Ready state.
	MachinePhaseRunning = MachinePhase("running")

	// MachinePhaseDeleting is the Machine state when a delete
	// request has been sent to the API Server,
	// but its infrastructure has not yet been fully deleted.
	MachinePhaseDeleting = MachinePhase("deleting")

	// MachinePhaseDeleted is the Machine state when the object
	// and the related infrastructure is deleted and
	// ready to be garbage collected by the API Server.
	MachinePhaseDeleted = MachinePhase("deleted")

	// MachinePhaseFailed is the Machine state when the system
	// might require user intervention.
	MachinePhaseFailed = MachinePhase("failed")

	// MachinePhaseUnknown is returned if the Machine state cannot be determined.
	MachinePhaseUnknown = MachinePhase("")
)

Controller

cluster-api 不再负责具体的 API 所有资源的定义，而是通过设置资源的 owner 来达到最终 cluster 包含 machine 的效果。

用 AWS 官方示例展示：

cluster.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

---
apiVersion: cluster.x-k8s.io/v1alpha2
kind: Cluster
metadata:
  name: ${CLUSTER_NAME}
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["192.168.0.0/16"]
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1alpha2
    kind: AWSCluster
    name: ${CLUSTER_NAME}
---
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha2
kind: AWSCluster
metadata:
  name: ${CLUSTER_NAME}
spec:
  region: ${AWS_REGION}
  sshKeyName: ${SSH_KEY_NAME}

在执行完 kubectl apply -f cluster.yaml 后， aws cluster 控制器会等待 cluster-api 控制器将 AWSCluster 与 Cluster 资源进行关联后进行下一步操作，这样最终能够达到 Cluster 资源是所有资源的 owner，也可以获得到所有资源的具体的 Spec 和 Status 信息。

（等版本 release 之后好好了解下其中的关系。

Boostrap(kubeadm)

相比 cluster-api 的复杂，目前 Bootstrap 的唯一实现 CABPK 是一个分拆出来的独立项目，这个项目的主要目的是通过 Cluster 和 Machine 及对应的 Infrastructure Cluster 和 Machine 信息，来生成 cloud-init 配置（Userdata）。

目前 v1alpha2 统一部署 k8s 集群的方式为 cloud-init ，通过 CABPK 项目生成对应 Machine 的 cloud-init 配置，在部署虚拟机的时候传递 Userdata，达到自动配置的效果。也就是说如果你的 Hypervisor 不支持 cloud-init，就没办法使用 cluster-api v1alpha2 进行部署，只能通过 v1alpha1 的方式，在 Infrastructure 控制器做所有事情。

需要注意的是，在 Infrastructure 控制器工作前，需要保证 Bootstrap 控制器正常工作，生成用于最终创建虚拟机的 cloud-init 配置。

Infrastructure

前面说的两个控制器都是社区官方维护的，下面来说下各个厂家（provider）维护的 Infrastructure 控制器（最近几天都在搞这个）。

v1alpha2 版本要求各个 provider 实现一个标准且完整的 Operator。包含对应的 Cluster,Machine。以下还是使用 cluster-api-provider-vsphere 具体，截止到 20190823 ，对应 PR 还处于未完成状态。

API

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// VSphereClusterSpec defines the desired state of VSphereCluster
type VSphereClusterSpec struct {
	Server string `json:"server,omitempty"`
	Username string `json:"username,omitempty"`
	Password string `json:"password,omitempty"`
	Insecure *bool `json:"insecure,omitempty"`
	SSHAuthorizedKeys []string `json:"sshAuthorizedKeys,omitempty"`
	CloudProviderConfiguration cloud.Config `json:"cloudProviderConfiguration,omitempty"`
}

// VSphereClusterStatus defines the observed state of VSphereClusterSpec
type VSphereClusterStatus struct {
	Ready bool `json:"ready"`
	APIEndpoints []APIEndpoint `json:"apiEndpoints,omitempty"`
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// VSphereMachineSpec defines the desired state of VSphereMachine
type VSphereMachineSpec struct {
	MachineRef string `json:"machineRef,omitempty"`
	Template string `json:"template"`
	Datacenter string `json:"datacenter"`
	Network NetworkSpec `json:"network"`
	NumCPUs int32 `json:"numCPUs,omitempty"`
	NumCoresPerSocket int32 `json:"numCoresPerSocket,omitempty"`
	MemoryMiB int64 `json:"memoryMiB,omitempty"`
	DiskGiB int32 `json:"diskGiB,omitempty"`
	TrustedCerts [][]byte `json:"trustedCerts,omitempty"`
	NTPServers []string `json:"ntpServers,omitempty"`
}

// VSphereMachineStatus defines the observed state of VSphereMachine
type VSphereMachineStatus struct {
	Ready bool `json:"ready"`
	Addresses []v1.NodeAddress `json:"addresses,omitempty"`
	TaskRef string `json:"taskRef,omitempty"`
	Network []NetworkStatus `json:"networkStatus,omitempty"`
	ErrorReason *errors.MachineStatusError `json:"errorReason,omitempty"`
	ErrorMessage *string `json:"errorMessage,omitempty"`
}

定义 VSphereCluster 与 VSphereMachine CRD，这里根据自己需要定义相关参数就好，比如如果不想支持自定义目标虚拟机配置，那么就不用提供 CPU、Memory 等配置。

Controller

来分别看看 cluster controller 与 machine controller 做了啥。

Cluster Controller

在 Reconcile 的实现中，先获取 VSphereCluster 信息：

1
2
3
4
5
6
7
8

vsphereCluster := &infrav1.VSphereCluster{}
err := r.Get(parentContext, req.NamespacedName, vsphereCluster)
if err != nil {
	if apierrors.IsNotFound(err) {
		return reconcile.Result{}, nil
	}
	return reconcile.Result{}, err
   }

然后获取 VSphereCluster 关联的 Cluster 信息：

1
2
3
4
5
6
7
8
9

// util 由 cluster-api 提供
cluster, err := util.GetOwnerCluster(parentContext, r.Client, vsphereCluster.ObjectMeta)
if err != nil {
	return reconcile.Result{}, err
}
if cluster == nil {
	logger.Info("Waiting for Cluster Controller to set OwnerRef on VSphereCluster")
	return reconcile.Result{RequeueAfter: 10 * time.Second}, nil
   }

在获取了足够的信息之后，针对这些信息，创建了 context（这里 aws 是叫 scope，是一个东西），判断是否包含 DeletionTimestamp 来决定进行什么调度，是 reconcileDelete 还是 reconcileNormal 。

1
2
3
4
5
6
7
8

func reconcileDelete(ctx *context.ClusterContext) (reconcile.Result, error) {
	ctx.Logger.Info("Reconciling VSphereCluster delete")

	// Cluster is deleted so remove the finalizer.
	ctx.VSphereCluster.Finalizers = util.Filter(ctx.VSphereCluster.Finalizers, infrav1.ClusterFinalizer)

	return reconcile.Result{}, nil
}

在所有的 provider 中，都对相应资源进行了 Finalizer 配置，方便后续在资源删除前进行一些额外的操作，这里 vsphere 还没有具体的实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

func reconcileNormal(ctx *context.ClusterContext) (reconcile.Result, error) {
	ctx.Logger.Info("Reconciling VSphereCluster")

	vsphereCluster := ctx.VSphereCluster

	// If the VSphereCluster doesn't have our finalizer, add it.
	if !util.Contains(vsphereCluster.Finalizers, infrav1.ClusterFinalizer) {
		vsphereCluster.Finalizers = append(vsphereCluster.Finalizers, infrav1.ClusterFinalizer)
	}

	// Set APIEndpoints so the Cluster API Cluster Controller can pull them
	vsphereCluster.Status.APIEndpoints = []infrav1.APIEndpoint{
		{
			Host: "", // vsphereCluster.Status.Network.APIServerELB.DNSName,
			Port: 0,
		},
	}

	// No errors, so mark us ready so the Cluster API Cluster Controller can pull it
	vsphereCluster.Status.Ready = true

	return reconcile.Result{}, nil
}

在 reconcileNormal 中对集群进行 Finalizer 判断，然后这里直接更新了 vsphereCluster.Status 具体字段，应该是还没实现完成。

Machine Controller

与 Cluster 相比，Machine 包含了具体的虚拟机创建动作，相应需要的信息也会多一些，除了通过 VSphereMachine获取关联 Machine 以外，还通过 Machine 获取了 Cluster 信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// Fetch the Machine.
	machine, err := util.GetOwnerMachine(parentContext, r.Client, vsphereMachine.ObjectMeta)
	if err != nil {
		return reconcile.Result{}, err
	}
	if machine == nil {
		logger.Info("Waiting for Machine Controller to set OwnerRef on VSphereMachine")
		return reconcile.Result{RequeueAfter: 10 * time.Second}, nil
	}

	logger = logger.WithName(fmt.Sprintf("machine=%s", machine.Name))

	// Fetch the Cluster.
	cluster, err := util.GetClusterFromMetadata(parentContext, r.Client, machine.ObjectMeta)
	if err != nil {
		logger.Info("Machine is missing cluster label or cluster does not exist")
		return reconcile.Result{}, nil
    }

与 Cluster 一样，也会进行 DeletionTimestamp 判断，来看下 reconcileNormal 的实现：

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

func (r *VSphereMachineReconciler) reconcileNormal(ctx *context.MachineContext) (reconcile.Result, error) {
	// 如果 VSphereMachine 的状态一场，则直接返回
	if ctx.VSphereMachine.Status.ErrorReason != nil || ctx.VSphereMachine.Status.ErrorMessage != nil {
		ctx.Logger.Info("Error state detected, skipping reconciliation")
		return reconcile.Result{}, nil
	}

	// 如果 VSphereMachine 没有 Finalizer，则添加
	if !util.Contains(ctx.VSphereMachine.Finalizers, infrav1.MachineFinalizer) {
		ctx.VSphereMachine.Finalizers = append(ctx.VSphereMachine.Finalizers, infrav1.MachineFinalizer)
	}

	if !ctx.Cluster.Status.InfrastructureReady {
		ctx.Logger.Info("Cluster infrastructure is not ready yet, requeuing machine")
		return reconcile.Result{RequeueAfter: waitForClusterInfrastructureReadyDuration}, nil
	}

	// 在真正创建虚拟机之前，需要确保 cloud-init 配置已经生成
	if ctx.Machine.Spec.Bootstrap.Data == nil {
		ctx.Logger.Info("Waiting for bootstrap data to be available")
		return reconcile.Result{RequeueAfter: 10 * time.Second}, nil
	}

    // 这里缺少真正创建虚拟机的实现
	return reconcile.Result{}, nil
}

vsphere 所有关于虚拟机的操作都在这里，感兴趣的可以看看。

main.go

看完了具体实现逻辑，那么去看下控制器入口： main.go

1
2
3
4
5
6
7
8
9
10
11
12

func init() {
	_ = clientgoscheme.AddToScheme(scheme)
	_ = infrav1.AddToScheme(scheme)
	// +kubebuilder:scaffold:scheme

	if v, err := time.ParseDuration(os.Getenv(syncPeriodEnvVar)); err == nil {
		defaultSyncPeriod = v
	}
	if v, err := time.ParseDuration(os.Getenv(requeuePeriodEnvVar)); err == nil {
		defaultRequeuePeriod = v
	}
}

需要注意的是 init 函数，这里应该加上 _ = clusterv1.AddToScheme(scheme) ，否则在真正创建对应资源的时候，会报 no kind is registered for the type 的错误。（对 Operator 还不太熟，这里具体原因未了解）

总结

相对来说 v1alpha2 版本改动范围较大，但是真香。各个逻辑部分比之前容易理解的多，且provider 实现也比之前简单许多（虽然还是比较麻烦）。

但是恰恰因为是 alpha 版本，再次吐槽，改动真的是太频繁了，按照项目中 Milestone 规划，在 20190831 就要 release v1alpha2 了，但是目前完成度还只有 58% 。而且目前看到除了 aws 和 vmware 对这个项目参与的比较积极，其他项目都处于假死状态，不知道后续是否会有其他厂家参与进来共同完善。

P.S.

• cluster-api 相关项目使用 kubebuilder 辅助构建的，随着 kubebuilder v2 正式发布，相关代码结构改动较大，最好花费些时间了解下 kubebuilder v2。
• 目前 provider 中 aws 完善度是最高的，但是 aws 中的概念是真的复杂，概念劝退。

背景

之前 liqiang 同学写了一篇博客：Status 还是 State 用于总结日常工作中遇到的相似词的区别。这两天看代码，经常能够看到两个词：provider 和 provisioner，作为一个英语渣渣，很难准确的理解两个词的区别。

字典解释

provider 字典中的解释为：

1. 供应者（商）
2. 提供者（商）
3. 供养人
4. …

provisioner 字典中的解释为：

1. 粮食供应者

看上去从字面上也是一个意思，那么我们来找个实际场景看看。

实际场景

Terraform

在 Terraform 概念中，同时存在 provider 和 provisioner 两个概念：

1
2

A provider is responsible for understanding API interactions and exposing resources. Providers generally are an IaaS (e.g. AWS, GCP, Microsoft Azure, OpenStack), PaaS (e.g. Heroku), or SaaS services (e.g. Terraform Cloud, DNSimple, CloudFlare).

1

Provisioners are used to execute scripts on a local or remote machine as part of resource creation or destruction. Provisioners can be used to bootstrap a resource, cleanup before destroy, run configuration management, etc.

这里的 provider 对应 供应商 的含义是可以正确理解的，不同的供应商提供不同的插件。

provisioner 在这里指的是定义的资源可使用的插件，如 remote-exec,file,chef 等等，跟供应商关系不大。

Vagrant Docker

在搜索过程中，看到有人在 SO 上问了这么个问题 Vagrant - Docker provider vs. docker provisioner

下面的高票回答：

1

Docker provisioner help to prepare environment: build and pull images, run containers if you need multiple containers running for your vagrant machine. Docker provider is running vagrant machine in docker container (instead of VM/cloud as other providers do).

虽然感觉说的不是很清楚，但是也可以看出 provider 是有明确分类的，而 provisioner 更像是具体的动作种类，比如创建、删除、更新等。

CSI

在 k8s CSI 中，也有 provisioner 的概念，这里主要是指具体的“置备动作执行者”。

当然 provisioner 也有多个，根据具体的存储供应商的不同，提供不同的 provisioner。

Cluster-API

在 Cluster-API 中，不同厂家为了支持 Cluster-API，会实现不同的 provider，比如 cluster-api-provider-aws, cluster-api-provider-vspher 等。

总结

根据实际的情况，provider 主要是用来区分供应者，是谁来提供某个事物，通常以公司区分。

provisioner 使用场景不多，主要是涉及到具体的功能执行，我这里理解为“置备动作执行者”，虽然也可以进行分类，但是主要意思应该是前者比较多一些。

背景

上一篇博客讲了 Cluster-API 的相关概念，现在我们来找一个 provider 实现看看具体里面做了啥，因为对 vmware 产品中的概念比较熟悉，就找了 cluster-api-provider-vsphere 。

以下内容均对应 clusterapi v1alpha1 版本。

clusterctl 命令

cluster-api provider 提供了命令行 clusterctl 用于给我们快速创建 bootstrap 集群用于创建目标 k8s 集群，我们来执行一下看看具体做了哪些工作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

root@yiran-workstation:~/go/src/github.com/kubernetes-sigs/cluster-api-provider-vsphere 
master ✗ $ clusterctl create cluster \                                                       
  --provider vsphere \
  --bootstrap-type kind \
  --cluster ./out/management-cluster/cluster.yaml \
  --machines ./out/management-cluster/machines.yaml \
  --provider-components ./out/management-cluster/provider-components.yaml \
  --addon-components ./out/management-cluster/addons.yaml \
  --kubeconfig-out ./out/management-cluster/kubeconfig
I0816 17:28:05.815156   14562 createbootstrapcluster.go:27] Preparing bootstrap cluster
I0816 17:29:15.292547   14562 clusterdeployer.go:78] Applying Cluster API stack to bootstrap cluster
I0816 17:29:15.292619   14562 applyclusterapicomponents.go:26] Applying Cluster API Provider Components
I0816 17:29:16.492405   14562 clusterdeployer.go:83] Provisioning target cluster via bootstrap cluster
I0816 17:29:16.505317   14562 applycluster.go:36] Creating cluster object management-cluster in namespace "default"
I0816 17:29:16.518456   14562 clusterdeployer.go:92] Creating control plane machine in namespace "default"
I0816 17:29:16.548814   14562 applymachines.go:36] Creating machines in namespace "default" # 因为众所周知的“网络”问题，导致我的 Pod image 无法拉取，所以就卡在这里了。。。
...

可以看到这个命令一共做了如下的事情：

1. 创建 bootstrap 集群
2. 安装 Provider 组件
3. 创建目标 k8s 集群，创建 Cluster CR，Machine CR
4. …

这里因为“网络”问题我无法继续下去了，那么我们来看下命令行的具体实现。

这个命令最终是由 provider 提供的，在 provider 中需要实现 2个接口来辅助信息的获取：

1
2
3
4
5
6

type Deployer interface {
	// TODO: This requirement can be removed once after: https://github.com/kubernetes-sigs/cluster-api/issues/158
	GetIP(cluster *clusterv1.Cluster, machine *clusterv1.Machine) (string, error)
	// TODO: This requirement can be removed after: https://github.com/kubernetes-sigs/cluster-api/issues/160
	GetKubeConfig(cluster *clusterv1.Cluster, master *clusterv1.Machine) (string, error)
}

在 Bootstrap 集群中，会运行 2个 StatefulSet ，分别对应的是 Cluster-api-control-manager 和 provider-control-manager。其中跟 Hypervisor 打交道的逻辑全部在 provider-control-manager 中实现。

Cluster

创建流程：

删除流程：

在 Cluster Controller 中，最终所有的调度任务都会通过 actuator 完成，actuator 需要实现以下接口：

1
2
3
4
5
6

type Actuator interface {
	// Reconcile creates or applies updates to the cluster.
	Reconcile(*clusterv1.Cluster) error
	// Delete the cluster.
	Delete(*clusterv1.Cluster) error
}

来看下 vsphere 的实现：

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

func (a *Actuator) Reconcile(cluster *clusterv1.Cluster) (opErr error) {
	ctx, err := context.NewClusterContext(&context.ClusterContextParams{
		Cluster:          cluster,
		Client:           a.client,
		CoreClient:       a.coreClient,
		ControllerClient: a.controllerClient,
		Logger:           klogr.New().WithName("[cluster-actuator]"),
	})
	if err != nil {
		return err
	}

	defer func() {
		opErr = actuators.PatchAndHandleError(ctx, "Reconcile", opErr)
	}()

	ctx.Logger.V(6).Info("reconciling cluster")

	if err := a.reconcilePKI(ctx); err != nil {
		return err
	}

	if err := a.reconcileCloudConfigSecret(ctx); err != nil {
		return err
	}

	if err := a.reconcileReadyState(ctx); err != nil {
		return err
	}

	return nil
}

如果在 actuator 中遇到需要等待或重新调度的情况，比如目标虚拟机未创建完成，目标集群未 ready 的情况，需要返回 clusterErr.RequeueAfterError ，从而重新调度。比如在配置 secret 时，如果无法获取目标集群的 k8s client，那么表示集群还未配置完成：

1
2
3
4
5
6
7

func (a *Actuator) reconcileCloudConfigSecret(ctx *context.ClusterContext) error {
	client, err := kubeclient.New(ctx)
	if err != nil {
		ctx.Logger.Error(err, "target cluster is not ready")
		return &clusterErr.RequeueAfterError{RequeueAfter: config.DefaultRequeue}
	}
...

machine

创建流程：

删除流程：

在 v1alpha1 版本中，machine actuator 负责 2件事情：

1. 虚拟机构建；
2. k8s 集群构建（cloud-init 或 ssh）

在 vsphere 中，创建虚拟机和 k8s 集群构建两件事情时一起完成的，大概流程如下：

1. 生成配置信息，如证书
2. 判断目标 k8s 集群是否需要初始化（kubeadm init）
3. 根据是否需要初始化及是否为 controlplane，生成对应 cloud-init 配置文件
4. 克隆虚拟机，并将 cloud-init 配置文件作为 guestinfo.userdata 放入虚拟机配置参数中
5. 虚拟机开机，通过 vmtoolsd 获取 guestinfo.userdata 信息，并作为 cloud-init 参数进行配置
6. k8s 集群构建完成（我在实际测试中，发现并没有自动创建 CNI 插件，不知道是不是 bug）
7. vsphere 克隆虚拟机为异步任务，提交克隆虚拟机任务后，得到 task id，后续判断虚拟机是否存在会用到；

Cloud-init or SSH

Cloud-init

在 vsphere provider 中，k8s 部署是通过 cloud-init 实现的，因为之前对 cloud-init 并不了解，这里大概看了下实现方式。

首先在克隆虚拟机时，给目标虚拟机添加了 guestinfo.userdata 字段作为虚拟机配置参数，这个参数是配置在 Hypervisor 层面的，理论上存在虚拟机隔离性，那么虚拟机内部应该无法感知这个参数，这时候就需要一个工具：vmtools。各个虚拟化平台都会提供一个 vmtools 或类似的工具，用于给虚拟机提供一些高级功能，如：获取 IP、设置主机名、配置 NTP/DNS Server、执行特定命令等等。这些都是根据 vmtools 的实现方式不同支持的功能也不同。

vmware vmtools 在安装后，vsphere 可以获取到虚拟机的 IP 等信息，同时，在虚拟机内部会安装一些命令，比如：

1
2
3
4
5
6
7

 $ which vmtoolsd     
/usr/bin/vmtoolsd
root@yiran-workstation:~/project/cluster-api-provider-vsphere 
7d21730f ✔ $ vmware-*
vmware-checkvm             vmware-hgfsclient          vmware-toolbox-cmd         vmware-vgauth-cmd        
vmware-config-tools.pl     vmware-namespace-cmd       vmware-uninstall-tools.pl  vmware-vmblock-fuse      
vmware-guestproxycerttool  vmware-rpctool             vmware-user-suid-wrapper   vmware-xferlogs

vsphere provider 代码中并没有很明确的给出参数是如何传递的，通过不断的寻找，我找到了这个项目： https://github.com/vmware/cloud-init-vmware-guestinfo ，在这里我们可以看到获取 Hypervisor 层面虚拟机的额外配置：

1
2
3
4
5
6
7
8

def get_guestinfo_value(key):
    '''
    Returns a guestinfo value for the specified key.
    '''
    LOG.debug("Getting guestinfo value for key %s", key)
    try:
        (stdout, stderr) = util.subp(
            [VMTOOLSD, "--cmd", "info-get guestinfo." + key])

那么后续的步骤就可以想象的到了，全靠 cloud-init ，这里因为对 cloud-init 了解不多，之后有机会去学习下。

SSH

SSH 是我们日常远程连接服务器最常用的方式了，通过用户名，密码（或密钥）来进行 SSH 连接，之后都是通过 Shell 脚本的方式实现 k8s 集群部署，当然 Shell 脚本最终调用的命令是 kubeadm。

总结

通过阅读 vsphere provider 代码，我们大概了解了实现一个 Cluster-API provider 需要做哪些事情，最主要的资源控制工作都是在 Cluster-API 实现的，而 provider 主要根据各个场景不同，通过 actuator 实现对应工作，代码量和实现方式上也是千差万别。比如 aws 全部代码可能要 2w 行，而 IBM 的加一起可能不到2k，全看各家的重视程度了。

在写这篇博客的间隙，Cluster-API 开始了 alpha2 的实质性工作： https://github.com/kubernetes-sigs/cluster-api/blob/master/docs/developer/v1alpha1-compared-to-v1alpha2.md ，还没有了解具体的改动，等 beta 之后再看吧。

吐槽：

因为 Cluster-API 处于 v1alpha1 阶段，master 分支代码改动非常大，前几天看的代码今天再看就跟记忆中对不上了，之后看代码的时候一定要注意去一个稳定分支上看，免得费时费力。

背景

在当前 Kubernetes 生态中，生命周期管理相关工具官方的有 kubeadm、kubespray（部署集群部分通过 kubeadm） ，开源社区还有很多其他的实现，我们可以通过这类工具来实现 k8s 集群的部署，升级，增删节点，但是使用一个工具的前提是：基础设施已经准备完成。只有当基础设施准备完成后，kubeadm 之类工具才可以正常工作。

当我们在部署 Kubernetes 集群时，节点可能在任何环境上，比如 AWS、OpenStack、Vsphere、Azure 等，那么想要自动化配置基础设施，通常我们根据自己的环境不同，编写不通的代码来支持我们的虚拟化（or 服务器）场景。

基础设施包括不限于：

• OS 安装
• Load Balance 配置
• 网络配置
• IP 分配
• …

Cluster-API

Kubernetes 社区针对基础设施问题，发起了一个项目：cluster-api，目前处于 alpha1 版本，项目目标：

1. 使用声明式API管理 Kubernetes 集群的生命周期
2. 支持多种环境，私有云或公有云
3. 使用社区中现有的工具完成相应功能
4. …

功能简述

1. 无需创建额外基础设施前提下创建 bootstrap cluster
2. 通过 bootstrap cluster 创建目标 k8s 集群

工作流程

1. cluster-api 使用声明式 API 管理 k8s 集群，需要环境中先存在一个 k8s 集群，通常成为 bootstrap cluster，若不存在，也可通过提供的命令行工具 clusterctl 创建 bootstrap cluster
2. 在 bootstrap cluster 中，部署 CRD 及相应的 cluster api 控制器及 provider 控制器
3. 在 bootstrap cluster 中，开始创建我们真正想要创建的资源：k8s 集群
   创建资源类型为 Cluster、Machine 或 MachineDeployment ，对应的控制器会自动为我们创建好虚拟机
4. 在虚拟机创建完成后，通过 kubeadm 创建 k8s 集群

具体实现

虚拟机创建

目前看到的几个 Cluster-API Provider 项目实现，虚拟机均通过克隆的方式创建出来的。

虚拟机创建失败处理

百度：每次等待 30s 查询一次，重试10次，若仍未成功，则创建失败

腾讯：每 2s 查询一次，若不成功，则一直循环

vsphere：提交虚拟机创建任务后未检查是否正确创建，未发现重试逻辑

OpenStack：每 10s 检测一次，若超过设定 timeout ，则创建失败

虚拟机控制方式

如果虚拟化平台支持 Cloud-init（或类似功能），后续 k8s 部署通过 Cloud-init 实现；

若虚拟化平台不支持，则 bootstrap cluster 中的 Pod 通过 ssh 方式进入倒虚拟机内部执行命令。

通过 Clout-init 实现的好处是Controller 只需要控制虚拟机开机即可，后续无需再主动与虚拟机进行通信，由 Cloud-init 自行触发部署 k8s集群任务；若没有 Cloud-init，则 Controller 在提交虚拟机创建任务后，需要循环等待虚拟机是否正常，等待正常后还需通过 ssh 主动与虚拟机进行连接控制，过于繁琐。

总结

Cluster API 目前还处于 Alpha1 版本，但是已经有很多厂家对其进行适配了，目前看到完成度比较高的公有云是 AWS，私有云是 Vsphere，之后好好读一下 Vsphere 的代码，了解下具体实现。

背景

在看一个新项目的时候，通常我都会了解下这个项目的代码量，然后心里给个预期，大概需要多久了解这个项目。

wc

在以前，我一般都是使用 find 配合 wc 来完成，比如：

1
2
3
4

root@yiran-workstation:/tmp/cloc 
 $ find . -name "*.go" | xargs wc -l {} 
  81 ./installer.go
  81 total

显示有一个 installer.go 的文件，一共有 81行。但是这里有个问题，就是 wc 是不会统计代码里面的具体内容的，比如注释、空白行等。

这时候我们就需要一个更高级的工具了： cloc

cloc

cloc 是一个 Perl 语言实现的项目，用途就像它的名字全称：Count Lines of Code。

使用方法的话最简单的直接加上项目路径：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

root@yiran-workstation:~/go/src/github.com/kubermatic/kubeone 
master ✗ $ pwd        
/root/go/src/github.com/kubermatic/kubeone
root@yiran-workstation:~/go/src/github.com/kubermatic/kubeone 
master ✗ $ cloc .                   
     292 text files.
     274 unique files.                                          
      78 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.80 s (269.1 files/s, 32223.3 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Go                             122           2861           2791          14374
Markdown                        38           1003              0           3172
YAML                            41             14            158            524
Bourne Shell                     5             44             89            206
Python                           4             66             76            186
XML                              4              0              0            100
make                             1             17             13             52
-------------------------------------------------------------------------------
SUM:                           215           4005           3127          18614
-------------------------------------------------------------------------------

可以看到统计结果，其中默认会按照语言分类。

如果是 Golang 的项目，且使用了 vendor ，那么可以通过 --exclude-dir 来过滤掉某些路径：

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

aster ✗ $ cloc . 
    3304 text files.
    3170 unique files.                                          
     429 files ignored.

github.com/AlDanial/cloc v 1.70  T=12.40 s (232.7 files/s, 101850.0 lines/s)
--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
Go                             2501         101422         113437        1007168
Markdown                        108           2688              0           6786
Protocol Buffers                 53           3006           9076           5133
YAML                            108            305            377           4032
Bourne Shell                     38            381            839           1897
JSON                              7              0              0           1748
Assembly                         35            271            320           1603
Python                            5            277            113            588
make                             23            165            162            556
Bourne Again Shell                3             45             56            378
XML                               4              0              0            106
C                                 1              8              7             24
--------------------------------------------------------------------------------
SUM:                           2886         108568         124387        1030019
--------------------------------------------------------------------------------
root@yiran-workstation:~/go/src/github.com/kubernetes-sigs/cluster-api-provider-vsphere 
master ✗ $ ls    
boilerplate.go.txt  cmd                 config           Dockerfile  go.mod  hack     Makefile  OWNERS_ALIASES  PROJECT    RELEASE.md  SECURITY_CONTACTS
build               code-of-conduct.md  CONTRIBUTING.md  docs        go.sum  LICENSE  OWNERS    pkg             README.md  scripts     vendor
root@yiran-workstation:~/go/src/github.com/kubernetes-sigs/cluster-api-provider-vsphere 
master ✗ $ cloc . --exclude-dir=vendor
     234 text files.
     234 unique files.                                          
      73 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.55 s (294.2 files/s, 26466.9 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Go                              64           1110           1355           5106
YAML                            37            150            302           1907
Bourne Shell                    22            256            475           1125
Markdown                        17            332              0            895
Python                           5            277            113            588
make                             9             57            112            177
JSON                             4              0              0            131
XML                              4              0              0            106
-------------------------------------------------------------------------------
SUM:                           162           2182           2357          10035
-------------------------------------------------------------------------------
root@yiran-workstation:~/go/src/github.com/kubernetes-sigs/cluster-api-provider-vsphere 
master ✗ $

有时候仅仅按照语言分类还不够，我们想看到具体的那些文件代码量比较大，可以使用 --by-file 参数：

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

root@yiran-workstation:~/go/src/github.com/kubermatic/kubeone 
master ✗ $ cloc . --by-file |head -n 30
     292 text files.
     274 unique files.                                          
      78 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.70 s (307.5 files/s, 36823.9 lines/s)
--------------------------------------------------------------------------------------------------------------------
File                                                                             blank        comment           code
--------------------------------------------------------------------------------------------------------------------
./pkg/templates/machinecontroller/deployment.go                                     52             24            762
./pkg/apis/kubeone/v1alpha1/zz_generated.conversion.go                              86             54            614
./pkg/apis/kubeone/validation/validation_test.go                                    22             12            530
./pkg/cmd/config.go                                                                 81             42            477
./pkg/apis/kubeadm/v1beta2/zz_generated.deepcopy.go                                 53             60            443
./pkg/apis/kubeadm/v1beta1/zz_generated.deepcopy.go                                 53             60            439
./pkg/templates/weave/weave-net.go                                                  32             13            433
./pkg/config/cluster.go                                                             80             69            417
./pkg/terraform/config.go                                                           76             30            368
./pkg/templates/canal/daemonset.go                                                   9             42            344
./pkg/yamled/document_test.go                                                      113             15            344
./pkg/apis/kubeone/v1alpha1/zz_generated.deepcopy.go                                47             53            340
./pkg/apis/kubeone/zz_generated.deepcopy.go                                         47             53            340
./pkg/templates/machinecontroller/webhook.go                                        35             22            332
./pkg/installer/installation/prerequisites.go                                       73             21            281
./pkg/templates/canal/prerequisites.go                                              16             40            257
./pkg/upgrader/upgrade/preflight_checks.go                                          44             30            247
./pkg/yamled/document.go                                                            70             31            240
./pkg/upgrader/upgrade/preflight_checks_test.go                                     14             12            237
./pkg/templates/metricsserver/deployment.go                                         22             13            227
./pkg/templates/externalccm/packet.go                                               20             12            222
./docs/quickstart-vsphere.md                                                        59              0            222