Läs på engelska

Dela via

Diagnostisera anslutningsproblem för Azure Arc-aktiverade Kubernetes-kluster

  • Artikel

Om du har problem med att ansluta ett kluster till Azure Arc beror det förmodligen på något av problemen som anges här. Vi tillhandahåller två flödesscheman med guidad hjälp: ett om du inte använder en proxyserver och ett som gäller om nätverksanslutningen använder en proxyserver.

Tips

Stegen i det här flödesschemat gäller oavsett om du använder Azure CLI eller Azure PowerShell för att ansluta klustret. Vissa av stegen kräver dock användning av Azure CLI. Om du inte redan har installerat Azure CLI måste du göra det innan du börjar.

Anslutningar utan proxy

Granska det här flödesschemat för att diagnostisera problemet när du försöker ansluta ett kluster till Azure Arc utan en proxyserver. Mer information om varje steg finns nedan.

Flödesschema som visar en visuell representation av kontrollen av anslutningsproblem när du inte använder en proxy.

Har Azure-identiteten tillräcklig behörighet?

Granska förutsättningarna för att ansluta ett kluster och se till att den identitet som du använder för att ansluta klustret har nödvändiga behörigheter.

Kör du den senaste versionen av Azure CLI?

Kontrollera att du har den senaste versionen installerad.

Om du har anslutit klustret med hjälp av Azure PowerShell kontrollerar du att du kör den senaste versionen.

connectedk8s Är tillägget den senaste versionen?

Uppdatera Azure CLI-tillägget connectedk8s till den senaste versionen genom att köra det här kommandot:

az extension update --name connectedk8s

Om du inte har installerat tillägget ännu kan du göra det genom att köra följande kommando:

az extension add --name connectedk8s

Pekar kubeconfig på rätt kluster?

Kör kubectl config get-contexts för att bekräfta målkontextnamnet. Ange sedan standardkontexten till rätt kluster genom att köra kubectl config use-context <target-cluster-name>.

Är alla nödvändiga resursprovidrar registrerade?

Kontrollera att resursprovidrarna Microsoft.Kubernetes, Microsoft.KubernetesConfiguration och Microsoft.ExtendedLocation är registrerade.

Uppfylls alla nätverkskrav?

Granska nätverkskraven och se till att inga nödvändiga slutpunkter blockeras.

Körs alla poddar i azure-arc namnområdet?

Om allt fungerar korrekt bör alla poddar vara i tillståndet Running . Kör kubectl get pods -n azure-arc för att bekräfta om någon podds tillstånd inte Runningär .

Har du fortfarande problem?

Stegen ovan löser många vanliga anslutningsproblem, men om du fortfarande inte kan ansluta genererar du en felsökningsloggfil och öppnar sedan en supportbegäran så att vi kan undersöka problemet ytterligare.

Kör följande kommando för att generera felsökningsloggfilen:

az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>

När du skapar din supportbegäran använder du alternativet Filuppladdning i avsnittet Ytterligare information för att ladda upp den genererade loggfilen.

Anslutningar med en proxyserver

Om du använder en proxyserver på minst en dator utför du de första fem stegen i flödesschemat för icke-proxy (via registrering av resursprovider) för grundläggande felsökningssteg. Om du fortfarande stöter på problem läser du sedan nästa flödesschema för ytterligare felsökningssteg. Mer information om varje steg finns nedan.

Flödesschema som visar en visuell representation av kontroll av anslutningsproblem när du använder en proxy.

Kör datorn kommandon bakom en proxyserver?

Om datorn kör kommandon bakom en proxyserver måste du ange alla nödvändiga miljövariabler. Mer information finns i Ansluta med en utgående proxyserver.

Till exempel:

export HTTP_PROXY="http://<proxyIP>:<proxyPort>"
export HTTPS_PROXY="https://<proxyIP>:<proxyPort>"
export NO_PROXY="<cluster-apiserver-ip-address>:<proxyPort>"

