次の方法で共有


Azure Arc 対応 Kubernetes クラスターの接続の問題を診断する

クラスターを Azure Arc に接続するときに問題が発生している場合は、ここに記載されているいずれかの問題が原因である可能性があります。 ガイド付きヘルプを含む 2 つのフローチャートを用意しました。1 つはプロキシ サーバーを使用していない場合、もう 1 つはネットワーク接続でプロキシ サーバーを使用する場合に適用されるフローチャートです。

ヒント

このフローチャートの手順は、Azure CLI または Azure PowerShell を使用してクラスターに接続している場合に適応されます。 ただし、一部の手順では Azure CLI を使用する必要があります。 まだ Azure CLI をインストールしていない場合は、開始する前に必ずしてください。

プロキシを経由しない接続

プロキシ サーバーを経由せずにクラスターを Azure Arc に接続しようとするときの問題を診断するには、このフローチャートを確認してください。 各手順の詳細について、以下に示します。

プロキシを使用しない場合の接続に関する問題の確認について視覚的に表現したフローチャート。

Azure ID に十分なアクセス許可がありますか?

クラスターを接続するための前提条件を確認し、クラスターの接続に使用している ID に必要なアクセス許可があることを確認してください。

最新バージョンの Azure CLI を実行していますか?

最新バージョンがインストールされていることを確認してください。

Azure PowerShell を使用してクラスターを接続した場合は、最新バージョンを実行していることを確認してください。

connectedk8s 拡張機能は最新バージョンですか?

次のコマンドを実行して、Azure CLI connectedk8s 拡張機能を最新バージョンに更新してください。

az extension update --name connectedk8s

拡張機能をまだインストールしていない場合は、次のコマンドを実行してインストールできます。

az extension add --name connectedk8s

kubeconfig は適切なクラスターを指していますか?

kubectl config get-contexts を実行して、ターゲットのコンテキスト名を確認してください。 次に、kubectl config use-context <target-cluster-name> を実行して、既定のコンテキストを適切なクラスターに設定します。

必要なすべてのリソース プロバイダーが登録されていますか?

Microsoft.Kubernetes、Microsoft.KubernetesConfiguration、および Microsoft.ExtendedLocation リソース プロバイダーが登録されていることを確認してください。

すべてのネットワーク要件が満たされていますか?

ネットワーク要件を確認し、必要なエンドポイントがブロックされていないことを確認してください。

azure-arc 名前空間内のすべてのポッドが実行されていますか?

すべてが正常に動作している場合は、ポッドはすべて Running 状態であるはずです。 kubectl get pods -n azure-arc を実行して、Running 状態ではないポッドがあるかどうか確認してください。

まだ問題が解決されない場合は、

上記の手順で、一般的な接続の問題の多くは解決しますが、それでも正常に接続できない場合は、トラブルシューティング ログ ファイルを生成し、サポート リクエストを開いてください。問題をさらに調査します。

トラブルシューティング ログ ファイルを生成するには、次のコマンドを実行します。

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

サポート リクエストを作成するとき、[追加情報] セクションで、[ファイルのアップロード] オプションを使用して、生成されたログ ファイルをアップロードします。

プロキシ サーバーを経由する接続

少なくとも 1 台のマシンでプロキシ サーバーを使用している場合は、基本的なトラブルシューティング手順として、プロキシを経由しない場合のフローチャートにある最初の 5 つの手順 (リソース プロバイダーの登録まで) を実行してください。 その後、問題が引き続き発生する場合は、追加のトラブルシューティング手順として、次のフローチャートを確認してください。 各手順の詳細について、以下に示します。

プロキシを使用する場合の接続に関する問題の確認について視覚的に表現したフローチャート。

プロキシ サーバーの背後にあるマシンでコマンドを実行していますか?

プロキシ サーバーの背後にあるマシンでコマンドを実行している場合は、必要なすべての環境変数を設定する必要があります。 詳細については、「送信プロキシ サーバーを使用して接続する」を参照してください。

