kube-apiserver无法创建存储后端

Question

我按照官方的Creating HA clusters with kubeadm指南设置了一个高可用性Kubernetes集群。这是一个实验群集，用于探索内部高可用性部署的可行性，因此，我在VMware工作站上托管的六台Cent OS 7虚拟机上创建了该群集-三个主节点和三个工作节点。

它在初始设置后运行良好，但是在我昨晚关闭所有东西并在今天早上重新启动所有VM之后，kube-apiserver不再在任何主节点上启动。它在所有节点上都失败，并显示一条消息，指出它无法创建存储后端(超过上下文截止日期)：

F0614 20:18:43.297064       1 storage_decorator.go:57] Unable to create storage backend: config (&{ /registry [https://192.168.56.10.localdomain:2379 https://192.168.56.11.localdomain:2379 https://192.168.56.12.localdomain:2379] /etc/pki/tls/private/client-key.pem /etc/pki/tls/certs/client.pem /etc/pki/ca-trust/source/anchors/ca.pem true false 1000 0xc42047e100 <nil> 5m0s 1m0s}), err (context deadline exceeded)

这表明etcd有问题，但etcd集群报告健康，我可以成功地使用它来设置和查询值，使用提供给kube-apiserver的相同证书。

我的版本是：

CentOS 7.5.1804
Kubernetes - 1.10.4
Docker - 18.03.1-ce
etcd - 3.1.17
keepalived - 1.3.5

尽管昨晚所有这些都工作得很好，但为了排除版本冲突，我尝试将--storage-backend=etcd3添加到kube-apiserver.yaml清单文件中，并将Docker降级到17.03.2-ce。两者都没有帮助。

我还禁用了firewalld，以确保它不会阻塞任何etcd流量。同样，这也没有帮助(我也没有看到任何连接中断的证据)

我不知道如何更深入地研究kube-apiserver为什么不能创建其存储后端。到目前为止，我的高可用性实验是失败的。

Answer 1

错误消息(context deadline expired)末尾的详细信息建议超时(Go的context package用于处理超时)。但是当我通过etcdctl直接访问etcd集群时，我没有看到任何缓慢的情况，所以我设置了一个tcpdump捕获，看看它是否能告诉我关于kube-apiserver和etcd之间发生的事情的更多信息。我过滤了端口2379，这是etcd的客户端请求端口：

tcpdump -i any port 2379

一开始我没有看到任何活动，所以我通过etcdctl直接查询etcd来强制执行活动。这起作用了，它显示了到端口2379的预期流量。

在这一点上，我仍然被卡住了，因为kube-apiserver似乎根本没有调用etcd。但是随后tcpdump的输出中出现了一些神秘的条目：

18:04:30.912541 IP master0.34480 > unallocated.barefruit.co.uk.2379: Flags [S], seq 1974036339, win 29200, options [mss 1460,sackOK,TS val 4294906938 ecr 0,nop,wscale 7], length 0
18:04:32.902298 IP master0.34476 > unallocated.barefruit.co.uk.2379: Flags [S], seq 3960458101, win 29200, options [mss 1460,sackOK,TS val 4294908928 ecr 0,nop,wscale 7], length 0
18:04:32.910289 IP master0.34478 > unallocated.barefruit.co.uk.2379: Flags [S], seq 2100196833, win 29200, options [mss 1460,sackOK,TS val 4294908936 ecr 0,nop,wscale 7], length 0

什么是unallocated.barefruit.co.uk ?为什么我的主节点上的一个进程试图向它发出etcd客户端请求？

在谷歌上快速搜索一下，就会发现unallocated.barefruit.co.uk是一项域名系统“增强”服务，可以重定向不好的域名系统查询。

我的节点没有在DNS中注册，因为这只是一个实验集群。我在/etc/hosts中有它们的条目，但仅此而已。显然，kube-apiserver中的某些东西正在尝试解析我的etcd节点名(例如，master0.localdomain)，并且在/etc/hosts之前查询DNS (我总是认为/etc/hosts优先)。我的ISP (Verizon FIOS)没有拒绝无效的域名，而是使用了这个“增强的”DNS服务，它重定向到unallocated.barefruit.co.uk，令人惊讶的是，它并没有为我运行etcd集群。

我编辑了我的主节点上的网络配置，以证明我的假设，添加了指向google服务器8.8.8.8和8.8.4.4的显式DNS设置，这些设置没有“增强”。然后我重启了系统，集群马上就出现了。

那么从昨晚到今天到底发生了什么变化呢？我的实验集群在我的笔记本电脑上运行，昨天我在办公室工作(没有FIOS)，而今天我在家里工作(连接到FIOS)。呃。谢谢Verizon！

我仍然不确定为什么kube-apiserver似乎优先考虑DNS而不是/etc/hosts。但我猜教训是要么确保您的节点名称具有有效的DNS条目，要么通过IP地址指定所有内容。有没有人有关于哪种是最佳实践的想法？

Answer 2

我遇到了这个问题，并通过删除主机操作系统上的/etc/kubernetes目录并重新安装k8s来解决它。(使用Rancher)