次の方法で共有


AKS クラスターの作成に関する問題の基本的なトラブルシューティング

この記事では、Microsoft Azure Kubernetes Service (AKS) クラスターを正常に作成またはデプロイできない場合に使用する基本的なトラブルシューティング方法について説明します。

前提条件

  • Azure CLI (バージョン 2.0.59 以降のバージョン)。

  • Kubernetes kubectl ツール。 Azure CLI を使用して kubectl をインストールするには、 az aks install-cli コマンドを実行します。

Azure CLI からエラーを表示する

Azure CLI を使用してクラスターを作成しようとしたときに操作が失敗した場合、出力にはエラー情報が表示されます。 Azure CLI のコマンドと出力の例を次に示します。

# Create a cluster specifying subnet

az aks create --resource-group myResourceGroup
--name MyManagedCluster \
--load-balancer-sku standard \
--vnet-subnet-id /subscriptions/<subscriptions-id>/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/aks_demo_vnet/subnets/AKS

出力のサンプル:

It is highly recommended to use USER assigned identity (option --assign-identity)when you want to bring you own subnet, which will have no latency for the role assignment to take effect. When you SYSTEM assigned identity, azure-cli will grant Network Contributor role to the system assigned identity after the cluster is created, and the role assignment will take some time to take effect, see https://learn.microsoft.com/azure/aks/use-managed-identity, proceed to create cluster with system assigned identity? (y/N): y`

(ControlPlaneAddOnsNotReady) Pods not in Running status: konnectivity-agent-67f7f5554f-nsw2g,konnectivity-agent-8686cb54fd-xlsgk,metrics-server-6bc97b47f7-dfhbr,coredns-845757d86-7xjqb,coredns-autoscaler-5f85dc856b-mxkrj

出力からエラー コードとエラー メッセージを識別できます。 この場合、次のようになります。

  • エラー コード: ControlPlaneAddOnsNotReady
  • エラー メッセージ: Pods not in Running status: konnectivity-agent-67f7f5554f-nsw2g,konnectivity-agent-8686cb54fd-xlsgk,metrics-server-6bc97b47f7-dfhbr,coredns-845757d86-7xjqb,coredns-autoscaler-5f85dc856b-mxkrj

これらの説明には、多くの場合、クラスターの作成で問題が発生した内容の詳細が含まれており、さらに詳細が含まれている記事にリンクされています。 さらに、Azure CLI 操作によって生成されるエラーに基づいて、トラブルシューティングに関する記事を参照として使用できます。

Azure portal でエラーの詳細を表示する

