Container Service for Kubernetes:リソースプロファイリングに基づいてコンテナーのリソース構成提案を提供する

課金ルール

ack-koordinatorコンポーネントをインストールして使用する場合、料金はかかりません。 ただし、次のシナリオでは料金が請求される場合があります。

• ack-koordinatorは、インストール後にワーカーノードリソースを占有する管理対象外のコンポーネントです。 コンポーネントのインストール時に、各モジュールが要求するリソースの量を指定できます。

• 既定では、ack-koordinatorは、リソースプロファイリングやきめ細かいスケジューリングなどの機能のモニタリングメトリックをPrometheusメトリックとして公開します。 ack-koordinatorのPrometheusメトリクスを有効にし、PrometheusのManaged Serviceを使用する場合、これらのメトリクスはカスタムメトリクスと見なされ、料金が課金されます。 料金は、クラスターのサイズやアプリケーションの数などの要因によって異なります。 Prometheusメトリクスを有効にする前に、Prometheusのマネージドサービスの課金概要トピックを読んで、カスタムメトリクスの無料クォータと課金ルールを確認することをお勧めします。 リソース使用量を監視および管理する方法の詳細については、「リソース使用量と請求書」をご参照ください。

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

手順1: リソースプロファイリングコンポーネントのインストール

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

2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[コストスイート] > [コスト最適化] を選択します。

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

   • ページの指示に従って、ack-koordinatorコンポーネントをインストールまたは更新します。 リソースプロファイリングを初めて使用する場合は、ack-koordinatorコンポーネントをインストールする必要があります。

     説明

     0.7.0より前のack-koordinatorバージョンを使用する場合は、移行と更新を実行する必要があります。 詳細については、「マーケットプレイスページからアドオンページへのack-koordinatorの移行」をご参照ください。

   • リソースプロファイリングを初めて使用する場合は、コンポーネントをインストールまたは更新した後、[デフォルト設定] を選択してすべてのワークロードのリソースプロファイリングを有効にすることを推奨します。 [プロファイル設定] をクリックすると、リソースプロファイリングの適用範囲を後で変更できます。

4. [リソースプロファイリングの有効化] をクリックして、[リソースプロファイリング] タブに移動します。

手順2: リソースプロファイリングポリシーの管理

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

2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[コストスイート] > [コスト最適化] を選択します。

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

   [グローバル設定] または [カスタム設定] を選択できます。 リソースプロファイリングコンポーネントのインストール時に選択したデフォルト設定は、グローバル構成に属します。 [グローバル設定] を選択して設定を変更し、[OK] をクリックして変更を適用します。

   グローバル設定モード (推奨)

   グローバル構成モードでは、デフォルトでarms-promおよびkube-system名前空間以外のワークロードに対してリソースプロファイリングが有効になります。

   パラメーター	説明	有効値
   除外された名前空間	リソースプロファイリングを無効にする名前空間。 ほとんどの場合、システムコンポーネントの名前空間のリソースプロファイリングは無効になっています。 グローバル構成を変更すると、リソースプロファイリングは、除外された名前空間に属していない指定された型のワークロードに対してのみ有効になります。	クラスター内で1つ以上の既存の名前空間を指定できます。 デフォルトでは、kube-systemおよびarms-prom名前空間が指定されます。
   ワークロードタイプ	リソースプロファイリングが有効になっているワークロードの種類。 グローバル構成を変更すると、リソースプロファイリングは、除外された名前空間に属していない指定された型のワークロードに対してのみ有効になります。	Kubernetesのワークロードタイプがサポートされています: Deployment、StatefulSet、およびDaemonSet。 1つ以上のワークロードタイプを選択できます。
   CPU冗長率 /メモリ冗長率	リソースプロファイリングポリシーで指定されている冗長率。 詳細については、次のセクションをご参照ください。	冗長率は0または正の値でなければなりません。 このシステムは、70% 、50% 、30% の3つの一般的に使用される冗長レートも提供します。

   カスタム設定モード

   カスタム構成モードでは、リソースプロファイリングは部分的なワークロードに対してのみ有効になります。 クラスターが大規模 (1,000ノードを超える) である場合、または部分的なワークロードのリソースプロファイリングを有効にする場合は、カスタム構成モードを選択します。

   パラメーター	説明	有効値
   名前空間	リソースプロファイリングを有効にする名前空間。 カスタム構成を変更すると、選択した名前空間に属する指定された型のワークロードに対してリソースプロファイリングが有効になります。	クラスター内の1つ以上の既存の名前空間を選択できます。
   ワークロードタイプ	リソースプロファイリングを有効にするワークロードの種類。 カスタム構成を変更すると、選択した名前空間に属する指定された型のワークロードに対してリソースプロファイリングが有効になります。	Kubernetesのワークロードタイプがサポートされています: Deployment、StatefulSet、およびDaemonSet。 1つ以上のワークロードタイプを選択できます。
   CPU冗長率 /メモリ冗長率	リソースプロファイリングポリシーで指定されている冗長率。 詳細については、次のセクションをご参照ください。	冗長率は0または正の値でなければなりません。 このシステムは、70% 、50% 、30% の3つの一般的に使用される冗長レートも提供します。

   リソースの冗長性: 管理者がアプリケーションのQPSなどのアプリケーションのワークロードを評価する場合、管理者は通常、ワークロードが100% の物理リソースを占有しないと想定します。 これは、ハイパースレッディングなどのテクノロジーでも物理リソースに制限があり、アプリケーションはピーク時のトラフィックスパイクに対処するためにリソースを予約する必要があるためです。 推奨リソース要求と元のリソース要求の差が指定された冗長度を超える場合、システムはリソース要求を減らすことを提案します。 リソースプロファイリングアルゴリズムの詳細については、「アプリケーションプロファイルの概要」をご参照ください。

