Question

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

初始设置后运行正常，但是昨晚关闭所有内容并在今天早上重启所有虚拟机后，kube-apiserver不再在任何主节点上启动。它在所有节点上失败，并显示一条消息，指出它无法创建存储后端（超出上下文截止时间）＆＃34;：

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＆＃34;增强＆＃34;重定向错误DNS查询的服务。

我的节点未在DNS中注册，因为这只是一个实验性群集。我在/ etc / hosts中有他们的条目，但那就是它。显然kube-apiserver中的某些东西试图解析我的etcd节点名称（例如master0.localdomain）并在/ etc / hosts之前查询DNS（我一直认为/ etc / hosts优先）。而不是拒绝无效的名称，我的ISP（Verizon FIOS）正在使用这个＆＃34;增强型＆＃34;重定向到unallocated.barefruit.co.uk的DNS服务，令人惊讶的是，它并没有为我运行一个etcd集群。

我在主节点上编辑了网络配置，以证明我的假设，添加明确的DNS设置，指向谷歌的服务器8.8.8.8和8.8.4.4，这些服务器不是＆＃34;增强的＆＃34;。然后我重新启动，群集就出现了。

那么昨晚和今天之间究竟发生了什么变化？我的实验性集群在我的笔记本电脑上运行，昨天我在办公室工作（没有FIOS），而今天我在家工作（连接到FIOS）。啊。谢谢Verizon！

我还不确定为什么kube-apiserver似乎优先考虑DNS / etc / hosts上的DNS。但我想我们的教训是确保您的节点名称具有有效的DNS条目或通过IP地址指定所有内容。任何人都有任何想法，哪种是最佳做法？

Answer 2

我遇到了这个问题，并通过删除主机OS上的/ etc / kubernetes目录并重新安装k8s来解决了该问题。（使用Rancher）

kube-apiserver无法创建存储后端

2 个答案: