kubernetes - kube-apiserver 无法创建存储后端

Question

我按照官方Creating HA clusters with kubeadm搭建了一个高可用的Kubernetes集群指导。这是一个用于探索本地高可用性部署可行性的实验性集群，因此我在 VMware Workstation 上托管的六个 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 list 文件并将 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“增强”服务，可以重定向错误的 DNS 查询。

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

我编辑了主节点上的网络配置以证明我的假设，添加了指向未“增强”的谷歌服务器 8.8.8.8 和 8.8.4.4 的显式 DNS 设置。然后我重新启动，集群就出现了。

那么昨晚和今天之间到底发生了什么变化呢？我的实验集群在我的笔记本电脑上运行，昨天我在办公室工作(没有 FIOS)，而今天我在家工作(连接到 FIOS)。啊。感谢威瑞森!

我仍然不确定为什么 kube-apiserver 似乎将 DNS 优先于/etc/hosts。但我想教训是要么确保您的节点名称具有有效的 DNS 条目，要么按 IP 地址指定所有内容。任何人都对哪种最佳做法有任何想法？