1

这是使用 calico 的 Kubespray 部署。除了存在代理之外，所有默认设置都保持原样。Kubespray 运行到最后没有问题。

对 Kubernetes 服务的访问开始失败，经过调查，没有路由可以托管到coredns服务。通过 IP 访问 K8S 服务有效。其他一切似乎都是正确的，所以我留下了一个可以工作的集群，但没有 DNS。

以下是一些背景信息： 启动一个 busybox 容器：

# nslookup kubernetes.default
Server:     169.254.25.10
Address:    169.254.25.10:53

** server can't find kubernetes.default: NXDOMAIN

*** Can't find kubernetes.default: No answer

现在是显式定义 CoreDNS pod 之一的 IP 时的输出：

# nslookup kubernetes.default 10.233.0.3
;; connection timed out; no servers could be reached

注意 telnet 到 Kubernetes API 是有效的：

# telnet 10.233.0.1 443
Connected to 10.233.0.1

kube-proxy 日志： 10.233.0.3 是 coredns 的服务 IP。最后一行看起来令人担忧，尽管它是 INFO。

$ kubectl logs kube-proxy-45v8n -nkube-system
I1114 14:19:29.657685       1 node.go:135] Successfully retrieved node IP: X.59.172.20
I1114 14:19:29.657769       1 server_others.go:176] Using ipvs Proxier.
I1114 14:19:29.664959       1 server.go:529] Version: v1.16.0
I1114 14:19:29.665427       1 conntrack.go:52] Setting nf_conntrack_max to 262144
I1114 14:19:29.669508       1 config.go:313] Starting service config controller
I1114 14:19:29.669566       1 shared_informer.go:197] Waiting for caches to sync for service config
I1114 14:19:29.669602       1 config.go:131] Starting endpoints config controller
I1114 14:19:29.669612       1 shared_informer.go:197] Waiting for caches to sync for endpoints config
I1114 14:19:29.769705       1 shared_informer.go:204] Caches are synced for service config 
I1114 14:19:29.769756       1 shared_informer.go:204] Caches are synced for endpoints config 
I1114 14:21:29.666256       1 graceful_termination.go:93] lw: remote out of the list: 10.233.0.3:53/TCP/10.233.124.23:53
I1114 14:21:29.666380       1 graceful_termination.go:93] lw: remote out of the list: 10.233.0.3:53/TCP/10.233.122.11:53

所有 pod 都在运行而不会崩溃/重新启动等，否则服务会正常运行。

IPVS 看起来是正确的。CoreDNS 服务在那里定义：

# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.233.0.1:443 rr
  -> x.59.172.19:6443           Masq    1      0          0         
  -> x.59.172.20:6443           Masq    1      1          0         
TCP  10.233.0.3:53 rr
  -> 10.233.122.12:53             Masq    1      0          0         
  -> 10.233.124.24:53             Masq    1      0          0         
TCP  10.233.0.3:9153 rr
  -> 10.233.122.12:9153           Masq    1      0          0         
  -> 10.233.124.24:9153           Masq    1      0          0         
TCP  10.233.51.168:3306 rr
  -> x.59.172.23:6446           Masq    1      0          0         
TCP  10.233.53.155:44134 rr
  -> 10.233.89.20:44134           Masq    1      0          0         
UDP  10.233.0.3:53 rr
  -> 10.233.122.12:53             Masq    1      0          314       
  -> 10.233.124.24:53             Masq    1      0          312

主机路由看起来也正确。

# ip r
default via x.59.172.17 dev ens3 proto dhcp src x.59.172.22 metric 100 
10.233.87.0/24 via x.59.172.21 dev tunl0 proto bird onlink 
blackhole 10.233.89.0/24 proto bird 
10.233.89.20 dev calib88cf6925c2 scope link 
10.233.89.21 dev califdffa38ed52 scope link 
10.233.122.0/24 via x.59.172.19 dev tunl0 proto bird onlink 
10.233.124.0/24 via x.59.172.20 dev tunl0 proto bird onlink 
x.59.172.16/28 dev ens3 proto kernel scope link src x.59.172.22 
x.59.172.17 dev ens3 proto dhcp scope link src x.59.172.22 metric 100 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

我已经用 iptables 而不是 ipvs 在 flannel 和 calico 的不同环境中重新部署了同一个集群。临时部署后，我还禁用了 docker http 代理。这些都没有任何区别。

另外：kube_service_addresses：10.233.0.0/18 kube_pods_subnet：10.233.64.0/18（它们不重叠）

调试此问题的下一步是什么？

4

2 回答 2

2

我强烈建议您避免使用最新的 busybox 映像来排除 DNS 故障。在1.28 之后的版本上，关于 dnslookup 的报告很少。

v 1.28.4

user@node1:~$ kubectl exec -ti busybox busybox | head -1
BusyBox v1.28.4 (2018-05-22 17:00:17 UTC) multi-call binary.

user@node1:~$ kubectl exec -ti busybox -- nslookup kubernetes.default 
Server:    169.254.25.10
Address 1: 169.254.25.10

Name:      kubernetes.default
Address 1: 10.233.0.1 kubernetes.default.svc.cluster.local

v 1.31.1

user@node1:~$ kubectl exec -ti busyboxlatest busybox | head -1
BusyBox v1.31.1 (2019-10-28 18:40:01 UTC) multi-call binary.

user@node1:~$ kubectl exec -ti busyboxlatest -- nslookup kubernetes.default 
Server:     169.254.25.10
Address:    169.254.25.10:53

** server can't find kubernetes.default: NXDOMAIN

*** Can't find kubernetes.default: No answer

command terminated with exit code 1

更深入并探索更多可能性，我在 GCP 上重现了您的问题，经过一番挖掘，我能够找出导致此通信问题的原因。

GCE（谷歌计算引擎）默认阻止主机之间的流量；我们必须允许 Calico 流量在不同主机上的容器之间流动。

根据 calico文档，您可以通过创建允许此通信规则的防火墙来做到这一点：

gcloud compute firewall-rules create calico-ipip --allow 4 --network "default" --source-ranges "10.128.0.0/9"

您可以使用以下命令验证规则：

gcloud compute firewall-rules list

这在最新的 calico 文档中没有出现，但它仍然是真实且必要的。

创建防火墙规则之前：

user@node1:~$ kubectl exec -ti busybox2 -- nslookup kubernetes.default 
Server:    10.233.0.3
Address 1: 10.233.0.3 coredns.kube-system.svc.cluster.local

nslookup: can't resolve 'kubernetes.default'
command terminated with exit code 1

创建防火墙规则后：

user@node1:~$ kubectl exec -ti busybox2 -- nslookup kubernetes.default 
Server:    10.233.0.3
Address 1: 10.233.0.3 coredns.kube-system.svc.cluster.local

Name:      kubernetes.default
Address 1: 10.233.0.1 kubernetes.default.svc.cluster.local

不管你是使用 kubespray 还是 kubeadm 引导你的集群，这个问题都会发生，因为 calico 需要在节点之间进行通信，而 GCE 默认阻止它。

于 2019-11-21T13:19:43.647 回答
0

这对我有用，我尝试使用配置了 calico 作为 CNI 和 containerd 作为容器运行时的 kubespray 安装我的 k8s 集群

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
[delete coredns pod]
于 2021-05-04T13:29:54.440 回答