Поделиться через

Устранение неполадок Kubernetes

  • Статья

На этой странице рассматриваются некоторые распространенные проблемы с настройкой Kubernetes, сетями и развертываниями.

Совет

Предложить элемент часто задаваемых вопросов, вызвав pr в наш репозиторий документации.

Эта страница разделена на следующие категории:

  1. Общие вопросы
  2. Распространенные сетевые ошибки
  3. Распространенные ошибки Windows
  4. Распространенные основные ошибки Kubernetes

Общие вопросы

Разделы справки знать, что Kubernetes в Windows завершено успешно?

Вы должны увидеть kubelet, kube-proxy и (если вы выбрали Flannel в качестве сетевого решения) фланнеллированные процессы агента узла, выполняемые на узле. Помимо этого, узел Windows должен быть указан как "Готово" в кластере Kubernetes.

Можно ли настроить выполнение всех этих действий в фоновом режиме?

Начиная с Kubernetes версии 1.11, kubelet и kube-proxy можно запускать как собственные службы Windows. Вы также можете использовать альтернативные диспетчеры служб, такие как nssm.exe , чтобы всегда выполнять эти процессы (flanneld, kubelet и kube-proxy) в фоновом режиме.

Распространенные сетевые ошибки

Подсистемы балансировки нагрузки несогласованы между узлами кластера

В Windows kube-proxy создает подсистему балансировки нагрузки HNS для каждой службы Kubernetes в кластере. В конфигурации kube-proxy узлы в кластерах с множеством (обычно 100+) подсистемы балансировки нагрузки могут выйти из доступных временных TCP-портов (a.k.a. динамический диапазон портов, который по умолчанию охватывает порты 49152–65535). Это связано с большим количеством портов, зарезервированных на каждом узле для каждого балансировщика нагрузки (не dsR). Эта проблема может проявляться через ошибки в kube-proxy, например:

Policy creation failed: hcnCreateLoadBalancer failed in Win32: The specified port already exists.

Пользователи могут определить эту проблему, выполнив скрипт CollectLogs.ps1 и проконсультировавшись с файлами *portrange.txt .

Также CollectLogs.ps1 будет имитировать логику выделения HNS для тестирования доступности распределения пула портов в диапазоне эфемерных TCP-портов и сообщите об успешном выполнении и сбое в reservedports.txt. Скрипт резервирует 10 диапазонов из 64 временных портов TCP (для эмуляции поведения HNS), подсчитывает успехи резервирования и сбои, а затем освобождает выделенные диапазоны портов. Число успешного выполнения меньше 10 указывает, что временный пул занимает свободное место. Эвристическая сводка о том, сколько резервирований портов из 64 блоков, также будет создано в reservedports.txt.

Чтобы устранить эту проблему, можно выполнить несколько действий.

  1. Для постоянного решения балансировка нагрузки kube-proxy должна иметь режим DSR. Режим DSR полностью реализован и доступен только в новой сборке программы предварительной оценки Windows Server 18945 (или более поздней версии).
  2. В качестве обходного решения пользователи также могут увеличить конфигурацию Windows по умолчанию для временных портов, доступных с помощью команды, например netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>. ПРЕДУПРЕЖДЕНИЕ. Переопределение диапазона динамических портов по умолчанию может иметь последствия для других процессов и служб на узле, которые полагаются на доступные TCP-порты из неэфемерного диапазона, поэтому этот диапазон следует тщательно выбрать.
  3. Существует улучшение масштабируемости подсистем балансировки нагрузки, отличных от DSR, с помощью интеллектуального совместного использования пула портов, включенных в накопительный пакет обновления KB4551853 (и всех новых накопительных обновлений).

Публикация HostPort не работает

Чтобы использовать функцию HostPort, убедитесь, что подключаемые модули CNI версии 0.8.6 или выше, а файл конфигурации CNI имеет portMappings набор возможностей:

"capabilities": {
    "portMappings":  true
}

Я вижу ошибки, такие как "hnsCall произошел сбой в Win32: неправильный дискет находится на диске".

Эта ошибка может возникать при внесении пользовательских изменений в объекты HNS или установке новых Обновл. Windows, которые вводят изменения в HNS без разрыва старых объектов HNS. Он указывает, что объект HNS, созданный ранее перед обновлением, несовместим с текущей установленной версией HNS.

В Windows Server 2019 (и более ранних версиях) пользователи могут удалять объекты HNS, удалив файл HNS.data

Stop-Service HNS
rm C:\ProgramData\Microsoft\Windows\HNS\HNS.data
Start-Service HNS

Пользователи должны иметь возможность напрямую удалять все несовместимые конечные точки или сети HNS:

hnsdiag list endpoints
hnsdiag delete endpoints <id>
hnsdiag list networks
hnsdiag delete networks <id>
Restart-Service HNS

