サイドカープロキシが動的オーバコミットされた ACK リソースを使用してリソース利用率を向上도록設定する - Alibaba Cloud Service Mesh

サイドカープロキシは、接続設定時には高く、定常的なトラフィックでは低いというように、CPU をバースト的に消費します。このバースト的なパターンは、サイドカーに割り当てられた CPU とメモリの大部分がほとんどの時間アイドル状態であることを意味します。ACK 動的オーバーコミットリソース (バッチ CPU とバッチメモリ) をサイドカーコンテナに割り当てることで、そのアイドル容量を再利用し、他の Pod で利用できるようにして、クラスター全体の利用率を向上させます。

このトピックでは、オーバーコミット ConfigMap のデプロイ、ASM コンソールでのサイドカーコンテナのバッチリソース制限の設定、サンプルワークロードのデプロイ、および結果の確認について説明します。

動的リソースオーバーコミットの仕組み

Kubernetes では、kubelet は Quality of Service (QoS) クラス (Guaranteed、Burstable、BestEffort) に基づいて Pod のリソースを管理します。これらのクラスは、各 Pod に設定された CPU とメモリのリクエストと制限によって決定されます。

ack-koordinator は、ノードの負荷をリアルタイムで監視し、割り当てられているがアクティブに使用されていないリソースを再利用することで、このモデルを拡張します。これらの再利用されたリソースを通常の CPU やメモリと区別するために、ack-koordinator は Batch 優先度を割り当てます：

リソースタイプ	リソースキー	単位
バッチ CPU	`kubernetes.io/batch-cpu`	ミリコア
バッチメモリ	`kubernetes.io/batch-memory`	バイト

バッチリソースを消費する Pod は、koordinator.sh/qosClass: "BE" ラベルを付与する必要があります。これは Koordinator の BestEffort QoS クラスにマッピングされます。このラベルは、スケジューラに対して、この Pod を再利用された容量の低優先度コンシューマーとして扱うように指示します。

オーバーコミットモデルの詳細については、動的リソースオーバーコミットの有効化をご参照ください。

前提条件

開始する前に、次のことを確認してください：

ACK Pro マネージドクラスター。詳細については、ACK Pro マネージドクラスターの作成をご参照ください
説明 ACK Pro マネージドクラスターのみが動的オーバーコミットリソースをサポートします。
ACK Pro マネージドクラスターで動的リソースオーバーコミット機能が有効になっていること。詳細については、動的リソースオーバーコミットの有効化をご参照ください
ACK Pro マネージドクラスターが、バージョン 1.16 以降を実行している ASM インスタンスに追加されていること。詳細については、ASM インスタンスへのクラスターの追加をご参照ください

ステップ 1：ack-slo-config ConfigMap のデプロイ

ack-slo-config ConfigMap は、ack-koordinator が各ノードでアイドル状態のリソースをどのように再利用するかを制御します。

configmap.yaml という名前のファイルを次の内容で作成します。主要なパラメーターを次の表に示します。すべての設定項目の詳細については、動的リソースオーバーコミットの有効化をご参照ください。

パラメーター	説明	値の例
`enable`	ノードのリソースオーバーコミットを有効にします。	`true`
`metricAggregateDurationSeconds`	ノードリソースメトリックを集計する間隔 (秒)。	`60`
`cpuReclaimThresholdPercent`	再利用可能な割り当て済み CPU の割合。	`60`
`memoryReclaimThresholdPercent`	再利用可能な割り当て済みメモリの割合。	`70`
`memoryCalculatePolicy`	メモリの可用性を計算する方法。`usage` は実際のメモリ消費量に基づいて計算します。	`"usage"`

   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 を適用します。
