第15章

目標

学習目標

• メトリクスサブシステムの アーキテクチャと動作 を説明できるようになる。

• メトリクスサブシステムを インストール できるようになる。

内容

• メトリクスサブシステムのアーキテクチャの説明（およびクイズ）

• メトリクスサブシステムのインストール（およびガイド付き演習）

メトリクスサブシステムのアーキテクチャの説明

目的

メトリクスサブシステムの構成要素

メトリクスサブシステムのアーキテクチャ

メトリクスサブシステムの概要

1. Heapster

• Red Hat OpenShift では、Heapster のストレージエンジンとして Hawkular を使用します。

• Heapster は、Kubernetes コミュニティによって開発され、サードパーティのアプリケーションがクラスタのパフォーマンスデータを取得できるように設計されています。

2. Hawkular Metrics

• Hawkular Metrics は Cassandra をデータストアとして使用します。

• Hawkular は、RHQ プロジェクト（Red Hat JBoss Operations Network の上流プロジェクト）の後継として開発され、Red Hat CloudForms のミドルウェア管理機能の一部を担っています。

3. Hawkular Agent

• アプリケーションは、Hawkular Agent に対して独自のメトリクスを提供できます。

• Hawkular OpenShift Agent（HOSA）は、現在 テクノロジープレビュー機能 であり、デフォルトではインストールされません。Red Hat は、本番環境での使用を推奨していません。

4. Cassandra

メトリクスサブシステムの独立性と必要なコンポーネント

1. OpenShift Web コンソール
• Web コンソールは Hawkular Metrics API を利用し、プロジェクト内の Pod のパフォーマンスグラフを表示します。
• メトリクスサブシステムが導入されていない場合、グラフは表示されません。
• 注意: メトリクス API へのリクエストは、ユーザーの Web ブラウザから直接送信され、OpenShift マスター経由ではありません。

2. oc adm top コマンド
• Heapster API を利用し、クラスタ内の Pod やノードの現在のリソース使用状況を取得します。

3. Kubernetes のオートスケールコントローラー
• Heapster API からデプロイメント内の Pod の現在の状態を取得し、スケーリングの判断を行います。

外部モニタリングシステムとの統合

• 既に 外部のモニタリングシステム を運用している場合、Heapster のみを導入 し、メトリクスの長期保存を外部システムに任せることが可能です。

• もし外部モニタリングシステムがアラート通知やヘルスチェック機能のみを提供している場合、Hawkular API を利用してメトリクスを取得し、アラートを生成することもできます。

Heapster のメトリクス収集とクエリ機能

• ワーキングセット（Working set）
• ノード上のすべてのプロセスが実際に使用しているメモリ量（バイト単位）。

• CPU 使用量（CPU usage）
• ノード上のすべてのプロセスが使用している CPU の量（ミリコア単位）。
• 例: 10 ミリコア = CPU 1% の使用率に相当。

Heapster と Hawkular の利用方法

• Pod のリソース要求（Requests） は、スケジューリング時に考慮されます。

• リソース要求は、ノードの総容量から差し引かれ、ノードの利用可能な容量が決定 されます。

• ただし、実際のリソース使用量はこの計算には影響しません。

oc describe node コマンドの挙動

• OpenShift 3.9 以降、oc describe node コマンドは Pod が宣言したリソース要求のみを表示 します。

• Pod がリソース要求を宣言していない場合、実際の使用量は考慮されません。

• その結果、ノードの空き容量が実際より多く見える可能性があります。

まとめ

• Heapster: メトリクスの収集・集約を行う。

• Hawkular Metrics: メトリクスの保存・取得を行う。

• Hawkular Agent: アプリケーションのカスタムメトリクスを収集する（技術プレビュー）。

• Cassandra: メトリクスを保存するデータベース。

• メトリクスサブシステムを導入すると、Web コンソールのグラフ表示、oc adm top コマンド、オートスケーリングが利用可能になる。

• OpenShift は、外部のモニタリングシステムとの統合にも対応している。

• oc describe node は、リソース要求のみを表示し、実際のリソース使用量は考慮しない。

Web コンソールとノードメトリクスの取得

Web コンソールの表示内容

• Web コンソールは oc describe node コマンドと同じ情報を表示 します。

• Hawkular Metrics から取得した実際のリソース使用量も表示可能 ですが、OpenShift 3.9 では Pod とプロジェクト単位のメトリクスのみを表示 します。

• ノード単位のメトリクスは Web コンソールでは確認できません。

ノードの実際のリソース使用状況を確認する方法

1. oc adm top コマンドを使用（ノードのハードウェア・仮想環境のキャパシティ状況を確認）

2. 詳細な情報が必要な場合 → Linux の標準コマンドを使用（例: vmstat, ps）

