Служба Kubernetes на узле Windows недоступна - PullRequest
Новая
       8

Служба Kubernetes на узле Windows недоступна

0 голосов
/ 05 декабря 2018

В настоящее время я работаю над смешанным кластером 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 -> Модуль Linux: да
  • Модуль Linux -> Модуль Windows: да
  • Модуль Windows -> Модуль Linux: да
  • Модуль Windows -> Модуль Windows: да
  • Модуль Linux -> Служба Linux: да
  • Модуль Linux -> Служба Windows: нет
  • Модуль Windows -> Linuxслужба: нет
  • модуль Windows -> служба Windows: нет
  • узел Linux -> модуль Linux: да
  • узел Linux -> модуль Windows: да
  • Хост Windows -> Модуль Linux: да
  • Хост Windows -> Модуль Windows: да
  • Хост Linux -> Служба Linux: да
  • Хост Linux -> Служба Windows:нет
  • Хост Windows -> служба Linux: нет
  • Хост Windows -> служба Windows: нет

Короче говоря: прямые подключения к модулям работают черезWindows и Linux, сервисные соединения работают только для сервисов Linux (сервисов, поддерживаемых модулями Linux) и только с модулей или хостов Linux.

Разрешение DNS также работает, хотя я не могу разрешить service.namespace на модулях Windows, простоимя хоста или полное доменное имя работают, ничего между ними.

Таблицы маршрутизации с узлов 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 to kube-dns: 

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 к 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 * *

Hop 1 - это сетевой адрес модуля, hops 2 и 3 - стандартный шлюз(VRRP) хоста Linux, hop 7 - это коммутатор в физической сети, hop 8 - это сервис kube-dns, остальные прыжки (4-6), вероятно, маршрутизаторы Cisco в физической сети.

Тот факт, что DNS-запросы работают, и я могу пропинговать 10.96.0.1 (сервисы kubernetes) и 10.96.0.10 (kube-dns) с хоста, позволяет мне полагать, что маршрутизация работает, но я не могу пропинговать ни другой адрес сервиса, нимогу я например, сверните мой входной контроллер с хоста Windows.

Отключение брандмауэра Windows также не имеет значения.

У меня нет идей о том, что еще я могу проверить здесь, и почти не гуглюсьприносит что-нибудь применимое.

1 Ответ

0 голосов
/ 13 декабря 2018

Относительно сбоя служб 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 года.

...