ステップ3: リソースプロファイルの表示

このページには、集計されたリソースプロファイルデータと各ワークロードのリソースプロファイルが表示されます。

ステップ4: リソースプロファイルの詳細を表示する

ステップ5: リソース設定の変更

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

手順1: リソースプロファイリングの有効化

1. 次のYAMLテンプレートを使用して、recommendation-profile.yamlという名前のファイルを作成し、ワークロードのリソースプロファイリングを有効にします。

   RecommendationProfile CRDを使用して、ワークロードのリソースプロファイルを生成し、リソース構成の提案を取得できます。 RecommendationProfile CRDが適用される名前空間とワークロードタイプを指定できます。

   apiVersion: autoscaling.alibabacloud.com/v1alpha1
   kind: RecommendationProfile
   メタデータ:
     # RecommendationProfile CRDの名前。 名前空間のないRecommendationProfile CRDを作成する場合は、名前空間を指定しないでください。 
     名前: profile-demo
   spec:
     # リソースプロファイリングを有効にするワークロードの種類。 
     controllerKind:
     -デプロイ
     # リソースプロファイリングを有効にする名前空間。 
     enabledNamespaces:
     -default 

   次の表に、YAMLテンプレートのパラメーターを示します。

   パラメーター	タイプ	説明
   metadata.name	String	リソースオブジェクトの名前。 名前空間のないRecommendationProfile CRDを作成する場合は、名前空間を指定しないでください。
   spec.controllerKind	String	リソースプロファイリングを有効にするワークロードの種類。 有効な値: Deployment、StatefulSet、およびDaemonSet。
   spec.enabledNamespaces	String	リソースプロファイリングを有効にする名前空間。

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

   kubectl apply -f recommender-profile.yaml

3. cpu-load-gen.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。

   apiVersion: apps/v1
   kind: 配置
   メタデータ:
     名前: cpu-load-gen
     ラベル：
       アプリ: cpu-load-gen
   spec:
     レプリカ：2
     セレクタ：
       matchLabels:
         アプリ: cpu-load-gen-selector
     template:
       metadata:
         labels:
           アプリ: cpu-load-gen-selector
       仕様：
         containers:
         -name: cpu-load-gen
           画像: registry.cn-zhangjiakou.aliyuncs.com/acs/slo-test-cpu-load-gen:v0.1
           コマンド: ["cpu_load_gen.sh"]
           imagePullPolicy: Always
           resources:
             requests:
               cpu: 8# アプリケーションに8つのCPUコアを要求します。 
               メモリ: "1Gi"
             limits:
               cpu: 12
               メモリ: "2Gi" 

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

   kubectl apply -f cpu-load-gen.yaml

5. 次のコマンドを実行して、作成したアプリケーションのリソース構成の提案を取得します。

   kubectlがおすすめを取得-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 

   説明

   正確なリソース構成の提案を生成するには、システムがデータを収集するためのリソースプロファイリングを有効にしてから少なくとも1日待つことをお勧めします。

   ワークロードのリソースプロファイリングを有効にすると、ack-koordinatorはワークロードのリソース構成の提案を提供します。 提案は推奨CRDに記憶される。 次のコードブロックは、cpu-load-gen.yamlという名前のリソースプロファイルを示しています。

   apiVersion: autoscaling.alibabacloud.com/v1alpha1
   kind: Recommendation
   メタデータ:
     ラベル：
       alpha.alibabacloud.com/recommendation-workload-apiVersion: app-v1
       alpha.alibabacloud.com/recommendation-workload-kind: デプロイ
       alpha.alibabacloud.com/recommendation-workload-name: cpu-load-gen
     名前: f20ac0b3-dc7f-4f47-b3d9-bd91f906 ****
     名前空間: recommender-demo
   spec:
     workloadRef:
       apiVersion: apps/v1
       kind: Deployment
       名前: cpu-load-gen
   ステータス:
     recommendResources:
       containerRecommendations:
       -containerName: cpu-load-gen
         ターゲット:
           cpu: 4742m
           メモリ: 262144k
         originalTarget: # リソースプロファイリングアルゴリズムによって生成された中間結果。 中間結果を使用しないことを推奨します。 
          # ...

   データの取得を容易にするために、推奨CRDはワークロードと同じ名前空間で生成されます。 さらに、Recommendation CRDは、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. recommendoResources. containerRecommendationsに保存されます。 下表に、各パラメーターを説明します。

   パラメーター	説明	Format	例
   containerName	コンテナーの名前。The name of the container.	String	cpu-load-gen
   ターゲット	提案されたCPU要求とメモリ要求を含むリソースプロファイリング結果。	map[ResourceName]resource.Quantity	cpu: 4742mmemory: 262144k
   originalTarget	リソースプロファイリングアルゴリズムによって生成された中間結果。 中間結果を使用しないことを推奨します。 要件がある場合は、チケットを起票します。	-	-

   説明

   推奨されるCPUリソースの最小量は0.025 CPUコアです。 推奨されるメモリリソースの最小量は250 MBです。

   cpu-load-gen.yamlアプリケーションによって要求されたリソース設定と、この手順で推奨されるリソース設定を比較します。 要求されたCPUリソースは、提案されたCPUリソースよりも大きい。 リソースを節約するために、アプリケーションのCPU要求を減らすことができます。

   リソース	要求された金額	推奨金額
   CPU	8 vCPU	4.742 vCPU

ステップ2。 (オプション): Managed Service for Prometheusでプロファイリング結果を確認する

よくある質問

リソースプロファイリングアルゴリズムはどのように機能しますか?

リソースプロファイリングに適したアプリケーションの種類?

リソースプロファイリングは、オンラインアプリケーションに適しています。

ほとんどの場合、リソースプロファイリング機能によって提案されるリソース設定は、アプリケーションのリソース要件を満たすことができます。 オフラインアプリケーションはバッチ処理を使用し、高いスループットを必要とします。 オフラインアプリケーションは、リソース利用を改善するためにリソース競合を許容する。 オフラインアプリケーションのリソースプロファイリングを有効にすると、リソースの無駄が発生する可能性があります。 ほとんどの場合、主要なシステムコンポーネントはアクティブ /スタンバイモードでデプロイされ、複数のレプリカがあります。 スタンバイレプリカに割り当てられているリソースはアイドル状態です。 結果として、資源プロファイリングアルゴリズムは、不正確な結果を生成する。 上記のケースでは、リソースプロファイリングによって提案されたリソース設定を使用しないことを推奨します。 ACKは、これらの場合にリソースプロファイリングによって提供される提案に基づいてリソース構成を指定する方法に関する更新を提供します。

コンテナのリソース要求とリソース制限を指定するときに、リソースプロファイリングで提案されたリソース設定を直接使用できますか。

リソースプロファイリングは、アプリケーションの現在のリソース要求に基づいてリソース構成提案を生成する。 管理者は、ビジネス特性を考慮し、それに応じて推奨値を変更する必要があります。 たとえば、トラフィックの急増を処理するためにリソースを予約したり、ゾーン災害復旧のためにリソースを予約したりする必要があります。 また、ホストの負荷が高い場合にリソースを必要とするアプリケーションを安定して実行できるように、推奨値を増やす必要がある場合もあります。

自己管理型のPrometheusモニタリングシステムを使用する場合、リソースプロファイルを表示するにはどうすればよいですか?

ack-Koordinatorのkoordinator Managerコンポーネントは、HTTP API操作を使用して、リソースプロファイルのモニタリングメトリックをPrometheusメトリックとして公開します。 次のコマンドを実行して、ポッドのIPアドレスを照会し、メトリクスデータを表示します。

# 次のコマンドを実行して、ポッドのIPアドレスを照会します。$kubectl get pod -A -o wide | grep koord-manager
# 期待される出力は、環境によって異なる場合があります
kube-system ack-koord-manager-5479f85d5f-7xd5k 1/1実行0 19d 192.168.12.242 cn-beijing.192.168.xx.xxx <none> <none>
kube-system ack-koord-manager-5479f85d5f-ftblj 1/1実行0 19d 192.168.12.244 cn-beijing.192.168.xx.xxx <none> <none>

# 次のコマンドを実行してメトリクスデータを表示します (Koordinator Managerはマスターレプリカアーキテクチャにあり、メトリクスデータはプライマリレプリカポッドにあります)
# IPアドレスとポートについては、Koordinator Managerの展開設定を参照してください。# コマンドを実行するホストとコンテナーが相互接続されていることを確認してから
$curl -s http:// 192.168.12.244:9326 /メトリクス | grep slo_manager_recommender_recommendation_workload_target
# 期待される出力は、環境によって異なる場合があります
# HELP slo_manager_recommender_recommendation_workload_targetワークロードリソース要求の推奨.
# タイプslo_manager_recommender_recommendation_workload_targetゲージ
slo_manager_recommender_recommendation_workload_target{container_name="xxx",namespace="xxx",recommendation_name="xxx",resource="cpu",workload_api_version="apps/v1",workload_kind="Deployment",workload_name="xxx"} 2.406
slo_manager_recommender_recommendation_workload_target{container_name="xxx",namespace="xxx",recommendation_name="xxx",resource="memory",workload_api_version="apps/v1",workload_kind="Deployment",workload_name="xxx"} 3.861631195e + 09 

ack-koordinatorのインストール後、ServiceとService Monitorは自動的に作成され、ポッドに関連付けられます。 Releventメトリクスは、Alibaba Cloud Prometheus Serviceを使用している場合、Grafanaダッシュボードに収集および表示されます。

自己管理型Prometheusモニタリングシステムのカスタムメトリック収集構成を構成する方法の詳細については、公式のPrometheusドキュメントを参照してください。 Grafanaダッシュボードを設定して、リソースプロファイルを表示できます。 詳細については、ステップ2をご参照ください。 (オプション): Managed Service for Prometheusでプロファイリング結果を確認します。

リソースプロファイルとリソースプロファイリングポリシーを削除する方法を教えてください。

リソースプロファイルは推奨CRDに格納されます。 リソースプロファイリングポリシーは、RecommendationProfile CRDに格納されます。 次のコマンドを実行して、すべてのリソースプロファイルとリソースプロファイリングポリシーを削除します。

# すべてのリソースプロファイルを削除します。 
kubectl削除の推奨事項-A -- すべて

# すべてのリソースプロファイリングポリシーを削除します。 
kubectl delete recommendationprofile -A -- すべて 

リソースプロファイリング機能を使用するようにRAMユーザーに権限を付与するにはどうすればよいですか?

ACKの承認システムは、リソースアクセス管理 (RAM) 承認とロールベースのアクセス制御 (RBAC) 承認で構成されます。 RAM権限は、クラウドリソースに対する権限を付与するために使用されます。 RBAC権限付与は、クラスター内のKubernetesリソースに対する権限を付与するために使用されます。 ACKの認証システムの詳細については、「認証のベストプラクティス」をご参照ください。 RAMユーザーにリソースプロファイリング機能の使用を許可するには、権限付与のベストプラクティスから次の手順を実行することを推奨します。

1. RAM権限付与

   Alibaba CloudアカウントでRAMコンソールにログインし、RAMユーザーに定義済みのAliyunCSFullAccess権限を付与します。 詳細については、「権限付与の概要」をご参照ください。

2. RBAC承認

   RAM権限付与を実行した後、ターゲットクラスターのこのRAMユーザーに対して開発者ロール以上のRBAC権限付与を実行する必要があります。 詳細については、「RAMユーザーまたはRAMロールへのRBAC権限の付与」をご参照ください。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
メタデータ:
  名前: recommendation-clusterrole
-apiGroups:
  - autoscaling.alibabacloud.com
  resources:
  - '*'
  verbs:
  - '*'