windows节点上的Kubernetes服务无法访问

【问题标题】：Kubernetes service on windows node not reachablewindows节点上的Kubernetes服务无法访问
【发布时间】：2019-05-07 07:31:57
【问题描述】：

我目前正在开发一个混合的 Linux/Windows Kubernetes 集群。 它目前有 4 个节点，在单个物理服务器上的 VMWare 集群中作为虚拟机运行：

  • 3 个 Linux 节点在 debian stretch 上运行并使用 kubeadm 进行配置
  • 1 个基于Microsoft's documentation 配置的 Windows Server 2019 (1809) 节点。

按照 Microsoft 的建议，我在 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 pod -> Windows pod：是
  • Windows pod -> Linux pod：是
  • Windows pod -> Windows pod：是
  • 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 解析也有效，虽然我无法在 Windows pod 上解析 service.namespace，只是主机名或 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 docker networking kubernetes flannel


【解决方案1】：

关于 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 版本之前不会更改。

【讨论】：

    猜你喜欢
    • 2018-09-12
    • 2018-02-27
    • 2020-09-02
    • 1970-01-01
    • 1970-01-01
    • 2016-11-17
    • 2020-05-19
    • 2020-07-15
    • 2020-03-04
    相关资源
    最近更新 更多
    热门标签
    Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode