Container Service for Kubernetes:動的リソースオーバーコミットメントの有効化

1.動的リソースオーバーコミットメントを有効にする

ConfigMap を使用して、動的リソースオーバーコミットメント機能を有効にできます。 ConfigMap で関連パラメータを構成して、リソースの再生しきい値やノードのリソース容量を計算するためのポリシーなど、再生リソースを柔軟に管理することもできます。

1. 次の ConfigMap コンテンツに基づいて、configmap.yaml という名前のファイルを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ack-slo-config
     namespace: kube-system
   data:
     colocation-config: |
       {
         "enable": true,
         "metricAggregateDurationSeconds": 60,
         "cpuReclaimThresholdPercent": 60,
         "memoryReclaimThresholdPercent": 70,
         "memoryCalculatePolicy": "usage"
       }

   ConfigMap のパラメータを変更することで、batch-cpu リソースと batch-memory リソースを柔軟に管理できます。

   パラメータ

   パラメータ	フォーマット	説明
   enable	ブール値	バッチ リソースに関する統計を動的に更新するかどうかを指定します。この機能を無効にすると、再生リソースの量は 0 にリセットされます。デフォルト値：false。
   metricAggregateDurationSeconds	整数	システムがメトリック データを集計して、バッチ リソースを更新または調整するかどうかを判断する頻度。単位：秒。デフォルト値（60 秒）を使用することをお勧めします。
   cpuReclaimThresholdPercent	整数	batch-cpu リソースの再生しきい値。デフォルト値：65。単位：パーセント（％）。動的にオーバーコミットできる CPU リソースの計算方法の詳細については、バッチ リソースの量の計算 をご参照ください。
   memoryReclaimThresholdPercent	整数	batch-memory リソースの再生しきい値。デフォルト値：65。単位：パーセント（％）。動的にオーバーコミットできるメモリ リソースの計算方法の詳細については、バッチ リソースの量の計算 をご参照ください。
   memoryCalculatePolicy	文字列	batch-memory リソースの量を計算するためのポリシー。有効な値： "usage"：batch-memory リソースの量は、QoS クラスが Burstable または Guaranteed であるポッドの実際のメモリ使用量に基づいて計算されます。 batch-memory リソースには、割り当てられていないリソースと、割り当てられているが使用されていないリソースが含まれます。これがデフォルト値です。 "request"：batch-memory リソースの量は、QoS クラスが Burstable または Guaranteed であるポッドのメモリ要求に基づいて計算されます。 batch-memory リソースには、割り当てられていないリソースのみが含まれます。

   バッチ リソースの量の計算

   実際のリソース使用量に基づいてバッチ リソースの量を計算する

   ノードのバッチ リソースの量は、実際のリソース使用量に基づいて計算されます。これには、割り当てられていないリソースと、割り当てられているが使用されていないリソースが含まれます。次の式を使用して、batch-cpu リソースの量と batch-memory リソースの量を計算できます。

   nodeBatchAllocatable = nodeAllocatable * thresholdPercent - podUsage(non-BE) - systemUsage

   • nodeAllocatable：ノードに割り当てることができる CPU またはメモリ リソースの量。

   • thresholdPercent：パーセントで表したリソースのしきい値。前の表の説明に従って、このパラメータを変更できます。

   • podUsage(non-BE)：QoS クラスが Burstable または Guaranteed であるポッドのリソース使用量。

   • systemUsage：ノード上のシステム リソースの使用量。

   ポッドのリソース要求に基づいてバッチ リソースの量を計算する

   batch-memory リソースは、ポッドのリソース要求に基づいて計算できます。 batch-memory リソースには、割り当てられていないリソースのみが含まれます。詳細については、パラメータ の memoryCalculatePolicy パラメータをご参照ください。

   次の式に基づいて batch-memory リソースの量を計算できます。

   nodeBatchAllocatable = nodeAllocatable * thresholdPercent - podRequest(non-BE) - systemUsage

   podRequest(non-BE) は、QoS クラスが Burstable および Guaranteed であるポッドのリソース要求の合計を指します。

2. kube-system ネームスペースに ack-slo-config という名前の ConfigMap が存在するかどうかを確認します。

   • ack-slo-config ConfigMap が存在する場合は、kubectl patch コマンドを実行して ConfigMap を更新することをお勧めします。これにより、ConfigMap の他の設定が変更されるのを防ぎます。

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

   • ack-slo-config ConfigMap が存在しない場合は、次のコマンドを実行して ConfigMap を作成します。

     kubectl apply -f configmap.yaml

2.ポッドのバッチ リソースを申請する

構成が完了したら、ポッドの YAML ファイルの metadata フィールドで koordinator.sh/qosClass ラベルを使用して、ノードのバッチ リソースの合計に基づいてポッドの QoS クラスを指定し、バッチ リソース リクエストとバッチ リソース制限を指定できます。

