Az Azure Arc-kompatibilis Kubernetes-fürtök csatlakozási problémáinak diagnosztizálása
Ha problémákat tapasztal egy fürt Azure Archoz való csatlakoztatásával kapcsolatban, az valószínűleg az itt felsorolt problémák egyikének tudható be. Két folyamatábrát biztosítunk irányított súgóval: egyet, ha nem proxykiszolgálót használ, és egyet, amely akkor érvényes, ha a hálózati kapcsolat proxykiszolgálót használ.
Tipp.
A folyamatábra lépései érvényesek arra, hogy az Azure CLI-t vagy az Azure PowerShellt használja-e a fürt csatlakoztatásához. Néhány lépés azonban megköveteli az Azure CLI használatát. Ha még nem telepítette az Azure CLI-t, mindenképpen tegye ezt meg a kezdés előtt.
Proxy nélküli kapcsolatok
Tekintse át ezt a folyamatábrát, hogy diagnosztizálhassa a problémát, amikor proxykiszolgáló nélkül próbál csatlakozni egy fürthöz az Azure Archoz. Az egyes lépésekről az alábbiakban talál további részleteket.
Rendelkezik az Azure-identitás megfelelő engedélyekkel?
Tekintse át a fürt csatlakoztatásának előfeltételeit, és győződjön meg arról, hogy a fürt csatlakoztatásához használt identitás rendelkezik a szükséges engedélyekkel.
Az Azure CLI legújabb verzióját futtatja?
Győződjön meg arról, hogy a legújabb verzió van telepítve.
Ha az Azure PowerShell használatával csatlakoztatta a fürtöt, győződjön meg arról, hogy a legújabb verziót futtatja.
A bővítmény a connectedk8s legújabb verzió?
A parancs futtatásával frissítse az Azure CLI-bővítményt connectedk8s a legújabb verzióra:
az extension update --name connectedk8s
Ha még nem telepítette a bővítményt, ezt az alábbi parancs futtatásával teheti meg:
az extension add --name connectedk8s
A kubeconfig a megfelelő fürtre mutat?
Futtassa kubectl config get-contexts a célkörnyezet nevét. Ezután futtassa kubectl config use-context <target-cluster-name>az alapértelmezett környezetet a megfelelő fürtre.
Minden szükséges erőforrás-szolgáltató regisztrálva van?
Győződjön meg arról, hogy a Microsoft.Kubernetes, a Microsoft.KubernetesConfiguration és a Microsoft.ExtendedLocation erőforrás-szolgáltatók regisztrálva vannak.
Minden hálózati követelmény teljesül?
Tekintse át a hálózati követelményeket , és győződjön meg arról, hogy nincsenek letiltva a szükséges végpontok.
Fut az összes pod a azure-arc névtérben?
Ha minden megfelelően működik, a podoknak mind állapotban Running kell lenniük. Futtassa kubectl get pods -n azure-arc annak megerősítéséhez, hogy egy pod állapota nem Running.
Még mindig vannak problémái?
A fenti lépések számos gyakori csatlakozási problémát megoldanak, de ha továbbra sem tud sikeresen csatlakozni, hozzon létre egy hibaelhárítási naplófájlt, majd nyisson meg egy támogatási kérést , hogy tovább vizsgálhassuk a problémát.
A hibaelhárítási naplófájl létrehozásához futtassa a következő parancsot:
az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>
A támogatási kérelem létrehozásakor a További részletek szakaszban a Fájlfeltöltés lehetőséggel töltse fel a létrehozott naplófájlt.
Proxykiszolgálóval létesített kapcsolatok
Ha proxykiszolgálót használ legalább egy gépen, végezze el a nem proxyalapú folyamatábra első öt lépését (az erőforrás-szolgáltató regisztrációjával) az alapvető hibaelhárítási lépésekhez. Ezután, ha továbbra is problémákba ütközik, tekintse át a következő folyamatábrát a további hibaelhárítási lépésekért. Az egyes lépésekről az alábbiakban talál további részleteket.
A gép parancsokat hajt végre proxykiszolgáló mögött?
Ha a gép proxykiszolgáló mögött hajt végre parancsokat, be kell állítania az összes szükséges környezeti változót. További információ: Csatlakozás kimenő proxykiszolgáló használatával.
Példa:
export HTTP_PROXY="http://<proxyIP>:<proxyPort>"
export HTTPS_PROXY="https://<proxyIP>:<proxyPort>"
export NO_PROXY="<cluster-apiserver-ip-address>:<proxyPort>"
A proxykiszolgáló csak megbízható tanúsítványokat fogad el?
A parancs futtatásakor az connectedk8s connect mindenképpen adja meg a tanúsítványfájl elérési útját--proxy-cert <path-to-cert-file>.
az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-cert <path-to-cert-file>
A proxykiszolgáló képes elérni a szükséges hálózati végpontokat?
Tekintse át a hálózati követelményeket , és győződjön meg arról, hogy nincsenek letiltva a szükséges végpontok.
A proxykiszolgáló csak HTTP-t használ?
Ha a proxykiszolgáló csak HTTP-t használ, mindkét paramétert használhatja proxy-http .
Ha a proxykiszolgáló HTTP és HTTPS protokollal is be van állítva, futtassa a az connectedk8s connect parancsot a --proxy-https megadott paraméterekkel és --proxy-http paraméterekkel. Győződjön meg arról, hogy a HTTP-proxyt és --proxy-https a HTTPS-proxyt használja--proxy-http.
az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port>
A proxykiszolgálónak ki kell hagynia a szolgáltatásközi kommunikáció tartományait?
Ha kihagyó tartományokra van szüksége, használja --proxy-skip-range <excludedIP>,<excludedCIDR> a az connectedk8s connect parancsot.
az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port> --proxy-skip-range <excludedIP>,<excludedCIDR>
Fut az összes pod a azure-arc névtérben?
Ha minden megfelelően működik, a podoknak mind állapotban Running kell lenniük. Futtassa kubectl get pods -n azure-arc annak megerősítéséhez, hogy egy pod állapota nem Running.
Ellenőrizze, hogy a DNS-feloldás sikeres-e a végponton
A podon belül futtathat EGY DNS-keresést a végpontra.
Mi a teendő, ha nem tudja futtatni a kubectl exec parancsot a podhoz való csatlakozáshoz és a DNS Utils-csomag telepítéséhez? Ebben az esetben a teszt podot ugyanabban a névtérben indíthatja el, mint a problémás pod, majd futtathatja a teszteket.
Feljegyzés
Ha a DNS-feloldás vagy a kimenő forgalom nem teszi lehetővé a szükséges hálózati csomagok telepítését, használhatja a rishasi/ubuntu-netutil:1.0 Docker-lemezképet. Ebben a képen a szükséges csomagok már telepítve vannak.
Íme egy példa a DNS-feloldás ellenőrzésére:
Indítsa el a teszt podot a problémás pod névterével megegyező névtérben:
kubectl run -it --rm test-pod --namespace <namespace> --image=debian:stableA teszt pod futtatása után hozzáférést kap a podhoz.
Futtassa a következő
apt-getparancsokat más eszközcsomagok telepítéséhez:apt-get update -y apt-get install dnsutils -y apt-get install curl -y apt-get install netcat -yA csomagok telepítése után futtassa az nslookup parancsot a DNS-felbontás végponton való teszteléséhez:
$ nslookup microsoft.com Server: 10.0.0.10 Address: 10.0.0.10#53 ... ... Name: microsoft.com Address: 20.53.203.50Próbálja ki a DNS-feloldási elemet közvetlenül a felsőbb rétegbeli DNS-kiszolgálóról. Ez a példa az Azure DNS-t használja:
$ nslookup microsoft.com 168.63.129.16 Server: 168.63.129.16 Address: 168.63.129.16#53 ... ... Address: 20.81.111.85Futtassa a
hostparancsot annak ellenőrzéséhez, hogy a DNS-kérések a felsőbb rétegbeli kiszolgálóra vannak-e irányítva:$ host -a microsoft.com Trying "microsoft.com.default.svc.cluster.local" Trying "microsoft.com.svc.cluster.local" Trying "microsoft.com.cluster.local" Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net" Trying "microsoft.com" Trying "microsoft.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884 ;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5 ;; QUESTION SECTION: ;microsoft.com. IN ANY ;; ANSWER SECTION: microsoft.com. 30 IN NS ns1-39.azure-dns.com. ... ... ns4-39.azure-dns.info. 30 IN A 13.107.206.39 Received 2121 bytes from 10.0.0.10#53 in 232 msFuttasson egy teszt podot a Windows-csomópontkészletben:
# For a Windows environment, use the Resolve-DnsName cmdlet. kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:1809' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"Futtassa a kubectl exec parancsot a podhoz való csatlakozáshoz a PowerShell használatával:
kubectl exec -it dnsutil-win powershellFuttassa a Resolve-DnsName parancsmagot a PowerShellben annak ellenőrzéséhez, hogy a DNS-feloldás működik-e a végponton:
PS C:\> Resolve-DnsName www.microsoft.com Name Type TTL Section NameHost ---- ---- --- ------- -------- www.microsoft.com CNAME 20 Answer www.microsoft.com-c-3.edgekey.net www.microsoft.com-c-3.edgekey. CNAME 20 Answer www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net net www.microsoft.com-c-3.edgekey. CNAME 20 Answer e13678.dscb.akamaiedge.net net.globalredir.akadns.net Name : e13678.dscb.akamaiedge.net QueryType : AAAA TTL : 20 Section : Answer IP6Address : 2600:1408:c400:484::356e Name : e13678.dscb.akamaiedge.net QueryType : AAAA TTL : 20 Section : Answer IP6Address : 2600:1408:c400:496::356e Name : e13678.dscb.akamaiedge.net QueryType : A TTL : 12 Section : Answer IP4Address : 23.200.197.152
Ha a DNS-feloldás nem sikerült, ellenőrizze a fürt DNS-konfigurációját.
Még mindig vannak problémái?
A fenti lépések számos gyakori csatlakozási problémát megoldanak, de ha továbbra sem tud sikeresen csatlakozni, hozzon létre egy hibaelhárítási naplófájlt, majd nyisson meg egy támogatási kérést , hogy tovább vizsgálhassuk a problémát.
A hibaelhárítási naplófájl létrehozásához futtassa a következő parancsot:
az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>
A támogatási kérelem létrehozásakor a További részletek szakaszban a Fájlfeltöltés lehetőséggel töltse fel a létrehozott naplófájlt.
Következő lépések
- További hibaelhárítási tippek az Azure Arc-kompatibilis Kubernetes használatához.
- Tekintse át a meglévő Kubernetes-fürtök Azure Archoz való csatlakoztatásának folyamatát.
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: