CSE エラーによって発生したノードの準備ができていないエラーのトラブルシューティング

  • [アーティクル]

この記事では、カスタム スクリプト拡張機能 (CSE) エラーが原因で、Microsoft Azure Kubernetes Service (AKS) クラスターSucceededが状態ではなく、ノード プール内で AKS ノードの準備ができていないシナリオのトラブルシューティングに役立ちます。

前提条件

現象

CSE エラーのため、AKS クラスター ノードはノード プール内で準備ができていないため、AKS クラスターは状態ではありません Succeeded 。

原因

kubelet やその他のコンポーネントをプロビジョニングすると、ノード拡張機能のデプロイが失敗し、複数のエラー コードが返されます。 これがエラーの最も一般的な原因です。 kubelet をプロビジョニングするときにノード拡張機能のデプロイが失敗していることを確認するには、次の手順に従います。

  1. クラスターの現在のエラーを理解するには、 az aks show コマンドと az resource update コマンドを実行してデバッグを設定します。

    clusterResourceId=$(az aks show \
    --resource-group <resource-group-name> --name <cluster-name> --output tsv --query id)
az resource update --debug --verbose --ids $clusterResourceId

  2. コマンドから az resource update 受け取ったデバッグ出力とエラー メッセージを、GitHub の CSE ヘルパー 実行可能ファイルのエラー リストと照合します。

いずれかのエラーに kubelet の CSE デプロイが含まれている場合は、ここで説明するシナリオが Node Not Ready エラーの原因であることを確認しました。

一般に、終了コードは、エラーの原因となっている特定の問題を特定します。 たとえば、"API サーバーと通信できません" や "インターネットに接続できません" などのメッセージが表示されます。または、終了コードによって、API ネットワークのタイムアウト、または交換が必要なノード障害が警告される場合があります。

解決策 1: カスタム DNS サーバーが正しく構成されていることを確認する

名前解決を正しく実行できるように、カスタム ドメイン ネーム システム (DNS) サーバーを設定します。 次の要件を満たすようにサーバーを構成します。

  • カスタム DNS サーバーを使用している場合は、サーバーが正常であり、ネットワーク経由で到達可能であることを確認します。

  • カスタム DNS サーバーに 、Azure DNS IP アドレス (またはそのアドレスへのフォワーダー) に必要な条件付き フォワーダーがあることを確認します。

  • プライベート AKS DNS ゾーンが Azure でホストされている場合は、カスタム DNS 仮想ネットワークにリンクされていることを確認します。

  • カスタム DNS サーバーの IP アドレスで Azure DNS IP アドレスを使用しないでください。 これを行うことはお勧めしません。

  • DNS 設定で DNS サーバーの代わりに IP アドレスを使用しないでください。 Azure CLI コマンドを使用して、仮想マシン (VM) スケール セットまたは可用性セットでこのような状況に対してチェックできます。

    • VM スケール セット ノードの場合は、 az vmss run-command invoke コマンドを使用します。

      az vmss run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-scale-set-name> \
    --command-id RunShellScript \
    --instance-id 0 \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet <dns-ip-address> 53"
az vmss run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-scale-set-name> \
    --instance-id 0 \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup <api-fqdn> <dns-ip-address>"

    • VM 可用性セット ノードの場合は、 az vm run-command invoke コマンドを使用します。

      az vm run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-availability-set-name> \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet <dns-ip-address> 53"
az vm run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-availability-set-name> \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup <api-fqdn> <dns-ip-address>"

詳細については、「 Azure 仮想ネットワーク内のリソースの名前解決 」と「 カスタム DNS を使用したハブとスポーク」を参照してください。

解決策 2: API ネットワークのタイムアウトを修正する

API サーバーに到達でき、遅延の影響を受けないことを確認します。 これを行うには、次の手順を実行します。

  • AKS サブネットを確認して、割り当てられたネットワーク セキュリティ グループ (NSG) が API サーバーへのエグレス トラフィック ポート 443 をブロックしているかどうかを確認します。

  • ノード自体を確認して、ノードにトラフィックをブロックしている別の NSG があるかどうかを確認します。

  • 割り当てられたルート テーブルがないか AKS サブネットを確認します。 ルート テーブルにネットワーク仮想アプライアンス (NVA) またはファイアウォールがある場合は、ポート 443 がエグレス トラフィックに使用できることを確認します。 詳細については、「 AKS のクラスター ノードのエグレス トラフィックを制御する」を参照してください。

  • DNS で名前が正常に解決され、API に到達可能であっても、API のタイムアウトのためにノード CSE が失敗した場合は、次の表に示すように適切なアクションを実行します。

    型の設定 アクション
    VM 可用性セット kubectl delete node コマンドを使用して、Azure portalと AKS API からノードを削除し、クラスターをもう一度スケールアップします。
    VM スケール セット ノードを再イメージ化するか、ノードを削除してから、クラスターをもう一度スケールアップします。

  • 要求が AKS API サーバーによって調整されている場合は、より高いサービス レベルにアップグレードします。 詳細については、「 AKS アップタイム SLA」を参照してください。

詳細