すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:クラスター管理に関するFAQ about cluster management

    ドキュメントセンター

    Container Service for Kubernetes:クラスター管理に関するFAQ about cluster management

    最終更新日:Oct 23, 2024

    このトピックでは、クラスターの作成、使用、および管理に関するよくある質問 (FAQ) に対する回答を提供します。

    Alibaba Cloud Linuxを実行するACKクラスターは、CentOSベースのコンテナーイメージと互換性がありますか。

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

    クラスターのコンテナランタイムをcontainerdからDockerに変更できますか?

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

    ノードのコンテナランタイムをDockerからcontainerdに変更できます。 詳細については、「コンテナランタイムをDockerからcontainerdに変更する」をご参照ください。

    説明

    Kubernetes 1.24を実行するクラスターは、組み込みコンテナランタイムとしてDockerを使用しなくなりました。 Kubernetes 1.24以降を実行するクラスターのコンテナランタイムとしてcontainerdを使用できます。

    containerd、Docker、およびSandboxed-Containerの違いは何ですか?

    Container Service for Kubernetesは、containerd、Docker、およびSandboxed-containerというコンテナーランタイムをサポートしています。 containerdをコンテナランタイムとして使用することを推奨します。 Kubernetes V1.22以前を実行するクラスターでは、コンテナーランタイムとしてDockerを使用できます。 Kubernetes V1.24以前を実行するクラスターのコンテナランタイムとしてSandboxed-Containerを使用できます。 さまざまなコンテナランタイムの比較の詳細については、「Docker、containerd、およびSandboxed-containerの比較」をご参照ください。 クラスターがコンテナーランタイムとしてDockerを使用している場合、クラスターのKubernetesバージョンを1.24以降に更新する前に、コンテナーランタイムをcontainerdに変更する必要があります。 詳細については、「コンテナランタイムをDockerからcontainerdに変更する」をご参照ください。

    ACKはレベル3サイバーセキュリティの認定を受けていますか?

    Alibaba Cloud Linuxに基づいて、セキュリティ強化を有効にし、クラスターのベースラインチェックポリシーを設定して、マルチレベル保護スキーム (MLPS) 2.0レベル3準拠を実現できます。 これには、クラスターが次のコンプライアンス要件を満たしていることを確認するためのコンプライアンスベースラインチェックの設定も含まれます。

    • ID検証

    • アクセス制御

    • セキュリティ監査

    • 侵入防止

    • 悪意のあるコード保護

    詳細については、「ACK security hardening based on MLPS」をご参照ください。

    クラスターのマスターノードを誤って削除した後、ACK専用クラスターを更新できますか?

    いいえ。クラスターのマスターノードを誤って削除した後は、ACK専用クラスターを更新できません。 ACK専用クラスターのマスターノードが削除された後、別のマスターノードを追加したり、クラスターのKubernetesバージョンを更新したりすることはできません。 この場合、別のACK専用クラスターを作成できます。

    マスターノードに接続する方法?

    • ACK専用クラスター: SSHを使用してACK専用クラスターのマスターノードに接続できます。

    • ACK管理クラスター: ACK管理クラスターでは、制御プレーンのノードは完全に管理されており、これらのノードの端末にログインすることはできません。 コントロールプレーンノードにログインする場合は、ACK専用クラスターを作成します。

    ACKクラスターの診断データを収集するにはどうすればよいですか?

    ACKは、数回のクリックでクラスターを診断できるクラスター診断機能を提供します。 この機能は、クラスターの問題とノードの異常のトラブルシューティングに役立ちます。 詳細については、「クラスター診断の操作」をご参照ください。

    さらに分析するために、マスターノードとワーカーノードから診断データを収集することもできます。 次のセクションでは、LinuxノードおよびWindowsノードから診断データを収集する方法について説明します。

    Linuxノードから診断データを収集する

    ワーカーノードはLinuxとWindowsをサポートしますが、マスターノードはLinuxのみをサポートします。 次の手順は、Linuxを実行するマスターノードとワーカーノードに適用されます。 この例では、診断データはマスターノードから収集されます。

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

      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

      次の出力が返されます。 診断スクリプトを実行するたびに、異なる名前のログファイルが生成されます。 この例では、ログファイルの名前はdiagnoste_1514939155.tar.gzです。 名前は実際の条件に左右されます。 

      ......
