唠唠技术 on Ethan S. Chen

Kubernetes生态下的软件调试方法——以Provider为例

Sat, 04 Jan 2025 12:00:00 +0800

背景

在公司的时候，有很多调试环境部署有K8S集群供开发自验证，

但在家参与一些开源项目的时候，因为无法使用公司环境，导致缺少可以自验证的环境。

以前一般使用MiniKube或Docker部署K8S集群等方式构建测试环境，

但缺点是对机器的要求比较高，我的17年8G运行内存的Mac只能是堪堪运行起集群，

再要在上面做一些调试，开个IDE，开个浏览器等，十分费劲。

趋势

升级机器配置，我也有过这个想法，但不免几年就需要升级一次，费钱费时间，且机器95%以上的时间都是闲置的，并不划算。

所以利用付费的云化资源+轻量的终端进行开发工作，越来越成为我近年来的一种趋势。

本文也是基于这一种思想构建的一种调试方法，供君参考。

更进一步

单纯的云化资源并不能很好的控制成本，借鉴企业的的做法，弹性伸缩才是降低成本的要点。

所以我们在使用云化资源的时候也要贯彻这一种做法，

尤其在需要使用K8S集群这类资源开销更大的业务时，

使用Terraform在测试时自动化创建出基础设施，是我们应该提倡的。

以Provider为例

上周在工作中遇到一个Kubernetes Provider的社区Bug，因为公司的业务版本发布在即，所以优先采用打补丁的方式完成修复。

但计划在业余时间帮助社区修复该Bug，修复时发现缺少自验证的环境，于是开始探索下面使用AWS的EKS构建测试环境的方法。

登录AWS控制台

登录AWS的EKS服务，本文以美国（俄亥俄州）为例

安装Terraform

参考Terraform的Install教程，在AWS临时终端中安装Terraform

1
2
3


sudo yum install -y yum-utils shadow-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
sudo yum -y install terraform

部署EKS集群

参考Terraform的部署EKS集群教程，通过AWS终端部署EKS集群

初始化工作空间

1
2
3


git clone https://github.com/hashicorp-education/learn-terraform-provision-eks-cluster
cd learn-terraform-provision-eks-cluster
terraform init

部署集群

1

terraform apply -auto-approve

预计花费10分钟完成集群部署，部署后可以在ESK集群管理页面看到该集群

验证集群功能

配置kubectl

1

aws eks --region $(terraform output -raw region) update-kubeconfig --name $(terraform output -raw cluster_name)

查看集群信息

1

kubectl cluster-info

查看node信息

1

kubectl get nodes

部署Deployment资源

参考Terraform的管理K8S资源，通过Terraform部署测试服务到集群

创建工作目录，编辑kubernetes.tf文件

1
2
3
4


cd ~
mkdir learn-terraform-deploy-nginx-kubernetes
cd learn-terraform-deploy-nginx-kubernetes
vim kubernetes.tf

初始化工作目录

1

terraform init

修改kubernetes.tf，增加Deployment资源后Apply

1
2


vim kubernetes.tf
terraform apply -auto-approve

查看Deployment资源

1

kubectl get deployments

去部署Deployment资源

1
2


cd ~/learn-terraform-deploy-nginx-kubernetes
terraform destroy -auto-approve

调试Provider

参考Kubernetes Provider项目的贡献指南

安装Go

1

brew install go@1.22

克隆Provider项目

Fork Provider项目到自己的仓库下，再克隆到本地

1
2


git clone https://github.com/<YOUR-USERNAME>/terraform-provider-kubernetes.git
cd terraform-provider-kubernetes

修改代码

即修改terraform-provider-kubernetes代码

编译Provider

1

bash scripts/build.sh

替换二进制文件

将编译好的Provider上传到AWS终端，替换原二进制文件

验证Provider修改

执行可以验证到修改的操作，例如再次部署Deployment资源

去部署EKS集群

验证完毕，别忘了销毁集群，因为它时刻都在计费！

1
2


cd ~/learn-terraform-provision-eks-cluster
terraform destroy -auto-approve

总结

到此，本文介绍的方法就讲完了，欢迎各位一试～

我在Dubbo源码里学到了如何保证虚拟节点均匀分布

Sun, 13 Jun 2021 12:00:00 +0800

背景

上周更新了一篇文章《一致性Hash算法与虚拟节点》，阅读和收藏人数挺多的。

今天有朋友问了我一个问题，虚拟节点如何保证均匀分布？

我不假思索的回答，

不需要保证虚拟节点的均匀分布，

虚拟节点用以保证相对的均匀靠得是量变产生质变，