次に例を示します。

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

プロキシ サーバーで信頼された証明書のみを受け入れていますか?

az connectedk8s connect コマンドの実行時に --proxy-cert <path-to-cert-file> を含めることで、証明書ファイルのパスを含めるようにしてください。

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

プロキシ サーバーは必要なネットワーク エンドポイントに到達できますか?

ネットワーク要件を確認し、必要なエンドポイントがブロックされていないことを確認してください。

プロキシ サーバーは HTTP のみを使用していますか?

プロキシ サーバーで HTTP のみが使用される場合は、両方のパラメーターに proxy-http を使用できます。

プロキシ サーバーが HTTP と HTTPS の両方で設定されている場合は、パラメーター az connectedk8s connect--proxy-https を指定して --proxy-http コマンドを実行してください。 HTTP プロキシに --proxy-http、HTTPS プロキシに --proxy-https を使用していることを確認してください。

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>  

プロキシ サーバーで、サービス間通信にスキップ範囲が要求されていますか?

スキップ範囲が必要な場合は、az connectedk8s connect コマンドで --proxy-skip-range <excludedIP>,<excludedCIDR> を使用します。

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>

azure-arc 名前空間内のすべてのポッドが実行されていますか?

すべてが正常に動作している場合は、ポッドはすべて Running 状態であるはずです。 kubectl get pods -n azure-arc を実行して、Running 状態ではないポッドがあるかどうか確認してください。

エンドポイントの DNS 解決が成功するかどうかを調べる

ポッド内から、エンドポイントへの DNS 参照を実行できます。

kubectl exec コマンドを実行してポッドに接続し、DNS Utils パッケージをインストールできない場合はどうしましょう。 そのようなときは、問題のあるポッドと同じ名前空間でテスト ポッドを開始し、テストを実行できます。

Note

DNS 解決またはエグレス トラフィックで必要なネットワーク パッケージをインストールできない場合は、rishasi/ubuntu-netutil:1.0 Docker イメージを使用できます。 このイメージには、必要なパッケージが既にインストールされています。

DNS 解決を確認する手順の例を次に示します。

  1. 問題のあるポッドと同じ名前空間でテスト ポッドを開始します。

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

    テスト ポッドが稼働した後、そのポッドにアクセスできるようになります。

  2. 次の apt-get コマンドを実行して、他のツール パッケージをインストールします。

    apt-get update -y
    apt-get install dnsutils -y
    apt-get install curl -y
    apt-get install netcat -y
    
  3. パッケージがインストールされたら、nslookup コマンドを実行して、エンドポイントへの DNS 解決をテストします。

    $ nslookup microsoft.com
    Server:         10.0.0.10
    Address:        10.0.0.10#53
    ...
    ...
    Name:   microsoft.com
    Address: 20.53.203.50
    
  4. アップストリームの DNS サーバーから直接 DNS 解決を試します。 この例では、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 コマンドを実行し、DNS 要求がアップストリーム サーバーにルーティングされるかどうかを調べます。

    $ 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. Windows ノード プールでテスト ポッドを実行します。

    # 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. kubectl exec コマンドを実行し、PowerShell を使ってポッドに接続します。

    kubectl exec -it dnsutil-win -- powershell
    
  8. PowerShell で Resolve-DnsName コマンドレットを実行して、エンドポイントに対する DNS 解決が機能しているかどうかを調べます。

    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
    

DNS 解決が成功しない場合は、クラスターの DNS 構成を確認します。

まだ問題が解決されない場合は、

上記の手順で、一般的な接続の問題の多くは解決しますが、それでも正常に接続できない場合は、トラブルシューティング ログ ファイルを生成し、サポート リクエストを開いてください。問題をさらに調査します。

トラブルシューティング ログ ファイルを生成するには、次のコマンドを実行します。

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

サポート リクエストを作成するとき、[追加情報] セクションで、[ファイルのアップロード] オプションを使用して、生成されたログ ファイルをアップロードします。

次のステップ