Container Service for Kubernetes:スケジューリングに関するよくある質問

vSwitch の IP アドレス不足による Pod の起動失敗を防ぐにはどうすればよいですか？

ack-descheduler を Koordinator Descheduler に移行するにはどうすればよいですか？

ack-descheduler コンポーネントはメンテナンスされなくなりました。詳細については、「コンポーネントのお知らせ: ack-descheduler コンポーネントの移行」をご参照ください。アクティブにメンテナンスされている Koordinator Descheduler コンポーネントへの移行を推奨します。移行プロセスは、Kubernetes Descheduler を Koordinator Descheduler に移行するのと同様です。詳細については、「Kubernetes Descheduler を Koordinator Descheduler に移行する」をご参照ください。

Container Service for Kubernetes (ACK) は、マーケットプレイスで ack-descheduler コンポーネントを提供しています。このコンポーネントは、オープンソースの Kubernetes Descheduler に基づいています。ack-descheduler のバージョン 0.20.0 と 0.27.1 が利用可能です。これらは、対応するオープンソースの Kubernetes Descheduler バージョンと同じ機能を提供し、同じ方法で使用されます。

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

ACK クラスターでは、ACK Scheduler のデフォルトのスケジューリングポリシーは、コミュニティの Kubernetes スケジューラと一致しています。Kubernetes スケジューラが Pod をノードにスケジューリングする方法を決定する際、プロセスには通常、フィルターとスコアという 2 つの主要なステップが含まれます。

• フィルター: Pod をスケジューリングできるノードをフィルタリングします。フィルタリングされたリストが空の場合、Pod はスケジューリングできません。

• スコア: フィルタリング後、スケジューラはスケジューリング可能なノードをスコアリングしてランク付けし、Pod に最も適したノードを選択します。

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

Pod のスケジューリング中にリソース使用率の高いノードを回避するにはどうすればよいですか？

ネイティブの Kubernetes スケジューリングポリシーでは、スケジューラはノードの実際のリソース使用率ではなく、リソースリクエストに基づいて決定を下します。さらに、さまざまなフィルターおよびスコアプラグインがスケジューリング結果に影響します。ACK クラスターが提供する以下の機能を使用して、Pod がリソース使用率の高いノードにスケジューリングされるのを防ぐことができます。

• 各 Pod に適切なリソースリクエストと制限を設定し、リソースの冗長性を計画します。リソースプロファイリング機能を使用して、過去のリソース使用量データに基づいて推奨されるコンテナー仕様を取得できます。詳細については、「リソースプロファイリング」をご参照ください。

• 負荷認識 Pod スケジューリング機能を有効にします。ACK が提供する kube-scheduler コンポーネントの負荷認識 Pod スケジューリング機能は、Kubernetes スケジューリングフレームワークに基づいています。ネイティブの Kubernetes スケジューリングポリシーとは異なり、ACK Scheduler はノードの実際のリソース使用量を認識できます。ノードの負荷データを分析し、新しい Pod のリソース要件を推定し、負荷の低いノードに Pod を優先的にスケジューリングして負荷分散を実現します。詳細については、「負荷認識スケジューリング」をご参照ください。

• 負荷認識ホットスポット Descheduling を有効にします。ノードの使用率は、クラスター環境、ワークロードのトラフィック、またはリクエストの変動により、時間とともに動的に変化します。これにより、クラスター内のノード間の負荷バランスが崩れる可能性があります。これに対処するため、ACK Scheduler は極端な負荷の不均衡を防ぐための Descheduling 機能を提供します。詳細については、「負荷認識ホットスポット Descheduling の使用」をご参照ください。

新しいノードがクラスターに追加されました。なぜ Pod はそこにスケジューリングされないのですか？

この問題はいくつかの理由で発生する可能性があります。次のように問題をトラブルシューティングできます。

1. ノードのステータスが正常かどうかを確認します。ノードが `NotReady` 状態の場合、Pod を受け入れることはできません。

2. Pod に `NodeSelector`、`NodeAffinity`、`PodAffinity` などのスケジューリングポリシーがあるか、または新しいノードへのスケジューリングを妨げる Taint があるかを確認します。

3. 問題がネイティブの Kubernetes スケジューリングポリシーに関連しているかどうかを評価します。ネイティブの Kubernetes スケジューリングポリシーでは、スケジューラはノードの実際のリソース使用率ではなく、リソースリクエストに基づいて決定を下します。これにより、一部のノードは多くの Pod を実行しているのに対し、他のノードはほとんどまたはまったく Pod を実行していないという結果になる可能性があります。

   この問題の解決策の詳細については、「Pod のスケジューリング中にリソース使用率の高いノードを回避するにはどうすればよいですか？」をご参照ください。

クラスター全体の利用率が高くないのに、CPU またはメモリの不足によりスケジューリングが失敗するのはなぜですか？

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

この問題の解決策の詳細については、「Pod のスケジューリング中にリソース使用率の高いノードを回避するにはどうすればよいですか？」をご参照ください。

ACK で Descheduling 機能を使用する際に知っておくべきことは何ですか？ Pod は再起動されますか？

ACK は Koordinator Descheduler を通じて Descheduling 機能を提供します。Descheduling 機能を使用する際は、次の点に注意してください。

• Koordinator Descheduler は、実行中の Pod のエビクションのみを担当し、その再作成や後続のスケジューリングは行いません。エビクション後の Pod の再作成は、Deployment や StatefulSet などの対応するワークロードコントローラーによって処理されます。再作成された Pod のスケジューリングは、スケジューラによって処理されます。

• Descheduling 中、新しい Pod が作成される前に古い Pod がエビクションされます。エビクション中にアプリケーションの可用性に影響を与えないように、アプリケーションに十分な数のレプリカ (replicas) があることを確認してください。

詳細については、「Descheduling」をご参照ください。

アプリケーションを特定のノードにスケジューリングするにはどうすればよいですか？

ノードにラベルを追加し、アプリケーションの YAML ファイルに対応する nodeSelector を追加することで、アプリケーションを特定のノードにスケジューリングできます。詳細については、「アプリケーションを特定のノードにスケジューリングする」をご参照ください。

Deployment で、特定の数の Pod を ECS に、特定の数の Pod を ECI にスケジューリングするにはどうすればよいですか？

ECS と ECI リソースを一緒に使用するシナリオでは、UnitedDeployment を使用してワークロード管理用のサブセットを定義できます。たとえば、UnitedDeployment の YAML ファイルで、subset-ecs の replicas を 10 に、subset-eci の replicas を 10 に設定できます。詳細については、「UnitedDeployment に基づいてワークロードをスケーリングする」をご参照ください。

スケジューリング中にワークロードの Pod の高可用性を確保するにはどうすればよいですか？

ポッドアフィニティを使用して、ワークロードの Pod を異なるゾーンまたはノードに分散させることができます。たとえば、Pod の YAML ファイルに次のフィールドを追加して、preferredDuringSchedulingIgnoredDuringExecution ルールを宣言できます。このルールは、security=S2 ラベルを持つ Pod を異なるゾーンにスケジューリングしようとします。この条件が満たせない場合、スケジューラは Pod を他のノードにスケジューリングしようとします。

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

詳細については、Kubernetes ドキュメントの「podAffinity と podAntiAffinity」および「Pod トポロジースプレッド制約」をご参照ください。

新しく作成された Pod のバッチについて、なぜそれらすべてが最も負荷の低いノードにスケジューリングされないのですか？

スケジューラが新しく作成された Pod のバッチを現在の負荷が最も低いノードにスケジューリングすると、新しい Pod が起動した後にノードの負荷が増加するため、そのノードがすぐにホットスポットになる可能性があります。

したがって、負荷認識スケジューリングプラグインがノードスコアを計算する際、まだ使用率が報告されていない新しい Pod があるノードのスコアを調整します。これにより、過剰なスケジューリングと新しいホットスポットの作成を防ぎます。

ノードの負荷レベル以外に、スケジューリング結果に影響を与える他の要因は何ですか？

Kubernetes スケジューラは複数のプラグインで構成されています。スケジューリング中、アフィニティプラグインやトポロジースプレッドプラグインなど、多くのプラグインがノードのスコアリングとランク付けに参加します。ノードの最終的なランク付けは、これらすべてのプラグインの影響を受けます。必要に応じて、各プラグインのスコアリングの重みを調整できます。

