Deci, în general, dacă obțineți un CmdletizationQuery_NotFound eroare, este posibil să nu fie întotdeauna însoțită de informații despre câmpul eșuat dacă există multe câmpuri în interogare...
â sig-windows-dev-tools git:(antrea-node-ip-hardcoding) â vagabond winrm winw1 --shell=powershell --command="Get-NetRoute -InterfaceIndex 123 "
Nu s-au găsit obiecte MSFT_NetRoute cu proprietatea „InterfaceIndex” egală cu „123”. Verificați valoarea proprietății și încercați din nou.
La linia:1 char:1
+ Get-NetRoute -InterfaceIndex 123
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo: ObjectNotFound: (123:UInt32) [Get-NetRoute], CimJobException
+ FullyQualifiedErrorId: CmdletizationQuery_NotFound_InterfaceIndex, Get-NetRoute
Se datorează faptului că interogarea CIM-urilor specifice a eșuat și, astfel, obiectul pe care îl căutați nu a fost găsit.
Cu toate acestea, se pare că uneori, o interogare CIMS nu va returna un rezultat fără a vă oferi partea specifică a interogării care a eșuat (de ex. CmdletizationQuery_NotFound_InterfaceIndex de mai sus a fost frumos și ușor de citit, dar aceeași interogare de mai jos când adăugăm DestinationPrefix câmpul de căutare, oferă un mesaj de eroare mai criptic)...
â 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 "
Nu s-au găsit obiecte MSFT_NetRoute potrivite de interogarea CIM pentru instanțe ale clasei ROOT/StandardCimv2/MSFT_NetRoute pe serverul CIM: SELECT * FROM MSFT_NetRoute WHERE ((DestinationPrefix LIKE '0.0.0.0/1')) AND ((InterfaceIndex = 7)). Verificați parametrii de interogare și încercați din nou.
La linia:1 char:1
+ Get-NetRoute -InterfaceIndex 7 -DestinationPrefix 0.0.0.0/1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~
+ CategoryInfo: ObjectNotFound: (MSFT_NetRoute:String) [Get-NetRoute], CimJobException
+ FullyQualifiedErrorId: CmdletizationQuery_NotFound, Get-NetRoute
În acest caz specific:
- nu a existat o interfață IP existentă cu id = 26 care avea, DE asemenea, prefixul de destinație 0.0.0.0/0
În cazuri mai generale, dacă primiți o eroare similară, ar putea fi cauzat de faptul că tocmai creați o interogare CIMS care nu poate returna date.
Acum, deoarece întrebarea inițială era legată de un furnizor Kubernetes CNI, voi aborda acea parte:
În Kubernetes pe Windows
Furnizorii CNI, cum ar fi antrea, au nevoie de aceste informații atunci când intră online, iar lucrul general de care trebuie să vă asigurați este faptul că Windows Kubelet își setează corect adresa IP (adică prin câmpul node-ip la pornire).
În cazul meu, am constatat că după setarea asta, această interogare a fost generată corect și a început să caute interfața potrivită pentru această valoare (adică cea care corespundea adresei IP interne a Nodului meu).
Există întrebarea mai amplă despre cum, în general, DestinationPrefixes ar trebui să fie configurate în mașinile virtuale Kubernetes Windows, dar aceasta este în afara domeniului de aplicare al întrebării mele inițiale, dar, în general, dacă ați configurat corect rețeaua astfel încât:
- ta
nod-ip după cum arată kubectl obține noduri -o lățime este cea corectă pe care o doriți pentru Windows Kubelet și
- acea
nod-ip este asociat cu o interfață care are o adresă IP de prefix de destinație = 0.0.0.0/0
Apoi, în mod specific, furnizorul antrea CNI va putea determina cu exactitate corect următorul pas pentru gateway-ul său, care în cele din urmă este folosit pentru a configura regulile de rutare OVS pe un nod pentru rețelele dumneavoastră de pod.