就像我文末提到的，在实际场景中，虚拟节点的个数只有3个是远远不够的。

例如Dubbo中用到一致性hash算法时，默认的虚拟节点个数是160个，

假设我们有四个服务节点需要创建虚拟节点，那就会有 4 * 160 = 640 个虚拟节点，

在这样大量的基数下，必然他们的分布就会呈一种相对均匀的状态。

回答完我感觉很满意，不愧是我！

可转念一想，再想，三想，

好像不是这么一回事，

别说是有640个节点了，就算有6400个，64000个节点又如何呢？

在极小极小的概率下，如果hash算法不能保证映射的均匀性，

他们依然可能落在十分聚集的一小块区域中。

反推一下，既然一致性hash算法作为一个成熟并拥有很多应用场景的算法，

不可能如此不严谨，所以hash算法本身应该是可以保证映射的一致性的。

“应该”？这么不确定可不行，我得好好补补空白，确实之前没有去了解过hash算法到底实现了个啥。

东查西查，终于有了答案。

百度百科对Hash的名次解释如下：

Hash，一般翻译做散列、杂凑，或音译为哈希，是把任意长度的输入（又叫做预映射pre-image）通过散列算法变换成固定长度的输出，该输出就是散列值。

哦，原来就是散列函数啊！

那就简单了，散列函数我本科学过啊！

脑海一番搜索，糟糕，我真的学过吗？唯一的印象就是学过。

没事，学过忘了没关系，再学就完事了。

以下是干货，

一个合格的散列函数包含三个特征：

单向性：容易计算输入的散列结果，但是从散列结果无法倒推出输入；
抗冲突性：很难找到两个不同的输入散列结果相同；
映射分布均匀性和差分分布均匀性：散列结果中 bit 位上的 0 和 1 的数量应当大致相等；改变输入内容的 1 个 bit 信息会导致散列结果一半以上的 bit 位变化（雪崩效应）。

真刺激，到这是不是就完事了，散列函数保证了映射的分布均匀性。

我劝你要不要再回去看两遍映射分布均匀性和差分分布均匀性的内容。

看完了吗？

再想想《一致性Hash算法与虚拟节点》中的hash环，

有没有顿时反应过来，这边又TM不严谨了。

说好的散列结果中bit位上 0 和 1 的数量大致相等，这要是映射到hash环上，

最小值岂不是 00000000000000001111111111111111，

最大值岂不是 11111111111111110000000000000000，

（别数数字，我随便打的，你懂我意思吧）

那在hash环上不就出现了一段真空地带了吗？

虽然实际上真空地带比图上的还小，只有 65536/4294967295 约等于百万分之十五，

但这微小的缺口无疑将带来无法估计的灾难，尤其是在实际生产环境中，

你永远不知道一个微小的漏洞可能会造成多大的后果。

不行，“革命还未成功，同志仍需努力。”

我应该离胜利不远了，

正好，最近在学Dubbo，

里面的负载均衡就用到了一致性hash算法，

我直接掏出源码看看不就知道了。

Dubbo仓库地址：https://github.com/apache/dubbo

找到 ConsistentHashLoadBalance 类，

这边我将我们最关心的代码贴上来，

1
2
3
4
5
6
7


for (int i = 0; i < replicaNumber / 4; i++) {
 byte[] digest = Bytes.getMD5(address + i);
 for (int h = 0; h < 4; h++) {
 long m = hash(digest, h);
 virtualInvokers.put(m, invoker);
 }
}

其中 replicaNumber 就是我们要创建的虚拟节点数目（副本数），

可以看到，代码中巧妙的通过两层 for 循环，

令外层循环上限除以 4，内层循环 4 次，使得总副本数目保持原水平，

如（160/4）* 4 = 160。

为什么要有这种安排呢？

让我们继续往下看，

首先让实际服务地址加上 i 形成新的字符串，再对其取 MD5 值，

也就是说一个 MD5 值实际上是要生成 4 个副本位置的。

问题一个接着一个，

为什么要让一个 MD5 值生成 4 个副本位置？

一来节约了计算的成本，

二来实际上一个 MD5 值确实够生成 4 个副本位置了。

别忘了，我们的 hash 环只有 2 的 32 次方 - 1 个位置，

而一个 MD5 值却有 16 个字节，16 * 8 = 128 个bit，

这意味着只要我们切分得当，一个 MD5 值确实可以生成 4 个hash环中的位置值。

让我们继续看看上面贴出来的代码中的 hash 方法实现

1
2
3
4
5
6
7


