すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:クラスター管理のよくある質問

    ドキュメントセンター

    Container Service for Kubernetes:クラスター管理のよくある質問

    最終更新日:Nov 09, 2025

    このトピックでは、クラスターの作成、使用、管理に関する一般的な問題と解決策について説明します。

    自己管理型 Kubernetes クラスターを ACK に移行するにはどうすればよいですか？

    Alibaba Cloud Container Service for Kubernetes (ACK) は、自己管理型 Kubernetes クラスターを ACK クラスターに移行するためのシームレスなソリューションを提供します。このソリューションにより、移行中にビジネスに影響が及ばないことが保証されます。詳細については、「Kubernetes 移行ソリューションの概要」をご参照ください。

    Alibaba Cloud Linux オペレーティングシステムを使用するクラスターは、CentOS コンテナイメージと互換性がありますか？

    はい、互換性があります。Alibaba Cloud Linux を実行するクラスターは、CentOS ベースのコンテナイメージと互換性があります。詳細については、「Alibaba Cloud Linux 3」をご参照ください。

    クラスター作成時に containerd コンテナーランタイムを選択した場合、後で Docker に変更できますか？

    いいえ、変更できません。クラスターが作成された後、そのコンテナーランタイムを変更することはできません。ただし、同じクラスター内に異なるコンテナーランタイムを使用するノードプールを作成することはできます。詳細については、「ノードプールの作成と管理」をご参照ください。

    ノードのコンテナーランタイムを Docker から containerd に移行するには、「ノードのコンテナーランタイムを Docker から containerd に移行する」をご参照ください。

    説明

    Kubernetes 1.24 以降を実行するクラスターでは、Docker は組み込みのコンテナーランタイムとしてサポートされていません。これらのクラスターでは、ノードプールランタイムとして containerd を使用する必要があります。

    containerd、Docker、サンドボックス化されたコンテナーランタイムの違いは何ですか？

    Container Service for Kubernetes は、containerd、Docker、Sandboxed-Container の 3 つのランタイムをサポートしています。コンテナーランタイムとして containerd を使用することをお勧めします。Kubernetes 1.22 以前を実行するクラスターでは、Docker をコンテナーランタイムとして使用できます。Kubernetes 1.24 以前を実行するクラスターでは、Sandboxed-Container をコンテナーランタイムとして使用できます。これらのランタイムの比較については、「containerd、Sandboxed-Container、Docker ランタイムの比較」をご参照ください。クラスターが Docker をコンテナーランタイムとして使用している場合、クラスターの Kubernetes バージョンを 1.24 以降に更新する前に、コンテナーランタイムを containerd に移行する必要があります。詳細については、「ノードのコンテナーランタイムを Docker から containerd に移行する」をご参照ください。

    Container Service for Kubernetes (ACK) は MLPS 2.0 レベル 3 の認定を受けていますか？

    はい、受けています。クラスターの等級保護を有効にし、ベースラインチェックポリシーを設定できます。Alibaba Cloud Linux に基づいて、MLPS 2.0 レベル 3 を実装し、等級保護コンプライアンスのベースラインチェックを設定して、次の要件を満たすことができます：

    • ID 認証

    • アクセス制御

    • セキュリティ監査

    • 侵入防止

    • 悪意のあるコードの防止

    詳細については、「ACK MLPS 強化手順」をご参照ください。

    ACK クラスターは Istio をサポートしていますか？

    はい、サポートしています。Alibaba Cloud Service Mesh (ASM) を使用できます。ASM は、コミュニティの Istio と完全に互換性のあるサービスメッシュプロダクトです。完全に管理されたコントロールプレーンを提供し、ビジネスアプリケーションの開発とデプロイに集中できます。 ASM は、ACK ノードの複数のオペレーティングシステムと、クラスター内にデプロイされたさまざまなネットワークプラグインをサポートしています。既存の ACK クラスターを ASM インスタンスに追加して、トラフィック管理、障害処理、統一されたモニタリング、ログ管理などの機能を使用できます。詳細については、「クラスターを ASM インスタンスに追加する」をご参照ください。ASM の課金については、「ASM の課金」をご参照ください。

    Kubernetes クラスターの診断情報を収集するにはどうすればよいですか？

    Kubernetes クラスターに問題がある場合やノードが異常な場合は、ACK が提供する診断機能を使用して、クラスターの問題を特定するのに役立ちます。詳細については、「クラスター診断の使用」をご参照ください。

    クラスター診断機能がニーズを満たさない場合は、マスターノードと異常なワーカーノードから診断情報を収集できます。以下の手順に従って、Linux または Windows ノードから情報を収集します。

    Linux ノードから診断情報を収集する

    ワーカーノードは Linux または Windows を実行できますが、マスターノードは Linux のみ実行できます。次のメソッドは、Linux を実行するマスターノードとワーカーノードの両方に適用されます。この例では、マスターノードを使用します。

    1. Kubernetes クラスターのマスターノードにログインし、次のコマンドを実行して診断スクリプトをダウンロードします。

      curl -o /usr/local/bin/diagnose_k8s.sh http://aliacs-k8s-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/public/diagnose/diagnose_k8s.sh
      説明

      Linux ノードの診断スクリプトは、中国 (杭州) リージョンからのみダウンロードできます。

    2. 次のコマンドを実行して、診断スクリプトに実行権限を付与します。

      chmod u+x /usr/local/bin/diagnose_k8s.sh

    3. 次のコマンドを実行して、指定したディレクトリに移動します。

      cd /usr/local/bin

    4. 次のコマンドを実行して、診断スクリプトを実行します。

      diagnose_k8s.sh

      次の出力が返されます。診断スクリプトによって生成されるログファイルの名前は異なります。この例では、ファイル名は diagnose_1514939155.tar.gz です。

      ......