1. 次のコマンドを実行して、ノードで使用可能なバッチ リソースの合計量をクエリします。

   # $nodeName をクエリするノードの名前に置き換えます。
   kubectl get node $nodeName -o yaml

   予想される出力：

   # ポッド情報。
   status:
     allocatable:
       # 単位：ミリコア（1 コア = 1000 ミリコア）。次の例では、50 コアを割り当てることができます。
       kubernetes.io/batch-cpu: 50000
       # 単位：バイト。次の例では、50 GB のメモリを割り当てることができます。
       kubernetes.io/batch-memory: 53687091200

2. ポッドを作成し、バッチ リソースを申請します。

   重要

   • Deployment または他のタイプのワークロードを使用してポッドをプロビジョニングする場合は、template.metadata フィールドを構成します。ポッドは、バッチ リソースと通常のリソースを同時に申請することはできません。

   • ack-koordinator は、ノードの実際の負荷に基づいて、ポッドに割り当てることができるバッチ リソースを動的に調整します。まれに、kubelet がノード ステータス情報の同期に一定の遅延を起こす場合があります。その結果、リソースが不足しているためにポッドのスケジュールが失敗します。この場合は、ポッドを削除して再作成します。

   • Kubernetes クラスターでは、拡張リソースの量を整数に設定する必要があります。 batch-cpu リソースの単位はミリコアです。

   metadata:
     labels:
       # 必須。ポッドの QoS クラスを BestEffort に設定します。
       koordinator.sh/qosClass: "BE"
   spec:
     containers:
     - resources:
         requests:
           # 単位：ミリコア（1 コア = 1000 ミリコア）。次の例では、CPU リクエストは 1 コアに設定されています。
           kubernetes.io/batch-cpu: "1k"
           # 単位：バイト。次の例では、メモリ リクエストは 1 GB に設定されています。
           kubernetes.io/batch-memory: "1Gi"
         limits:
           kubernetes.io/batch-cpu: "1k"
           kubernetes.io/batch-memory: "1Gi"

Managed Service for Prometheus でバッチ リソースの使用状況を表示する

ACK クラスターは、Prometheus ダッシュボードを提供する Managed Service for Prometheus と統合されています。 ACK コンソールでバッチ リソースの使用状況を表示できます。

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

2. [クラスター] ページで、目的のクラスターを見つけて名前をクリックします。左側のペインで、[操作] > Prometheus Monitoring を選択します。

3. [その他] タブをクリックし、[k8s-reclaimed-resource] タブをクリックします。

   [k8s-reclaimed-resource] タブでは、クラスターの混合収益、クラスター、ノード、ポッド レベルのリソース容量などの詳細を表示できます。詳細については、コロケーション監視機能の有効化 をご参照ください。

   Prometheus ダッシュボードを作成した場合は、次のメトリックに基づいてコロケートされたリソースのデータを表示できます。

   # ノードで割り当て可能な batch-cpu リソースの量。
   koordlet_node_resource_allocatable{resource="kubernetes.io/batch-cpu",node="$node"}
   # ノードに割り当てられている batch-cpu リソースの量。
   koordlet_container_resource_requests{resource="kubernetes.io/batch-cpu",node="$node"}
   # ノードで割り当て可能な batch-memory リソースの量。
   kube_node_status_allocatable{resource="kubernetes.io/batch-memory",node="$node"}
   # ノードに割り当てられている batch-memory リソースの量。
   koordlet_container_resource_requests{resource="kubernetes.io/batch-memory",node="$node"}

ack-slo-manager から ack-koordinator にアップグレードした後、以前のバージョンの ack-slo-manager プロトコルに基づいて有効になっているリソースオーバーコミットメント機能はサポートされますか？

以前のバージョンの ack-slo-manager プロトコルには、次のコンポーネントが含まれています。

• alibabacloud.com/qosClass ポッド アノテーション。

• ポッドのリソース要求と制限を指定するために使用される alibabacloud.com/reclaimed フィールド。

ack-koordinator は、以前のバージョンの ack-slo-manager プロトコルと互換性があります。ACK Pro クラスター のスケジューラは、以前のプロトコル バージョンと新しいプロトコル バージョンに基づいて、要求されたリソースの量と使用可能なリソースの量を計算できます。 ack-slo-manager から ack-koordinator にシームレスにアップグレードできます。

次の表は、ACK Pro クラスター のスケジューラ、ack-koordinator、およびさまざまなプロトコルの互換性を示しています。

アプリケーションがバッチ リソースを使用すると、メモリ使用量が急激に増加するのはなぜですか？

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

この場合は、アプリケーション構成を変更して、実際のメモリ使用量がバッチ メモリ制限を下回るようにすることをお勧めします。また、アプリケーションの起動スクリプトでメモリ制限パラメータを確認して、アプリケーションの起動前にパラメータが構成されていることを確認することもできます。これにより、アプリケーションのメモリ使用量が適切に制限され、OOM エラーを回避できます。

コンテナで次のコマンドを実行して、メモリ制限をクエリします。

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