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 解決を確認する手順の例を次に示します。
問題のあるポッドと同じ名前空間でテスト ポッドを開始します。
kubectl run -it --rm test-pod --namespace <namespace> --image=debian:stable
テスト ポッドが稼働した後、そのポッドにアクセスできるようになります。
次の
apt-get
コマンドを実行して、他のツール パッケージをインストールします。apt-get update -y apt-get install dnsutils -y apt-get install curl -y apt-get install netcat -y
パッケージがインストールされたら、nslookup コマンドを実行して、エンドポイントへの DNS 解決をテストします。
$ nslookup microsoft.com Server: 10.0.0.10 Address: 10.0.0.10#53 ... ... Name: microsoft.com Address: 20.53.203.50
アップストリームの 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
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
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"
kubectl exec コマンドを実行し、PowerShell を使ってポッドに接続します。
kubectl exec -it dnsutil-win -- powershell
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>
サポート リクエストを作成するとき、[追加情報] セクションで、[ファイルのアップロード] オプションを使用して、生成されたログ ファイルをアップロードします。
次のステップ
- その他の Azure Arc 対応 Kubernetes を使用するためのトラブルシューティングのヒントをご覧ください。
- 既存の Kubernetes クラスターを Azure Arc に接続する方法についてご確認ください。