Accepterar proxyservern endast betrodda certifikat?

Se till att inkludera sökvägen till certifikatfilen genom att inkludera --proxy-cert <path-to-cert-file> när du kör az connectedk8s connect kommandot.

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-cert <path-to-cert-file>

Kan proxyservern nå nödvändiga nätverksslutpunkter?

Granska nätverkskraven och se till att inga nödvändiga slutpunkter blockeras.

Använder proxyservern bara HTTP?

Om proxyservern bara använder HTTP kan du använda proxy-http för båda parametrarna.

Om proxyservern har konfigurerats med både HTTP och HTTPS kör az connectedk8s connect du kommandot med angivna --proxy-https parametrar och --proxy-http . Se till att du använder --proxy-http för HTTP-proxyn och --proxy-https för HTTPS-proxyn.

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>

Kräver proxyservern hoppintervall för tjänst-till-tjänst-kommunikation?

Om du behöver hoppa över intervall använder du --proxy-skip-range <excludedIP>,<excludedCIDR> i kommandot az connectedk8s connect .

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>

Körs alla poddar i azure-arc namnområdet?

Om allt fungerar korrekt bör alla poddar vara i tillståndet Running . Kör kubectl get pods -n azure-arc för att bekräfta om någon podds tillstånd inte Runningär .

Kontrollera om DNS-matchningen lyckas för slutpunkten

Inifrån podden kan du köra en DNS-sökning till slutpunkten.

Vad händer om du inte kan köra kommandot kubectl exec för att ansluta till podden och installera DNS Utils-paketet? I det här fallet kan du starta en testpodd i samma namnområde som den problematiska podden och sedan köra testerna.

Anteckning

Om DNS-matchningen eller utgående trafik inte låter dig installera nödvändiga nätverkspaket kan du använda Docker-avbildningen rishasi/ubuntu-netutil:1.0 . I den här avbildningen är de nödvändiga paketen redan installerade.

Här är ett exempel på en procedur för att kontrollera DNS-matchning:

  1. Starta en testpodd i samma namnområde som den problematiska podden:

    kubectl run -it --rm test-pod --namespace <namespace> --image=debian:stable

    När testpodden har körts får du åtkomst till podden.

  2. Kör följande apt-get kommandon för att installera andra verktygspaket:

    apt-get update -y
apt-get install dnsutils -y
apt-get install curl -y
apt-get install netcat -y

  3. När paketen har installerats kör du kommandot nslookup för att testa DNS-matchningen till slutpunkten:

    $ nslookup microsoft.com
Server:         10.0.0.10
Address:        10.0.0.10#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

  4. Prova DNS-matchningen direkt från den överordnade DNS-servern. I det här exemplet används Azure DNS:

    $ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85

  5. host Kör kommandot för att kontrollera om DNS-begäranden dirigeras till den överordnade servern:

    $ 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 ms

  6. Kör en testpodd i Windows-nodpoolen:

    # 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"

  7. Kör kommandot kubectl exec för att ansluta till podden med hjälp av PowerShell:

    kubectl exec -it dnsutil-win -- powershell

  8. Kör cmdleten Resolve-DnsName i PowerShell för att kontrollera om DNS-matchningen fungerar för slutpunkten:

    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

Om DNS-matchningen inte lyckas kontrollerar du DNS-konfigurationen för klustret.

Har du fortfarande problem?

Stegen ovan löser många vanliga anslutningsproblem, men om du fortfarande inte kan ansluta genererar du en felsökningsloggfil och öppnar sedan en supportbegäran så att vi kan undersöka problemet ytterligare.

Kör följande kommando för att generera felsökningsloggfilen:

az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>

När du skapar din supportbegäran använder du alternativet Filuppladdning i avsnittet Ytterligare information för att ladda upp den genererade loggfilen.

Nästa steg