10.4 在Statefulset中发现伙伴节点
我们仍然需要弄清楚一件很重要的事情。集群应用中很重要的一个需求是伙伴节点彼此能发现——这样才可以找到集群中的其他成员。一个Statefulset中的成员需要很容易地找到其他的所有成员。当然它可以通过与API服务器通信来获取，但是Kubernetes的一个目标是设计功能来帮助应用完全感觉不到Kubernetes的存在。因此让应用与API服务器通信的设计是不允许的。
那如何使得一个pod可以不通过API与其他伙伴通信呢？是否有已知的广泛存在的技术来帮助你达到目的呢？那使用域名系统（DNS）如何？这依赖于你对DNS系统有多熟悉，你可能理解什么是A、CNAME或MX记录的用处是什么。DNS记录里还有其他一些不是那么知名的类型，SRV记录就是其中的一个。
介绍SRV记录
SRV记录用来指向提供指定服务的服务器的主机名和端口号。Kubernetes通过一个headless service创建SRV记录来指向pod的主机名。
可以在一个临时pod里运行DNS查询工具——dig命令，列出你的有状态pod的SRV记录。示例命令如下：
$ kubectl run -it srvlookup --image=tutum/dnsutils --rm --restart=Never -- dig SRV kubia.custom.svc.cluster.local
上面的命令运行一个名为srvlookup的一次性pod（--restart=Never），它会关联控制台（-it）并且在终止后立即删除（--rm）。这个pod依据tutum/dnsutils镜像启动单独的容器，然后运行下面的命令：
dig SRV kubia.default.svc.cluster.local
下面的代码清单显示了这个命令的输出结果。
代码清单10.8 列出你的headless Service的DNS SRV记录
....
;; ANSWER SECTION:
kubia.custom.svc.cluster.local. 30 IN SRV 0 50 80 kubia-1.kubia.custom.svc.cluster.local.
kubia.custom.svc.cluster.local. 30 IN SRV 0 50 80 kubia-0.kubia.custom.svc.cluster.local.
;; ADDITIONAL SECTION:
kubia-1.kubia.custom.svc.cluster.local. 30 IN A 172.18.0.2
kubia-0.kubia.custom.svc.cluster.local. 30 IN A 172.18.0.4
上面的ANSWER SECTION显示了两条指向后台headless service的SRV记录。同时如ADDITIONAL SECTION所示，每个pod都拥有独自的一条记录。
当一个pod要获取一个Statefulset里的其他pod列表时，你需要做的就是触发一次SRV DNS查询。例如，在Node.js中查询命令为：
dns.resolveSrv("kubia.custom.svc.cluster.local", callBackFunction);
可以在你的应用中使用上述命令让每个pod发现它的伙伴pod。
注意 返回的SRV记录顺序是随机的，因为它们拥有相同的优先级。所以不要期望总是看到kubia-0会排在kubia-1前面。
10.4.1 通过DNS实现伙伴间彼此发现
原始的数据存储服务还不是集群级别的，每个数据存储节点都是完全独立于其他节点的——它们彼此之间没有通信。下一步你要做的就是让它们彼此通信。
客户端通过kubia-public Service连接你的数据存储服务，并且会到达集群里随机的一个节点。集群可以存储多条数据项，但是客户端当前却不能看到所有的数据项。因为服务把请求随机地送达一个pod，所以若客户端想获取所有pod的数据，必须发送很多次请求，一直到它的请求发送到所有的pod为止。
可以通过让节点返回所有集群节点数据的方式来改进这个行为。为了达到目的，节点需要能找到它所有的伙伴节点。可以使用之前学习到的Statefulset和SRV记录来实现这个功能。
可以如下面的代码清单所示修改你的应用源码（完整的代码在本书的代码附件中，这里仅展示其中重要的一段）。
代码清单10.9 在简单应用中发现伙伴节点：kubia-pet-peers-image/app.js
const http = require('http');
const os = require('os');
const fs = require('fs');
const dns = require('dns');
const dataFile = "/var/data/kubia.txt";
const serviceName = "kubia.default.svc.cluster.local";
const port = 8080;
function fileExists(file) {
try {
fs.statSync(file);
return true;
} catch (e) {
return false;
}
}
function httpGet(reqOptions, callback) {
return http.get(reqOptions, function(response) {
var body = '';
response.on('data', function(d) { body += d; });
response.on('end', function() { callback(body); });
}).on('error', function(e) {
callback("Error: " + e.message);
});
}
var handler = function(request, response) {
if (request.method == 'POST') {
var file = fs.createWriteStream(dataFile);
file.on('open', function (fd) {
request.pipe(file);
response.writeHead(200);
response.end("Data stored on pod " + os.hostname() + "\n");
});
} else {
response.writeHead(200);
if (request.url == '/data') {
var data = fileExists(dataFile) ? fs.readFileSync(dataFile, 'utf8') : "No data posted yet";
response.end(data);
} else {
response.write("You've hit " + os.hostname() + "\n");
response.write("Data stored in the cluster:\n");
dns.resolveSrv(serviceName, function (err, addresses) { # 通过DNS查询SRV记录
if (err) {
response.end("Could not look up DNS SRV records: " + err);
return;
}
var numResponses = 0;
if (addresses.length == 0) {
response.end("No peers discovered.");
} else {
addresses.forEach(function (item) { #与每个SRV记录的pod通信
var requestOptions = {
host: item.name,
port: port,
path: '/data'
};
httpGet(requestOptions, function (returnedData) {
numResponses++;
response.write("- " + item.name + ": " + returnedData + "\n");
if (numResponses == addresses.length) {
response.end();
}
});
});
}
});
}
}
};
var www = http.createServer(handler);
www.listen(port);
图10.12展示了一个GET请求到达你的应用后的处理过程。首先收到请求的服务器会触发一次headless kubia服务的SRV记录查询，然后发送GET请求到服务背后的每一个pod（也会发送给自己，虽说没有必要，这里只是为了保证代码简单易懂），然后返回所有节点和它们的数据信息的列表。
[图片上传失败...(image-7c7606-1627739427880)]
图10.12 简单的分布式数据存储服务的操作流程
包含最新版本内容的应用对应的容器镜像链接为：docker.io/luksa/kubia-petpeers。
10.4.2 更新Statefulset
现在你的Statefulset已经运行起来，那让我们看一下如何更新它的pod模板，让它使用新的镜像。同时你也会修改副本数为3。通常会使用kubectl edit命令来更新Statefulset（另一个选择是patch命令）。
$ kubectl edit statefulset kubia
上面的命令会使用默认的编辑器打开Statefulset的定义。在定义中，修改 spec.replicas 为3，修改 spec.template.spec.containers.image 属性指向新的镜像（使用luksa/kubia-pet-peers替换 luksa/kubia-pet）。然后保存文件并退出，Statefulset就会更新。
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: kubia
spec:
serviceName: kubia
replicas: 3
selector:
matchLabels:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: luksa/kubia-pet-peers
ports:
- name: http
containerPort: 8080
volumeMounts:
- name: data
mountPath: /var/data
volumeClaimTemplates:
- metadata:
name: data
spec:
resources:
requests:
storage: 1Mi
accessModes:
- ReadWriteOnce
之前Statefulset有两个副本，现在应该可以看到一个新的名叫kubia-2的副本启动了。通过下面的代码列出pod来确认：
$ kubectl get po
新的pod实例会使用新的镜像运行，那已经存在的两个副本呢？Statefulset支持与 Deployment和DaemonSet一样的滚动升级。 Statefulset会依据新的模板重新调度启动它们。
$ watch kubectl get pod
10.4.3 尝试集群数据存储
当两个pod都启动后，即可测试你的崭新的新石器时代的数据存储是否按预期一样工作了。如下面的代码清单所示，发送一些请求到集群。
代码清单10.10 通过service往集群数据存储中写入数据
$ curl -X POST -d "The sun is shining" \localhost:8001/api/v1/namespaces/custom/services/kubia-public/proxy/$ curl -X POST -d "The weather is sweet" \localhost:8001/api/v1/namespaces/custom/services/kubia-public/proxy
现在，读取存储的数据，如下面的代码清单所示。
代码清单10.11 从数据存储中读取数据
$ curl localhost:8001/api/v1/namespaces/custom/services/kubia-public/proxy/
非常棒！当一个客户端请求到达集群中任意一个节点后，它会发现它的所有伙伴节点，然后通过它们收集数据，然后把收集到的所有数据返回给客户端。即使你扩容或缩容Statefulset，服务于客户端请求的pod都会找到所有的伙伴节点。
这个应用本身也许没太多用处，但笔者希望你觉得这是一种有趣的方式，一个多副本Statefulset应用的实例如何发现它的伙伴，并且随需求做到横向扩展。