Azure ポータルで AKS クラスターの作成エラーを調査するにはActivity Logを開きます。 ニーズに合わせて結果をフィルター処理できます。 これを行うには、[フィルター 追加 を選択して、フィルターにプロパティを追加します。

フィルターを追加する方法のスクリーンショット。

Activity Log ページで、Operation name 列に Create または Update Managed Cluster が表示されているログ エントリを見つけます。

Event initiated by 列には、操作を実行したユーザー (職場アカウント、学校アカウント、Azure マネージド IDなど) が表示されます。

操作が成功した場合、 Status 列の値は Accepted。 次の操作名など、クラスター コンポーネントを作成するためのサブ操作エントリも表示されます。

  • ルート テーブルの作成または更新
  • ネットワーク セキュリティ グループを作成または更新する
  • ユーザー割り当て ID 作成の更新
  • ロード バランサーの作成または更新
  • パブリック IP アドレスの作成または更新
  • ロールの割り当てを作成する
  • リソース グループを更新する

これらのサブ操作エントリでは、 Status 値は Succeededed Event initiated by フィールドは AzureContainerService に設定されます。

アクティビティ ログのビューのスクリーンショット。

代わりにエラーが発生した場合はどうしますか? その場合、 Status 値は Failed です。 クラスター コンポーネントを作成する操作とは異なり、失敗したサブ操作エントリを展開して確認する必要があります。 一般的なサブ操作名は、'audit' ポリシー アクション'auditIfNotExists' Policy action. などのポリシー アクションです。すべてのサブ操作が必ずしも一緒に失敗するわけではありません。 それらの一部が成功することを期待できます。

失敗したサブ操作のいずれかを選択して、さらに調査します。 問題のトラブルシューティングを行うには、 SummaryJSONChange History タブを選択します。 JSON タブには、エラーの出力テキストが JSON 形式で表示され、通常は最も役立つ情報が表示されます。

JSON 形式の詳細なログのスクリーンショット。

JSON 形式の詳細なログの例を次に示します。

{
     "status": {
        "value": "Failed",
        "localizedValue": "Failed"
    },
    "subStatus": {
        "value": "",
        "localizedValue": ""
    },
    "submissionTimestamp": "2024-08-30T10:06:07Z",
    "subscriptionId": "<subscriptionId>",
    "tenantId": "<tenantId>",
    "properties": {
        "statusMessage": "{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceOperationFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Failed'.\",\"details\":[{\"code\":\"VMExtensionProvisioningError\",\"message\":\"Unable to establish outbound connection from agents, please see https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/error-code-outboundconnfailvmextensionerror and https://aka.ms/aks-required-ports-and-addresses for more information.\"}]}}",
}
}

クラスターの分析情報を表示する

クラスターは Azure portal で作成されましたか。 これが当てはまる場合は、トラブルシューティングに役立つクラスター分析情報を生成できます。 この機能にアクセスするには、次の手順に従います。

  1. azure portal で、Kubernetes サービスを検索して選択します。

  2. AKS クラスターの名前を選択します。

  3. AKS クラスター ページのナビゲーション ウィンドウで、 Diagnose を選択し、問題を解決します

  4. Diagnose と問題の解決 ページで、Cluster insights リンクを選択します。 クラスター分析情報ツールはクラスターを分析し、その結果の一覧を Cluster Insights ページの Observations and Solutions セクションで提供します。

  5. いずれかの結果を選択して、問題とその考えられる解決策に関する詳細情報を表示します。

Azure portal でリソースを表示する

Azure portal では、クラスターの作成時に作成されたリソースを表示できます。 通常、これらのリソースは、名前が MC_ で始まるリソース グループ内にあります。 マネージド クラスター リソース グループには、 MC_MyResourceGroup_MyManagedCluster_<location-code> などの名前が付いている場合があります。 ただし、カスタムマネージド クラスター リソース グループを使用してクラスターを構築した場合は、名前が異なる場合があります。

リソース グループを見つけるには、Azure portal で リソース グループ を検索して選択し、クラスターが作成されたリソース グループを選択します。 リソース 一覧は、リソース グループの Overview ページに表示されます。

警告

MC_ リソース グループ内のリソースは変更しないことをお勧めします。 このアクションは、AKS クラスターに悪影響を与える可能性があります。

仮想マシン スケール セットの状態を確認するには、リソース グループのリソースの一覧からスケール セット名を選択します。 Name aks-nodepool1-12345678-vmss のような値があり、Type 仮想マシン スケール セットの値です。 スケール セットの状態はノード プールの Overview ページの上部に表示され、詳細は Essentials 見出しに表示されます。 デプロイが失敗した場合、表示される状態は Failed

すべてのリソースについて、詳細を確認して、デプロイが失敗した理由について理解を深めることができます。 スケール セットの場合は、 Failed 状態テキストを選択して、エラーに関する詳細を表示できます。 詳細は、 StatusLevel、および Code 列を含む行にあります。 次の例は、列値の行を示しています。

値の例
状態 プロビジョニングに失敗しました
Level エラー
コード ProvisioningState/failed/VMExtensionProvisioningError

行を選択すると、 Message フィールドが表示されます。 これには、そのエラーに関するさらに多くの情報が含まれています。 たとえば、例の行の Message フィールドは、次のテキストで始まります。

拡張機能 'vmssCSE' の処理中に VM からエラーが報告されました。 エラー メッセージ: "Enable failed: failed to execute command: command terminated with exit status=50 [stdout] [stderr] 0 0 0 --:

この情報を使用して、スケール セット内の VM が失敗し、終了状態 50 が生成されたと結論付けることができます。

Note

クラスターのデプロイが、これらのリソースが作成された時点に達しなかった場合は、Azure portal でマネージド クラスター リソース グループを確認できない可能性があります。

Kubectl コマンドを使用する

クラスターのエラーのトラブルシューティングに役立つ別のオプションについては、kubectl コマンドを使用して、クラスターにデプロイされたリソースの詳細を取得します。 これを行うには、最初に AKS クラスターにサインインします。

az aks get-credentials --resource-group MyResourceGroup --name MyManagedCluster

障害の種類と発生時刻によっては、クラスターにサインインして詳細を取得できない場合があります。 ただし、クラスターが作成され、Azure portal に表示される場合は、サインインして kubectl コマンドを実行できる必要があります。

クラスター ノードの表示 (kubectl get nodes)

クラスター ノードの状態を確認するには、 kubectl get nodes コマンドを実行してノードを表示します。 この例では、クラスター内のノードは報告されません。

$ kubectl get nodes

No resources found

システム名前空間のポッドを表示する (kubectl get pods)

kube-system 名前空間でポッドを表示することも、問題のトラブルシューティングに適した方法です。 このメソッドを使用すると、Kubernetes システム ポッドの状態を表示できます。 この例では、 kubectl get pods コマンドを入力します。

$ kubectl get pods -n kube-system
NAME                                  READY   STATUS    RESTARTS   AGE
coredns-845757d86-7xjqb               0/1     Pending   0          78m
coredns-autoscaler-5f85dc856b-mxkrj   0/1     Pending   0          77m
konnectivity-agent-67f7f5554f-nsw2g   0/1     Pending   0          77m
konnectivity-agent-8686cb54fd-xlsgk   0/1     Pending   0          65m
metrics-server-6bc97b47f7-dfhbr       0/1     Pending   0          77m

ポッドの状態を記述する (kubectl describe ポッド)

ポッドの状態を記述することで、構成の詳細と、ポッドで発生したすべてのイベントを表示できます。 kubectl describe pods コマンドを実行します。

$ kubectl describe pod coredns-845757d86-7xjqb -n kube-system
Name:                 coredns-845757d86-7xjqb
Namespace:            kube-system
Priority:             2000001000
Priority Class Name:  system-node-critical
Node:                 <none>
Labels:               k8s-app=kube-dns
                      kubernetes.io/cluster-service=true
                      pod-template-hash=845757d86
                      version=v20
...
Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning  FailedScheduling  24m (x1 over 25m)   default-scheduler  no nodes available to schedule pods
  Warning  FailedScheduling  29m (x57 over 84m)  default-scheduler  no nodes available to schedule pods

コマンド出力では、使用可能なノードがないため、ポッドをノードにデプロイできないことがわかります。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。