+ echo 'please get diagnose_1514939155.tar.gz for diagnostics'
please get diagnose_1514939155.tar.gz for diagnostics
+ echo 'Please upload diagnose_1514939155.tar.gz'
Please upload diagnose_1514939155.tar.gz

    5. 次のコマンドを実行して、クラスターの診断情報が格納されているファイルを表示します。

      ls -ltr | grep diagnose_1514939155.tar.gz
      説明

      diagnose_1514939155.tar.gz を実際のログファイル名に置き換えてください。

    Windows ノードから診断情報を収集する

    Windows を実行するワーカーノードから診断情報を収集するには、診断スクリプトをダウンロードして実行します。

    説明

    Windows はワーカーノードでのみ使用できます。

    1. 異常なワーカーノードにログインし、[ファイル名を指定して実行] ウィンドウを開き、[cmd] と入力して [OK] をクリックしてコマンドラインインターフェイスを開きます。

    2. 次のコマンドを実行して PowerShell モードに入ります。

      powershell

    3. 次のコマンドを実行して、診断スクリプトをダウンロードして実行します。

      Windows ノードの診断スクリプトは、クラスターが存在するリージョンからダウンロードできます。コマンドの [$Region_ID] を実際のリージョン ID に置き換えてください。

      Invoke-WebRequest -UseBasicParsing -Uri http://aliacs-k8s-[$Region_ID].oss-[$Region_ID].aliyuncs.com/public/pkg/windows/diagnose/diagnose.ps1 | Invoke-Expression

      次の出力は、診断情報が収集されたことを示します。

      INFO: Compressing diagnosis clues ...