スケジューラが新しいバージョンにアップグレードされた後、古いプロトコルを使用する負荷認識スケジューリング機能はまだサポートされていますか？

古いバージョンの負荷認識スケジューリング機能を使用するには、Pod にアノテーション alibabacloud.com/loadAwareScheduleEnabled: "true" を追加する必要があります。

以下の表は、プロトコルのサポートとコンポーネントのバージョン要件を示しています。

CPU Burst 設定を有効にした後、なぜ Pod はまだスロットリングされるのですか？

この問題はいくつかの理由で発生する可能性があります。以下の解決策を参照して調整を行ってください。

• 設定形式が正しくないため、CPU Burst ポリシーが有効になっていません。詳細については、「高度なパラメーター設定」を参照して設定を修正し、確認してください。

• CPU 使用率が cfsQuotaBurstPercent で指定された上限に達した場合、CPU リソースが不足しているため、CPU スロットリングが依然として発生します。

  アプリケーションの実際の要件に基づいて、リクエストとリミットの値を調整してください。

• CPU Burst ポリシーは、Pod の 2 つの cgroup パラメーターを調整します: cpu.cfs_quota_us と cpu.cfs_burst_us。詳細については、「高度なパラメーター設定」をご参照ください。cpu.cfs_quota_us パラメーターは、ack-koordinator が CPU スロットリングを検出した後にのみ設定されるため、わずかな遅延が発生します。対照的に、cpu.cfs_burst_us パラメーターは設定に基づいて直接設定され、より応答性が高くなります。

  より良いパフォーマンスを得るために、この機能を Alibaba Cloud Linux オペレーティングシステムと共に使用してください。

• CPU Burst ポリシーには、cpu.cfs_quota_us を調整するための保護メカニズムが含まれており、sharePoolThresholdPercent パラメーターを使用してマシンの安全しきい値を定義します。マシン全体の利用率が高くなりすぎると、cpu.cfs_quota_us は初期値にリセットされ、単一の Pod が過度の干渉を引き起こすのを防ぎます。

  ノードの高い利用率がアプリケーションのパフォーマンスに影響を与えないように、アプリケーションの要件に基づいてノードの安全しきい値を設定する必要があります。

CPU Burst ポリシーを有効にするには Alibaba Cloud Linux が必要ですか？

ack-koordinator の CPU Burst ポリシーは、すべての Alibaba Cloud Linux および CentOS オープンソースカーネルと互換性があります。ただし、Alibaba Cloud Linux の使用を推奨します。Alibaba Cloud Linux カーネルの機能を活用することで、ack-koordinator はより詳細な CPU 弾力性管理メカニズムを提供できます。詳細については、「cgroup v1 インターフェイスで CPU Burst 機能を有効にする」をご参照ください。

アプリケーションが Batch リソースを使用した後、なぜそのメモリ使用量が急に増加するのですか？

Batch メモリ制限 (kubernetes.io/batch-memory) で設定されたアプリケーションの場合、ack-koordinator はコンテナーが作成された後にコンテナーの cgroup メモリ制限を設定します。一部のアプリケーションは、起動時に cgroup 制限に基づいてメモリを要求します。アプリケーションが ack-koordinator が cgroup 制限を設定する前に起動した場合、その実際のメモリ使用量は意図した Batch メモリ制限を超える可能性があります。オペレーティングシステムはプロセスのメモリ使用量をすぐには削減しません。その結果、実際の使用量が Batch メモリ制限を下回るまで cgroup メモリ制限を適用できません。

この場合、アプリケーションの設定パラメーターを調整して、そのメモリ使用量を Batch 制限以下に制御できます。または、アプリケーションの起動スクリプトでメモリ制限パラメーターを確認し、アプリケーションが起動する前に設定されていることを確認します。これにより、アプリケーションのメモリ使用量が合理的に制限され、メモリ不足 (OOM) エラーなどの問題を防ぐことができます。

コンテナーで次のコマンドを実行して、メモリリソース制限パラメーターを表示できます。

# 単位はバイトです。
cat /sys/fs/cgroup/memory/memory.limit_in_bytes 
# 期待される出力。
1048576000