Пользователи в Windows Server версии 1903 могут перейти в следующее расположение реестра и удалить все сетевые адаптеры, начиная с сетевого имени (например vxlan0 , или cbr0):

\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\NicList

Контейнеры в развертывании host-gw flannel в Azure не могут получить доступ к Интернету

При развертывании Flannel в режиме host-gw в Azure пакеты должны пройти через vSwitch физического узла Azure. Пользователи должны программировать определяемые пользователем маршруты типа "виртуальное устройство" для каждой подсети, назначенной узлу. Это можно сделать с помощью портал Azure (см. пример здесь) или с помощью az Azure CLI. Ниже приведен один пример UDR с именем MyRoute с помощью az commands для узла с IP 10.0.0.4 и соответствующей подсетью pod 10.244.0.0/24:

az network route-table create --resource-group <my_resource_group> --name BridgeRoute 
az network route-table route create  --resource-group <my_resource_group> --address-prefix 10.244.0.0/24 --route-table-name BridgeRoute  --name MyRoute --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4 

Совет

При развертывании Kubernetes на виртуальных машинах Azure или IaaS из других поставщиков облачных служб можно также использовать overlay networking .

Мои модули pod Windows не могут выполнять проверку подлинности внешних ресурсов

Модули pod Windows не имеют правил исходящего трафика, запрограммированных для протокола ICMP сегодня. Однако поддерживается протокол TCP/UDP. При попытке продемонстрировать подключение к ресурсам за пределами кластера замените ping <IP> соответствующими curl <IP> командами.

Если вы по-прежнему сталкиваетесь с проблемами, скорее всего, ваша конфигурация сети в cni.conf заслуживает дополнительного внимания. Вы всегда можете изменить этот статический файл, конфигурация будет применена к любым вновь созданным ресурсам Kubernetes.

Почему? Одним из требований к сети Kubernetes (см . модель Kubernetes) является подключение к кластеру без NAT внутри сети. Для выполнения этого требования у нас есть список исключений для всех сообщений, в которых мы не хотим выполнять исходящий NAT. Однако это также означает, что необходимо исключить внешний IP-адрес, который вы пытаетесь запросить из ExceptionList. Только после этого трафик, исходящий из модулей pod Windows, будет правильно создан SNAT, чтобы получить ответ от внешнего мира. В этом отношении список исключений должен cni.conf выглядеть следующим образом:

"ExceptionList": [
  "10.244.0.0/16",  # Cluster subnet
  "10.96.0.0/12",   # Service subnet
  "10.127.130.0/24" # Management (host) subnet
]

Мой узел Windows не может получить доступ к службе NodePort

Локальный доступ NodePort с самого узла может завершиться ошибкой. Это известный разрыв функций, который устраняется с накопительным обновлением KB4571748 (или более поздней версии). Доступ NodePort будет работать с другими узлами или внешними клиентами.

Мой узел Windows останавливает маршрутизацию thourgh NodePorts после уменьшения масштаба модулей pod

Из-за ограничения разработки необходимо иметь по крайней мере один модуль pod, работающий на узле Windows для переадресации NodePort.

Через некоторое время удаляются виртуальные сетевые адаптеры и конечные точки HNS контейнеров.

Эта проблема может быть вызвана, если hostname-override параметр не передается в kube-proxy. Чтобы устранить эту проблему, пользователям необходимо передать имя узла в kube-proxy следующим образом:

C:\k\kube-proxy.exe --hostname-override=$(hostname)

В режиме Flannel (vxlan) мои модули pod имеют проблемы с подключением после повторного соединения узла.

При повторном подключении к кластеру удаленного узла flannelD попытается назначить узлу новую подсеть pod. Пользователи должны удалить старые файлы конфигурации подсети pod в следующих путях:

Remove-Item C:\k\SourceVip.json
Remove-Item C:\k\SourceVipRequest.json

После запуска Kubernetes Flanneld зависает в разделе "Ожидание создания сети".

Эта проблема должна быть устранена с помощью Flannel версии 0.12.0 (и выше). Если вы используете старую версию Flanneld, существует известное состояние гонки, которое может произойти таким образом, что IP-адрес управления фланельной сети не задан. Обходной путь — просто повторно запустить FlannelD вручную.

PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1

Мои модули pod Windows не могут запускаться из-за отсутствия /run/flannel/subnet.env

Это означает, что Flannel не запущен правильно. Можно либо перезапустить flanneld.exe, либо скопировать файлы вручную из /run/flannel/subnet.env главного C:\run\flannel\subnet.env узла Kubernetes в рабочий узел Windows и изменить FLANNEL_SUBNET строку в подсеть, которая была назначена. Например, если подсеть узла 10.244.4.1/24 была назначена:

FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.4.1/24
FLANNEL_MTU=1500
FLANNEL_IPMASQ=true

Чаще всего возникает другая проблема, которая может привести к этой ошибке, которую необходимо сначала исследовать. Рекомендуется разрешить flanneld.exe создать этот файл.

