Metering Operator は、Kubernetes クラスタ全体でリソースがどのように使用されているかに関するアカウンタビリティを明確にするチャージバックおよびレポートツールです。クラスタ管理者は、Pod、Namespace、クラスタ全体の使用履歴データに基づいてレポートのスケジュールを設定できます。
Metering Operator をインストールすると、すぐに使用できるレポートクエリが多数用意されています。たとえば、管理者がクラスタノード (または Pod) の CPU (またはメモリー) 使用量を測定したい場合、必要なのは、Metering Operator をインストールし、レポート (月次、時間別など) を生成するための Report カスタムリソースを作成することだけです。
ユースケース
お客様からよく聞く要件がいくつかあります。
- プロダクション以外の環境の OpenShift クラスタにあるワーカーノードは、常に実行されているわけではありません (たとえば、管理者が使用可能な容量に基づいて、または週末に、いくつかのワーカーノードをオフにする場合など)。したがって、ノードの CPU (またはメモリー) 使用量を月単位で測定し、インフラストラクチャチームが実際のノード使用量に基づいてユーザーに対してチャージバックできるようにしたいと考えています。
- お客様には、特定のチーム専用の OpenShift クラスタをデプロイするデプロイモデルがあります。Metering Operator をインストールしてノードの使用状況を取得することはできますが、お客様はワーカーノードがどのチーム (または部門) に使用されているかをチャージバックレポートに含めたいと考えています。このユースケースはさらに拡張して、共有の専用クラスタに「ラベル付けされた」ノードがあり、ノード上で実行される部門/チームのワークロードをそのラベルで識別するようにもできます。
- 共有クラスタで、運用チームは、Pod の実行時間 (CPU やメモリー消費量など) に基づいてチームに対してチャージバックしたいと考えています。ここでも、レポートを単純化して Pod が属するチーム (または部門) を含めたいと考えています。
これらの要件を満たすためには、クラスタ内にカスタムリソースをいくつか作成する必要があります。この記事では、作成を簡単に行う方法について説明します。ただし、この記事では Metering Operator のインストールは扱いません。インストールに関するドキュメントは、こちらを参照してください。すぐに使用できるレポートの使用方法の詳細については、こちらのドキュメントを参照してください。
メータリングの仕組み
前項で取り上げたユースケースで使用する新しいカスタムリソースの作成に進む前に、OpenShift Metering がどのように機能するかについて少し説明します。Metering Operator をインストールすると、合計で 6 つのカスタムリソースが作成されます。6 つのうち、以下について少し説明します。
- ReportDataSources (rds):rds は、ReportQuery または Report カスタムリソースがどのデータにアクセスでき、使用できるかを定義するメカニズムです。また、複数のソースからデータをフェッチすることもできます。OpenShift では、データは Prometheus および ReportQuery (rq) カスタムリソースからプルされます。
- ReportQuery (rq):rq には、rds で保存されたデータの分析を実行するための SQL クエリが含まれます。rq オブジェクトが Report オブジェクトによって参照されている場合、 rq オブジェクトは、レポート実行時にレポートする内容も管理します。rds オブジェクトによって参照される場合、 rq オブジェクトは、レンダリングされたクエリに基づいて Presto テーブル (Metering をインストールする際に作成される) 内にビューを作成するように Metering に指示します。
- Report:このカスタムリソースは、設定された ReportQuery リソースを使用してレポートが生成されるようにします。Metering Operator のエンドユーザーは主にこのリソースを使用します。レポートはスケジュールに従って実行するよう設定できます。
そのまま使用できる rds や rq が多数用意されています。ここではノードレベルのメータリングに焦点を当てているので、独自にカスタマイズしたクエリを作成するために理解しておく必要があるものを示します。“openshift-metering” プロジェクトで次のコマンドを実行します。
$ oc project openshift-metering $ oc get reportdatasources | grep node node-allocationable-cpu-cores node-allocationable-memory-bytes node-capacity-cpu-cores node-capacity-memory-bytes node-cpu-allocatable-raw node-cpu-capacity-raw node-memory-allocatable-raw node-memory-capacity-raw |
CPU 消費量を測定したいので、“node-capacity-cpu-cores” と “node-cpu-capacity-raw” の 2 つの rds に注目します。ここでは node-capacity-cpu-cores に焦点を当て、次のコマンドを実行して Prometheus からデータをどのように収集しているかを確認します。
$ oc get reportdatasource/node-capacity-cpu-cores -o yaml spec: prometheusMetricsImporter: query: | kube_node_status_capacity_cpu_cores * on(node) group_left(provider_id) max(kube_node_info) by (node, provider_id) |
Prometheus からデータをフェッチし、Presto テーブルに保存するために使用される Prometheus クエリを確認できます。OpenShift のメトリクスコンソールで同じクエリを実行し、結果を見てみましょう。2 つのワーカーノード (各ノードは 16 コア) と 3 つのマスターノード (各ノードは 8 コア) を持つ OpenShift クラスタがあります。最後の列の “value” には、ノードに割り当てられたコアの数が記録されます。