CPU コア数を増やした後、なぜパフォーマンスが低下し、Pod で CPU スロットリングの問題が発生するのですか？

レガシーな ack-slo-manager プロトコルの動的リソースオーバーコミット機能は、ack-koordinator コンポーネントへのアップグレード後もサポートされますか？

古いバージョンの動的リソースオーバーコミットプロトコルには、2 つの部分が含まれます:

• Pod の alibabacloud.com/qosClass アノテーション。

• Pod のリクエストとリミット内の alibabacloud.com/reclaimed リソース。

ack-koordinator は、前述の古いプロトコルと互換性があり、ACK Pro マネージドクラスターのスケジューラで新旧両方のプロトコルのリソースリクエストと利用可能なリソースを統一的に計算します。コンポーネントを ack-koordinator にシームレスにアップグレードできます。

ACK Pro マネージドクラスターのスケジューラと ack-koordinator は、次のように異なるプロトコルバージョンをサポートしています。

ack-slo-manager の古いプロトコルで CPU Burst 機能を使用している場合、ack-koordinator へのアップグレード後もサポートされますか？

以前のバージョンの Pod プロトコルでは、Annotation に alibabacloud.com/cpuBurst を指定する必要があります。ack-koordinator はこの以前のバージョンと完全に互換性があり、コンポーネントを新しいバージョンにシームレスにアップグレードできます。

ack-koordinator と異なるプロトコルバージョンとの互換性は次のとおりです。

ack-slo-manager の古いプロトコルで CPU QoS 機能を使用しています。この機能は ack-koordinator にアップグレードした後もサポートされますか？

古い Pod プロトコル (バージョン 0.8.0 以前) では、Pod に alibabacloud.com/qosClass アノテーションを追加することで CPU QoS が有効になります。

ack-koordinator は古いプロトコルとの互換性を維持しています。コンポーネントを ack-koordinator にシームレスにアップグレードし、Pod を徐々に koordinator.sh プロトコルに切り替えることができます。ack-koordinator は、2023 年 7 月 30 日までこれらの古いプロトコルとの互換性を維持します。元のプロトコルのリソースフィールドを速やかに新しいバージョンにアップグレードすることをお勧めします。

ack-slo-manager のレガシープロトコルから ack-koordinator にアップグレードした後も、コンテナーメモリ QoS 機能はサポートされますか？

古い Pod プロトコル (バージョン 0.8.0 以前) には以下が含まれます:

• Pod の alibabacloud.com/qosClass アノテーション。

• Pod の alibabacloud.com/memoryQOS アノテーション。

ack-koordinator は以前のプロトコルバージョンと互換性があり、コンポーネントを ack-koordinator にシームレスにアップグレードできます。下位互換性は 2023 年 7 月 30 日までサポートされます。元のプロトコルのリソースフィールドを速やかに新しいバージョンにアップグレードすることをお勧めします。

ack-koordinator は、異なるバージョンでメモリ QoS 機能を次のようにサポートしています。

ノードの使用率がしきい値に達しましたが、ノード上の Pod がエビクションされません。どうすればよいですか？

この問題はいくつかの理由で発生する可能性があります。以下の解決策を参照して調整を行ってください。

Descheduler が頻繁に再起動するのはなぜですか？

これは、Descheduler の ConfigMap の形式が正しくないか、ConfigMap が存在しない場合に発生する可能性があります。ConfigMap ファイルの内容と形式を確認し、必要な修正を行ってください。詳細については、「高度な設定パラメーター」をご参照ください。ConfigMap を変更した後、Descheduler を再起動する必要があります。Descheduler の再起動方法の詳細については、「ステップ 2: Descheduling プラグインを有効にして、リソース使用率の高いノードに Pod を分散させる」をご参照ください。

負荷認識スケジューリングとホットスポットの Descheduling を一緒に使用するにはどうすればよいですか？

リソース使用率の高いノードに対して Descheduling を有効にすると、それらのノード上の Pod がエビクションされます。その後、スケジューラは、Deployment などの親コントローラーによって作成された新しい Pod を、その設定に基づいて適切なノードにスケジューリングします。より良い負荷分散を実現するためには、スケジューラに対して負荷認識スケジューリングも有効にする必要があります。詳細については、「負荷認識スケジューリングの使用」をご参照ください。

