スケジューリングとソリューションに関するFAQ - Container Service for Kubernetes

このトピックでは、Container Service for Kubernetes (ACK) クラスターのスケジューリングポリシーに関するよくある質問に対する回答を提供します。

vSwitchによって提供されるIPアドレス不足によるポッドの起動失敗を回避するにはどうすればよいですか?
ack-deschedulerからKoordinator Deschedulerに移行するにはどうすればよいですか?
ACKスケジューラのデフォルトのスケジューリングポリシーは何ですか?
ホットスポットノードへのポッドのスケジューリングを回避するにはどうすればよいですか?
クラスターに追加した新しいノードにポッドがスケジュールされないのはなぜですか？
クラスターのCPUまたはメモリ使用率が高くない場合でも、スケジューリング中にCPUまたはメモリリソースが不足していることを示すメッセージがシステムに表示されるのはなぜですか？
ACKでスケジュール解除機能を使用するための注意事項は何ですか? この機能はポッドを再起動しますか?
アプリケーションを特定のノードにスケジュールするにはどうすればよいですか?
デプロイによって作成された特定の数のポッドをECSインスタンスとelastic containerインスタンスにスケジュールするにはどうすればよいですか？
ワークロードのポッドをスケジュールするときに、ポッドの高可用性を確保する方法を教えてください。

vSwitchによって提供されるIPアドレス不足によるポッドの起動失敗を回避するにはどうすればよいですか?

Kubernetesネイティブスケジューラは、vSwitchの使用可能なIPアドレスが十分かどうかを検出できません。その結果、クラスターに十分なIPアドレスがなく、ポッドが起動できない場合でも、システムはこれらのノードへのポッドのスケジューリングを試み続け、障害のあるポッドが急速に増加します。この問題を解決するために、ACKスケジューラはk8s.aliyun.com/max-available-ipアノテーションを追加して、各ノードで使用可能なIPアドレスの最大数を指定します。この注釈と、ポッドが排他的IPアドレスを必要とするかどうかに基づいて、スケジューラはノードにスケジュールできるポッドの数を制限します。さらに、ノードがそのIPアドレスを使い果たしたことが検出されると、スケジューラは、ノードステータスの十分なIP条件を更新する。この更新により、排他的IPアドレスを必要とする新しいポッドがそのノードに追加されないようになり、IPアドレス不足による大規模なポッド障害が防止されます。

k8s.aliyun.com/max-available-ipアノテーションを使用するには、クラスターとkube-schedulerコンポーネントが次の要件を満たしている必要があります。

クラスターはACK Proクラスターである必要があり、Terway 1.5.7以降がクラスターにインストールされています。詳細については、「ACK管理クラスターの作成」をご参照ください。

kube-schedulerのバージョンは、次の要件を満たす必要があります。

Kubernetesバージョン	kube-schedulerのバージョン
1.30	すべてのバージョン
1.28	V1.28.3-aliyun-6.3以降
1.26	V1.26.3-aliyun-6.3またはそれ以降
1.24	V1.24.6-aliyun-6.3以降
1.22	V1.22.15-aliyun-6.3またはそれ以降

どうすればack-deschedulerからKoordinator Deschedulerに移行できますか?

ACKは、ackコンソールのMarketplaceページにあるACK-deschedulerスケジューリング解除コンポーネントを提供します。このコンポーネントは、オープンソースのKubernetes Deschedulerに基づいて開発されています。 ack-descheduler 0.20.0および0.27.1が利用可能です。 ack-descheduler 0.20.0と0.27.1は同じ機能を提供し、オープンソースのKubernetes Descheduler 0.20.0と0.27.1と同じ方法で使用できます。

ack-deschedulerは中止されます。 ack-deschedulerからKoordinator Deschedulerに移行することを推奨します。移行手順は、Kubernetes DeschedulerからKoordinator Deschedulerに移行する手順と同様です。詳細については、「Kubernetes DeschedulerからKoordinator Deschedulerへの移行」をご参照ください。

ACKスケジューラのデフォルトのスケジューリングポリシーは何ですか?

ACKクラスターでは、ACKスケジューラのデフォルトのスケジューリングポリシーは、オープンソースのKubernetesスケジューラと同じです。 Kubernetesスケジューラは、ポッドをノードにスケジュールする方法を決定すると、フィルターとスコアの2つの主要な手順を実行します。

フィルタ: このステップは、スケジューリング可能なノードを検索する。ノードリストが空の場合、ポッドはスケジュールできません。
スコア: このステップでは、ポッドに最適なノードを選択するために、スケジュール可能なノードをスコア付けしてランク付けします。

最新バージョンのACKスケジューラで有効になっているフィルターおよびスコアプラグインの詳細については、「フィルターおよびスコアプラグイン」をご参照ください。

ホットスポットノードへのポッドのスケジューリングを回避するにはどうすればよいですか?

Kubernetesネイティブスケジューリングポリシーでは、スケジューラはリソースリクエストに基づいてポッドをスケジュールし、ノードの実際の使用率を考慮しません。スケジューラは、スケジューリングに協調的に影響を与える様々なフィルタおよびスコアプラグインを使用する。ホットスポットノードへのポッドのスケジューリングを回避するために、ACKクラスターの次の機能を使用することを推奨します。

リソースの冗長性を確保するために、各ポッドに適切なリソース要求と制限を設定します。リソースプロファイリング機能を使用して、履歴リソース使用量データの分析に基づいて推奨されるコンテナ仕様を取得できます。詳細については、「リソースプロファイリング」をご参照ください。
ワークロード認識スケジューリングを有効にします。 ACKが提供するKube Schedulerコンポーネントの負荷認識スケジューリング機能は、Kubernetesスケジューリングフレームワークに基づいて設計されています。 Kubernetesネイティブスケジューリングポリシーとは異なり、ACKスケジューラはノードの実際のリソース使用量を取得できます。システムは、ノードの負荷の履歴統計に基づいて低負荷のノードにポッドをスケジュールし、負荷分散を実装します。詳細については、「負荷対応スケジューリングの使用」をご参照ください。
負荷認識ホットスポットのスケジューリング解除を有効にします。時間、クラスター環境、トラフィックやワークロードへの要求などの要因が動的に変化すると、ノード間の負荷が不均衡になる可能性があります。この問題を防ぐために、ACKスケジューラはデスケジューリング機能を提供します。詳細については、「負荷認識型ホットスポットのスケジューリング解除」をご参照ください。

クラスターに追加した新しいノードにポッドがスケジュールされないのはなぜですか？

原因はさまざまです。次の操作を実行して、問題をトラブルシューティングできます。

ノードのステータスが正常かどうかを確認します。ノードがNotReady状態にある場合、ノードは準備ができていません。
ポッドがNodeSelector、NodeAffinity、PodAffinityなどの不適切なスケジューリングポリシーで構成されているかどうか、またはノードに汚染があるかどうかを確認します。上記のいずれかの条件が存在する場合、ポッドを新しいノードにスケジュールすることはできません。
問題がKubernetesネイティブのスケジューリングポリシーに関連しているかどうかを確認します。 Kubernetesネイティブスケジューリングポリシーでは、スケジューラはリソースリクエストに基づいてポッドをスケジュールし、ノードの実際の使用率を考慮しません。その結果、一部のノードでは多数のポッドが実行され、他のノードではポッドがいくつかまたはまったく実行されません。
この問題を解決する方法の詳細については、「ホットスポットノードへのポッドのスケジューリングを回避するにはどうすればよいですか?」をご参照ください。

クラスターのCPUまたはメモリ使用率が高くない場合でも、スケジューリング中にCPUまたはメモリリソースが不足していることを示すメッセージがシステムに表示されるのはなぜですか？

Kubernetesネイティブスケジューリングポリシーでは、スケジューラはリソースリクエストに基づいてポッドをスケジュールし、ノードの実際の使用率を考慮しません。クラスターの実際のCPU使用率が高くない場合でも、CPUまたはメモリリソースが不足しているため、ポッドのスケジュールに失敗する可能性があります。

この問題を解決する方法の詳細については、「ホットスポットノードへのポッドのスケジューリングを回避するにはどうすればよいですか?」をご参照ください。

ACKでスケジュール解除機能を使用するための注意事項は何ですか? この機能はポッドを再起動しますか?

ACK Deschedulerは、スケジューリング解除機能を提供します。スケジュール解除機能を使用する場合は、次の項目に注意してください。

Koordinator Deschedulerは実行中のポッドのみをエビクトし、エビクトされたポッドを再作成またはスケジュールしません。ポッドが削除されると、ポッドはDeploymentやStatefulSetなどのワークロードコントローラーによって再作成されます。再作成されたポッドはスケジューラによってスケジュールされます。
スケジュール解除プロセス中に、古いポッドが削除され、新しいポッドが作成されます。削除中にアプリケーションの可用性が影響を受ける場合に備えて、アプリケーションに十分なレプリカがあることを確認してください。

詳細については、「スケジュール解除の概要」をご参照ください。

ポッドを特定のノードにスケジュールするにはどうすればよいですか?

ノードラベルを設定し、YAMLファイルでnodeSelectorパラメーターを設定して、ポッドを特定のノードにスケジュールすることができます。詳細については、「特定のノードへのポッドのスケジュール」をご参照ください。

デプロイによって作成された特定の数のポッドをECSインスタンスとelastic containerインスタンスにスケジュールするにはどうすればよいですか？

Elastic Compute Service (ECS) インスタンスとelastic containerインスタンスがコロケートされているシナリオでは、UnitedDeploymentコントローラーを使用してワークロードを管理することで、各サブセットのレプリカ数を調整できます。たとえば、UnitedDeployment YAMLファイルのレプリカをサブセットecsで10に設定し、レプリカをサブセットeciで10に設定できます。詳細については、「ACKクラスターでのUnitedDeploymentコントローラーの使用」をご参照ください。

ワークロードのポッドをスケジュールするときに、ポッドの高可用性を確保するにはどうすればよいですか？

ポッド間アフィニティとアンチアフィニティを使用して、ワークロードのポッドを異なるゾーンまたはノードに分散できます。たとえば、次のYAMLファイルに基づいてポッドに次のフィールドを追加して、preferredDuringSchedulingIgnoredDuringExecutionプリファレンスルールを指定できます。このように、スケジューラは、セキュリティ=S2のラベルを有するポッドを異なるゾーンにスケジュールする。条件が満たされない場合、スケジューラはポッドを他のノードにスケジュールします。

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone

詳細については、「Inter-pod affinity and anti-affinity」および「Pod topology spread constraints」をご参照ください。

Container Service for Kubernetes:スケジューリングに関するFAQ

目次