Container Service for Kubernetes:スケジューリング FAQ

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

Kubernetes のネイティブスケジューラーは、Node 上で利用可能な IP アドレスを把握できません。IP リソースが枯渇した Node に Pod がスケジュールされると、起動時に失敗し、異常な Pod が大量に発生することがあります。

ACK Scheduler は、IP 感知スケジューリングでこの問題を解決します。各 Node の k8s.aliyun.com/max-available-ip アノテーションを読み取り、独立した IP を必要とする Pod の上限数を設定します。Node の IP リソースが不足すると、ACK Scheduler は Node のステータスに SufficientIP 条件を設定し、IP を必要とする新しい Pod がその Node にスケジュールされないようにします。

kube-scheduler アドオンは、この機能を自動的に有効化します。クラスターは次の要件を満たす必要があります：

• クラスターが Terway v1.5.7 以降を使用する ACK マネージドクラスター Pro 版であること。詳細については、「ACK マネージドクラスターの作成」をご参照ください。

• kube-scheduler のバージョンが次の要件を満たしていること：

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

ACK Scheduler は、コミュニティの Kubernetes scheduler と同じデフォルトポリシーに従います。スケジューリングは 2 つの手順で構成されます：

• Filter：Pod を実行できない Node を除外します。Filter を通過する Node がない場合、Pod はスケジュール不可のままになります。

• Score：残った Node を順位付けし、Pod に最適な Node を選択します。

最新の ACK Scheduler で有効化されているすべての Filter および Score プラグインは、「kube-scheduler」に記載されています。

リソース使用率が高い Node に Pod がスケジュールされないようにするにはどうすればよいですか？

Kubernetes のネイティブスケジューラーは、実際の使用率ではなくリソースリクエストを使用します。そのため、一部の Node に負荷が集中し、他の Node がアイドルになることがあります。ACK では次の 3 つの方法を提供します：

• 正確なリソースリクエストと制限を設定します。 過去の使用状況に基づいてコンテナー仕様の推奨値を提示する「リソースプロファイリング」を使用します。

• 負荷感知スケジューリングを有効化します。 ACK Scheduler は実際の Node 負荷を考慮し、履歴データを分析して、投入される Pod の要件を推定し、使用率の低い Node に Pod を配置します。詳細については、「負荷感知スケジューリング」をご参照ください。

• 負荷感知ホットスポットデスケジューリングを有効化します。 トラフィックやワークロードの変化により、一部の Node が過負荷になることがあります。ACK の Descheduler はホットスポットを検出し、Pod をエビクションしてバランスを回復します。詳細については、「負荷感知ホットスポットデスケジューリングの使用」をご参照ください。

新しい Node をクラスターに追加しました。なぜ Pod がその Node にスケジュールされないのですか？

次の項目を順に確認してください：

1. Node のステータス：スケジューラーは NotReady の Node をスキップします。Node が Ready になるまで待ってください。

2. Pod のスケジューリング制約：Pod に nodeSelector、nodeAffinity、podAffinity のルールが設定されていないか、または Node に Pod が許容しない Taint が付与されていないかを確認してください。

3. リソースリクエストの偏り：スケジューラーは実際の使用率ではなくリソースリクエストを使用します。既存の Node に十分な未使用のリクエスト容量がある場合、新しい Node が使用されないことがあります。詳細については、「リソース使用率が高いNodeにPodがスケジュールされないようにするにはどうすればよいですか？」をご参照ください。

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

スケジューラーは、実際の消費量ではなくリクエストされたリソースを評価します。CPU 使用率が低い Node でも、Pod のリソースリクエストが大きいと「満杯」に見える場合があります。クラスター全体の使用率が低くても、新しい Pod に必要なリクエスト容量を満たす単一の Node が存在しない場合、スケジューリングに失敗します。

詳細については、「リソース使用率が高いNodeにPodがスケジュールされないようにするにはどうすればよいですか？」をご参照ください。

ACK でデスケジューリングを使用する前に知っておくべきことはありますか？Pod は再起動されますか？

ACK は Koordinator Descheduler を通じてデスケジューリングを提供します。次の 2 点に注意してください：

• デスケジューリングは Pod をエビクションするだけです。 Koordinator Descheduler は実行中の Pod をエビクションしますが、再作成は行いません。再作成はワークロードコントローラー (Deployment、StatefulSet など) が行い、スケジューラーが新しい Pod を配置します。

• 十分なレプリカ数を維持します。 新しい Pod が起動する前に、古い Pod がエビクションされます。エビクション中も可用性を維持できるよう、ワークロードに十分な replicas があることを確認してください。

詳細については、「デスケジューリング」をご参照ください。

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

対象の Node にラベルを追加し、アプリケーションの Pod 仕様に一致する nodeSelector を追加します。詳細については、「特定のノードにアプリケーションをスケジュールする」をご参照ください。

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

UnitedDeployment を使用して、ECS と ECI のそれぞれに別のサブセットを定義します。たとえば、ECS サブセットに replicas: 10、ECI サブセットに replicas: 10 を設定します。詳細については、「UnitedDeploymentに基づくワークロードのスケーリング」をご参照ください。

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

podAntiAffinity を使用して、ゾーンまたは Node をまたいで Pod を分散します。たとえば、次の設定では、security=S2 ラベルを持つ Pod を異なるゾーンにスケジュールします。制約を満たせない場合、スケジューラーは他の Node にフォールバックします。

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

Kubernetes のドキュメントでは、「Pod affinity and anti-affinity」および「Podトポロジースプレッド制約」も解説しています。

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

ack-descheduler アドオンは非推奨です。Kubernetes Descheduler と同じ手順で Koordinator Descheduler に移行してください。詳細については、「Kubernetes DeschedulerからKoordinator Deschedulerへの移行」および「\[Notice\] ack-descheduler migration」をご参照ください。

ACK マーケットプレイスの ack-descheduler アドオンは、オープンソースの Kubernetes Descheduler をベースにしています。バージョン 0.20.0 と 0.27.1 は、それぞれ対応するオープンソースのバージョンと一致します。

バッチ内のすべての Pod が負荷の最も低い Node にスケジュールされないのはなぜですか？

新しい Pod をすべて負荷の最も低い Node に配置すると、ホットスポットが発生します。負荷感知スケジューリングのプラグインは、使用率がまだレポートされていない新規スケジュール済み Pod がある場合に Node の Score を調整し、過度な集中を防いで Node 間の負荷を平準化します。

Node の負荷以外に、スケジューリング結果に影響する要因はありますか？

Kubernetes scheduler は複数のプラグイン (アフィニティルール、Pod トポロジースプレッド制約など) を使用し、それらが最終的な Node の順位付けに寄与します。要件に応じて、プラグインのスコアリング重みを調整してください。

スケジューラーのアップグレード後も、旧プロトコルを使用する負荷感知スケジューリング機能はサポートされますか？

旧プロトコルでは、Pod に alibabacloud.com/loadAwareScheduleEnabled: "true" アノテーションが必要です。ACK Scheduler は下位互換性があるため、アップグレードしても既存の Pod は影響を受けません。アップグレード後は、Pod ごとのアノテーション管理を避けるために、グローバルな負荷感知スケジューリングポリシーに切り替えてください。

次の表は、クラスターのバージョン別にプロトコルのサポート状況をまとめたものです。

CPU Burst 設定を有効化しても Pod がスロットリングされるのはなぜですか？

CPU スロットリングが解消しない原因として、次の条件が考えられます：

• 設定フォーマットが不正です。 CPU Burst ポリシーの設定が誤っていると効果がありません。フォーマットを確認してください。詳細については、「高度なパラメーター設定」をご参照ください。

• CPU 使用率が上限に達しています。 実際の CPU 使用量が cfsQuotaBurstPercent の上限に達している場合、物理 CPU リソースが不足しているためスロットリングが継続します。実際の要件に合わせて request と limit の値を調整してください。

• cpu.cfs_quota_us の調整に遅延があります。 CPU Burst は cpu.cfs_quota_us と cpu.cfs_burst_us を変更します。cpu.cfs_quota_us は ack-koordinator がスロットリングを検知した後にのみ更新されるため、遅延が発生します。一方、cpu.cfs_burst_us は即時に設定されます。最適な効果を得るには、この機能を Alibaba Cloud Linux と併用してください。

• Node の安全しきい値がトリガーされました。 Node の使用率が sharePoolThresholdPercent のしきい値を超えると、CPU Burst は cpu.cfs_quota_us をベースラインにリセットします。要件に応じてしきい値を調整してください。

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

いいえ。CPU Burst は、すべての Alibaba Cloud Linux および CentOS カーネルで動作します。ack-koordinator はカーネルレベルの機能を活用してより細かな CPU の弾力性を実現できるため、Alibaba Cloud Linux を推奨します。詳細については、「cgroup v1インターフェイスでCPU Burst機能を有効化する」をご参照ください。

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

Batch メモリ制限 (kubernetes.io/batch-memory) を持つコンテナーでは、ack-koordinator がコンテナー起動後に cgroup のメモリ制限を設定します。アプリケーションが起動時に cgroup の制限値を読み取る場合、ack-koordinator が適用する前に読み取ってしまうと、意図したよりも多くのメモリを確保する可能性があります。OS はそのメモリを直ちに回収しないため、使用量が制限値を下回るまで制限が適用されません。

