仮想ネットワーク外のエンドポイントへの接続のトラブルシューティング
この記事では、Microsoft Azure Kubernetes Service (AKS) クラスターから (つまり、パブリック インターネットを介して) 仮想ネットワークの外部にあるエンドポイントへの接続をトラブルシューティングする方法について説明します。
前提条件
Kubernetes kubectl ツール、またはクラスターに接続するための同様のツール。 Azure CLI を使用して kubectl をインストールするには、 az aks install-cli コマンドを 実行します。
トラブルシューティング チェックリスト
手順 1: 基本的なトラブルシューティングを行う
インターネット上のパブリック エンドポイントに接続できることを確認します。 手順については、「 送信 AKS クラスター接続の基本的なトラブルシューティング」を参照してください。
手順 2: AKS クラスターの送信の種類を決定する
AKS クラスターの送信の種類を特定するには、 az aks show コマンドを実行します。
az aks show --resource-group <resource_group> --name <cluster_name> --query "networkProfile.outboundType"
送信の種類が の場合は loadBalancer、AKS ノードに関連付けられているルート テーブルにインターネットへの既定のルートがあることを確認します。 詳細を次の表に示します。
| ソース | アドレス プレフィックス | 次ホップの種類 |
|---|---|---|
| 既定値 | 0.0.0.0/0 | インターネット |
送信の種類が の場合は、 userDefinedRouting次の条件が満たされていることを確認します。
エグレス デバイス (ファイアウォールまたはプロキシ) に到達可能です。
エグレス デバイスは、クラスターからの 必要な送信トラフィック を許可します。
AKS クラスターで許可されている FQDN の一覧を取得するには、 az aks egress-endpoints list コマンドを 実行します。
az aks egress-endpoints list --resource-group <resource_group> --name <cluster_name>
送信の種類が の場合はmanagedNATGateway、az network nat gateway show コマンドを実行して、AKS サブネットが NAT ゲートウェイに関連付けられているかどうかをチェックします。
az network nat gateway show --resource-group <resource_group> --name <nat_gateway_name> --query "subnets[].id"
AKS と共に NAT ゲートウェイを使用する方法の詳細については、「 マネージド NAT ゲートウェイ」を参照してください。
手順 3: クラスターに接続するときにcURL出力を確認する
cURL応答コードは、問題の種類を特定するのに役立ちます。 応答コードが使用可能になったら、問題の動作をよりよく理解してみてください。 HTTP 状態コードと問題の基になる動作の詳細については、次の表を参照してください。
| 情報ソース | リンク |
|---|---|
| インターネット割り当て番号機関 (IANA) | ハイパーテキスト転送プロトコル (HTTP) 状態コード レジストリ |
| Mozilla | HTTP 応答状態コード |
| ウィキペディア | HTTP 状態コードの一覧 |
次の HTTP 状態コードは、一覧表示されている問題を示している可能性があります。
| HTTP ステータス コード | 問題 | 例 |
|---|---|---|
4xx |
|
|
5xx |
問題がサーバーに影響します。 | アプリケーションがダウンしているか、ゲートウェイが動作していません。 |
手順 4: 送信トラフィックが通常仮想アプライアンスを通過するが、代わりにバイパスする場合の動作を判断する
エグレス デバイス (仮想アプライアンス) が問題を引き起こすかどうかを迅速にテストするために、すべてのトラフィックがインターネットを通過することを一時的に許可できます。 このセットアップを構成するには、仮想アプライアンスを介しての既定の 0.0.0.0/0 IP アドレスとポート ルートを変更して、代わりにインターネットを経由するようにします。
問題は断続的ですか?
多くの理由で断続的な送信の問題が発生する可能性があります。 断続的な送信接続の問題のトラブルシューティングを行うには、次のチェックを試してください。
ポッドまたはノードがリソースで使い果たされていますか?
次のコードを実行して、リソースの使用方法をチェックします。
kubectl top pods
kubectl top nodes
オペレーティング システム ディスクは頻繁に使用されていますか?
オペレーティング システム ディスクが頻繁に使用されているかどうかをチェックするには、次の手順に従います。
Azure portalで、[仮想マシン スケール セット] を検索して選択します。
スケール セットの一覧で、AKS クラスターに使用するスケール セットを選択します。
スケール セットのナビゲーション ウィンドウで、[ 監視 ] セクションに移動し、[ メトリック] を選択します。
次のフィールドを探して、[ メトリック] セクションからスケール セットのディスク メトリックを表示します。
フィールド 値 範囲 VMSS 名 Metrics 名前空間 仮想マシン ホスト 指標 OS とデータ ディスクのメトリック
メトリックの詳細については、「 OS ディスクとデータ ディスクのメトリック」を参照してください。
ディスク使用率に関する AKS の推奨事項を表示するには、次の手順に従います。
Azure portalで、Kubernetes サービスを検索して選択します。
Kubernetes サービスの一覧で、AKS クラスターの名前を選択します。
AKS クラスターのナビゲーション ウィンドウで、[ 監視 ] セクションに移動し、[Advisor の 推奨事項] を選択します。
ディスク使用量に関する推奨事項を確認します。
OS ディスクが頻繁に使用される場合は、次の解決策を使用することを検討してください。
OS ディスク サイズを増やします。
エフェメラル OS ディスクに切り替えます。
これらの解決策で問題が解決しない場合は、ディスクで大量の読み取り/書き込み操作を行うプロセスを分析します。 次に、OS ディスクではなくデータ ディスクにアクションを移動できるかどうかをチェックします。
送信元ネットワーク アドレス変換ポートが使い果たされていますか?
アプリケーションが多数の送信接続を行っている場合、送信デバイスの IP アドレスで使用可能なポートの数が不足する可能性があります。 Standard ロード バランサーの診断メトリック、アラート、リソース正常性に従って、既存のロード バランサーのソース ネットワーク アドレス変換 (SNAT) ポートの使用状況と割り当てを監視します。 監視して、SNAT ポートの枯渇のリスクを確認または判断します。
割り当てられた SNAT ポートの最大数に達しているか、超えていますか? その場合は、アプリケーションをチェックして、既存の接続を再利用しているかどうかを判断できます。 詳細については、「 接続を効率的に使用するようにアプリケーションを設計する」を参照してください。
アプリケーションが正しく構成されていて、割り当てられたポートの既定の数よりも多くの SNAT ポートが必要な場合は、次の手順に従います。
エグレス デバイス上のパブリック IP の数を増やします。 エグレス デバイスがロード バランサーの場合は、 ロード バランサーのパブリック IP アドレスの数を増やすことができます。
サードパーティのお問い合わせ窓口に関する免責事項
Microsoft では、このトピックに関する追加情報を見つけるのに役立つサード パーティの連絡先情報を提供しています。 将来予告なしに変更されることがあります。 Microsoft は、第三者の連絡先情報の正確性を保証しません。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示