これらの機能を設定する際、負荷認識スケジューリングのノードフィルタリング機能の loadAwareThreshold パラメーターを、Descheduler の highThresholds パラメーターと同じ値に設定します。詳細については、「ポリシーの説明」をご参照ください。ノードの負荷が highThresholds を超えると、Descheduler はそのノードから Pod をエビクションします。その後、スケジューラは loadAwareThreshold を使用して、新しい Pod がそのノードに再びスケジューリングされるのを防ぎます。そうしないと、特に Pod が指定されたノードスケジューリングスコープを持ち、ノード数が少なく、使用率レベルが似ている場合、エビクションされた Pod が元のノードに再スケジューリングされる可能性があります。

Descheduling に使用される使用率アルゴリズムは何ですか？

Descheduler は一定期間にわたってリソース使用率を継続的に監視し、平均値を計算します。Descheduling は、平均値が特定の期間しきい値を超え続けた場合にのみトリガーされます。デフォルトの期間は約 10 分です。メモリリソースについては、Descheduler のメモリ使用量計算はページキャッシュを除外します。なぜなら、このメモリはオペレーティングシステムによって回収可能だからです。しかし、kubectl top node が返す使用率の値にはページキャッシュが含まれます。Alibaba Cloud Prometheus によるモニタリングを使用して、実際のメモリ使用量を確認できます。

wrk を使用したストレステスト中に、結果に "Socket errors: connect 54," と表示されます。どうすればよいですか？

問題の説明

wrk を使用したストレステスト中に、結果に Socket errors: connect 54, と表示されます。wrk クライアントが Nginx サーバーとの接続を確立できず、テスト結果が無効になります。

原因

このエラーは通常、クライアントで利用可能な接続数が制限されているために発生し、接続試行が失敗します。

解決策

このエラーを解決するには、ストレステストマシンの TCP 接続設定を確認し、TCP 接続の再利用を有効にします。

1. ストレステストマシンにログインし、次のコマンドを実行して TCP 接続の再利用が有効になっているか確認します。

   sudo sysctl -n net.ipv4.tcp_tw_reuse

   0 または 2 の出力は、システムが TCP 接続の再利用を完全に有効にしていないことを示します。

2. 次のコマンドを実行して TCP 接続の再利用を有効にします。

   sudo sysctl -w net.ipv4.tcp_tw_reuse=1

3. wrk ツールを使用して再度ストレステストリクエストを送信します。

   テスト結果に Socket errors: connect 54, ... エラーメッセージが含まれなくなり、結果が有効であることを確認します。

[k8s-reclaimed-resource] タブのクラスターコロケーションのメリットセクションにデータが表示されないのはなぜですか？

1. ack-koordinator コンポーネントがインストールされているか確認します。

   1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。

   2. クラスター ページで、対象のクラスターを見つけてその名前をクリックします。左側のペインで、[アプリケーション] > [Helm] を選択します。

   3. [Helm] ページで、ack-koordinator コンポーネントが存在するか確認します。

      • 存在しない場合は、「コンポーネントのインストールと管理」をご参照ください。ack-koordinator コンポーネントをインストールし、以下の手順に従ってください。

      • 存在する場合は、次のステップに進みます。

2. 複数タイプのワークロードのコロケーションダッシュボードに関連データが表示されるか確認します。

   表示されない場合は、次の手順を実行します:

   1. ARMS コンソールにログインします。

   2. 左側のナビゲーションウィンドウで、[Managed Service For Prometheus] > [インスタンス] を選択します。

   3. ページの左上隅でターゲットリージョンを選択し、Prometheus インスタンスの名前をクリックし、左側のナビゲーションウィンドウで [メトリクス管理] をクリックします。

   4. 青い [メトリクス] ボタンをクリックし、プロンプトに従って [kube_node_labels] を検索して選択し、メトリクスのデータ詳細を表示します。

Arm ベースのスポットインスタンスを使用できますか？

はい、Arm ベースのスポットインスタンスは利用可能です。使用方法の詳細については、「スポットインスタンスの使用」をご参照ください。

ACK クラスターで Arm ベースのノードを使用する場合の制限事項は何ですか？