データが収集され、Presto テーブルに保存されます。では、いくつかの ReportQuery (rq) カスタムリソースに着目してみましょう。
$ oc project openshift-metering $ oc get reportqueries | grep node-cpu node-cpu-allocatable node-cpu-allocatable-raw node-cpu-capacity node-cpu-capacity-raw node-cpu-utilization |
ここでは “node-cpu-capacity” と “node-cpu-capacity-raw” の rq に焦点を当てます。これらの rq を確認すると、それらによってデータが計算され (ノードの稼働時間や割り当てられている CPU 数など)、データが集約されていることを把握できます。
実際、次の図は 2 つの rds と 2 つの rq がどのように接続されているかのチェーンを示しています。
node-cpu-capacity (rq) > (使用) > node-cpu-capacity-raw (rds) > (使用) > node-cpu-capacity-raw (rq) > (使用) > node-capacity-cpu-cores (rds)
レポートのカスタマイズ
カスタマイズした rds と rq の作成を見ていきましょう。まず、Prometheus クエリを変更して、ノードがマスターとワーカーのいずれとして機能しているかを含め、さらにノードが属するチームを識別する適切なノードラベルを追加する必要があります。ノードのロール (マスターまたはワーカー) に関するデータは、Prometheus の “kube_node_role” メトリクスにあります。“role” 列を参照してください。

Prometheus の “kube_node_labels” メトリクスは、ノードに適用されたすべてのラベルをキャプチャします。ラベルはすべて “label_

ここで必要なのは、この追加の Prometheus クエリを使用して元のクエリを変更し、関連するデータを取得できるようにすることだけです。このクエリは次のようになります。
((kube_node_status_capacity_cpu_cores * on(node) group_left(provider_id) max(kube_node_info) by (node, provider_id)) * on(node) group_left (role) kube_node_role{role='worker'}) * on(node) group_right(provider_id, role) kube_node_labels
OpenShift のメトリクスコンソールでこのクエリを実行し、ラベル (node_lob) とロールの両方の情報が取得されていることを確認しましょう。以下では、出力として label_node_lob とロールが含まれています (クエリによって出力される列の数が多いのでロール情報は表示されていませんが、ロール情報はキャプチャされます)。

そこで、4 つのカスタムリソースを作成します。簡単に確認できるよう、カスタムリソースはダウンロードできるようにしておきました。
- rds-custom-node-capacity-cpu-cores.yaml:Prometheus クエリを定義します
- rq-custom-node-cpu-capacity-raw.yaml:上記の rds を参照し、生データを計算します
- rds-custom-node-cpu-capacity-raw.yaml:上記の rq を参照し、Presto にビューを作成します
- rq-custom-node-cpu-capacity-with-cpus-labels.yaml:上記 3 に記載されている rds を参照し、入力の開始と終了のデータに基づいてデータを計算します。また、これは role および node_label 列を取得するファイルです
これらの yaml ファイルを作成したら、openshift-metering プロジェクトに移動し、次のコマンドを実行します。
$ oc project openshift-metering $ oc create -f rds-custom-node-capacity-cpu-cores.yaml $ oc create -f rq-custom-node-cpu-capacity-raw.yaml $ oc create -f rds-custom-node-cpu-capacity-raw.yaml $ oc create -f rq-custom-node-cpu-capacity-with-cpus-labels.yaml |
最後に、上記で作成した最後の rq オブジェクトを参照する Report カスタムオブジェクトを作成します。以下に例を示します。以下のレポートはすぐに実行され、9 月 15 日から 30 日までのデータが表示されます。
$ cat report_immediate.yaml apiVersion: metering.openshift.io/v1 kind: Report metadata: name: custom-role-node-cpu-capacity-lables-immediate namespace: openshift-metering spec: query: custom-role-node-cpu-capacity-labels reportingStart: "2020-09-15T00:00:00Z" reportingEnd: "2020-09-30T00:00:00Z" runImmediately: true
$ oc create -f report-immediate.yaml |
このレポートを実行したら、以下の URL からファイル (CSV または JSON) をダウンロードできます (DOMAIN_NAME 部分は適宜変更してください)。
以下の CSV のスナップショットは取得されたデータを示したもので、role 列と node_lob 列の両方が含まれていることがわかります。ノードの実行時間 (秒) を計算するには、列 “node_capacity_cpu_core_seconds” を “node_capacity_cpu_cores” で割ります。

まとめ
Metering Operator はとても便利で、OpenShift クラスタが実行されている場所であればどこでも実行できます。拡張可能なフレームワークを提供するので、お客様は独自のカスタムリソースを作成して、ニーズに応じたレポートを作成できます。上記で使用されているコードはすべて、こちらで公開されています。
執筆者紹介
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
オリジナル番組
エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー