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

vSwitch の利用可能な IP アドレス数が不足している場合に、Pod の起動失敗を防ぐにはどうすればよいですか？

ネイティブの Kubernetes スケジューラは、Node 上で利用可能な IP アドレス数を認識できません。そのため、既に IP リソースをすべて消費してしまった Node に Pod がスケジュールされ、その結果、Pod が起動時に失敗することがあります。これは短時間で多数の異常な Pod を生じさせる原因となります。

ACK スケジューラは、IP 感知スケジューリング機能によりこの問題を解決します。ACK スケジューラは各 Node の k8s.aliyun.com/max-available-ip アノテーションを読み取り、利用可能な IP アドレスの最大数を取得し、その値に基づいて、当該 Node 上で独立した IP アドレスを必要とする Pod の数を制限します。Node の IP リソースが枯渇すると、ACK スケジューラは Node のステータスに SufficientIP 条件を設定し、独立した IP アドレスを必要とする新しい Pod のスケジュールをブロックします。

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

• クラスターが ACK マネージドクラスター Pro エディションであり、ネットワークプラグインが Terway v1.5.7 以降であること。詳細については、「ACK マネージドクラスターの作成」をご参照ください。

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

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

ACK スケジューラは、コミュニティ版の Kubernetes スケジューラ と同じデフォルトポリシーに従います。Pod のスケジューリングには、次の 2 つの主要ステップがあります：

