次の方法で共有

CSE エラーが原因のノードの準備ができていないエラーのトラブルシューティング

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

前提条件

現象

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

原因

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

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

    環境変数を設定し、コマンドを実行してクラスターの状態とデバッグ情報を表示します。

    export RG_NAME="my-aks-rg"
export CLUSTER_NAME="myakscluster"
clusterResourceId=$(az aks show \
    --resource-group $RG_NAME --name $CLUSTER_NAME --output tsv --query id)
az resource update --debug --verbose --ids $clusterResourceId

    結果:

    {
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-aks-rg-xxx/providers/Microsoft.ContainerService/managedClusters/myaksclusterxxx",
  "name": "myaksclusterxxx",
  "type": "Microsoft.ContainerService/managedClusters",
  "location": "eastus2",
  "tags": null,
  "properties": {
    ...
  }
}

  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 仮想ネットワークにリンクされていることを確認します。

  • Azure DNS の IP アドレスをカスタムDNS サーバーの IP アドレスに置き換えます。 これを行うことはお勧めしません。

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

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

      大事な： VM スケール セットの --instance-id を指定する必要があります。 ここでは、AKS ノード リソース グループ内の有効なインスタンス ID (例: 0) と VMSS のクエリを実行する方法を示します。 環境に合わせて値を適切に更新します。

      export NODE_RESOURCE_GROUP=$(az aks show --resource-group $RG_NAME --name $CLUSTER_NAME --query nodeResourceGroup -o tsv)
export VMSS_NAME=$(az vmss list --resource-group $NODE_RESOURCE_GROUP --query "[0].name" -o tsv)
export DNS_IP_ADDRESS="10.0.0.10"
export INSTANCE_ID=$(az vmss list-instances --resource-group $NODE_RESOURCE_GROUP --name $VMSS_NAME --query "[0].instanceId" -o tsv)
export API_FQDN=$(az aks show --resource-group $RG_NAME --name $CLUSTER_NAME --query fqdn -o tsv)

az vmss run-command invoke \
    --resource-group $NODE_RESOURCE_GROUP \
    --name $VMSS_NAME \
    --instance-id $INSTANCE_ID \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet $DNS_IP_ADDRESS 53"
az vmss run-command invoke \
    --resource-group $NODE_RESOURCE_GROUP \
    --name $VMSS_NAME \
    --instance-id $INSTANCE_ID \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup $API_FQDN $DNS_IP_ADDRESS"

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

      大事な： リソース グループの可用性セットで有効な VM の --name を指定する必要があります。 ネットワーク チェックを実行するためのテンプレートを次に示します。

      az vm run-command invoke \
    --resource-group $RG_NAME \
    --name $AVAILABILITY_SET_VM \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet $DNS_IP_ADDRESS 53"
az vm run-command invoke \
    --resource-group $RG_NAME \
    --name $AVAILABILITY_SET_VM \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup $API_FQDN $DNS_IP_ADDRESS"

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

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

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

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

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

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

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

    種類の設定 アクション
    VM 可用性セット kubectl delete node コマンドを使用して Azure portal と AKS API からノードを削除し、クラスターをもう一度スケールアップします。
    仮想マシン スケール セット Azure portal からノードを再イメージ化するか、ノードを削除してから、クラスターをもう一度スケールアップします。 特定のノードを削除するには、 az aks nodepool delete-machines コマンドを使用します。 最初に切断してドレインし、ノードを削除します。

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

詳細

  • Last updated on