Container Compute Service:リソースプロファイリングによるコンテナー仕様の推奨

課金

ack-koordinator コンポーネントのインストールと使用は無料です。ただし、以下のシナリオでは追加費用が発生する場合があります。

• インストール後、ack-koordinator は 2 つの汎用 ACK Pod インスタンスをリクエストします。コンポーネントのインストール中に、各モジュールのリソースリクエストを構成できます。

• ack-koordinator は、デフォルトでリソースプロファイリングなどのメトリックを Prometheus 形式で公開します。Alibaba Cloud Prometheus で [ack-koordinator の Prometheus メトリックを有効にする] を選択した場合、これらはクラスターの規模に基づいて課金対象のカスタムメトリックとして扱われます。有効にする前に、課金ドキュメントで価格と無料クォータを確認してください。使用量クエリで利用状況を監視できます。

制限事項

コンソールでのリソースプロファイリングの使用

ステップ 1：リソースプロファイリングの有効化

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

2. クラスターリスト ページで、対象クラスターの名前をクリックします。左側のナビゲーションウィンドウで、コスト管理スイート > コスト最適化モード を選択します。

3. [コスト最適化] ページで、[リソースプロファイリング] タブをクリックします。[リソースプロファイリング] エリアで、画面の指示に従って機能を有効にします。

   • コンポーネントのインストールまたはアップグレード：プロンプトに従って ack-koordinator コンポーネントをインストールまたはアップグレードします。

   • プロファイリング構成：初めて機能を使用する場合、コンポーネントをインストールまたはアップグレードした後、[デフォルト設定] を選択してリソースプロファイリングの範囲を制御します (推奨)。後で構成を調整するには、コンソールの [プロファイリング構成] をクリックします。

4. [リソースプロファイリングを有効にする] をクリックして [コスト最適化] ページを開きます。

ステップ 2：リソースプロファイリングの構成

1. [コスト最適化] ページで、[リソースプロファイリング] タブをクリックし、[プロファイリング構成] をクリックします。

   プロファイリング構成には、[グローバル構成] と [カスタム構成] の 2 つのモードがあります。推奨されるデフォルトは [グローバル構成] です。ここでモードとそのパラメーターを変更できます。[OK] をクリックして変更を適用します。

   グローバル構成

   グローバル構成モードは、デフォルトで arms-prom と kube-system のシステム名前空間を除く、すべてのワークロードに対してリソースプロファイリングを有効にします。

   構成項目	説明	有効値
   [除外する名前空間]	リソースプロファイリングが有効にならない名前空間で、通常はシステムコンポーネント用です。最終的に有効になる範囲は、有効な名前空間とワークロードタイプの積集合です。	現在のクラスターに存在する名前空間。複数の名前空間を選択できます。デフォルト値は kube-system と arms-prom です。
   ワークロードタイプ	リソースプロファイリングが有効になるワークロードタイプの範囲。最終的に有効になる範囲は、有効な名前空間とワークロードタイプの積集合です。	Deployment、StatefulSet、DaemonSet を含むネイティブ Kubernetes ワークロードをサポートします。複数のタイプを選択できます。
   CPU/メモリ冗長率	リソース推奨を生成するために使用される安全マージン。詳細は以下の説明をご参照ください。	非負の数である必要があります。70%、50%、30% の 3 つの一般的な冗長レベルから選択できます。

   カスタム構成

   カスタム構成モードは、特定の名前空間のワークロードに対してリソースプロファイリングを有効にします。大規模なクラスター (例：1,000 ノード以上) がある場合や、一部のワークロードに対してのみ機能を有効にしたい場合は、このモードを使用して必要に応じて指定します。

   設定項目	説明	有効値
   [ネームスペース]	リソースプロファイリングが有効化されたネームスペースです。最終的に有効化されるスコープは、有効化されたネームスペースとワークロードタイプの共通部分となります。	現在のクラスターに存在するネームスペースです。複数のネームスペースを選択できます。
   [ワークロードタイプ]	リソースプロファイリングが有効化されるワークロードタイプのスコープです。最終的に有効化されるスコープは、有効化されたネームスペースとワークロードタイプの共通部分となります。	Kubernetes の 3 つのネイティブなワークロードタイプ (Deployment、StatefulSet、DaemonSet) をサポートしています。複数のタイプを選択できます。
   [CPU]/[メモリ] 冗長率	リソース推奨を生成するために使用される安全マージンです。詳細については、以下の説明をご参照ください。	0 以上の数値を指定する必要があります。一般的な 3 つの冗長レベル (70%、50%、30%) から選択できます。

   説明

   リソース消費の冗長性：管理者は通常、ハイパースレッディングなどのハードウェアの制限や、ピーク負荷のためのバッファーを確保する必要があるため、物理リソースを 100% 使用することを避けます。コンソールは、プロファイル値と元のリクエストの差が安全マージンを超えた場合にダウングレードを推奨します。アルゴリズムについては、「アプリケーションプロファイルの概要」の推奨ロジックをご参照ください。