3. Heapster API を利用（より詳細なメトリクスの取得が可能）

Heapster API のアクセス方法

Heapster API は外部から直接アクセスできない

• OpenShift は Heapster をクラスタ外部には公開していません。

• Heapster にアクセスするには、OpenShift マスター API プロキシ機能を利用 する必要があります。

• マスター API プロキシは、OpenShift の認証・アクセス制御ポリシーに基づいて動作 します。

Heapster API に curl でアクセスする例

コマンドのポイント

1. OpenShift マスター API プロキシ URL を設定
• openshift-infra ネームスペース内の Heapster サービスへプロキシ経由でアクセス。

2. Heapster API の URL 設定
• サービス名 heapster を URL に含める（ホスト名の代わりにサービス名を使用）。

3. OpenShift ユーザーの認証トークンを取得
• oc whoami -t コマンドでトークン取得（最低限クラスタの読み取り権限が必要）。

4. curl で API にリクエスト送信
• k: SSL 証明書の検証を無効化（必要に応じて）
• H "Authorization: Bearer $TOKEN": 認証トークンをリクエストヘッダーに設定
• ?start=$START: 特定のタイムスタンプ（UTC形式）以降のメトリクスを取得
• 例: 2017-07-27T17:27:37Z（date '+%FT%TZ' コマンドで取得可能）

Hawkular の外部公開に関する注意点

• Hawkular を外部アクセス可能にする場合、セキュリティ上の考慮が必要。

• 詳細は Red Hat OpenShift Container Platform の公式ドキュメント を参照。

他の監視ツールとの統合

• Heapster や Hawkular API の利用が難しい場合、他のオープンソース監視ツール（Nagios、Zabbix など）と統合可能。

• OpenShift のオープンソース版（Origin）や Kubernetes コミュニティでは、これらのツールとの連携を提供。

まとめ

メトリクスサブシステムの適切なサイズ設計

概要

メトリクスサブシステムのスケーリング

• 各コンポーネント（Heapster、Hawkular、Cassandra）はそれぞれ独立したデプロイメントコントローラーを持ち、個別にスケール可能。

• OpenShift クラスタ内のどこにでもデプロイ可能だが、本番環境ではメトリクス用に専用のノードを確保するのが一般的。

• Cassandra と Hawkular は Java アプリケーション であり、大規模なヒープメモリを活用する。
• デフォルト設定は中小規模の OpenShift クラスタ向け に調整済み。
• テスト環境ではメモリ・CPU のデフォルト設定を変更 し、少ないリソースで動作させることも可能。

• Heapster と Hawkular は標準の OpenShift ツールでサイズ変更・スケール調整が可能。
• 数百のノード、数千のプロジェクトのメトリクスを少数の Heapster & Hawkular ポッドで管理できる。

• oc コマンドを使用してリソースの増減やレプリカ数の変更が可能。
• ただし、推奨される設定方法は Ansible の変数を調整すること（次の「インストール」セクションで解説）。

• Cassandra は oc コマンドではスケール不可（データベースはステートレスアプリではないため）。
• Cassandra のスケーリング & 設定は Metrics インストール Playbook を使用。

Cassandra の永続ストレージの確保

• Cassandra は「共有なし（shared-nothing）」のストレージアーキテクチャを採用。
• 各 Cassandra ポッドは専用の永続ボリューム（PV）を使用。

• 高可用性（HA）を実現するには、最低 3 つの Cassandra ポッドが必要。

• 一時ストレージ（ephemeral storage）も利用可能だが、データ消失のリスクあり。
• emptyDir ボリュームタイプはテスト環境向けであり、本番環境には 推奨されない。

• 必要なストレージサイズはクラスタの規模（ノード数 & Pod 数）だけでなく、メトリクスの保存期間 & 解像度にも依存。
• 適切なストレージサイズについては Red Hat の公式ドキュメントを参照。

永続ボリュームの管理

• Metrics インストール Playbook では、静的 or 動的プロビジョニング の永続ボリューム（PV）が利用可能。

• Playbook は 一意のプレフィックス + 連番 を使用して 永続ボリューム要求（PVC）を作成。
• 静的に PV をプロビジョニングする場合は、同じ命名規則を適用することが推奨される。

参考情報 & ドキュメントリンク

• インストール & 設定ガイド
• 公式ドキュメント

• スケーリング & パフォーマンスガイド
• 公式ドキュメント

• Heapster（GitHub）
• Heapster プロジェクト
• Heapster Storage Schema

• Hawkular
• Hawkular プロジェクト

• Apache Cassandra
• Cassandra 公式サイト

• OpenShift Origin（GitHub）
• OpenShift Origin プロジェクト

まとめ