windows - windows节点上的Kubernetes服务无法访问
问题描述
我目前正在开发一个混合的 Linux/Windows Kubernetes 集群。它目前有 4 个节点，在单个物理服务器上的 VMWare 集群中作为 VM 运行：
- 3 个在 debian 上运行并使用 kubeadm 配置的 Linux 节点
- 1 个基于Microsoft 文档配置的 Windows Server 2019 (1809) 节点。
按照微软的建议，我在 host-gw 模式下使用 flannel 进行网络连接。IP 已正确分配给各自范围内的 Pod 和服务（Pod 为 10.244.0.0/16，服务为 10.96.0.0/12）。
整个事情都是在 Kubernetes 1.13 上运行的。从 1.12.3 升级，今天刚从Microsoft/SDN下载的 flannel 二进制文件。
用于启动服务的 Windows Powershell 命令：
.\start.ps1 -ManagementIP 10.71.145.37 -ClusterCIDR 10.244.0.0/16 -ServiceCIDR 10.96.0.0/12 -KubeDnsServiceIP 10.96.0.10
什么在起作用？
- Linux pod -> Linux pod：是
- Linux 吊舱 -> Windows 吊舱：是
- Windows 吊舱 -> Linux 吊舱：是
- Windows 吊舱 -> Windows 吊舱：是
- Linux pod -> Linux 服务：是
- Linux pod -> Windows 服务：否
- Windows pod -> Linux 服务：否
- Windows pod -> Windows 服务：否
- Linux 主机 -> Linux pod：是
- Linux 主机 -> Windows pod：是
- Windows 主机 -> Linux pod：是
- Windows 主机 -> Windows pod：是
- Linux 主机 -> Linux 服务：是
- Linux 主机 -> Windows 服务：否
- Windows 主机 -> Linux 服务：否
- Windows 主机 -> Windows 服务：否
长话短说：与 pod 的直接连接跨 Windows 和 Linux 工作，服务连接仅适用于 Linux 服务（由 Linux pod 支持的服务）并且仅适用于 Linux pod 或主机。
DNS 解析也在工作，虽然我无法service.namespace在 Windows pod 上解析，只是主机名或 FQDN 工作，两者之间没有任何关系。
来自 Linux 节点的路由表：
# host linux-node-1: 10.71.144.71
root@linux-node-1:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.71.144.1 0.0.0.0 UG 0 0 0 ens32
10.71.144.0 0.0.0.0 255.255.252.0 U 0 0 0 ens32
10.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
10.244.1.0 linux-node-2 255.255.255.0 UG 0 0 0 ens32
10.244.2.0 linux-node-3 255.255.255.0 UG 0 0 0 ens32
10.244.5.0 windows-node-1 255.255.255.0 UG 0 0 0 ens32
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
# host linux-node-2: 10.71.147.15
root@linux-node-2:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.71.144.1 0.0.0.0 UG 0 0 0 ens32
10.71.144.0 0.0.0.0 255.255.252.0 U 0 0 0 ens32
10.244.0.0 linux-node-1 255.255.255.0 UG 0 0 0 ens32
10.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
10.244.2.0 linux-node-3 255.255.255.0 UG 0 0 0 ens32
10.244.5.0 windows-node-1 255.255.255.0 UG 0 0 0 ens32
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
# host linux-node-3: 10.71.144.123
root@linux-node-3:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.71.144.1 0.0.0.0 UG 0 0 0 ens32
10.71.144.0 0.0.0.0 255.255.252.0 U 0 0 0 ens32
10.244.0.0 linux-node-1 255.255.255.0 UG 0 0 0 ens32
10.244.1.0 linux-node-2 255.255.255.0 UG 0 0 0 ens32
10.244.2.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
10.244.5.0 windows-node-1 255.255.255.0 UG 0 0 0 ens32
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
Windows 节点的路由表：
PS C:\k> route print
===========================================================================
Interface List
9...00 50 56 89 69 ce ......Hyper-V Virtual Ethernet Adapter #2
21...00 15 5d 8d 98 26 ......Hyper-V Virtual Ethernet Adapter #3
1...........................Software Loopback Interface 1
12...00 15 5d 84 c0 c9 ......Hyper-V Virtual Ethernet Adapter
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.71.144.1 10.71.145.37 25
0.0.0.0 0.0.0.0 10.244.5.1 10.244.5.2 281
10.71.144.0 255.255.252.0 On-link 10.71.145.37 281
10.71.145.37 255.255.255.255 On-link 10.71.145.37 281
10.71.145.37 255.255.255.255 10.71.144.1 10.71.145.37 125
10.71.147.255 255.255.255.255 On-link 10.71.145.37 281
10.244.0.0 255.255.255.0 10.71.144.71 10.71.145.37 281
10.244.1.0 255.255.255.0 10.71.147.15 10.71.145.37 281
10.244.2.0 255.255.255.0 10.71.144.123 10.71.145.37 281
10.244.5.0 255.255.255.0 On-link 10.244.5.2 281
10.244.5.2 255.255.255.255 On-link 10.244.5.2 281
10.244.5.255 255.255.255.255 On-link 10.244.5.2 281
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
172.27.80.0 255.255.240.0 On-link 172.27.80.1 5256
172.27.80.1 255.255.255.255 On-link 172.27.80.1 5256
172.27.95.255 255.255.255.255 On-link 172.27.80.1 5256
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 172.27.80.1 5256
224.0.0.0 240.0.0.0 On-link 10.71.145.37 281
224.0.0.0 240.0.0.0 On-link 10.244.5.2 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 172.27.80.1 5256
255.255.255.255 255.255.255.255 On-link 10.71.145.37 281
255.255.255.255 255.255.255.255 On-link 10.244.5.2 281
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 10.244.5.1 Default
10.244.0.0 255.255.255.0 10.71.144.71 Default
10.244.1.0 255.255.255.0 10.71.147.15 Default
10.244.2.0 255.255.255.0 10.71.144.123 Default
0.0.0.0 0.0.0.0 10.244.5.2 Default
10.71.145.37 255.255.255.255 10.71.144.1 100
===========================================================================
从 Windows pod 到 kube-dns 的 Traceroute：
C:\>tracert -4 -d -h 10 10.96.0.10
Tracing route to 10.96.0.10 over a maximum of 10 hops
2
1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
Trace complete.
从 Linux pod 到 kube-dns 的 Traceroute：
root@deb:/# traceroute -4 -n 10.96.0.10
traceroute to 10.96.0.10 (10.96.0.10), 30 hops max, 60 byte packets
1 10.244.2.1 0.396 ms 0.336 ms 0.314 ms
2 10.71.144.1 7.044 ms 9.939 ms 10.062 ms
3 10.71.144.2 1.727 ms 1.917 ms 10.71.144.3 1.233 ms
4 10.68.132.166 6.985 ms 10.68.132.162 7.934 ms 8.404 ms
5 10.103.4.246 203.807 ms 203.405 ms 203.777 ms
6 10.103.4.245 209.431 ms 209.348 ms 209.772 ms
7 10.96.108.86 496.457 ms 502.957 ms 494.978 ms
8 10.96.0.10 211.666 ms * *
1 跳是 pod 网络地址，2 和 3 跳是 Linux 主机的标准网关（VRRP），7 跳是物理网络中的交换机，8 跳是 kube-dns 服务，其余的跳（4-6 ) 可能是物理网络中的 Cisco 路由器。
DNS 查询正在工作，我可以从主机 ping 10.96.0.1（kubernetes 服务）和 10.96.0.10（kube-dns）这一事实让我相信路由工作正常，但我无法 ping 任何其他服务地址，也不能例如，我从 Windows 主机卷曲我的入口控制器。
禁用 Windows 防火墙也没有什么不同。
我不知道我还能在这里检查什么，谷歌搜索几乎没有任何适用的东西。
解决方案
关于 Windows 服务失败：您可以发布 CollectLogs.ps1 输出（https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/windows/debug/collectlogs.ps1）和您的 CNI 配置文件吗？Windows pod 可以访问外部互联网（例如 curl -useb http://google.com吗？）
此外，最近在 KubeCon 上发布了一个视频，详细介绍了如何在 Windows 上解决 Kubernetes 网络问题，您可能会觉得这很有帮助：https ://www.youtube.com/watch?v=tTZFoiLObX4&feature=youtu.be
关于 service.namespace 的解析，不幸的是，这是当今 Windows 上 DNS 解析器设计的行为差异，其中任何包含点的名称搜索都会被权威地处理。这也是为什么默认的 CNI 配置文件没有在 SearchList 中指定的所需的 DNS 足够，这在今天不起作用。此行为在 Windows Server 版本 1903 版本之前不会更改。
推荐阅读
- python - AttributeError：“MySQL”对象没有属性“模型”
- javascript - Vanilla JavaScript - 仅使用事件冒泡选择“this”特定元素
- android - 在 Google Play 商店中打开应用程序
- node.js - 如何在此处触发错误页面的获取请求？
- node.js - Nodejs - 从生成的 bat 文件进程中隐藏窗口 | 视窗
- sql-server - 使用延迟加载时，Entity Framework 如何知道 X 实体有 Y 实体的集合？
- winforms - 在控制台应用程序中使用 RadDesktopAlert
- javascript - 尝试访问 facebook graph api 回调中的生成器函数功能
- java - 如何将 Java 解释为 Lua 数字以将纪元转换为人类可读
- r - 如何在 R ggplot（饼图）中绘制前 2 行与其他行