ステップ 3：アプリケーションプロファイルの概要の表示

1. リソースプロファイリングポリシーを構成した後、[リソースプロファイリング] ページで各ワークロードのリソースプロファイルを表示できます。

   結果の精度を向上させるため、初めて機能を使用する際には、システムが少なくとも 24 時間のデータを蓄積する必要があるというプロンプトが表示されます。

2. 次の表は、プロファイルの概要の列について説明しています。

   

   説明

   以下の表では、ハイフン (-) はその項目が適用されないことを示します。

   列名	説明	値の説明	フィールドフィルタリングのサポート
   [ワークロード名]	ワークロードの名前。	-	サポートされています。メニューバーの上部で名前による完全一致検索を実行できます。
   名前空間	ワークロードの名前空間。	-	サポートされています。デフォルトのフィルター条件には kube-system 名前空間は含まれません。
   ワークロードタイプ	ワークロードのタイプ。	Deployment、DaemonSet、StatefulSet が含まれます。	サポートされています。デフォルトのフィルター条件は「すべて」です。
   CPU リクエスト	ワークロードの Pod の CPU リソースリクエスト。	-	サポートされていません。
   メモリ要求	ワークロードの Pod のメモリリソースリクエスト。	-	サポートされていません。
   プロファイルデータのステータス	ワークロードのリソースプロファイルステータス。	収集中：リソースプロファイルが作成されたばかりで、蓄積されたデータが少ない状態です。初めて使用する場合は、ワークロードが安定して実行され、トラフィックのピークと谷をカバーするために、少なくとも 24 時間待つことを推奨します。 正常：リソースプロファイルが生成されました。 ワークロード削除済み：対応するワークロードが削除されました。プロファイルは保持期間後に自動的に削除されます。	サポートされていません。
   CPU プロファイル、メモリ プロファイル	プロファイル値、元のリクエスト、および構成されたリソース消費の冗長性に基づいてリソースリクエストを調整するための推奨。	アップグレード、ダウングレード、維持が含まれます。パーセンテージは逸脱の大きさを示します。式：Abs(プロファイル値 - 元のリクエスト) / 元のリクエスト。	サポートされています。デフォルトのフィルター条件には、アップグレードとダウングレードが含まれます。
   [作成時刻]	プロファイルの作成時刻。	-	サポートされていません。
   [操作]	プロファイルと推奨を評価した後、[リソース構成の変更] をクリックしてリソースを変更します。詳細については、「ステップ 5：アプリケーションリソース仕様の変更」をご参照ください。	-	サポートされていません。

   説明

   ACK リソースプロファイリングは、各コンテナーのプロファイル値を生成します。この推奨値、元のリクエスト、および冗長性バッファーを比較することにより、コンソールはアップグレードやダウングレードなどの操作を提案します。複数コンテナーのワークロードの場合、推奨は最も逸脱が大きいコンテナーを反映します。計算ロジックは次のとおりです。

   • プロファイル値 (推奨) > 元のリソースリクエスト (リクエスト)：これは、コンテナーが長期間にわたってリソースを過剰に使用しており (使用量がリクエストより大きい)、安定性のリスクがあることを示します。コンソールはアップグレードを提案します。

   • プロファイル値 (推奨) < 元のリソースリクエスト (リクエスト)：これは、リソースの無駄の可能性を示しており、仕様を削減できることを意味します。これは、構成されたリソース消費の冗長性によって決定されます。詳細は次のとおりです：

     1. プロファイル値と構成された冗長性に基づいて、ターゲットリソース仕様 (Target) を計算します：Target = Recommend * (1 + Buffer)

     2. Target に対する元の Request の逸脱度 (Degree) を計算します: Degree = 1 - Request / Target

     3. プロファイル値と Degree に基づいて、CPU とメモリの推奨を生成します。Degree の絶対値が 0.1 より大きい場合、コンソールはダウングレードの提案をプロンプト表示します。

   • それ以外のすべての場合、推奨は [維持] となります。これは、すぐに調整する必要がないことを意味します。