- 名前空間 kube-system にすでに ack-slo-config ConfigMap が存在する場合は、他の設定を保持するためにパッチを適用します。
```
kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)"
```
- ConfigMap が存在しない場合は、作成します：
```
kubectl apply -f configmap.yaml
```
ノードで利用可能なバッチリソースを確認します。<node-name> を実際のノード名に置き換えます。出力の allocatable セクションを確認します。allocatable の下に kubernetes.io/batch-cpu と kubernetes.io/batch-memory が表示されていれば、オーバーコミット ConfigMap は正しく機能しています。
```
   kubectl get node <node-name> -o yaml
```
```
   status:
     allocatable:
       # 単位：ミリコア。この例では、50 コアが利用可能です。
       kubernetes.io/batch-cpu: 50000
       # 単位：バイト。この例では、50 GB のメモリが利用可能です。
       kubernetes.io/batch-memory: 53687091200
```

ステップ 2：サイドカーコンテナのバッチリソースの設定

ASM コンソールで、インジェクトされたサイドカープロキシコンテナと istio-init コンテナのバッチリソースのリクエストと制限を設定します。

ASM コンソールにログインします。
左側のナビゲーションウィンドウで、[Service Mesh] > [メッシュ管理] を選択します。
[メッシュ管理] ページで、対象の ASM インスタンスの名前をクリックします。
左側のナビゲーションウィンドウで、[データプレーンコンポーネント管理] > [サイドカープロキシ設定] を選択します。
[サイドカープロキシ設定] ページで、[global] タブをクリックし、[リソース設定] をクリックします。

「サイドカープロキシ用に動的に過剰割り当て可能な ACK リソースを設定」を選択し、リソース値を設定します。「使用制限」および「必要なリソース」を、ワークロードの QoS クラスに基づいて設定します。次の表に例を示します：

QoS クラス	ガイダンス
Guaranteed	[リソース制限] と [必須リソース] を同じ値に設定します。
Burstable または BestEffort	[必須リソース] を [リソース制限] より低く設定します。このガイダンスは通常のリソースにも適用されます。

コンテナ	設定	CPU	メモリ
[インジェクトされたサイドカープロキシのリソースを設定 (ACK 動的オーバーコミットリソース)]	リソースの使用制限	2000 ミリコア	2048 MiB
	[必須リソース]	200 ミリコア	256 MiB
[istio-init コンテナのリソースを設定 (ACK 動的オーバーコミットリソース)]	リソースの使用制限	1000 ミリコア	1024 MiB
	[必須リソース]	100 ミリコア	128 MiB

[設定を更新] をクリックします。

ステップ 3：バッチリソースを使用するワークロードのデプロイ

バッチリソースをリクエストするサンプルアプリケーションをデプロイします。バッチリソースを使用する各 Pod には、koordinator.sh/qosClass: "BE" ラベルを付与する必要があります。これにより、ack-koordinator はその Pod を BestEffort コンシューマーとしてスケジュールします。

demo.yaml という名前のファイルを次の内容で作成します：

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
           # 必須。Pod に BestEffort QoS を割り当てます。
           koordinator.sh/qosClass: "BE"
       spec:
         terminationGracePeriodSeconds: 0
         containers:
         - name: sleep
           image: curlimages/curl
           command: ["/bin/sleep", "infinity"]
           imagePullPolicy: IfNotPresent
           resources:
             requests:
               # 1 コア (1000 ミリコア)
               kubernetes.io/batch-cpu: "1k"
               # 1 GiB
               kubernetes.io/batch-memory: "1Gi"
             limits:
               kubernetes.io/batch-cpu: "1k"
               kubernetes.io/batch-memory: "1Gi"

アプリケーションをデプロイします：
```
   kubectl apply -f demo.yaml
```

ステップ 4 (任意)：リソース制限の確認

デプロイ後、cgroup レベルのリソース制限が設定した値と一致することを確認します。

Pod が実行されているノードにログインし、CPU 制限を確認します。期待される出力：

   cat /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod****.slice/cri-containerd-****.scope/cpu.cfs_quota_us

   # 1 コア = CFS 期間あたり 100000 マイクロ秒
   100000

メモリ制限を確認します。期待される出力：

   cat /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod****.slice/cri-containerd-****.scope/memory.limit_in_bytes

   # 1 GB = 1073741824 バイト
   1073741824

両方の値が Deployment スペックと一致する場合、バッチリソースの制限は有効になっています。