Служба Kubernetes на узле Windows недоступна
В настоящее время я работаю над смешанным кластером Linux/Windows Kubernetes. В настоящее время это 4 узла, которые работают как виртуальные машины в кластере VMWare на одном физическом сервере:
- 3 узла Linux, работающих на Debian Stretch и сконфигурированных с использованием kubeadm
- 1 Windows Server 2019 (1809) узел настроен на основе документации Microsoft.
Я использую фланель в режиме host-gw для работы в сети, как это было предложено Microsoft. IP-адреса должным образом назначены для модулей и служб в соответствующих диапазонах (10.244.0.0/16 для модулей и 10.96.0.0/12 для служб).
Все это работает с Kubernetes 1.13. обновленный с 1.12.3 и фланелевые бинарные файлы, недавно загруженные сегодня также из Microsoft / SDN.
Команда 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 -> Служба Windows: нет
- Linux host -> Linux pod: да
- Linux host -> Windows pod: да
- Windows host -> Linux pod: да
- Windows host -> Windows pod: да
- Linux host -> служба Linux: да
- Linux host -> служба Windows: нет
- Хост Windows -> служба Linux: нет
- Хост Windows -> Служба Windows: нет
Короче говоря: прямые подключения к модулям работают в Windows и Linux, подключения к службам работают только для служб Linux (служб, поддерживаемых модулями Linux) и только из модулей или узлов Linux.
Разрешение DNS также работает, хотя я не могу разрешить service.namespace на Windows pods работает только имя хоста или полное доменное имя, ничего между ними.
Таблицы маршрутизации от узлов 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-модуля в куб-днс:
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:
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 - это сетевой адрес модуля, переходы 2 и 3 - стандартный шлюз (VRRP) хоста Linux, переход 7 - это коммутатор в физической сети, переход 8 - служба kube-dns, остальные переходы (4-6), вероятно, маршрутизаторы Cisco в физической сети.
Тот факт, что DNS-запросы работают, и я могу пропинговать 10.96.0.1 (сервисы kubernetes) и 10.96.0.10 (kube-dns) с хоста, позволяет мне полагать, что маршрутизация работает, но я не могу пропинговать любой другой адрес сервиса и не могу Я, например, скручиваю свой входной контроллер с хоста Windows.
Отключение брандмауэра Windows также не имеет значения.
У меня нет идей о том, что еще я могу проверить здесь, и поиск в Google едва приносит что-либо применимое.
1 ответ
Относительно сбоя служб Windows: Можете ли вы опубликовать вывод CollectLogs.ps1 ( https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/windows/debug/collectlogs.ps1) и файл конфигурации CNI? Могут ли модули Windows выходить во внешний Интернет (например, curl -useb http://google.com/?)
Кроме того, недавно на KubeCon было представлено видео, подробно рассказывающее о том, как решать проблемы с сетью Kubernetes в Windows, которое может оказаться полезным: https://www.youtube.com/watch?v=tTZFoiLObX4&feature=youtu.be
Что касается разрешения service.namespace, к сожалению, в настоящее время это различие в поведении в связи с разработкой DNS-распознавателя в Windows, при которой любые поиски имен, содержащие точки, обрабатываются авторитетно. По этой же причине в конфигурационном файле CNI по умолчанию отсутствуют необходимые DNS-суффиксы, указанные в списке поиска, который сегодня не работает. Это поведение не изменится раньше, чем Windows Server версии 1903 года выпуска.