ステップ 4：アプリケーションプロファイル詳細の表示

1. [リソースプロファイリング] ページで、ワークロード名をクリックしてその [プロファイル詳細] ページを開きます。

   詳細ページには、基本的なワークロード情報、各コンテナーのプロファイル詳細のリソース曲線、およびアプリケーションのリソース仕様を変更するためのウィンドウの 3 つのセクションがあります。CPU を例にとると、プロファイル詳細リソース曲線のメトリックの意味は次のとおりです。

   曲線名	説明
   cpu limit	コンテナーの CPU リソースリミット。
   cpu request	コンテナーの CPU リソースリクエスト。
   cpu recommend	コンテナーの CPU プロファイル値。
   cpu usage (average)	ワークロード内のすべてのコンテナーレプリカの平均 CPU 使用量。
   cpu usage (max)	ワークロード内のすべてのコンテナーレプリカの中での最大 CPU 使用量。

ステップ 5：アプリケーションリソース仕様の変更

コマンドラインからのリソースプロファイリングの使用

ステップ 1：リソースプロファイリングの有効化

1. 以下の YAML コンテンツで recommendation-profile.yaml ファイルを作成し、ワークロードのリソースプロファイリングを有効にします。

   RecommendationProfile CRD を作成すると、一致するワークロードのリソースプロファイリングが有効になり、推奨データを取得できます。RecommendationProfile CRD は、名前空間とワークロードタイプを通じて有効範囲を制御することをサポートします。最終的な有効範囲は、この 2 つの積集合です。

   apiVersion: autoscaling.alibabacloud.com/v1alpha1
   kind: RecommendationProfile
   metadata:
     # オブジェクトの名前。非名前空間タイプの場合は名前空間を指定しないでください。
     name: profile-demo
   spec:
     # リソースプロファイリングを有効にするワークロードタイプ。
     controllerKind:
     - Deployment
     # リソースプロファイリングを有効にする名前空間。
     enabledNamespaces:
     - default

   各構成フィールドの意味は次のとおりです：

   パラメーター	タイプ	説明
   metadata.name	String	オブジェクトの名前。RecommendationProfile が非名前空間タイプの場合、名前空間を指定する必要はありません。
   spec.controllerKind	String	リソースプロファイリングが有効になっているワークロードタイプ。サポートされているタイプには、Deployment、StatefulSet、DaemonSet が含まれます。
   spec.enabledNamespaces	String	リソースプロファイリングが有効になっている名前空間の範囲。

2. 次のコマンドを実行して、対象アプリケーションのリソースプロファイリングを有効にします。

   kubectl apply -f recommender-profile.yaml