private long hash(byte[] digest, int number) {
 return (((long) (digest[3 + number * 4] & 0xFF) << 24)
 | ((long) (digest[2 + number * 4] & 0xFF) << 16)
 | ((long) (digest[1 + number * 4] & 0xFF) << 8)
 | (digest[number * 4] & 0xFF))
 & 0xFFFFFFFFL;
}

我来演示一下第一个副本位置值的生成过程，

假设我们的address是 127.0.0.1:20880，i 为0。

那么此时我们的 digest 就是 127.0.0.1:208800 取 MD5值，其 16 进制为

1

f74f8dee9c0d89ddc47b2926374ec3b5

在 byte 数组中为（展示二进制）

分解上面那个略微复杂但有规律可循的 hash 方法，

首先计算

1

((long) (digest[3 + number * 4] & 0xFF) << 24)

此刻，number为0，

即原式变为

1

((long) (11101110 & 0xFF) << 24)

结果为

1

11101110 00000000 00000000 00000000

依次计算

1
2
3


((long) (digest[2 + number * 4] & 0xFF) << 16)
((long) (digest[1 + number * 4] & 0xFF) << 8)
((long) (digest[1 + number * 4] & 0xFF) << 8)

结果分别为

1
2
3


00000000 10001101 00000000 00000000
00000000 00000000 01001111 00000000
00000000 00000000 00000000 11110111

进行或运算，结果为

1

11101110 10001101 01001111 11110111

再与 0xFFFFFFFFL 进行与运算，保证结果为 32 位。

到这里，我们的第一个副本位置终于确定啦

1

11101110 10001101 01001111 11110111

你可以依葫芦画瓢的由同一个 MD5 值生成另外三个副本位置，

我将另外三个副本位置附上，你可以像上数学课时一样，

当作参考答案，确保自己的思路是正确的。

另外三个副本位置如下：

1
2
3


10011100 00001101 10001001 11011101
11000100 01111011 00101001 00100110
00110111 01001110 11000011 10110101

总结

撒花，终于算完了，我们可以来总结一下了。

在Dubbo的源码中，

我们发现，实现一致性hash算法时，

用于计算副本位置的定位算法，实际上每个位置只需要 MD5 值的四分之一，

而上面提到的合格的散列函数应该（大致）包含一半bit为 0 一半为 1 大于四分之一，

所以定位算法产生的结果覆盖了 0 ~ （2 的 32 次方 -1），

即 hash 环上所有位置，

又因为散列函数的雪崩效应，实现了映射分布的均匀性，

即虚拟节点的均匀分布。

怎么样？同学，对我这个答案还满意吗？

所以说，同一个问题，

或许我们可以“不假思索”的回答，

但有时候我们也可以沉下心来好好研究研究。

一致性Hash算法与虚拟节点

Sat, 05 Jun 2021 01:07:08 +0800

缘起

今天我们来说说“一致性Hash”算法，以及虚拟节点。

这并不是一个难理解的概念，希望一篇文章下来，你能完全吃透。

在网站系统发展初期，前辈工程师探索出了数据库这一系统核心组件，

数据的持久化被与系统本身解耦开，独立发展且愈加可靠。

时间往后推移，随着互联网的普及，一个系统需要承载的用户数量指数级增长，

开发者不得不横向扩展服务器，通过负载均衡技术，使用户分散到各个服务器上。

随着服务器的增多，可靠的数据库系统也不堪重负，

开发者不得不将数据库中的数据通过“分库分表”技术，切分到不同的数据库中，

减轻单一数据库系统的压力。

那么问题来了，如何知道我们需要的数据在哪个数据库中？

没错。hash！

正如我们在 HashMap 中做的一样，对参数取 hash 值，再对 hash 值取模，

就可以既均匀切分存储数据，又知道数据在哪个库中。

简单hash

举个例子，现在有A，B，C，D共4个库，和参数为1，2，3……9，10共10个数据。

我们简化hash算法为乘以1，

即 (1*1)%4=1，参数为1的数据落在A库中。

即 (2*1)%4=2，参数为2的数据落在B库中。

即 (3*1)%4=3，参数为3的数据落在C库中。

即 (4*1)%4=0，参数为4的数据落在D库中。

……

嗯！我很满意，一切井然有序。

当系统需要参数为2的数据时，只需要通过定位算法 (2*1)%4=2 便知道数据存在B库中。

当系统需要参数为9的数据时，只需要通过定位算法 (9*1)%4=1 便知道数据存在A库中。

可好景不长，正当系统稳定健康运行的时候，

B库不知道出现什么问题，失去了连接，系统中只剩下A，C，D共3个库。

这可真糟糕，但是我们还不知道会发生什么事情，对系统的影响有多大。

让我们先把目光聚集到局部上面来分析一下，