Подключение pod к pod между узлами не работает в кластере Kubernetes, работающем в vSphere

Так как vSphere и Flannel резервируют порт 4789 (порт VXLAN по умолчанию) для наложения сети, пакеты могут быть перехвачены. Если vSphere используется для наложения сети, его следует настроить для использования другого порта, чтобы освободить до 4789.

Мои конечные точки и IP-адреса утечки

Существует 2 известных в настоящее время проблем, которые могут привести к утечке конечных точек.

  1. Первая известная проблема в Kubernetes версии 1.11. Избегайте использования Kubernetes версии 1.11.0 – 1.11.2.
  2. Вторая известная проблема , которая может привести к утечке конечных точек, является проблемой параллелизма в хранилище конечных точек. Чтобы получить исправление, необходимо использовать Docker EE 18.09 или более поздней версии.

Мои модули pod не могут запускаться из-за ошибок "сеть: не удалось выделить для диапазона" ошибки

Это означает, что пространство IP-адресов на узле используется. Чтобы очистить все утечки конечных точек, перенесите все ресурсы на затронутые узлы и выполните следующие команды:

c:\k\stop.ps1
Get-HNSEndpoint | Remove-HNSEndpoint
Remove-Item -Recurse c:\var

Мой узел Windows не может получить доступ к моим службам с помощью IP-адреса службы

Это известное ограничение текущего сетевого стека в Windows. Однако модули pod Windows могут получить доступ к IP-адресу службы.

Сетевой адаптер не найден при запуске Kubelet

В сетевом стеке Windows требуется виртуальный адаптер для работы сети Kubernetes. Если следующие команды не возвращают результатов (в оболочке администратора), создание сети HNS — необходимое условие для работы Kubelet — завершилось сбоем:

Get-HnsNetwork | ? Name -ieq "cbr0"
Get-HnsNetwork | ? Name -ieq "vxlan0"
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"

Часто следует изменить параметр InterfaceName скрипта start.ps1, если сетевой адаптер узла не является Ethernet. В противном случае обратитесь к выходным данным скрипта, чтобы узнать, возникают ли ошибки во время создания виртуальной start-kubelet.ps1 сети.

Я все еще вижу проблемы. Что делать?

В сети или на узлах могут быть дополнительные ограничения, предотвращающие определенные типы обмена данными между узлами. Убедитесь в следующем:

  • вы правильно настроили выбранную топологию сети (l2bridge или overlay)
  • трафик, который выглядит так, как он поступает из модулей pod, разрешен
  • При развертывании веб-служб разрешен трафик HTTP.
  • Пакеты из разных протоколов (т. е. ICMP и TCP/UDP) не удаляются

Совет

Для дополнительных ресурсов самостоятельной помощи существует также руководство по устранению неполадок сети Kubernetes для Windows , доступное здесь.

Распространенные ошибки Windows

Мои модули pod Kubernetes зависают на "ContainerCreating"

Эта проблема может иметь множество причин, но одна из наиболее распространенных заключается в том, что образ приостановки был неправильно настроен. Это высокий уровень симптома следующей проблемы.

При развертывании контейнеры Docker продолжают перезапускать

Убедитесь, что образ приостановки совместим с версией ОС. Kubernetes предполагает, что как ОС, так и контейнеры имеют соответствующие номера версий ОС. Если вы используете экспериментальную сборку Windows, например сборку программы предварительной оценки, необходимо соответствующим образом настроить образы. Дополнительные сведения см. в репозитории Docker Корпорации Майкрософт для изображений.

Распространенные основные ошибки Kubernetes

Отладка главного узла Kubernetes состоит из трех основных категорий (в порядке вероятности):

  • Что-то не так с системными контейнерами Kubernetes.
  • Что-то не так с тем, как kubelet работает.
  • Что-то не так с системой.

Запустите kubectl get pods -n kube-system , чтобы просмотреть модули pod, созданные Kubernetes; это может дать некоторое представление о том, какие конкретные модули завершаются сбоем или не запускаются правильно. Затем выполните команду docker ps -a , чтобы просмотреть все необработанные контейнеры, которые возвращают эти модули pod. Наконец, запустите docker logs [ID] контейнеры, которые подозреваются в возникновении проблемы, чтобы увидеть необработанные выходные данные процессов.

Не удается подключиться к серверу API в https://[address]:[port]

Чаще всего эта ошибка указывает на проблемы с сертификатом. Убедитесь, что вы создали файл конфигурации правильно, что IP-адреса в нем соответствуют узлу и что вы скопировали его в каталог, подключенный сервером API.

Хорошие места для поиска этого файла конфигурации:

  • ~/kube/kubelet/
  • $HOME/.kube/config
  • /etc/kubernetes/admin.conf

В противном случае обратитесь к файлу манифеста сервера API, чтобы проверить точки подключения.