3. 以下の YAML コンテンツで cpu-load-gen.yaml ファイルを作成します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: cpu-load-gen
     labels:
       app: cpu-load-gen
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: cpu-load-gen-selector
     template:
       metadata:
         labels:
           app: cpu-load-gen-selector
       spec:
         containers:
         - name: cpu-load-gen
           image: registry.cn-zhangjiakou.aliyuncs.com/acs/slo-test-cpu-load-gen:v0.1
           command: ["cpu_load_gen.sh"]
           imagePullPolicy: Always
           resources:
             requests:
               cpu: 8 # このアプリケーションの CPU リクエストは 8 コアです。
               memory: "1Gi"
             limits:
               cpu: 12
               memory: "2Gi"

4. 次のコマンドを実行して、cpu-load-gen アプリケーションをデプロイします。

   kubectl apply -f cpu-load-gen.yaml

5. 次のコマンドを実行して、リソース仕様プロファイルを取得します。

   kubectl get recommendations -l \
     "alpha.alibabacloud.com/recommendation-workload-apiVersion=apps-v1, \
     alpha.alibabacloud.com/recommendation-workload-kind=Deployment, \
     alpha.alibabacloud.com/recommendation-workload-name=cpu-load-gen" -o yaml

   説明

   正確なプロファイリング結果を得るために、システムが十分なデータを収集できるよう、少なくとも 24 時間待機してください。

   ack-koordinator は、リソースプロファイリングが有効になっている各ワークロードに対応するリソース仕様プロファイルを生成し、結果を Recommendation CRD に保存します。cpu-load-gen という名前のワークロードのリソース仕様プロファイルの例を以下に示します。

   apiVersion: autoscaling.alibabacloud.com/v1alpha1
   kind: Recommendation
   metadata:
     labels:
       alpha.alibabacloud.com/recommendation-workload-apiVersion: app-v1
       alpha.alibabacloud.com/recommendation-workload-kind: Deployment
       alpha.alibabacloud.com/recommendation-workload-name: cpu-load-gen
     name: f20ac0b3-dc7f-4f47-b3d9-bd91f906****
     namespace: recommender-demo
   spec:
     workloadRef:
       apiVersion: apps/v1
       kind: Deployment
       name: cpu-load-gen
   status:
     recommendResources:
       containerRecommendations:
       - containerName: cpu-load-gen
         target:
           cpu: 4742m
           memory: 262144k
         originalTarget: # これはリソースプロファイリングアルゴリズムの中間結果を示します。直接使用しないでください。
          # ...

   取得を容易にするため、Recommendation とワークロードは同じ名前空間を共有します。ワークロードの API バージョン、タイプ、名前は、以下の表で説明するようにラベルに保存されます。

   ラベルキー	説明	例
   alpha.alibabacloud.com/recommendation-workload-apiVersion	ワークロードの API バージョン。Kubernetes のラベル制約により、スラッシュ (/) はハイフン (-) に置き換えられます。	app-v1 (元は app/v1)
   alpha.alibabacloud.com/recommendation-workload-kind	対応するワークロードタイプ (Deployment や StatefulSet など)。	Deployment
   alpha.alibabacloud.com/recommendation-workload-name	ワークロードの名前。Kubernetes のラベル制約により、長さは 63 文字を超えることはできません。	cpu-load-gen

   各コンテナーのリソース仕様プロファイルは status.recommendResources.containerRecommendations に保存されます。各フィールドの意味は次のとおりです。

   フィールド名	説明	フォーマット	例
   containerName	コンテナーの名前。	string	cpu-load-gen
   target	CPU とメモリのディメンションを含むリソース仕様プロファイル。	map[ResourceName]resource.Quantity	cpu: 4742mmemory: 262144k
   originalTarget	リソースプロファイリングアルゴリズムの中間結果を表します。このフィールドを直接使用しないでください。	-	-

   説明

   単一コンテナーの最小推奨値は、CPU が 25m、メモリが 250Mi です。

   対象アプリケーション cpu-load-gen で宣言されたリソース仕様と、このステップのプロファイリング結果を比較すると、コンテナーの CPU リクエストが高すぎることがわかります。リクエストを減らしてクラスターリソースを節約できます。

   カテゴリ	元のリソース仕様	リソース仕様
   CPU	8 コア	4.742 コア