参数为2,6和10的数据存在B库上，影响应该是最大的，

如果现在系统需要参数为2的数据，那么它会通过定位算法 (2*1)%3=2 找到C库上。

但很遗憾，C上并没有存储参数为2的数据。

值得庆幸的是，原来数据是有副本的，失去连接的B库数据并没有丢失，而是在一个更大的主库中，

只要给系统一些时间，主库中对应B库的数据，就会根据定位算法被重新分配到A，C，D库中。

分配如下，

即 (2*1)%3=2，参数为2的数据落在C库中。

即 (6*1)%3=0，参数为6的数据落在D库中。

即 (10*1)%3=1，参数为10的数据落在A库中。

好了，现在原来B库中的数据被重新分配到A，C，D库。

当系统需要取数据的时候，只需要通过参数根据定位算法，

到对应的库中读取即可。

如果现在你以为万事大吉，那可就太早了。

别忘了我们刚刚是聚焦到局部来分析状况的。

当我们目光拉远时，我们发现，

不止是参数为2,6,10的数据被重新分配，

几乎所有的数据都被重新分配了！

因为，

(1*1)%3=1，参数为1的数据落在A库中。

(2*1)%3=2，参数为2的数据落在C库中。

(3*1)%3=0，参数为3的数据落在D库中。

……

真是糟糕透顶！

原本是想节约提高性能，结果凭空需要浪费这么多计算资源在重新分配数据上。

该怎么办呢？

诶，对，一致性Hash算法要大显身手了！

一致性Hash算法

一致性Hash算法通过一个 Hash 环，巧妙的让影响降到很低。

假设存在一个 Hash 环，它一圈的范围是 0 到 2^32-1，

先对数据库A，B，C和D的标识做 hash 运算，即上面的定位算法，

确定4个库在 Hash 环上的位置，

再通过定位算法将得出参数为1，2，3……9，10共10个数据在 Hash环上的位置，

这边我们不展示过程，只展示结果。

一致性Hash算法规定我们将数据存在定位到的 Hash 环上位置顺时针遇到的第一个节点（数据库）。

即，

参数为1,4和8的数据存在数据库A中，

参数为5的数据存在数据库B中，

参数为3和7的数据存在数据库C中，

参数为2,6,9和10的数据存在数据库D中。

此时，其实我们已经不惧怕数据库宕机的情况了，

假设我们的数据库B又一次失去连接。

会发生什么情况呢？

影响十分有限，只有数据库A和B在 Hash 环上的位置之间的数据，才受到了影响。

如图，参数为5的数据，需要重新从主库中复制到数据库C中，以保证系统需要参数为5的数据时可以顺利读取到。

而对于其他参数值的数据，并没有受到影响。

以上描述的是节点减少的情况，实际上在节点增加的时候，

一致性Hash算法依然可以保持大部分节点的稳定，不需要改变。

在这里我不做赘述，但你参考上面，独立思考一下。

一致性 Hash 算法如果只是到这里，实际上还引入了一个新的问题——数据倾斜。

即我们假设数据落在 Hash 环上每个位置的概率是一致的，

但实际上，每个节点覆盖的 Hash 环上的大小并不相等，

甚至可能有几倍的差距。

例如，在上面A，C，D库的基础上，我们添加了一个节点——数据库E。

它的位置如图所示。

因为它（数据库E）与上一个节点（数据库D）距离太近，导致没有任何一个数据落到它上面，

而正是与他相近特别近的上一个节点（数据库D），却存储了4个数据，

这就是数据倾斜，有些节点承载了很重的任务，有些节点却悠闲悠闲。

虚拟节点

为了解决数据倾斜的问题，我们还需要加入虚拟节点这一策略。

即，将每个数据库都通过定位算法生成几个在 Hash 环上的位置，

每个位置都承担上面节点的功能，

区别在于原来每个数据库对应一个节点，

现在每个数据库会对应若干个节点，

这就是虚拟节点。

为了避免图过于混乱，这边我标出 E 数据库的 3 个虚拟节点，

可以从图中看出，现在

E#1有 0 个数据，

E#2有 1 个数据（参数为5的数据），

E#3有 2 个数据（参数为6和9的数据）。

而实际上，不管数据定位后归属与E#1、E#2还是E#3，

在实际的数据存储和读取时，都是在数据库 E。

不难发现，在添加了虚拟节点的策略之后，

数据倾斜的情况得到了改善。

这就是完整的一致性Hash算法与虚拟节点啦！

记住，在实际应用中，3个虚拟节点是不够的，你需要更多的虚拟节点，以保证节点的负载更加均衡。