Container Service for Kubernetes:動的リソース過剰割り当ての有効化

QoS クラスと Batch リソース

Kubernetes は、Pod のリソース構成に基づいて各 Pod にサービス品質（QoS）クラスを割り当てます。Batch リソースは、特に BestEffort クラス向けに設計されています。

動的リソース過剰割り当てを利用するには、Pod に koordinator.sh/qosClass: "BE" のラベルを設定し、標準のリソースフィールドを kubernetes.io/batch-cpu および kubernetes.io/batch-memory に置き換えます。

手順 1：ConfigMap の作成

以下の内容で configmap.yaml というファイルを作成します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: ack-slo-config
  namespace: kube-system
data:
  # colocation-config は、動的 Batch リソースの計算および更新を制御します。
  # 関連機能：動的リソース過剰割り当て、負荷感知スケジューリング。
  colocation-config: |
    {
      "enable": true,                        # 必須：Batch リソースの更新を有効化します。false に設定すると、回収可能なリソースは 0 にリセットされます。
      "metricAggregateDurationSeconds": 60,  # ノードメトリックを集計する間隔（秒）。デフォルト値を使用してください。
      "cpuReclaimThresholdPercent": 60,      # batch-cpu の回収しきい値（割り当て可能な CPU のパーセンテージ）。デフォルト：65。
      "memoryReclaimThresholdPercent": 70,   # batch-memory の回収しきい値（割り当て可能なメモリのパーセンテージ）。デフォルト：65。
      "memoryCalculatePolicy": "usage"       # batch-memory 容量の計算方法："usage"（デフォルト）または "request"。
    }

この例の cpuReclaimThresholdPercent および memoryReclaimThresholdPercent の値（60 および 70）はサンプル値です。実際のデフォルト値は、いずれも 65 です。

以下の表では、各パラメーターについて詳しく説明します。

Batch リソース容量の計算

ack-koordinator は、各ノードで利用可能な Batch リソース量を算出するために、以下の数式を適用します。

使用量ベースの計算（デフォルト、memoryCalculatePolicy: "usage"）：

nodeBatchAllocatable = nodeAllocatable × thresholdPercent − podUsage(non-BE) − systemUsage

リクエストベースの計算（memoryCalculatePolicy: "request"、batch-memory のみに適用）：

nodeBatchAllocatable = nodeAllocatable × thresholdPercent − podRequest(non-BE) − systemUsage

ここで、

手順 2：ConfigMap の適用

ack-slo-config ConfigMap が kube-system 名前空間内にすでに存在するか確認します。

• 存在する場合、他の設定を上書きせずに変更をマージするには、kubectl patch を使用します。

  kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)"

• 存在しない場合、以下のように作成します。

  kubectl apply -f configmap.yaml

手順 1：ノード上の利用可能な Batch リソースの確認

# $nodeName を実際のノード名に置き換えてください。
kubectl get node $nodeName -o yaml

出力内の status.allocatable セクションを確認します。

status:
  allocatable:
    # 単位：ミリコア。次の例では、50 コアが利用可能であることを示しています。
    kubernetes.io/batch-cpu: 50000
    # 単位：バイト。次の例では、50 GB が利用可能であることを示しています。
    kubernetes.io/batch-memory: 53687091200

手順 2：Pod による Batch リソースの利用構成

Pod のメタデータに koordinator.sh/qosClass: "BE" のラベルを追加し、コンテナの resources フィールドに kubernetes.io/batch-cpu および kubernetes.io/batch-memory を設定します。

metadata:
  labels:
    # 必須：Pod の QoS クラスを BestEffort に設定します。
    koordinator.sh/qosClass: "BE"
spec:
  containers:
  - resources:
      requests:
        # 単位：ミリコア。「1k」＝1000 ミリコア＝1 コア。
        kubernetes.io/batch-cpu: "1k"
        # 単位：バイト。
        kubernetes.io/batch-memory: "1Gi"
      limits:
        kubernetes.io/batch-cpu: "1k"
        kubernetes.io/batch-memory: "1Gi"

ack-slo-manager から ack-koordinator へアップグレードした後、従来の過剰割り当て構成は引き続き有効ですか？

はい。ack-koordinator は、以前の ack-slo-manager プロトコルと下位互換性があります。ACK Pro クラスタースケジューラは、旧形式および新形式の両方のプロトコルでリクエストおよび利用可能なリソースを計算できるため、既存のワークロードを再構成することなくアップグレードできます。

以前のプロトコルでは、以下の要素が使用されます。

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

• alibabacloud.com/reclaimed フィールドによるリソースリクエストおよび制限

ack-koordinator は、2023 年 7 月 30 日以前のプロトコルバージョンまでサポートしています。既存のワークロードを koordinator.sh プロトコルへ移行するのは、都合のよいタイミングで行ってください。

以下の表は、コンポーネントバージョン間の互換性を示しています。

Pod 起動直後にメモリ使用量が急増するのはなぜですか？

症状： コンテナ起動直後にメモリ使用量が急上昇し、kubernetes.io/batch-memory の制限を超えることがあります。

原因： コンテナが作成されると、ack-koordinator は cgroup のメモリ制限を kubernetes.io/batch-memory に基づいて設定します。一部のアプリケーションでは、起動時に cgroup 制限を読み取り、内部で割り当てるメモリ量を決定します。アプリケーションが ack-koordinator による制限の書き込み前に cgroup を読み取ると、意図した以上のメモリを割り当ててしまうことがあります。オペレーティングシステムは即座にそのメモリを回収しないため、設定された制限を下回るまで使用量が高止まりのままになります。

確認方法： コンテナ内で以下のコマンドを実行し、メモリ制限が正しく設定されているか確認します。

# 単位：バイト
cat /sys/fs/cgroup/memory/memory.limit_in_bytes
# 期待される出力例
1048576000

修正方法： アプリケーションのメインプロセス開始前に、起動スクリプト内でアプリケーションのメモリ制限を構成します。これにより、アプリケーションが cgroup を読み取る前に制限が適用されます。

BestEffort Pod が Pending 状態のままであるのはなぜですか？

症状： Batch リソースを構成した Pod が Pending 状態のままとなり、スケジューリングできません。

確認方法： kubectl describe pod <pod-name> を実行し、スケジューリング失敗イベントを確認します。

主な原因と修正方法：