• [フィルター](https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/#filter)： Pod を実行できない Node を除外します。フィルターを通過する Node が存在しない場合、Pod はスケジュール不可の状態になります。

• [スコアリング](https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/#scoring)： 残りの Node を順位付けし、Pod に最も適した Node を選択します。

最新版の ACK スケジューラで有効化されているフィルタープラグインおよびスコアリングプラグインの完全な一覧については、「kube-scheduler」をご参照ください。

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

ネイティブの Kubernetes スケジューラは、実際の使用率ではなく、リソースの *リクエスト* 値に基づいて判断を行います。その結果、一部の Node が過負荷になる一方で、他の Node はアイドル状態のままとなることがあります。ACK では、この問題に対処するための 3 つのアプローチを提供しています：

• 正確なリソースリクエストおよび制限値を設定する。 リソースプロファイリング機能を使用して、過去の使用履歴データに基づくコンテナ仕様の推奨値を取得します。詳細については、「リソースプロファイリング」をご参照ください。

• 負荷感知スケジューリングを有効化する。 ACK スケジューラは、スケジューリング判断時に実際の Node 負荷を考慮に入れることができます。ACK スケジューラは過去の負荷データを分析し、新規 Pod のリソース要件を推定して、使用率の低い Node を優先的に選択します。詳細については、「負荷感知スケジューリング」をご参照ください。

• 負荷感知ホットスポットデスケジューリングを有効化する。 トラフィックやワークロードの変化に伴い、Node の使用率は時間とともに変動します。ACK のデスケジューリング機能はホットスポットを検出し、過負荷状態の Node から Pod をエビクションして、負荷バランスを回復させます。詳細については、「負荷感知ホットスポットデスケジューリングの使用」をご参照ください。

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

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

1. Node のステータス： Node が NotReady 状態の場合、スケジューラはその Node に Pod を配置しません。Node が Ready 状態になるまでお待ちください。

2. Pod のスケジューリング制約： Pod に nodeSelector、nodeAffinity、または podAffinity ルールが設定されていないか、または Node に Pod が許容しない Taint が設定されていないかを確認してください。これらの制約により、Node が正常に動作していても、Pod が新しい Node に配置されないことがあります。

3. リソースリクエストの不均衡： ネイティブの Kubernetes スケジューラは、実際の使用率ではなくリソースリクエストに基づいて Pod を配置します。既存の Node に十分な空き *リクエスト* 容量がある場合、スケジューラは新しい Node を使用しない可能性があります。「リソース使用率が高い Node への Pod のスケジューリングを回避するにはどうすればよいですか？」をご参照ください。

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

スケジューラは、実際の消費量ではなくリクエストされたリソースを評価します。Node の実際の 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 Spec に一致する nodeSelector を追加します。詳細については、「アプリケーションを特定の Node にスケジュールする」をご参照ください。

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

ECS および ECI リソース用に別々のサブセットを定義するために UnitedDeployment を使用します。たとえば、UnitedDeployment Spec 内の ECS サブセットで replicas: 10 を、ECI サブセットで replicas: 10 を設定します。詳細については、「UnitedDeployment を使用したワークロードのスケーリング」をご参照ください。

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

podAntiAffinity を使用して、Pod を異なるゾーンまたは Node に分散させます。たとえば、以下の構成では、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 のアフィニティおよびアンチアフィニティ」および「Pod トポロジ拡散制約」をご参照ください。

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

ack-descheduler アドオンは、今後メンテナンスされません。積極的にメンテナンスされている Koordinator Descheduler へ移行してください。移行手順は、Kubernetes Descheduler から Koordinator Descheduler への移行手順と同一です。「Kubernetes Descheduler から Koordinator Descheduler への移行」および「［通知］ ack-descheduler の移行」をご参照ください。

ACK マーケットプレイスで提供されている ack-descheduler アドオンは、オープンソースの Kubernetes Descheduler をベースとしています。バージョン 0.20.0 および 0.27.1 が利用可能で、それぞれ対応するオープンソース版と同様の動作をします。

すべての Pod を、現在の負荷が最も低い Node に一括してスケジュールしないのはなぜですか？

すべての新規 Pod を現在負荷が最も低い Node に配置すると、それらの Pod がリソースを消費し始める際に新たなホットスポットが発生します。これを防ぐため、負荷感知スケジューリングプラグインは、すでに新規にスケジュールされた Pod を保持しており、その利用状況がまだ報告されていない Node のスコアを調整します。これにより、過度な集中を防止し、Node 間でより均等に負荷を分散させます。

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

Kubernetes スケジューラは、最終的な Node 順位付けに寄与する複数のプラグインを使用します。アフィニティルール、トポロジ拡散制約、およびその他のプラグインは、それぞれ Node のスコアに加算または減算されます。最終的な配置は、すべてのアクティブなプラグインの重みの合計を反映します。要件に応じて、各プラグインのスコアリング重みを調整してください。

スケジューラをアップグレードした後、旧プロトコルによる負荷感知スケジューリング機能は引き続きサポートされますか？

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

以下の表は、クラスターバージョンごとのプロトコル対応状況をまとめています。

CPU Burst 構成を有効化した後も、Pod が依然として速度制限を受けているのはなぜですか？

以下のような条件が、CPU 速度制限の継続を引き起こす可能性があります：

• 構成フォーマットの誤り。 CPU Burst ポリシーのフォーマットが正しくない場合、そのポリシーは適用されません。構成フォーマットを確認してください。「高度なパラメーター構成」をご参照ください。

• CPU 使用率が上限に達している。 実際の CPU 使用率が cfsQuotaBurstPercent 制限に達している場合、物理 CPU リソースが不足しているため、速度制限が継続します。アプリケーションの実際の要件に合わせて、リクエストおよび制限値を調整してください。

• cpu.cfs_quota_us の調整遅延。 CPU Burst は、cpu.cfs_quota_us および cpu.cfs_burst_us の 2 つの cgroup パラメーターを変更します。cpu.cfs_quota_us パラメーターは、ack-koordinator が速度制限を検出した後にのみ更新されるため、わずかな遅延が発生します。cpu.cfs_burst_us パラメーターは、構成に基づいて即座に設定されます。最良の結果を得るには、Alibaba Cloud Linux を使用することを推奨します。

• Node の安全しきい値がトリガーされた。 CPU Burst には保護機構が含まれており、Node の全体的な使用率が sharePoolThresholdPercent しきい値を超えた場合に、cpu.cfs_quota_us をベースライン値にリセットします。この現象を回避するために、アプリケーションの要件に応じて Node の安全しきい値を設定してください。

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

いいえ。ack-koordinator の CPU Burst ポリシーは、Alibaba Cloud Linux および CentOS のすべてのオープンソースカーネルで動作します。ただし、Alibaba Cloud Linux を推奨します。理由は、ack-koordinator がカーネルレベルの機能を活用して、より細かい粒度での CPU エラスティシティ管理を実現できるためです。「cgroup v1 インターフェイスでの CPU Burst 機能の有効化」をご参照ください。

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

Batch メモリ制限 (kubernetes.io/batch-memory) で構成されたコンテナに対して、ack-koordinator はコンテナ起動後に cgroup メモリ制限を設定します。アプリケーションが、ack-koordinator が制限を適用する前に起動時に cgroup 制限を読み取り、それに基づいて動作する場合、意図した Batch 制限を超えてメモリを割り当ててしまうことがあります。オペレーティングシステムはそのメモリを直ちに解放しないため、実際の使用量が制限値を下回るまで、cgroup 制限は適用されません。

この問題を解決するには、アプリケーションのメモリ使用量を Batch 制限内に保つようにチューニングするか、アプリケーションの起動スクリプトを確認して、アプリケーションの初期化前にメモリ制限パラメーターが設定されていることを確認してください。

コンテナ内で現在のメモリ制限 (バイト単位) を表示するには、以下のコマンドを実行します：

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

CPU コア数を増加させた後、なぜパフォーマンスが低下し、CPU 速度制限が増加するのですか？

ack-slo-manager の旧プロトコルによる動的リソース過剰割り当て機能は、ack-koordinator へのアップグレード後にサポートされますか？

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

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

• リクエストおよび制限内の alibabacloud.com/reclaimed リソース

ack-koordinator は旧プロトコルおよび新プロトコルの両方を認識し、両方のプロトコルでリソースリクエストおよび可用性を一貫して計算します。既存の Pod 構成をすぐに更新する必要なく、アドオンをアップグレードできます。

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

以下の表は、スケジューラおよび ack-koordinator のバージョンごとのプロトコル対応状況を示しています：

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

はい。旧プロトコルでは、Pod に alibabacloud.com/cpuBurst アノテーションを付与する必要があります。ack-koordinator はこのアノテーションと完全に互換性があり、アップグレードをシームレスに処理します。

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

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

はい。旧プロトコル (バージョン 0.8.0 以前) では、CPU QoS を有効化するために Pod に alibabacloud.com/qosClass アノテーションを追加します。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 がエビクションされません。どうすればよいですか？

デスケジューラが頻繁に再起動するのはなぜですか？

これは通常、デスケジューラの ConfigMap が欠落しているか、フォーマットにエラーがあることを意味します。ConfigMap の内容を確認し、問題を修正してください。「高度な構成パラメーター」をご参照ください。ConfigMap の修正後、デスケジューラを再起動してください。

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

両方の機能を有効化し、しきい値を統一してください。Node の負荷がデスケジューラの highThresholds 値を超えると、その Node から Pod がエビクションされます。loadAwareThreshold パラメーターを highThresholds と同一の値に設定することで、エビクションされた Pod が同じ過負荷 Node に即座に再スケジュールされるのを防げます。これは、少数の Node が類似した使用率で運用されているクラスターにおいて特に重要です。

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

デスケジューラが使用する使用率アルゴリズムは何ですか？

デスケジューラは、ローリングウィンドウ上でリソース使用率の平均値を算出し、その平均値がしきい値を超えて一定期間 (デフォルト：約 10 分) 維持された場合にのみ、デスケジューリングをトリガーします。メモリについては、オペレーティングシステムが再利用可能なページキャッシュを除外して計算します。一方、kubectl top node はページキャッシュを含めたメモリ値を表示します。デスケジューラの実際のメモリベースラインを確認するには、「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 ベースのスポットインスタンスを使用できますか？

はい。詳細については、「スポットインスタンスの使用」をご参照ください。

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

アドオン ページでは、Arm アーキテクチャをサポートするアドオンカテゴリは以下のとおりです：

• コアコンポーネント

• ロギングおよびモニタリング

• ストレージ

• ネットワーク

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