ステップ 2：(オプション) Prometheus での結果表示

# ワークロード内のコンテナーの CPU リソース仕様プロファイル。
koord_manager_recommender_recommendation_workload_target{exported_namespace="$namespace", workload_name="$workload", container_name="$container", resource="cpu"}
# ワークロード内のコンテナーのメモリリソース仕様プロファイル。
koord_manager_recommender_recommendation_workload_target{exported_namespace="$namespace", workload_name="$workload", container_name="$container", resource="memory"}

よくある質問

リソースプロファイリングアルゴリズムの仕組み

リソースプロファイリングに最適なアプリケーションタイプとは

最適な用途：

トラフィックパターンが変動するものの、ある程度予測可能なオンラインサービス。アルゴリズムは、ピーク時の使用量に対応するためにリソースの可用性を確保するように設計されています。

不向きな用途：

• オフライン/バッチジョブ：これらのワークロードは、即時のリソース可用性よりもスループットを優先し、ある程度のリソース競合を許容できるため、推奨事項が保守的すぎる場合があります。

• アクティブ/スタンバイ構成のアプリケーション：アクティブ/スタンバイモデルでデプロイされた重大なコンポーネントの場合、アイドル状態のスタンバイレプリカが使用状況データを偏らせ、結果として推奨事項が低すぎることがあります。

適合性が低いアプリケーションの種類については、推奨事項をベースラインとして扱い、お客様固有の運用要件に基づいて調整してください。

プロファイルされた値を直接使用して、コンテナーの requests と limits を設定できますか？

プロファイルされた値を確認せずに直接適用することはお勧めしません。これらの値は過去のリソース需要をまとめたものであり、最終的な構成ではなく、強力なベースラインとして使用すべきです。

推奨事項は、お使いのアプリケーションの特定のニーズに合わせて常に調整する必要があり、その例を次に示します。

• ピークトラフィックバッファー： 予測されるトラフィックスパイクやプロモーションイベントに対応するため、追加のキャパシティを確保します。

• 高可用性： アクティブ/アクティブディザスタリカバリのセットアップにおいて、シームレスなフェイルオーバーをサポートするために追加のリソースを割り当てます。

• パフォーマンス要件： ホストレベルのリソース競合の影響を受けやすいアプリケーションの場合、安定したパフォーマンスを確保するために、requests を推奨値よりも高く設定する必要がある場合があります。

以前の推奨事項を適用した直後に、リソースプロファイリングが新しいアップグレードまたはダウングレードを提案するのはなぜですか？

これは、変更を適用すると、ACK が基盤となるインスタンスのコンピューティングタイプに基づいてリソース仕様を正規化するためです。最終的な正規化された値は、元の推奨値と異なる場合があります。

プロセスは以下のとおりです。

1. リソースプロファイリングは、元の推奨値 (例： 4.742 コア) を生成します。

2. コンソール経由でこの推奨値を受け入れて適用します。

3. ACK は、ノードのコンピューティングタイプの制約に合わせて値を正規化します (例えば、値を 4.5 コアに丸めます)。 詳細については、「リソース仕様」をご参照ください。

4. 新しい正規化されたリクエスト (4.5 コア) は元の推奨値 (4.742 コア) と異なるため、新しい Downgrade の提案がトリガーされる場合があります。

セルフマネージド Prometheus で Resource Profiling メトリックをスクレイプするにはどうすればよいですか？