INFO: ...done
INFO: Please get diagnoses_1514939155.zip for diagnostics
      説明

      diagnoses_1514939155.zip ファイルは、スクリプトが実行されたディレクトリに保存されます。

    ACK クラスターの問題をトラブルシューティングするにはどうすればよいですか？

    1. クラスターノードの確認

    1. 次のコマンドを実行して、クラスター内のノードのステータスを表示します。すべてのノードが存在し、Ready 状態であることを確認します。

      kubectl get nodes

      期待される出力は、次のようになります。p

      • すべてのノードが存在し、Ready 状態である場合、クラスターノードは正常です。

      • ノードが異常な場合、ステップ 2 に進みます。

    2. 次のコマンドを実行して、ノードの詳細情報とイベントを表示します。

      [$NODE_NAME] をノード名に置き換えてください。

      kubectl describe node [$NODE_NAME]
      説明

      kubectl の出力の詳細については、「ノードのステータス」をご参照ください。

    2. クラスターコンポーネントの確認

    クラスターノードを確認しても問題が特定できない場合は、コントロールプレーンのコンポーネントログを確認します。

    1. 次のコマンドを実行して、kube-system 名前空間内のすべてのコンポーネントを表示します。

      kubectl get pods -n kube-system

      期待される出力は次のとおりです。1名前が `kube-` で始まる Pod は Kubernetes クラスターのシステムコンポーネントです。名前が `coredns-` で始まる Pod は DNS プラグインです。期待される出力は、コンポーネントが正常な状態であることを示します。コンポーネントが異常な状態の場合は、次のステップに進みます。

    2. 次のコマンドを実行して、異常なコンポーネントのログを表示し、問題を特定して解決します。

      [$Component_Name] を異常なコンポーネントの名前に置き換えてください。

      kubectl logs -f [$Component_Name] -n kube-system

    3. kubelet コンポーネントの確認

    1. 次のコマンドを実行して、kubelet のステータスを確認します。

      systemctl status kubelet

    2. kubelet のステータスが active (running) でない場合は、次のコマンドを実行して kubelet のログを表示し、問題を特定して解決します。

      journalctl -u kubelet

    一般的なクラスターの問題

    次の表に、ACK クラスターの障害の一般的な原因とその解決策をいくつか示します。

    トラブルシューティングシナリオ

    解決策

    API サーバーコンポーネントまたはマスターコンポーネントが実行を停止します：

    • Pod、サービス、デプロイメントなどのリソースを作成、停止、または更新できません。

    • Kubernetes Dashboard など、ACK API を呼び出す必要がある場合を除き、既存の Pod とサービスは実行を継続します。

    ACK コンポーネントには高可用性機能が組み込まれています。コンポーネント自体が異常かどうかを確認します。たとえば、ACK クラスターの API サーバーはデフォルトで SLB インスタンスを使用します。SLB インスタンスをトラブルシューティングして、異常なステータスの原因を特定できます。

    API サーバーのバックエンドデータが失われます：

    • API サーバーを起動できません。

    • Kubernetes Dashboard など、ACK API を呼び出す必要がある場合を除き、既存の Pod とサービスは実行を継続します。

    • API サーバーを起動するには、API サーバーデータを回復または再構築する必要があります。

    スナップショットを作成している場合は、スナップショットからデータを復元して問題を解決できます。スナップショットを作成していない場合は、チケットを送信できます。問題が解決したら、次のメソッドを使用して再発を防ぐことができます：

    個々のノードがシャットダウンし、そのノード上のすべての Pod が実行を停止します。

    Pod を直接作成するのではなく、デプロイメント、StatefulSet、DaemonSet などのワークロードを使用して Pod を作成します。これにより、Pod が他の正常なノードにスケジュールされないことを防ぎます。

    kubelet コンポーネントが失敗します：

    • kubelet が異常なノードでは Pod を作成できません。

    • kubelet が一部の Pod を誤って削除した可能性があります。

    • ノードは Unhealthy としてマークされます。

    • デプロイメントまたはレプリケーションコントローラーは、他のノードに新しい Pod を作成します。

    • 問題が発生する前にスナップショットを作成している場合は、スナップショットからデータを復元して解決できます。スナップショットを作成していない場合は、チケットを送信して問題を報告してください。問題が解決したら、kubelet によって管理されるボリュームのスナップショットを定期的に作成します。詳細については、「単一ディスクボリュームのスナップショットを作成する」をご参照ください。

    • Pod を直接作成するのではなく、デプロイメント、StatefulSet、DaemonSet などのワークロードを使用して Pod を作成します。これにより、Pod が他の正常なノードにスケジュールされないことを防ぎます。

    設定ミスまたはその他の問題。

    問題が発生する前にスナップショットを作成している場合は、スナップショットからデータを復元して解決できます。スナップショットを作成していない場合は、チケットを送信して問題を報告してください。問題が解決したら、kubelet によって管理されるボリュームのスナップショットを定期的に作成します。詳細については、「単一クラウドディスク永続ボリュームのスナップショットを作成する」をご参照ください。

    RAM ユーザーが ACK クラスターを操作する際に、詳細な権限を付与するにはどうすればよいですか？

    1. デフォルトでは、RAM ユーザーと RAM ロールには Alibaba Cloud サービスの OpenAPI を使用する権限がありません。ACK クラスターを使用および管理するには、Container Service の AliyunCSFullAccess システム権限または必要なカスタム権限を付与する必要があります。詳細については、「RAM を使用してクラスターとクラウドリソースへのアクセス権限を付与する」をご参照ください。

    2. Kubernetes RBAC メカニズムに基づいて、デプロイメントやサービスの作成など、クラスター内のリソースを管理するための権限を RAM ユーザーに付与するために RBAC を使用して RAM ユーザーに権限を付与する必要があります。

      リソースの読み取りおよび書き込み権限を詳細に制御する必要があるシナリオでは、カスタムの ClusterRole と Role を使用して、より詳細な RBAC 権限を設定できます。詳細については、「カスタム RBAC を使用してクラスター内のリソースに対する操作を制限する」をご参照ください。

    3. RAM ユーザーがコンソールにアクセスする場合、ノードプールのスケーリングアクティビティやクラスターダッシュボードの表示などの機能を使用するために、関連する Alibaba Cloud サービスに必要な権限も付与する必要があります。詳細については、「Container Service コンソールの権限依存関係」をご参照ください。

    クラスターの API サーバー SLB インスタンスのアクセス制御ポリシーを設定する際に、どの IP アドレス範囲を許可する必要がありますか？

    API サーバーの SLB インスタンスのアクセス制御リスト (ACL) ルールでは、次の IP アドレス範囲を許可する必要があります。

    • Container Service for Kubernetes によって管理される CIDR ブロック、つまり 100.104.0.0/16。

    • クラスターの VPC のプライマリ CIDR ブロックと追加の CIDR ブロック (ある場合)、またはクラスターノードが配置されている vSwitch CIDR ブロック。

    • ユーザー側で API サーバー接続エンドポイントにアクセスする必要があるクライアントの出口 CIDR ブロック。

    • 上記の CIDR ブロックに加えて、ACK Edge クラスターはエッジノードの出口 CIDR ブロックを許可する必要があります。

    • 上記の CIDR ブロックに加えて、ACK Lingjun クラスターは Lingjun Virtual Private Datacenter (VPD) の CIDR ブロックを許可する必要があります。

    詳細については、「API サーバーのアクセス制御ポリシーを設定する」をご参照ください。

    マスターノードにアクセスするにはどうすればよいですか？

    • ACK 専用クラスター: 詳細については、「SSH を使用して ACK 専用クラスターのマスターノードに接続する」をご参照ください。

    • ACK マネージドクラスター: ACK マネージドクラスターのコントロールプレーンノードは完全に管理されています。コントロールプレーンノードのターミナルにはログインできません。コントロールプレーンノードにログインするには、ACK 専用クラスターの使用を検討してください。

    ACK 専用クラスターから誤ってマスターノードを削除した場合でも、クラスターをアップグレードできますか？

    いいえ、できません。ACK 専用クラスターからマスターノードを削除すると、マスターノードを追加したり、クラスターをアップグレードしたりすることはできません。「ACK 専用クラスターの作成 (廃止)」をご参照ください。

    ACK 専用クラスターからマスターノードを追加または削除できますか？ 高リスクな操作は何ですか？

    いいえ、できません。ACK 専用クラスターからマスターノードを追加または削除すると、クラスターが使用不能になり、回復不能になる可能性があります。

    ACK 専用クラスターのマスターノードでは、不適切な操作によりマスターノード、さらにはクラスター全体が利用できなくなる可能性があります。高リスクな操作には、マスターまたは etcd 証明書の置換、コアコンポーネントの変更、ノード上の /etc/kubernetes などのコアディレクトリ内のデータの削除またはフォーマット、オペレーティングシステムの再インストールなどがあります。詳細については、「クラスター関連の高リスクな操作」をご参照ください。

    ACK 専用クラスターの API サーバーがエラー "api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after xxx を返す場合はどうすればよいですか？

    現象

    ACK 専用クラスターで Pod を作成すると、API サーバーが証明書の有効期限切れエラーを返すか、kube-controller-managerのログまたはイベントに証明書の有効期限切れエラーが表示されます。エラーメッセージは次のとおりです。

    "https://localhost:6443/api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after XXX
    "https://[::1]:6443/api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after XXX

    原因

    Kubernetes では、API サーバーには、その内部 LoopbackClient サーバー用の組み込み証明書があります。コミュニティバージョンでは、この証明書の有効期間は 1 年であり、自動的にローテーションすることはできません。API サーバー Pod が再起動した場合にのみ、自動的にローテーションおよび更新されます。Kubernetes のバージョンが 1 年以上アップグレードされていない場合、内部証明書が期限切れになり、API リクエストが失敗します。詳細については、「#86552」をご参照ください。

    Kubernetes 1.24 以降を実行する ACK クラスターの証明書の有効期間が短いことによるリスクを軽減するために、組み込み証明書のデフォルトの有効期間は 10 年に延長されています。詳細については、「製品の変更：ACK クラスター API サーバー内部証明書の有効期間の変更」をご参照ください。

    解決策

    マスターノードにログインし、次のコマンドを実行して LoopbackClient 証明書の有効期限をクエリします。

    コマンドでは、XX.XX.XX.XX はマスターノードのローカル IP アドレスです。

    curl --resolve apiserver-loopback-client:6443:XX.XX.XX.XX -k -v https://apiserver-loopback-client:6443/healthz 2>&1 |grep expire

    • 1 年間の証明書が期限切れまたは期限切れ間近のクラスターの場合は、クラスターをバージョン 1.24 以降にアップグレードします。詳細については、「クラスターの手動アップグレード」をご参照ください。ACK マネージドクラスター Pro インスタンスに移行することをお勧めします。詳細については、「ACK 専用クラスターから ACK マネージドクラスター Pro へのホットマイグレーション」をご参照ください。

    • 短期間でアップグレードできないACK 専用クラスターの場合は、各マスターノードにログインし、API サーバーを手動で再起動して、新しい有効な証明書を生成します。

      • containerd ノード

        crictl pods  |grep kube-apiserver- | awk '{print $1}' | xargs -I '{}' crictl stopp {}

      • Docker ノード

        docker ps | grep kube-apiserver- | awk '{print $1}' | xargs -I '{}' docker restart {}