Так что, в общем, если вы получаете КомандлетизацияQuery_NotFound
ошибка, может не всегда сопровождаться информацией о сбойном поле, если в запросе много полей...
â sig-windows-dev-tools git:(antrea-node-ip-hardcoding) â vagrant winrm winw1 --shell=powershell --command="Get-NetRoute -InterfaceIndex 123 "
Объекты MSFT_NetRoute со свойством «InterfaceIndex», равным «123», не найдены. Проверьте значение свойства и повторите попытку.
В строке:1 символ:1
+ Get-NetRoute -InterfaceIndex 123
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ Информация о категории: ObjectNotFound: (123:UInt32) [Get-NetRoute], CimJobException
+ FullyQualifiedErrorId: CmdletizationQuery_NotFound_InterfaceIndex,Get-NetRoute
Это связано с тем, что не удалось выполнить конкретный запрос CIM, и поэтому объект, который вы искали, не был найден.
Однако оказывается, что иногда запрос CIMS не возвращает результат не сообщая вам конкретную часть запроса, которая не удалась (т.е. КомандлетизацияQuery_NotFound_InterfaceIndex
выше было приятно и легко читать, но тот же запрос ниже, когда мы добавляем Префикс назначения
поле поиска, дает более загадочное сообщение об ошибке)...
sig-windows-dev-tools git:(antrea-node-ip-hardcoding) vagrant winrm winw1 --shell=powershell --command="Get-NetRoute -InterfaceIndex 7 -DestinationPrefix 0.0.0.0/1 "
Нет соответствующих объектов MSFT_NetRoute, найденных запросом CIM для экземпляров класса ROOT/StandardCimv2/MSFT_NetRoute на сервере CIM: SELECT * FROM MSFT_NetRoute WHERE ((DestinationPrefix LIKE '0.0.0.0/1')) AND ((InterfaceIndex = 7)). Проверьте параметры запроса и повторите попытку.
В строке:1 символ:1
+ Get-NetRoute -InterfaceIndex 7 -DestinationPrefix 0.0.0.0/1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~
+ CategoryInfo: ObjectNotFound: (MSFT_NetRoute:String) [Get-NetRoute], CimJobException
+ FullyQualifiedErrorId: CmdletizationQuery_NotFound,Get-NetRoute
В этом конкретном случае:
- не было существующего IP-интерфейса с id = 26, который ТАКЖЕ имел префикс назначения 0.0.0.0/0
В более общих случаях, если вы получаете аналогичную ошибку, это может быть вызвано тем, что вы только что создали запрос CIMS, который не может вернуть какие-либо данные.
Теперь, поскольку первоначальный вопрос был связан с провайдером Kubernetes CNI, я обращусь к этой части:
В Kubernetes в Windows
Провайдеры CNI, такие как antrea, нуждаются в этой информации при подключении к Интернету, и обычно нужно убедиться в том, что ваш Windows kubelet правильно устанавливает свой IP-адрес (то есть через поле node-ip при запуске).
В моем случае я обнаружил, что после установки этого запроса этот запрос был сгенерирован правильно, и он начал искать правильный интерфейс для этого значения (то есть тот, который соответствовал внутреннему IP-адресу моего узла).
Существует более широкий вопрос о том, как в целом следует настраивать DestinationPrefixes на виртуальных машинах Windows Kubernetes, но это выходит за рамки моего первоначального вопроса, но в целом, если вы правильно настроили свою сеть, так что:
- твой
IP-адрес узла
как показано kubectl получить узлы -o широкий
является правильным, который вы хотите для своего windows kubelet и
- что
IP-адрес узла
связан с интерфейсом, который имеет IP-адрес префикса назначения = 0.0.0.0/0
Тогда именно поставщик antrea CNI сможет точно определить правильный следующий прыжок
для его шлюза, который в конечном итоге используется для настройки правил маршрутизации OVS на узле для ваших сетей модулей.