ack-koordinator コンポーネントは、その koord-manager Pod 上の HTTP エンドポイント経由でメトリックを公開します。これらのメトリックを独自の Prometheus サーバーでスクレイプするには、以下の手順に従ってください。

1. koord-manager Pod IP の特定

koord-manager デプロイメントはアクティブ-スタンバイモードで実行され、アクティブな Pod のみがメトリックを提供します。まず、Pod の IP を検索します。

# Pod の IP アドレスを取得
kubectl get pod -n kube-system -o wide | grep ack-koord-manager

# 出力例:
# ack-koord-manager-5479f85d5f-7xd5k   1/1   Running   0   19d   192.168.12.242   ...
# ack-koord-manager-5479f85d5f-ftblj   1/1   Running   0   19d   192.168.12.244   ...

2. メトリクスエンドポイントの確認

curl を使用して、いずれかの IP の /metrics エンドポイントを確認します。デフォルトポートは 9326 です。一方の IP が失敗した場合は、もう一方をお試しください。リーダーのみがメトリックを提供するためです。

# ご使用の Pod IP に置き換えてください
curl -s http://192.168.12.244:9326/all-metrics | grep koord_manager_recommender_recommendation_workload_target

# 出力例には、次のようなメトリックが含まれます。
# koord_manager_recommender_recommendation_workload_target{...resource="cpu",...} 2.406
# koord_manager_recommender_recommendation_workload_target{...resource="memory",...} 3.861631195e+09

3. Prometheus スクレイプジョブの設定

ack-koordinator をインストールすると、Prometheus でのサービスディスカバリーに使用できる Service および ServiceMonitor オブジェクトが自動的に作成されます。Prometheus インスタンスを設定して、 koord-manager サービスをスクレイプします。具体的なスクレイプ設定については、Prometheus の公式ドキュメントをご参照ください。

Resource Profiling のデータとルールをすべて削除してリセットするにはどうすればよいですか？

このコマンドは、生成されたリソースの推奨を格納する Recommendation CR をすべて削除します。

kubectl delete recommendation -A --all

このコマンドは、プロファイルするワークロードを定義するすべての RecommendationProfile CR を削除します。

kubectl delete recommendationprofile -A --all

RAM ユーザーに Resource Profiling を使用するために必要な権限を付与するには、どうすればよいですか？

RAM ユーザーに権限を付与するには、Alibaba Cloud RAM (コンソールアクセス用) と Kubernetes RBAC (クラスター内の操作用) という 2 つのレベルで権限を付与する必要があります。

1. 1. RAM 権限の付与

   Resource Access Management (RAM) コンソールで、ターゲット RAM ユーザーに AliyunACKReadOnlyAccess システムポリシーを付与します。 これにより、Container Service for Kubernetes (ACK) 関連のクラウドリソースに必要な読み取り権限が付与されます。 詳細については、「システムポリシーを使用した権限の付与」をご参照ください。

2. 2. Kubernetes RBAC 権限の付与

   ACK コンソールで、ターゲットクラスターに対して、RAM ユーザーに事前定義済みの developer RBAC ロール (または admin のような上位のロール) を割り当てます。 これにより、プロファイリングに必要な Kubernetes リソースへの広範な読み取り/書き込みアクセス権が付与されます。 手順については、「RAM ユーザーまたは RAM ロールの RBAC 権限の設定」をご参照ください。

代替: きめ細かい RBAC 権限

広範な developer ロールの代わりに、よりきめ細かいコントロールを付与したい場合は、Resource Profiling CRD 専用の権限を持つカスタム ClusterRole を作成します。

1. 次の ClusterRole マニフェストをご利用のクラスターに適用してください：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: recommendation-clusterrole
rules:
- apiGroups:
  - "autoscaling.alibabacloud.com"
  resources:
  - "*"
  verbs:
  - "*"

2. 次に、この ClusterRole を ClusterRoleBinding を使用して RAM ユーザーにバインドする必要があります。