この問題を解決するには、アプリケーションを調整して Batch の制限値を下回るようにするか、アプリケーションの初期化前にメモリ制限パラメーターが設定されるようにしてください。

コンテナー内で現在のメモリ制限 (バイト単位) を確認します：

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

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

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

はい。ack-koordinator は互換性があります。旧プロトコルは、Pod 仕様内の次の 2 つのコンポーネントを使用します：

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

• requests と limits における alibabacloud.com/reclaimed リソース

ack-koordinator は両方のプロトコルを認識し、リソースリクエストと可用性を統一的に計算します。既存の Pod 設定を直ちに更新しなくても、アドオンをアップグレードできます。

旧プロトコルのサポートは 2023 年 7 月 30 日に終了します。できるだけ早くリソースパラメーターを最新バージョンに更新してください。

次の表は、スケジューラーと ack-koordinator のバージョン別にプロトコルのサポート状況を示します：

ack-koordinator にアップグレードした後、レガシー ack-slo-manager プロトコルの CPU Burst 機能はサポートされますか？

はい。旧プロトコルは alibabacloud.com/cpuBurst アノテーションを使用します。ack-koordinator は完全に互換性があり、シームレスにアップグレードを処理します。

旧プロトコルのサポートは 2023 年 7 月 30 日に終了します。できるだけ早く現行プロトコルに更新してください。

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

はい。旧プロトコル (バージョン 0.8.0 以前) は、alibabacloud.com/qosClass アノテーションで CPU QoS を有効化します。ack-koordinator は互換性を維持し、koordinator.sh プロトコルへの段階的な移行をサポートします。

下位互換性は 2023 年 7 月 30 日に終了します。Pod を速やかに新しいプロトコルに移行してください。

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

はい。旧プロトコル (バージョン 0.8.0 以前) は、alibabacloud.com/qosClass および alibabacloud.com/memoryQOS アノテーションを使用します。ack-koordinator は両方に対して下位互換性があります。

下位互換性は 2023 年 7 月 30 日に終了します。できるだけ早く現行プロトコルに移行してください。

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

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

通常は、Descheduler の ConfigMap が存在しないか、設定が誤っています。ConfigMap を修正して Descheduler を再起動してください。詳細については、「高度な設定パラメーター」をご参照ください。

負荷感知スケジューリングとホットスポットデスケジューリングを併用するにはどうすればよいですか？

両方の機能を有効化し、しきい値を揃えてください。Node の負荷が highThresholds を超えると Pod がエビクションされます。エビクションされた Pod が同じ過負荷の Node に再スケジュールされないように、loadAwareThreshold を highThresholds と同じ値に設定します。特に、同程度の使用率の Node が少数しかないクラスターでは重要です。

詳細については、「負荷感知スケジューリングを使用する」および「ポリシーの説明」をご参照ください。

Descheduler はどの使用率アルゴリズムを使用しますか？

Descheduler はローリングウィンドウで使用率を平均化し、平均が一定期間 (デフォルト：約 10 分) にわたってしきい値を超えた場合にのみトリガーされます。メモリの計算では、OS が回収可能なページキャッシュを除外します。一方、kubectl top node にはページキャッシュが含まれます。Descheduler のメモリ基準を確認するには、「Alibaba Cloud Prometheus」を使用してください。

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

wrk クライアントの 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, ... のメッセージは表示されなくなります。

これらのコマンドはストレステスト用マシンにのみ適用されます。テスト後は、sysctl -w net.ipv4.tcp_tw_reuse=<original_value> を使用して元の設定に戻してください。

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

1. ack-koordinator がインストールされていることを確認します：

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

   2. クラスター名をクリックします。左側のナビゲーションペインで、[アプリケーション] > [Helm] を選択します。

   3. [Helm] ページで ack-koordinator がリストされているかを確認し、リストされていない場合はインストールします。詳細については、「アドオンをインストールおよび管理する」をご参照ください。

2. コロケーションダッシュボードにデータが表示されない場合は、kube_node_labels メトリックが収集されているかを確認します：

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

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

   3. リージョンを選択し、Prometheus インスタンス名をクリックして、[メトリック管理] をクリックします。

   4. [メトリクス] をクリックし、kube_node_labels を検索し、メトリックにデータがあることを確認します。

Arm ベースのプリエンプティブルインスタンスは使用できますか？

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

ACK クラスターで Arm ベースの Node を使用する際の制限事項は何ですか？

[アドオン] ページでは、以下のアドオンカテゴリのみが Arm アーキテクチャに対応しています：

• コアコンポーネント

• ログと監視

• ストレージ

• ネットワーク

マーケットプレイスのアドオンは Arm アーキテクチャをサポートしていません。