+ echo 'please get diagnose_1514939155.tar.gz for diagnostics'
please get diagnose_1514939155.tar.gz for diagnostics
+ echo 'Upload diagnose_1514939155.tar.gz'
Upload diagnose_1514939155.tar.gz

    5. 次のコマンドを実行して、診断データを格納するログファイルを照会します。 

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

      diagnoste_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
      説明

      diagnostes_1514939155.zipファイルは、診断スクリプトが実行されるディレクトリに格納されます。

    ACKクラスターの問題のトラブルシューティング方法を教えてください。

    手順1: クラスターノードの確認

    1. 次のコマンドを実行して、すべてのクラスターノードが準備完了状態かどうかを確認します。 

      kubectl get nodes

      次の図は、期待される出力を示しています。p

      • すべてのクラスターノードが存在し、準備状態にある場合、ノードは期待どおりに実行されます。

      • ノードがレディ状態でない場合、ステップ2を実行する。

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

      [$NODE_NAME] を実際のノード名に置き換えます。 

      kubectl describe node [$NODE_NAME]
      説明

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

    手順2: クラスターコンポーネントの確認

    すべてのクラスターノードが期待どおりに実行される場合は、クラスターコンポーネントのログを確認します。

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

      kubectl get pods -n kube-system

      次の図は、期待される出力を示しています。 1名前がkube-で始まるコンポーネントはシステムコンポーネントです。 名前がcorednsで始まるコンポーネントは、Alibaba Cloud DNS (DNS) コンポーネントです。 出力は、すべてのクラスターコンポーネントが期待どおりに実行されることを示します。 コンポーネントが期待どおりに実行されない場合は、次の手順を実行します。

    2. 次のコマンドを実行して、コンポーネントのログを照会します。

      [$Component_Name] を実際のコンポーネント名に置き換えます。 

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

    ステップ3: kubeletを確認する

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

      systemctl status kubelet

    2. kubeletがActive状態でない場合は、次のコマンドを実行してkubeletログを表示します。 ログに基づいて問題を特定し、トラブルシューティングします。 

      journalctl -u kubelet

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

    次の表に、ACKクラスターの一般的な問題と対応するソリューションを示します。

    問題

    解決策

    APIサーバーまたはマスターノード上のコンポーネントが停止します。 その結果、次の問題が発生する可能性があります。

    • ポッド、サービス、またはデプロイメントを作成、停止、または更新することはできません。

    • Kubernetesダッシュボードの管理などの操作を実行するためにACK APIを呼び出す必要がない限り、既存のポッドとサービスはすべて期待どおりに実行されます。

    ACKのコンポーネントは高可用性をサポートします。 コンポーネントが異常であるかどうかを確認することを推奨します。 たとえば、ACKクラスターのAPIサーバーはClassic Load Balancer (CLB) インスタンスを使用します。 CLBインスタンスが異常である理由を確認できます。

    APIサーバーのバックエンドデータが失われました。 その結果、次の問題が発生する可能性があります。

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

    • Kubernetesダッシュボードの管理などの操作を実行するためにACK APIを呼び出す必要がない限り、既存のポッドとサービスはすべて期待どおりに実行されます。

    • APIサーバーは、APIサーバーのバックエンドデータが復元または再作成された後にのみ起動できます。

    問題が発生する前にスナップショットを作成した場合は、スナップショットからデータを復元して問題を解決できます。 スナップショットが事前に作成されていない場合は、テクニカルサポートについてContact Usください。 この問題を防ぐには、次の方法を使用できます。

    ノードに障害が発生し、ノード上のすべてのポッドの実行が停止します。

    Deployments、StatefulSets、DaemonSetsなどのワークロードを使用してポッドを作成します。 ポッドを直接作成しないでください。 そうしないと、システムはポッドを正常なノードにスケジュールできない可能性があります。

    kubeletは失敗します。 その結果、次の問題が発生する可能性があります。

    • kubeletが失敗したノードにポッドを作成することはできません。

    • kubeletが特定のポッドを誤って削除する可能性があります。

    • 特定のノードは異常としてマークされます。

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

    • 問題が発生する前にスナップショットを作成した場合は、スナップショットからデータを復元して問題を解決できます。 スナップショットが作成されない場合は、テクニカルサポートについてContact Usください。 kubeletが管理するボリュームのスナップショットを定期的に作成します。 詳細については、「ディスクから作成されたボリュームスナップショットの使用」をご参照ください。

    • Deployments、StatefulSets、DaemonSetsなどのワークロードを使用してポッドを作成します。 ポッドを直接作成しないでください。 そうしないと、システムはポッドを正常なノードにスケジュールできない可能性があります。

    無効な設定などのその他の問題。

    問題が発生する前にスナップショットを作成した場合は、スナップショットからデータを復元して問題を解決できます。 スナップショットが作成されない場合は、テクニカルサポートについてContact Usください。 kubeletが管理するボリュームのスナップショットを定期的に作成します。 詳細については、「ディスクから作成されたボリュームスナップショットの使用」をご参照ください。

    ACKクラスターのサブスクリプションノードを作成した後、APIサーバーに従量課金CLBインスタンスを使用するにはどうすればよいですか

    ACKクラスターの作成時に [課金方法] パラメーターに [サブスクリプション] を選択した場合、サブスクリプションECSインスタンスがノードプールに作成され、サブスクリプションCLBインスタンスがAPIサーバーに使用されます。 APIサーバーにサブスクリプションノードを使用せず、従量課金CLBインスタンスを使用する場合は、次の手順を実行します。

    1. ACKクラスターを作成し、次の要件に基づいてパラメーターを設定します。 ACKクラスターの作成に必要な設定項目の詳細については、「ACK管理クラスターの作成」をご参照ください。

      • 課金方法: [従量課金] を選択します。 この場合、APIサーバー用に内部対応のCLBインスタンスが作成されます。 デフォルトでは、従量課金の課金方法を使用してCLBインスタンスに対して課金されます。

      • 期待されるノード: このパラメーターを0に設定します。これは、クラスターにノードが作成されていないことを示します。

    2. サブスクリプションECSインスタンスを作成します。 詳細については、「クイック起動タブのサブスクリプションECSインスタンスの作成」をご参照ください。

    3. ECSインスタンスをノードプールに追加します。 ノードプールへのECSインスタンスの追加に関する制限、使用方法、手順、およびFAQの詳細については、「既存のECSインスタンスのACKクラスターへの追加」をご参照ください。

    ACKクラスターのAPIサーバーへのアクセスを許可するには、SLB ACLでどのようなCIDRブロックを設定する必要がありますか?

    次のCIDRブロックからのアクセスを受け入れるように、APIサーバーのServer Load Balancer (SLB) のアクセス制御リスト (ACL) を設定する必要があります。

    • Container Service for KubernetesのコントロールプレーンCIDRブロック: 100.104.0.0/16。

    • クラスターが存在する仮想プライベートクラウド (VPC) のプライマリCIDRブロックとセカンダリCIDRブロック (存在する場合) 、またはクラスター内のノードのvSwitch CIDRブロック。

    • APIサーバーのCLBインスタンスにアクセスする必要があるクライアントによって使用されるパブリックCIDRブロック。

    • お使いのクラスターがACK edgeクラスターの場合、エッジノードによって使用されるパブリックCIDRブロック。

    • クラスタがACK Lingjunクラスタである場合、VPD (Vital Product Data) CIDRはブロックされます。

    上記のCIDRブロックからのアクセスを受け入れるようにネットワークACLを設定する必要があります。 上記のCIDRブロックからのアクセスをブロックしないでください。

    詳細については、「ACKクラスターのAPIサーバーのネットワークACLの設定」をご参照ください。