3.8.3　Kubernetesコントロールプレーンでの作業

〈この項の構成〉

(1)　各種資材の配置
(2)　Namespaceの作成
(3)　TP1-Bridge、MediatorのgRPC通信機能の暗号化通信用シークレットの作成
(4)　MediatorのConsensusLogの永続ボリュームおよびストレージクラスのデプロイ
(5)　EADSの永続ボリュームのデプロイ（通常版限定）
(6)　Elasticsearchのelasticユーザパスワード用シークレットの作成
(7)　ElasticsearchのTLS通信用シークレットの作成
(8)　Elasticsearchデータディレクトリの永続ボリュームおよびストレージクラスのデプロイ
(9)　Elasticsearchリポジトリディレクトリの永続ボリュームおよびストレージクラスのデプロイ
(10)　デプロイ依存関係チェック機能用ロールおよびロールバインディングのデプロイ
(11)　コンテナログ収集用ロールおよびロールバインディングのデプロイ
(12)　メトリクス収集用ロールおよびロールバインディングのデプロイ
(13)　メトリクス向けKubernetesメタデータ付与用ロールおよびロールバインディングのデプロイ
(14)　uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のデプロイ（通常版限定）
(15)　Kubernetesアプリケーションのデプロイ
(16)　Elasticsearchのスナップショットリポジトリの作成およびスナップショットライフサイクルポリシーの作成
(17)　Elasticsearchのindex設定変更および削除
(18)　EADSのセットアップ（通常版限定）
(19)　EADSのアンセットアップ（通常版限定）
(20)　Kubernetesアプリケーションのアンデプロイ

(1)　各種資材の配置

Kubernetesコントロールプレーンの任意のパスへ、次の各種資材を配置してください。

表3‒15　Kubernetesコントロールプレーンに配置する資材の一覧
資材	備考
MediatorのConsensusLogの永続ボリュームおよびストレージクラスのKubernetesマニフェスト	「3.6.2　MediatorのConsensusLogの永続ボリュームおよびストレージクラスのKubernetesマニフェストの作成」で作成したもの
MediatorのHelmチャートパッケージファイル(mediator-V.R.S.tgz)	HMP-PCTO提供物
MediatorのHelmチャートのvalues.yaml	「3.7.3　MediatorのHelmチャートのカスタマイズ」でカスタマイズしたもの
TP1-BridgeのHelmチャートパッケージファイル（tp1-bridge-V.R.S.tgz）	HMP-PCTO提供物通常版の場合で、TP1-Bridgeを使用するときだけ配置します。
TP1-BridgeのHelmチャートのvalues.yaml	「3.7.4　TP1-BridgeのHelmチャートのカスタマイズ（通常版かつTP1-Bridge限定）」でカスタマイズしたもの通常版の場合で、TP1-Bridgeを使用するときだけ配置します。
EADSの永続ボリュームのKubernetesマニフェスト	「3.6.5　EADSの永続ボリュームのKubernetesマニフェストの作成（通常版限定）」で作成したもの通常版の場合だけ配置します。
EADSのHelmチャートパッケージファイル(eads-service-chart.tgz、eads-server-chart.tgz、eads-command-job-chart.tgz、eads-command-cronjob-chart.tgz)	EADS提供物
EADSのHelmチャートのvalues.yaml	「3.7.5　EADSのHelmチャートのカスタマイズ（通常版限定）」でカスタマイズしたもの
Ext-ConsのHelmチャートパッケージファイル(ext-cons-V.R.S.tgz)	HMP-PCTO提供物
Ext-ConsのHelmチャートのvalues.yaml	「3.7.6　Ext-ConsのHelmチャートのカスタマイズ（トライアル版限定）」でカスタマイズしたもの
FilebeatのHelmチャートのパッケージファイル(filebeat-V.R.S.tgz)	HMP-PCTO提供物
FilebeatのHelmチャートのvalues.yaml	「3.7.7　FilebeatのHelmチャートのカスタマイズ」でカスタマイズしたもの
Jaeger-queryのHelmチャートのパッケージファイル(jaeger-query-V.R.S.tgz)	HMP-PCTO提供物
Jaeger-queryのHelmチャートのvalues.yaml	「3.7.8　Jaeger-queryのHelmチャートのカスタマイズ」でカスタマイズしたもの
Jaeger-collectorのHelmチャートのパッケージファイル(jaeger-collector-V.R.S.tgz)	HMP-PCTO提供物
Jaeger-collectorのHelmチャートのvalues.yaml	「3.7.9　Jaeger-collectorのHelmチャートのカスタマイズ」でカスタマイズしたもの
PrometheusのHelmチャートのパッケージファイル(prometheus-V.R.S.tgz)	HMP-PCTO提供物
PrometheusのHelmチャートのvalues.yaml	「3.7.10　PrometheusのHelmチャートのカスタマイズ」でカスタマイズしたもの
MetricbeatのHelmチャートのパッケージファイル(metricbeat-V.R.S.tgz)	HMP-PCTO提供物
MetricbeatのHelmチャートのvalues.yaml	「3.7.11　MetricbeatのHelmチャートのカスタマイズ」でカスタマイズしたもの
Elasticsearchデータディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェスト	「3.6.3　Elasticsearchデータディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェストの作成」で作成したもの
Elasticsearchリポジトリディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェスト	「3.6.4　Elasticsearchリポジトリディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェストの作成」で作成したもの
ElasticsearchのHelmチャートのパッケージファイル(elasticsearch-V.R.S.tgz)	HMP-PCTO提供物
ElasticsearchのHelmチャートのvalues.yaml	「3.7.12　ElasticsearchのHelmチャートのカスタマイズ」でカスタマイズしたもの
LogstashのHelmチャートのパッケージファイル(logstash-V.R.S.tgz)	HMP-PCTO提供物
LogstashのHelmチャートのvalues.yaml	「3.7.13　LogstashのHelmチャートのカスタマイズ」でカスタマイズしたもの
デプロイ依存関係チェック機能用ロールおよびロールバインディングのKubernetesマニフェスト	「3.6.6　デプロイ依存関係チェック機能用ロールおよびロールバインディングのKubernetesマニフェストの作成」で作成したもの次のどちらかのKubernetesアプリケーションをデプロイするための作業時に配置します。ユーザ責務のKubernetesアプリケーション HMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーション
コンテナログ収集用ロールおよびロールバインディングのKubernetesマニフェスト	「3.6.7　コンテナログ収集用ロールおよびロールバインディングのKubernetesマニフェストの作成」で作成したもの
メトリクス収集用ロールおよびロールバインディングのKubernetesマニフェスト	「3.6.8　メトリクス収集用ロールおよびロールバインディングのKubernetesマニフェストの作成」で作成したもの
メトリクス向けKubernetesメタデータ付与用ロールおよびロールバインディングのKubernetesマニフェスト	「3.6.9　メトリクス向けKubernetesメタデータ付与用ロールおよびロールバインディングのKubernetesマニフェストの作成」で作成したもの
uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のKubernetesマニフェスト	「3.6.10　uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のKubernetesマニフェストの作成（通常版限定）」で作成したもの次のどちらかのKubernetesアプリケーションをデプロイするための作業時に配置します。ユーザ責務のKubernetesアプリケーション HMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーション

ページの先頭へ

(2)　Namespaceの作成

HMP-PCTOのKubernetesアプリケーションをデプロイするNamespaceを作成してください。この作業は、次のどちらかのKubernetesアプリケーションをデプロイするための作業時に実施します。

ユーザ責務のKubernetesアプリケーション
HMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーション

Namespaceの名称は任意です。また、Namespaceは、1つでも、複数のNamespaceに分けても、各Kubernetesアプリケーションをデプロイできます。Namespaceの設計・運用はユーザの要件に応じて対応してください。

ただし、RASのKubernetesアプリケーションの場合、デプロイするNamespaceは同一にする必要があります。RASのKubernetesアプリケーションについては、「1.1　HMP-PCTOのKubernetesアプリケーションの一覧と分類」の「表1‒1　HMP-PCTOのKubernetesアプリケーションの一覧と分類」を参照してください。

なお、ここで示すコマンド実行例やKubernetesマニフェスト記述例は、1つのNamespaceで運用するケースで説明しています。

HMP-PCTOのKubernetesアプリケーションをデプロイするNamespaceを「my-namespace」としたときのコマンド例を示します。

kubectl create namespace my-namespace

＜コマンドの実行結果の例＞

namespace/my-namespace created

このように、各Kubernetesオブジェクトの作成に成功したメッセージが出力されていることを確認してください。

ページの先頭へ

(3)　TP1-Bridge、MediatorのgRPC通信機能の暗号化通信用シークレットの作成

HMP-PCTOのgRPC通信機能で暗号化通信をする場合だけ実施します。

Kubernetesコントロールプレーンの任意のパスへ、次のとおりHMP-PCTOのgRPC通信機能の暗号化通信に必要なファイルを準備してください。なお、Participant（TP1-Bridge）の場合、TP1-Bridgeのアプリケーションの数だけ準備してください。

表3‒16　HMP-PCTOのgRPC通信機能の暗号化通信に必要なファイルの一覧
ファイル	備考
接続先サーバのサーバ証明書を発行したCAの証明書(PEM形式)ファイル	必ず準備します。
自サーバ証明書（PEM形式）ファイル	必ず準備します。
自サーバ証明書を作成した秘密鍵ファイル	必ず準備します。
自クライアント証明書ファイル（PEM形式）	クライアント認証を行う場合だけ準備します。
自クライアント証明書を作成した秘密鍵ファイル	クライアント認証を行う場合だけ準備します。
接続元クライアント（Orchestrator、Participant）の秘密鍵が格納されているキーストア（pkcs12、またはJKS）ファイル	クライアント認証を行う場合だけ準備します。

HMP-PCTOのgRPC通信機能の暗号化通信に必要なファイルを準備したディレクトリ/ファイル構成の例を次に示します。

クライアント認証を行わない場合

<任意のパス>/
    ca.crt              # 接続先サーバのサーバ証明書を発行したCAの証明書(PEM形式)ファイル
    participant/
        server.crt      # Participantの自サーバ証明書(PEM形式)ファイル
        server.key      # Participantの自サーバ証明書を作成した秘密鍵ファイル
    mediator/
        server.crt      # Mediatorの自サーバ証明書(PEM形式)ファイル
        server.key      # Mediatorの自サーバ証明書を作成した秘密鍵ファイル

クライアント認証を行う場合

<任意のパス>/
    ca.crt              # 接続先サーバのサーバ証明書を発行したCAの証明書(PEM形式)ファイル
    participant/
        server.crt      # Participantの自サーバ証明書(PEM形式)ファイル
        server.key      # Participantの自サーバ証明書を作成した秘密鍵ファイル
        client.crt      # Participantの自クライアント証明書ファイル(PEM形式)
        client.key      # Participantの自クライアント証明書を作成した秘密鍵ファイル
        keystore.jks    # Participantの接続元クライアント(orchestrator,participant)の秘密鍵が格納されている
                        # キーストア(pkcs12またはJKS)ファイル
    mediator/
        server.crt      # Mediatorの自サーバ証明書(PEM形式)ファイル
        server.key      # Mediatorの自サーバ証明書を作成した秘密鍵ファイル
        client.crt      # Mediatorの自クライアント証明書ファイル(PEM形式)
        client.key      # Mediatorの自クライアント証明書を作成した秘密鍵ファイル
        keystore.jks    # Mediatorの接続元クライアント(Orchestrator,Participant)の秘密鍵が格納されている
                        # キーストア(pkcs12またはJKS)ファイル

準備したファイルを使用してTP1-Bridge、MediatorのgRPC通信機能の暗号化通信用シークレットを作成します。

TP1-Bridge、MediatorのgRPC通信機能の暗号化通信用シークレットの作成要領を次に示します。

表3‒17　TP1-Bridge、MediatorのgRPC通信機能の暗号化通信用シークレットの作成要領
キー名	ファイル
ca.crt	接続先サーバのサーバ証明書を発行したCAの証明書（PEM形式）ファイル
server.crt	自サーバ証明書（PEM形式）ファイル
server.key	自サーバ証明書を作成した秘密鍵ファイル
client.crt	自クライアント証明書ファイル（PEM形式）
client.key	自クライアント証明書を作成した秘密鍵ファイル
keystore	接続元クライアント（Orchestrator、Participant）の秘密鍵が格納されているキーストア（pkcs12、またはJKS）ファイル
keystore_password	キーストアファイルのパスワード

TP1-Bridge、MediatorのgRPC通信機能の暗号化通信用シークレットを作成するコマンド例を次に示します。

TP1-Bridgeシークレット名：「participant-secret」
Mediator用シークレット名：「mediator-secret」
HMP-PCTOのKubernetesアプリケーションをデプロイするNamespace：「my-namespace」

クライアント認証を行わない場合

kubectl create secret generic --save-config participant-secret \
  --from-file=ca.crt=./ca.crt \
  --from-file=server.crt=./participant/server.crt \
  --from-file=server.key=./participant/server.key \
  -n my-namespace
 
kubectl create secret generic --save-config mediator-secret \
  --from-file=ca.crt=./ca.crt \
  --from-file=server.crt=./mediator/server.crt \
  --from-file=server.key=./mediator/server.key \
  -n my-namespace

クライアント認証を行う場合

kubectl create secret generic --save-config participant-secret \
  --from-file=ca.crt=./ca.crt \
  --from-file=server.crt=./participant/server.crt \
  --from-file=server.key=./participant/server.key \
  --from-file=client.crt=./participant/client.crt \
  --from-file=client.key=./participant/client.key \
  --from-file=keystore=./participant/keystore.jks \
  --from-literal=keystore_password=changeit \
  -n my-namespace
 
kubectl create secret generic --save-config mediator-secret \
  --from-file=ca.crt=./ca.crt \
  --from-file=server.crt=./mediator/server.crt \
  --from-file=server.key=./mediator/server.key \
  --from-file=client.crt=./mediator/client.crt \
  --from-file=client.key=./mediator/client.key \
  --from-file=keystore=./mediator/keystore.jks \
  --from-literal=keystore_password=changeit \
  -n my-namespace

＜コマンドの実行結果の例＞

secret/participant-secret created
 
secret/mediator-secret created

このように、Kubernetesオブジェクトの作成に成功したメッセージが出力されていることを確認してください。

ページの先頭へ

(4)　MediatorのConsensusLogの永続ボリュームおよびストレージクラスのデプロイ

「(1)　各種資材の配置」で配置したMediatorのConsensusLogの永続ボリュームおよびストレージクラスのKubernetesマニフェストをデプロイしてください。

コマンド例を次に示します。

kubectl apply -f ./mediator-consensus-log-volume.yaml

この例では、Kubernetesマニフェストのファイル名を「mediator-consensus-log-volume.yaml」としています。また、このファイルには、各Kubernetesマニフェストがすべて1つのファイル内に定義されている例としています。

もし、各Kubernetesマニフェストを別々のファイルで作成している場合は、作成したKubernetesマニフェストのファイルの分だけデプロイのコマンドを実行してください。

＜コマンドの実行結果の例＞

storageclass.storage.k8s.io/mediator-consensus-log created
persistentvolume/mediator-consensus-log-0 created
persistentvolume/mediator-consensus-log-1 created
persistentvolume/mediator-consensus-log-2 created
persistentvolume/mediator-consensus-log-3 created
persistentvolume/mediator-consensus-log-4 created

このように、各Kubernetesオブジェクトの作成に成功したメッセージが出力されていることを確認してください。

MediatorのConsensusLogの永続ボリュームをデプロイしたあと、次のコマンド例のように、MediatorのConsensusLogの永続ボリュームのデプロイが期待どおり成功していること（STATUS列が"Available"になっていること）を確認してください。

kubectl get pv

＜コマンドの実行結果の例＞

[図データ]

上記の例では、MediatorのConsensusLogの永続ボリュームだけを記載しています。実行環境によっては、そのほかに存在する永続ボリュームも一覧に表示されます。

なお、各列に表示される値は実行環境によって異なります。また、kubectlのdescribeサブコマンドを使用すると、各Kubernetesオブジェクトのさらに詳細な情報を参照できます。

ページの先頭へ

(5)　EADSの永続ボリュームのデプロイ（通常版限定）

「(1)　各種資材の配置」で配置したEADSの永続ボリュームのKubernetesマニフェストをデプロイしてください。

コマンド例を次に示します。

kubectl apply -f ./eads-volume.yaml

この例では、EADSの永続ボリュームのKubernetesマニフェストのファイル名を「eads-volume.yaml」としています。また、このファイルには、各Kubernetesマニフェストがすべて1つのファイル内に定義されている例としています。

各Kubernetesマニフェストを別々のファイルで作成している場合は、作成したKubernetesマニフェストのファイルの分だけデプロイのコマンドを実行してください。

＜コマンドの実行結果の例＞

persistentvolume/eads-cache-1 created
persistentvolume/eads-logs-1 created
persistentvolume/eads-store-1 created
persistentvolume/eads-cache-2 created
persistentvolume/eads-logs-2 created
persistentvolume/eads-store-2 created
persistentvolume/eads-cache-3 created
persistentvolume/eads-logs-3 created
persistentvolume/eads-store-3 created

このように、各Kubernetesオブジェクトの作成に成功したメッセージが出力されていることを確認してください。

ページの先頭へ

(6)　Elasticsearchのelasticユーザパスワード用シークレットの作成

Elasticsearchのelasticユーザのパスワードを設定するためのシークレットを作成してください。この作業は、ElasticsearchのTLS通信を行う場合だけ実施します。

次の例でElasticsearchのelasticユーザパスワード用シークレットを作成するコマンド例を示します。

Elasticsearchのelasticユーザパスワード用シークレット名：「user-secret」
elasticユーザパスワード：「password」
HMP-PCTOのKubernetesアプリケーションをデプロイするNamespace：「my-namespace」

echo -n password > ./password
kubectl create secret generic --save-config user-secret --from-file=./password -n my-namespace

ページの先頭へ

(7)　ElasticsearchのTLS通信用シークレットの作成

Kubernetesコントロールプレーンの任意のパスへ、次のとおりElasticsearchのTLS通信に必要なファイルを準備してください。この作業は、ElasticsearchのTLS通信を行う場合だけ実施します。

表3‒18　HMP-PCTOのElasticsearchのTLS通信に必要なファイルの一覧
対象Kubernetesアプリケーション	ファイル	備考
Elasticsearch	Elasticsearchのサーバ証明書を発行したCAの証明書（PEM形式）ファイル	-
	自サーバ証明書（PEM形式）ファイル	拡張属性のExtended Key Usageを使用して、クライアント認証も可能な証明書として作成してください。
	自サーバ証明書を作成した秘密鍵ファイル	-

HMP-PCTOのElasticsearchのTLS通信に必要なファイルを準備したディレクトリ/ファイル構成の例を次に示します。

<任意のパス>/
    ca.crt              # 接続先サーバのサーバ証明書を発行したCAの証明書(PEM形式)ファイル
    elasticsearch/
        elastic.crt      # 自サーバ証明書(PEM形式)ファイル
        elastic.key      # 自サーバ証明書を作成した秘密鍵ファイル

準備したファイルを使用してElasticsearchのTLS通信用シークレットを作成します。

Elasticsearch用シークレット名はelasticsearch-secretで作成してください。

ElasticsearchのTLS通信用シークレットの作成要領を次に示します。

表3‒19　ElasticsearchのTLS通信用シークレットの作成要領
キー名	ファイル
ca.crt	接続先サーバのサーバ証明書を発行したCAの証明書(PEM形式)ファイル
elastic.crt	自サーバ証明書(PEM形式)ファイル
elastic.key	自サーバ証明書を作成した秘密鍵ファイル

ElasticsearchのTLS通信用シークレットを作成するコマンド例を次に示します。

Elasticsearch用シークレット名：「elasticsearch-secret」
HMP-PCTOのKubernetesアプリケーションをデプロイするNamespace：「my-namespace」

kubectl create secret generic --save-config elasticsearch-secret \
  --from-file=ca.crt=./ca.crt \
  --from-file=elastic.crt=./elasticsearch/elastic.crt \
  --from-file=elastic.key=./elasticsearch/elastic.key \
  -n my-namespace

＜コマンドの実行結果の例＞

secret/elasticsearch-secret created

このように、各Kubernetesオブジェクトの作成に成功したメッセージが出力されていることを確認してください。

ページの先頭へ

(8)　Elasticsearchデータディレクトリの永続ボリュームおよびストレージクラスのデプロイ

「(1)　各種資材の配置」で配置したElasticsearchデータディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェストをデプロイしてください。

コマンド例を次に示します。

kubectl apply -f ./elasticsearch-data-volume.yaml

この例では、Kubernetesマニフェストのファイル名を「elasticsearch-data-volume.yaml」としています。また、このファイルには、各Kubernetesマニフェストがすべて1つのファイル内に定義されている例としています。

＜コマンドの実行結果の例＞

storageclass.storage.k8s.io/elasticsearch-data-masternode created
storageclass.storage.k8s.io/elasticsearch-data-datanode created
persistentvolume/elasticsearch-data-masternode-0 created
persistentvolume/elasticsearch-data-masternode-1 created
persistentvolume/elasticsearch-data-masternode-2 created
persistentvolume/elasticsearch-data-datanode-0 created
persistentvolume/elasticsearch-data-datanode-1 created
persistentvolume/elasticsearch-data-datanode-2 created

このように、各Kubernetesオブジェクトの作成に成功したメッセージが出力されていることを確認してください。

Elasticsearchデータディレクトリの永続ボリュームをデプロイしたあと、次のコマンド例のように、Elasticsearchデータディレクトリの永続ボリュームのデプロイが期待どおり成功していること（STATUS列が"Available"になっていること）を確認してください。

kubectl get pv

＜コマンドの実行結果の例＞

[図データ]

上記の例では、Elasticsearchデータディレクトリの永続ボリュームだけを記載しています。実行環境によっては、そのほかに存在する永続ボリュームも一覧に表示されます。

ページの先頭へ

(9)　Elasticsearchリポジトリディレクトリの永続ボリュームおよびストレージクラスのデプロイ

「(1)　各種資材の配置」で配置したElasticsearchリポジトリディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェストをデプロイしてください。

コマンド例を次に示します。

kubectl apply -f ./elasticsearch-repo-volume.yaml

この例では、Kubernetesマニフェストのファイル名を「elasticsearch-repo-volume.yaml」としています。また、このファイルには、各Kubernetesマニフェストがすべて1つのファイル内に定義されている例としています。

＜コマンドの実行結果の例＞

storageclass.storage.k8s.io/elasticsearch-repo created
persistentvolume/elasticsearch-repo-master-0 created
persistentvolume/elasticsearch-repo-master-1 created
persistentvolume/elasticsearch-repo-master-2 created
persistentvolume/elasticsearch-repo-data-0 created
persistentvolume/elasticsearch-repo-data-1 created
persistentvolume/elasticsearch-repo-data-2 created

このように、各Kubernetesオブジェクトの作成に成功したメッセージが出力されていることを確認してください。

Elasticsearchリポジトリディレクトリの永続ボリュームをデプロイしたあと、次のコマンド例のように、Elasticsearchリポジトリディレクトリの永続ボリュームのデプロイが期待どおり成功していること（STATUS列が"Available"になっていること）を確認してください。

kubectl get pv

＜コマンドの実行結果の例＞

[図データ]

上記の例では、Elasticsearchリポジトリディレクトリの永続ボリュームだけを記載しています。実行環境によっては、そのほかに存在する永続ボリュームも一覧に表示されます。

ページの先頭へ

(10)　デプロイ依存関係チェック機能用ロールおよびロールバインディングのデプロイ

「(1)　各種資材の配置」で配置したデプロイ依存関係チェック機能用ロールおよびロールバインディングのKubernetesマニフェストをデプロイしてください。この作業は、ユーザ責務のKubernetesアプリケーション、またはHMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーションのどちらかをデプロイするための作業時に実施します。

コマンド例を次に示します。

kubectl apply -f ./dependency-checker-role.yaml

この例では、Kubernetesマニフェストのファイル名を「dependency-checker-role.yaml」としています。また、このファイルには、各Kubernetesマニフェストがすべて1つのファイル内に定義されている例としています。

＜コマンドの実行結果の例＞

role.rbac.authorization.k8s.io/dependency-checker-role created
rolebinding.rbac.authorization.k8s.io/dependency-checker-role-binding created

このように、各Kubernetesオブジェクトの作成に成功したメッセージが出力されていることを確認してください。

ページの先頭へ

(11)　コンテナログ収集用ロールおよびロールバインディングのデプロイ

「(1)　各種資材の配置」で配置したコンテナログ収集用ロールおよびロールバインディングのKubernetesマニフェストをデプロイしてください。

次にコマンド例を示します。

kubectl apply -f ./filebeat-role.yaml

この例では、Kubernetesマニフェストのファイル名を「filebeat-role.yaml」としています。また、このファイルには、各Kubernetesマニフェストがすべて1つのファイル内に定義されている例としています。

＜コマンドの実行結果の例＞

clusterrole.rbac.authorization.k8s.io/filebeat-role created
clusterrolebinding.rbac.authorization.k8s.io/filebeat-role-binding created

上記のように各Kubernetesオブジェクトの作成に成功した旨のメッセージが出力されていることを確認してください。

ページの先頭へ

(12)　メトリクス収集用ロールおよびロールバインディングのデプロイ

「(1)　各種資材の配置」で配置したメトリクス収集用ロールおよびロールバインディングのKubernetesマニフェストをデプロイしてください。

次にコマンド例を示します。

kubectl apply -f ./prometheus-role.yaml

この例では、Kubernetesマニフェストのファイル名を「prometheus-role.yaml」としています。また、このファイルには、各Kubernetesマニフェストがすべて1つのファイル内に定義されている例としています。

＜コマンドの実行結果の例＞

clusterrole.rbac.authorization.k8s.io/prometheus-role created
clusterrolebinding.rbac.authorization.k8s.io/prometheus-role-binding created

上記のように各Kubernetesオブジェクトの作成に成功した旨のメッセージが出力されていることを確認してください。

ページの先頭へ

(13)　メトリクス向けKubernetesメタデータ付与用ロールおよびロールバインディングのデプロイ

「(1)　各種資材の配置」で配置したメトリクス向けKubernetesメタデータ付与用ロールおよびロールバインディングのKubernetesマニフェストをデプロイしてください。

次にコマンド例を示します。

kubectl apply -f ./metricbeat-role.yaml

この例では、Kubernetesマニフェストのファイル名を「metricbeat-role.yaml」としています。また、このファイルには、各Kubernetesマニフェストがすべて1つのファイル内に定義されている例としています。

＜コマンドの実行結果の例＞

clusterrole.rbac.authorization.k8s.io/metricbeat-role created
clusterrolebinding.rbac.authorization.k8s.io/metricbeat-role-binding created

上記のように各Kubernetesオブジェクトの作成に成功した旨のメッセージが出力されていることを確認してください。

ページの先頭へ

(14)　uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のデプロイ（通常版限定）

「(1)　各種資材の配置」で配置したuCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のKubernetesマニフェストをデプロイしてください。この作業は、ユーザ責務のKubernetesアプリケーション、またはHMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーションのどちらかをデプロイするための作業時に実施します。

次にコマンド例を示します。

kubectl apply -f ./ucars-snapshots.yaml

この例では、Kubernetesマニフェストのファイル名を「ucars-snapshots.yaml」としています。また、このファイルには、各Kubernetesマニフェストがすべて1つのファイル内に定義されている例としています。

＜コマンドの実行結果の例＞

persistentvolume/snapshot-volume created
persistentvolumeclaim/snapshot-volume created

上記のように各Kubernetesオブジェクトの作成に成功した旨のメッセージが出力されていることを確認してください。

uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームをデプロイしたあと、次のコマンド例のように、uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームのデプロイが期待どおり成功していること（STATUS列が"Available"になっていること）を確認してください。

kubectl get pv

＜コマンドの実行結果の例＞

[図データ]

上記の例では、uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームだけを記載しています。実行環境によっては、そのほかに存在する永続ボリュームも一覧に表示されます。

ページの先頭へ

(15)　Kubernetesアプリケーションのデプロイ

「(1)　各種資材の配置」で配置した各KubernetesアプリケーションのKubernetesマニフェストおよびHelmチャートをデプロイしてください。

なお、HMP-PCTOの各Kubernetesアプリケーションは次の順序でデプロイする必要があります。

Elasticsearch
Logstash、Jaeger-query、Jaeger-collector、Prometheus、Metricbeat、Filebeat
Mediator、EADS、Ext-Cons（トライアル版だけ）、Participantが使用するDB/外部サービス
Participant^※
Orchestrator

注※: TP1連携機能を使用する場合、TP1-Bridgeをデプロイする前に、OpenTP1のrapリスナーとrapサーバを起動してください。
上記以外の順序でデプロイした場合: 各Kubernetesアプリケーションの初期化コンテナとして構成しているDependency-Checkerコンテナで、上記のとおり依存するKubernetesアプリケーションが先にデプロイされるまで待機します。待機処理がリトライオーバーし、初期化コンテナが異常終了した場合、Podの状態はCrashLoopBackOffになります。その場合は、Dependency-Checkerコンテナが実行しているデプロイ依存関係チェックスクリプトのエラーメッセージに従い対処してください。

HMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーションは、次のとおりhelmコマンドでデプロイしてください。

helm△install△<リリース名>△<Helmチャートパッケージファイル名>△-f△<values.yamlファイル名>

（凡例）△：半角スペース1文字

<values.yamlファイル名>は、ユーザがカスタマイズしたvalues.yamlファイル名を指定してください。

<リリース名>および<Helmチャートパッケージファイル名>は、次のとおり指定してください。

Elasticsearchをクラスタ構成で構築する場合は、マスターノード用values.yamlを使用してhelmコマンドを実行し、その後データノード用values.yamlを使用してhelmコマンドを実行してください。

表3‒20　helmコマンドに指定するコマンド引数
Kubernetesアプリケーション	リリース名	Helmチャートパッケージファイル名
TP1-Bridge	tp1-bridge<通番> <通番>には、デプロイするtp1-bridgeごとに一意な番号を付与してください。例 tp1-bridgeを10台起動する場合 1台目：tp1-bridge1 2台目：tp1-bridge2 3台目：tp1-bridge3 ： 10台目：tp1-bridge10	tp1-bridge-V.R.S^※2.tgz
Mediator	Mediator	mediator-V.R.S^※2.tgz
Ext-Cons	ext-cons	ext-cons-V.R.S^※2.tgz
Filebeat	filebeat	filebeat-V.R.S^※2.tgz
Jaeger-query	jaeger-query	jaeger-query-V.R.S^※2.tgz
Jaeger-collector	jaeger-collector	jaeger-collector-V.R.S^※2.tgz
Prometheus	prometheus	prometheus-V.R.S^※2.tgz
Metricbeat	metricbeat	metricbeat-V.R.S^※2.tgz
Elasticsearch	クラスタ構成ではない場合： elasticsearch クラスタ構成の場合： elasticsearch-master(マスターノード) elasticsearch-data(データノード)	elasticsearch-V.R.S^※2.tgz
Logstash	logstash	logstash-V.R.S^※2.tgz
eads^※1	eads-service	eads-service-chart.tgz
eads^※1	eads-server	eads-server-chart.tgz

注※1: eads-service-chart.tgz→eads-server-chart.tgzの順番でデプロイしてください。
注※2: V.R.Sは使用するHMP-PCTOのバージョンに合わせて読み替えてください。

Mediatorをデプロイするコマンド例を次に示します。

helm install mediator ./mediator-V.R.S.tgz -f ./mediator-values.yaml

注　V.R.Sは使用するHMP-PCTOのバージョンに合わせて読み替えてください。

＜コマンドの実行結果の例＞

NAME: mediator
LAST DEPLOYED: Thu May 11 12:34:56 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

このように、Helmチャートのインストールに成功したメッセージが出力されていることを確認してください。なお、コマンドの実行結果の中で「NAMESPACE:」部分に出力されるNamespace名は、values.yamlファイルに記述したNamespace名ではなく、このコマンドを実行したKubernetesコントロールプレーンのデフォルトNamespace名が表示されます(上記例では"default")。実際には、values.yamlファイルに記述したNamespace名でKubernetesアプリケーションがデプロイされています。

RASのKubernetesアプリケーションをデプロイしたあと、次のコマンド例のように、各KubernetesアプリケーションがElasticsearchと接続できることを確認してください。

Logstashの確認
```
kubectl -n my-namespace exec -it logstash-7765767b94-25wrc -- curl --cacert /usr/share/logstash/config/certs/ca.crt --key /usr/share/logstash/config/certs/elastic.key --cert /usr/share/logstash/config/certs/elastic.crt -u elastic:password -XGET 'https://elasticsearch-master:9200/_cat/health?v'
```
Namespace名がmy-namespace、LogstashのPod名がlogstash-7765767b94-25wrc、Elasticsearchのelasticユーザパスワードがpasswordの場合の例です。

＜コマンドの実行結果の例＞

上記のようにElasticsearchの状態が示されていることを確認してください。

Metricbeatの確認

kubectl -n my-namespace exec -it metricbeat-dffb85bc6-w5jlc -- metricbeat test output

Namespace名がmy-namespace、LogstashのPod名がmetricbeat-dffb85bc6-w5jlcの場合の例です。

＜コマンドの実行結果の例＞

Defaulted container "metricbeat" out of: metricbeat, dependency-checker (init)
elasticsearch: https://elasticsearch-master:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 10.98.47.178
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: V.R.S^※

注※: V.R.Sは使用するMetricbeatのバージョンに合わせて読み替えてください。

上記のように「talk to server」がOKになっていることを確認してください。

Jaeger-collectorおよびJaeger-query

Jaeger-collectorおよびJaeger-queryの起動の際にElasticsearchとの接続確認が行われます。次のコマンド例のように、各KubernetesアプリケーションのSTATUSが"Running"になっていることを確認してください。
```
kubectl get pods -n my-namespace -o wide
```
＜コマンドの実行結果の例＞

なお、各列に表示される値は実行環境によって異なります。

HMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーションをデプロイしたあと、次のコマンド例のように、各Kubernetesアプリケーションが期待どおり起動していること（STATUS列が"Running"になっていることや、NODE列でPodが意図したワーカーノードに割り当てられていることなど）を確認してください。

kubectl get pods -n my-namespace -o wide

＜コマンドの実行結果の例（SQL-Participantを使用する場合）＞

[図データ]

＜コマンドの実行結果の例（TCC-Participantを使用する場合）＞

[図データ]

なお、各列に表示される値は実行環境によって異なります。また、kubectlのdescribeサブコマンドを使用すると、各Kubernetesオブジェクトの詳細な情報を参照できます。

ページの先頭へ

(16)　Elasticsearchのスナップショットリポジトリの作成およびスナップショットライフサイクルポリシーの作成

Elasticsearchにスナップショットを保存するためのスナップショットリポジトリを設定してください。

REST APIリクエスト

PUT /_snapshot/<repository>
パスパラメタ

<repository>：（必須）リポジトリ名（string）
リクエストボディ

type：リポジトリタイプ。"fs"を指定してください。

settings.location：リポジトリの場所。/usr/share/elasticsearch/repository/<リポジトリ名>を指定してください。

コマンド例を次に示します（Elasticsearchのhttp.portが30203の場合）。

curl --cacert ca.crt --key elastic.key --cert elastic.crt -u elastic:password -H "Content-Type: application/json" -XPUT 'https://localhost:30203/_snapshot/backup' -d '{
    "type": "fs",
    "settings": {
        "location": "/usr/share/elasticsearch/repository/backup"
    }
}'

＜コマンドの実行結果の例＞

{"acknowledged":true}

次に示すコマンド例を基にリポジトリが作成できたことを確認してください（Elasticsearchのhttp.portが30203の場合）。

curl --cacert ca.crt --key elastic.key --cert elastic.crt -u elastic:password -XGET 'https://localhost:30203/_snapshot/?pretty'

＜コマンドの実行結果の例＞

{
  "backup" : {
    "type" : "fs",
    "settings" : {
      "location" : "/usr/share/elasticsearch/repository/backup"
    }
  }
}

Elasticsearchのスナップショットライフサイクルポリシーを作成して、リポジトリにスナップショットを定期的に取得するように設定してください。

REST APIリクエスト

PUT /_slm/policy/<snapshot-lifecycle-policy-id>
パスパラメタ

<snapshot-lifecycle-policy-id>：スナップショットライフサイクルポリシーID(string)
リクエストボディ

config.ignore_unavailable：データが破損していた場合の無視の有無。"true"を指定してください。

name：自動的に付与されるスナップショット名（string）。Date math support in index and index alias names | Elasticsearch Guide [7.17] | Elasticを使用して名前を指定できます。

repository：スナップショットの作成先のリポジトリ名。作成したリポジトリ名を指定してください。

schedule：スナップショットを取得するタイミング（cron形式）

コマンド例を次に示します（Elasticsearchのhttp.portが30203の場合）。

curl --cacert ca.crt --key elastic.key --cert elastic.crt -u elastic:password -H "Content-Type: application/json" -XPUT 'https://localhost:30203/_slm/policy/my-policy' -d '{
  "schedule": "0 0 13 * * ?",
  "name": "<snapshot-{now/d}>",
  "repository": "backup",
  "config": {
    "ignore_unavailable": true
  }
}'

＜コマンドの実行結果の例＞

{"acknowledged":true}

次に示すコマンド例を基にスナップショットライフサイクルポリシーが作成できたことを確認してください（Elasticsearchのhttp.portが30203の場合）。

curl --cacert ca.crt --key elastic.key --cert elastic.crt -u elastic:password -XGET 'https://localhost:30203/_slm/policy/?pretty'

＜コマンドの実行結果の例＞

{
  "my-policy" : {
    "version" : 1,
    "modified_date_millis" : 1689140931238,
    "policy" : {
      "name" : "<snapshot-{now/d}>",
      "schedule" : "0 0 13 * * ?",
      "repository" : "backup",
      "config" : {
        "ignore_unavailable" : true
      }
    },
    "next_execution_millis" : 1689166800000,
    "stats" : {
      "policy" : "my-policy",
      "snapshots_taken" : 0,
      "snapshots_failed" : 0,
      "snapshots_deleted" : 0,
      "snapshot_deletion_failures" : 0
    }
  }
}

ページの先頭へ

(17)　Elasticsearchのindex設定変更および削除

HMP-PCTOがElasticsearchに出力する情報はindexとして格納されます。これらのindexには、次のライフサイクルが設定されています。

表3‒21　Elasticsearchのindexのライフサイクルポリシー
項番	Elasticsearchのindex名のプレフィックス	indexのライフサイクルポリシー
項番	Elasticsearchのindex名のプレフィックス	Elasticsearch ILMポリシー名	ポリシーの内容
1	「logstash」	「logstash-policy」	Elasticsearch ILMによって、次のポリシーが設定されます。作成されてから30日が経過したとき、または50Gバイトを超えたときに、indexがロールオーバーされ、新たなindexが作成されて使用される。indexは自動的に削除されない。
2	「jaeger」	（なし）	作成されてから1日が経過したときに、indexがロールオーバーされ、新たなindexが作成されて使用される。indexは自動的に削除されない。
3	「metricbeat」	「metricbeat」	Elasticsearch ILMによって、次のポリシーが設定されます。作成されてから30日が経過したとき、または50Gバイトを超えたときに、indexがロールオーバーされ、新たなindexが作成されて使用される。indexは自動的に削除されない。

(a)　情報の確認方法

indexの一覧とボリューム使用量を確認する方法を次に示します。

Kubernetesコントロールプレーン上で、REST APIのGETメソッドを使用して、「IPアドレス:ポート番号/」のあとに「_cat/indices」を指定することでindexの一覧とボリューム使用量が表示されます。

次にコマンド例を示します（Elasticsearchのhttp.portが30202の場合）。

# curl -XGET 'localhost:30202/_cat/indices?v&s=index'

＜コマンドの実行結果の例＞

[図データ]

(b)　情報のロールオーバー設定の変更方法

標準出力の情報およびメトリクスの情報は、それぞれ「logstash-policy」「metricbeat」という名前のElasticsearch ILMポリシーが設定されています。これらのILMポリシーにはロールオーバーする日数・上限サイズがあらかじめ設定されています。

まず、現在のILMポリシーの内容を確認します。

Kubernetesコントロールプレーン上で、REST APIのGETメソッドを使用して、「IPアドレス:ポート番号/_ilm/policy/」のあとにILMポリシー名を指定することで指定したILMポリシーを表示できます。

次にコマンド例を示します（Elasticsearchのhttp.portが30202の場合）。

# curl -XGET 'localhost:30202/_ilm/policy/logstash-policy?pretty'

＜コマンドの実行結果の例＞

{
  "logstash-policy" : {
(略)
    "policy" : {
      "phases" : {
        "hot" : {
          "min_age" : "0ms",
          "actions" : {
            "rollover" : {
              "max_size" : "50gb", …1
              "max_age" : "30d"
            }
          }
        }
      }
    },
(略)
  }
}

記述例の番号は、説明の番号と対応しています。

＜説明＞

ロールオーバーする上限のindexのサイズ(max_size)および日数(max_age)

上記の「policy」で表示されたポリシーのうち、変更したい部分だけを置き換えて、他の部分は表示された値のままで設定します。Kubernetesコントロールプレーン上で、REST APIのPUTメソッドを使用して、「IPアドレス:ポート番号/_ilm/policy/」のあとにILMポリシー名を指定し、後続に「policy」配下の設定をすべて記載することで、ILMポリシーの値を変更できます。

重要

ILMポリシー変更時の注意事項

必ずILMポリシーの「policy」以下のうち、変更したい部分だけを置き換えて、他の部分は表示された値をそのまま設定してください。もし他の部分を記載しなかった場合、記載しなかった部分は以前の設定から消えてしまいます。
バージョンアップ時の注意事項

HMP-PCTOの関連プログラムのElasticsearch、Jaeger、またはPrometheusをバージョンアップした際、インデックステンプレートが新規に作成されることがあります。カスタマイズしたILMポリシー設定を使用している場合、カスタマイズした設定内容は、新しいインデックステンプレートには反映されません。ILMポリシーを再設定してください。

次に、ロールオーバーする上限のindexのサイズ(max_size)を10Gバイトに、日数(max_age)を1日に変更する場合のコマンド例を示します（Elasticsearchのhttp.portが30202の場合）。

# curl -XPUT 'localhost:30202/_ilm/policy/logstash-policy' \
-H 'Content-Type: application/json; charset=utf-8' \
--data-binary @- << EOF
{
    "policy" : {
      "phases" : {
        "hot" : {
          "min_age" : "0ms",
          "actions" : {
            "rollover" : {
              "max_size" : "10gb",
              "max_age" : "1d"
            }
          }
        }
      }
    }
}
EOF

＜コマンドの実行結果の例＞

{"acknowledged":true}

(c)　情報の削除方法

デフォルトのポリシーでは、Elasticsearchのボリューム使用量が増加し続けるため、不要なindexは削除してください。

indexを削除する方法を次に示します。

■indexを自動的に削除する方法

標準出力の情報およびメトリクスの情報は、それぞれ「logstash-policy」「metricbeat」という名前のElasticsearch ILMポリシーが設定されています。これらのILMポリシーに対して、削除のポリシーを追加します。

分散トレースの情報はElasticsearch ILMポリシーが設定されていないため、削除を実施するILMポリシーの設定と、ILMポリシーを適用するための設定を行います。

Logstash、Metricbeatのindexを自動的に削除する方法

まず、現在のILMポリシーの内容を確認します（確認の方法は「(2)情報のロールオーバー設定の変更方法」をご覧ください）。

自動的に削除するためには、ILMポリシーの「policy.phases」に「delete」配下を追加し、deleteの「min_age」に、削除するまでに保持する日数を記載します。そのほかの部分は上記の確認結果で表示された値のままで設定します。

Kubernetesコントロールプレーン上で、REST APIのPUTメソッドを使用して、「IPアドレス:ポート番号/_ilm/policy/」のあとにILMポリシー名を指定し、後続に「policy」配下の設定をすべて記載することで、ILMポリシーの値を変更できます。

重要

ILMポリシー変更時の注意事項

必ずILMポリシーの「policy」以下のうち、変更したい部分だけを置き換えて、他の部分は表示された値をそのまま設定してください。もし他の部分を記載しなかった場合、記載しなかった部分は以前の設定から消えてしまいます。
バージョンアップ時の注意事項

HMP-PCTOの関連プログラムのElasticsearch、Jaeger、またはPrometheusをバージョンアップした際、インデックステンプレートが新規に作成されることがあります。カスタマイズしたILMポリシー設定を使用している場合、カスタマイズした設定内容は、新しいインデックステンプレートには反映されません。ILMポリシーを再設定してください。

次に、「policy.phases」に7日経過したらindexを削除する場合のコマンド例を示します（Elasticsearchのhttp.portが30202の場合）。

# curl -XPUT 'localhost:30202/_ilm/policy/logstash-policy' \
-H 'Content-Type: application/json; charset=utf-8' \
--data-binary @- << EOF
{
    "policy" : {
      "phases" : {
        "hot" : {
          "min_age" : "0ms",
          "actions" : {
            "rollover" : {
              "max_size" : "10gb",
              "max_age" : "1d"
            }
          }
        },
        "delete" : {
          "min_age" : "7d",
          "actions" : {
            "delete" : {}
          }
        }
      }
    }
}
EOF

＜コマンドの実行結果の例＞

{"acknowledged":true}

jaegerのindexを自動的に削除する方法

分散トレースの情報はElasticsearch ILMポリシーが設定されていません。そのため、次の(i)(ii)の操作が必要になります。

(i)分散トレースのILMポリシーの追加

自動的に削除するためには、ILMポリシーの「policy.phases」配下に「hot」と「delete」配下を追加し、deleteの「min_age」に、削除するまでに保持する日数を記載します（「hot」の「min_age」には即時反映を示す0msを指定します）。

Kubernetesコントロールプレーン上で、REST APIのPUTメソッドを使用して、「IPアドレス:ポート番号/_ilm/policy/」のあとにILMポリシー名「jaeger-ilm-policy」を指定し、後続に「policy」配下の設定をすべて記載することで、ILMポリシーを作成できます。

次に、「policy.phases」に7日経過したらindexを削除する場合のコマンド例を示します（Elasticsearchのhttp.portが30202の場合）。

# curl -XPUT 'localhost:30202/_ilm/policy/jaeger-ilm-policy' \
-H 'Content-Type: application/json; charset=utf-8' \
--data-binary @- << EOF
{
    "policy" : {
      "phases" : {
        "hot" : {
          "min_age" : "0ms",
          "actions" : {
          }
        },
        "delete" : {
          "min_age" : "7d",
          "actions" : {
            "delete" : {}
          }
        }
      }
    }
}
EOF

＜コマンドの実行結果の例＞

{"acknowledged":true}

(ii)分散トレースのindexのテンプレートの更新

新規に作成される分散トレースのindexに上記(i)で作成したILMポリシーを反映させるため、分散トレースの2つのindexテンプレート「jaeger-jaeger-service」「jaeger-jaeger-span」それぞれの設定に、(i)のILMポリシーを追加します。

まず、現在のindexテンプレートの内容を確認します。

Kubernetesコントロールプレーン上で、REST APIのGETメソッドを使用して、「IPアドレス:ポート番号/_template/」のあとにテンプレート名を指定することで指定したindexテンプレートを表示できます。

次にテンプレート名「jaeger-jaeger-service」を指定した場合のコマンド例を示します（Elasticsearchのhttp.portが30202の場合）。

# curl -XGET 'localhost:30202/_template/jaeger-jaeger-service?pretty'

＜コマンドの実行結果の例＞

{
  "jaeger-jaeger-service" : {
    "order" : 0,
    "index_patterns" : [
      "jaeger-jaeger-service-*"
    ],
    "settings" : {
      "index" : {
        "mapping" : {
          "nested_fields" : {
            "limit" : "50"
          }
        },
        "requests" : {
          "cache" : {
            "enable" : "true"
          }
        },
        "number_of_shards" : "5",
        "number_of_replicas" : "1"
      }
    },
    "mappings" : {
      "dynamic_templates" : [
        {
          "span_tags_map" : {
            "path_match" : "tag.*",
            "mapping" : {
              "ignore_above" : 256,
              "type" : "keyword"
            }
          }
        },
        {
          "process_tags_map" : {
            "path_match" : "process.tag.*",
            "mapping" : {
              "ignore_above" : 256,
              "type" : "keyword"
            }
          }
        }
      ],
      "properties" : {
        "operationName" : {
          "ignore_above" : 256,
          "type" : "keyword"
        },
        "serviceName" : {
          "ignore_above" : 256,
          "type" : "keyword"
        }
      }
    },
    "aliases" : { }
  }
}

indexテンプレートにILMポリシーを適用するためには、「settings.index」に「lifecycle」配下を追加し、「lifecycle.name」にILMポリシー名を記載します。そのほかの部分は上記の確認結果で表示された値のままで設定します。

Kubernetesコントロールプレーン上で、REST APIのPUTメソッドを使用して、「IPアドレス:ポート番号/_template/」のあとにindexテンプレート名を指定し、後続に「index_patterns」「settings」「mappings」「aliases」の設定をすべて記載することで、ILMポリシーを適用できます。

重要

indexテンプレート変更時の注意事項

必ず「settings.index」に「lifecycle」配下を追加し、他の部分は表示された値をそのまま設定してください。もし他の部分を記載しなかった場合、記載しなかった部分は以前の設定から消えてしまいます。

次に、indexテンプレート「jaeger-jaeger-service」にILMポリシー「jaeger-ilm-policy」を適用する場合のコマンド例を示します（Elasticsearchのhttp.portが30202の場合）。

# curl -XPUT 'localhost:30202/_template/jaeger-jaeger-service' \
-H 'Content-Type: application/json; charset=utf-8' \
--data-binary @- << EOF
{
    "index_patterns" : [
      "jaeger-jaeger-service-*"
    ],
    "settings" : {
      "index" : {
        "lifecycle" : {
           "name": "jaeger-ilm-policy"
         },
        "mapping" : {
          "nested_fields" : {
            "limit" : "50"
          }
        },
        "requests" : {
          "cache" : {
            "enable" : "true"
          }
        },
        "number_of_shards" : "5",
        "number_of_replicas" : "1"
      }
    },
    "mappings" : {
      "dynamic_templates" : [
        {
          "span_tags_map" : {
            "path_match" : "tag.*",
            "mapping" : {
              "ignore_above" : 256,
              "type" : "keyword"
            }
          }
        },
        {
          "process_tags_map" : {
            "path_match" : "process.tag.*",
            "mapping" : {
              "ignore_above" : 256,
              "type" : "keyword"
            }
          }
        }
      ],
      "properties" : {
        "operationName" : {
          "ignore_above" : 256,
          "type" : "keyword"
        },
        "serviceName" : {
          "ignore_above" : 256,
          "type" : "keyword"
        }
      }
    },
    "aliases" : { }
}
EOF

＜コマンドの実行結果の例＞

{"acknowledged":true}

分散トレースの2つのindexテンプレート「jaeger-jaeger-service」「jaeger-jaeger-span」それぞれに対して、ILMポリシーを適用してください。

■indexを手動で削除する方法

Kubernetesコントロールプレーン上で、REST APIのDELETEメソッドを使用して、「IPアドレス:ポート番号/」のあとに、index名を指定することで指定したindexを削除できます。

jaegerのindexは、同じ日付の名前を持つ「jaeger-jaeger-service XXXX-XX-XX」「jaeger-jaeger-span XXXX-XX-XX」の2種類があるため、同じ日付の名前のindexをペアで削除してください。

次にコマンド例を示します（Elasticsearchのhttp.portが30202の場合）。

# curl -XDELETE 'localhost:30202/metricbeat-X.XX.X-XXXX.XX.XX-XXXXXX'

＜コマンドの実行結果の例＞

{"acknowledged":true}

ページの先頭へ

(18)　EADSのセットアップ（通常版限定）

「(15)　Kubernetesアプリケーションのデプロイ」でEADSをデプロイしたあと、「(1)　各種資材の配置」で配置したEADSのHelmチャートパッケージファイル（eads-command-job-chart.tgzおよびeads-command-cronjob-chart.tgz）とEADSのHelmチャートのvalues.yamlを使用して、EADSをセットアップしてください。

コマンド例を次に示します。なお、初デプロイ時と再デプロイ時（＝eztool createcacheコマンドを1回実行済みでキャッシュ用PV内にファイルが書き込まれている時）で、実行するコマンドは内容が一部異なります。また、コマンド例で強調されている「hmppctoCache」は、EADSのHelmチャートのvalues.yamlの.caches[].nameフィールドに指定した文字列に置き換えてください。

（初デプロイ時）
helm -n my-namespace install eads-command-createcache ./eads-command-job-chart.tgz -f ./eads-values.yaml --set args="createcache hmppctoCache"
kubectl -n my-namespace wait --for=condition=complete job/eads-command-createcache-eads-command-job --timeout=300s
helm -n my-namespace install eads-command-open ./eads-command-job-chart.tgz -f ./eads-values.yaml --set args="open"
kubectl -n my-namespace wait --for=condition=complete job/eads-command-open-eads-command-job --timeout=60s
helm -n my-namespace uninstall eads-command-createcache
helm -n my-namespace uninstall eads-command-open
helm -n my-namespace install eads-command-compaction-0 ./eads-command-cronjob-chart.tgz -f ./eads-values.yaml --set args="compaction",index=0
helm -n my-namespace install eads-command-compaction-1 ./eads-command-cronjob-chart.tgz -f ./eads-values.yaml --set args="compaction",index=1
helm -n my-namespace install eads-command-compaction-2 ./eads-command-cronjob-chart.tgz -f ./eads-values.yaml --set args="compaction",index=2
 
（再デプロイ時）
helm -n my-namespace install eads-command-resume ./eads-command-job-chart.tgz -f ./eads-values.yaml --set args="resume"
kubectl -n my-namespace wait --for=condition=complete job/eads-command-resume-eads-command-job --timeout=300s
helm -n my-namespace install eads-command-open ./eads-command-job-chart.tgz -f ./eads-values.yaml --set args="open"
kubectl -n my-namespace wait --for=condition=complete job/eads-command-open-eads-command-job --timeout=60s
helm -n my-namespace uninstall eads-command-resume
helm -n my-namespace uninstall eads-command-open
helm -n my-namespace install eads-command-compaction-0 ./eads-command-cronjob-chart.tgz -f ./eads-values.yaml --set args="compaction",index=0
helm -n my-namespace install eads-command-compaction-1 ./eads-command-cronjob-chart.tgz -f ./eads-values.yaml --set args="compaction",index=1
helm -n my-namespace install eads-command-compaction-2 ./eads-command-cronjob-chart.tgz -f ./eads-values.yaml --set args="compaction",index=2

この例では、EADSのHelmチャートのvalues.yamlのファイル名を「eads-values.yaml」としています。

＜コマンドの実行結果の例＞

（初デプロイ時）
NAME: eads-command-createcache
LAST DEPLOYED: Tue Jun 27 17:45:45 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
job.batch/eads-command-createcache-eads-command-job condition met
NAME: eads-command-open
LAST DEPLOYED: Tue Jun 27 17:46:30 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
job.batch/eads-command-open-eads-command-job condition met
release "eads-command-createcache" uninstalled
release "eads-command-open" uninstalled
NAME: eads-command-compaction-0
LAST DEPLOYED: Tue Jun 27 17:46:15 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
NAME: eads-command-compaction-1
LAST DEPLOYED: Tue Jun 27 17:46:20 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
NAME: eads-command-compaction-2
LAST DEPLOYED: Tue Jun 27 17:46:25 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
 
（再デプロイ時）
NAME: eads-command-resume
LAST DEPLOYED: Tue Jun 27 17:45:45 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
job.batch/eads-command-resume-eads-command-job condition met
NAME: eads-command-open
LAST DEPLOYED: Tue Jun 27 17:46:30 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
job.batch/eads-command-open-eads-command-job condition met
release "eads-command-resume" uninstalled
release "eads-command-open" uninstalled
NAME: eads-command-compaction-0
LAST DEPLOYED: Tue Jun 27 17:46:15 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
NAME: eads-command-compaction-1
LAST DEPLOYED: Tue Jun 27 17:46:20 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
NAME: eads-command-compaction-2
LAST DEPLOYED: Tue Jun 27 17:46:25 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None

このように、各コマンドが成功したメッセージが出力されていることを確認してください。

ページの先頭へ

(19)　EADSのアンセットアップ（通常版限定）

「(20)　Kubernetesアプリケーションのアンデプロイ」でEADSをアンデプロイする前、「(1)　各種資材の配置」で配置したEADSのHelmチャートパッケージファイル（eads-command-job-chart.tgz）とEADSのHelmチャートのvalues.yamlを使用して、EADSをアンセットアップする手順を説明します。

コマンド例を次に示します。

helm -n my-namespace uninstall eads-command-compaction-0
helm -n my-namespace uninstall eads-command-compaction-1
helm -n my-namespace uninstall eads-command-compaction-2
helm -n my-namespace install eads-command-close ./eads-command-job-chart.tgz -f ./eads-values.yaml --set args="close"
kubectl -n my-namespace wait --for=condition=complete job/eads-command-close-eads-command-job --timeout=60s
helm -n my-namespace uninstall eads-command-close

この例では、EADSのHelmチャートのvalues.yamlファイルのファイル名を「eads-values.yaml」としています。

＜コマンドの実行結果の例＞

release "eads-command-compaction" uninstalled-0
release "eads-command-compaction" uninstalled-1
release "eads-command-compaction" uninstalled-2
NAME: eads-command-close
LAST DEPLOYED: Tue Jun 27 18:46:30 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
job.batch/eads-command-close-eads-command-job condition met
release "eads-command-close" uninstalled

このように、各コマンドが成功したメッセージが出力されていることを確認してください。

ページの先頭へ

(20)　Kubernetesアプリケーションのアンデプロイ

デプロイしたHMP-PCTOの各Kubernetesアプリケーションをアンデプロイする方法について説明します。

なお、HMP-PCTOの各Kubernetesアプリケーションは、次の順序でアンデプロイする必要があります。

Orchestrator
Participant^※
Mediator、EADS、Ext-Cons（トライアル版だけ）、Participantが使用するDB/外部サービス
Logstash、Jaeger-query、Jaeger-collector、Prometheus、Metricbeat、Filebeat
Elasticsearch

注※: TP1連携機能を使用している場合、TP1-Bridgeをアンデプロイしたあとに、OpenTP1のrapリスナーとrapサーバを停止してください。

重要

上記以外の順序でアンデプロイした場合に発生する問題

上記以外の順序でアンデプロイした場合、トラブルシュートに必要な情報が収集できなかったり、処理中のトランザクションが適切に終了しなかったりなどの問題が発生するおそれがあります。

HMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーションは、次のとおりhelmコマンドでアンデプロイしてください。

helm△uninstall△<リリース名>

（凡例）△：半角スペース1文字

<リリース名>は、デプロイ時と同様に指定してください。

Mediatorをアンデプロイするコマンド例を次に示します。

helm uninstall mediator

＜コマンドの実行結果の例＞

release "mediator" uninstalled

このように、Helmチャートのアンインストールに成功したメッセージが出力されていることを確認してください。

HMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーションをアンデプロイしたあと、次のコマンド例のように、各Kubernetesアプリケーションが期待どおり停止していること（一覧に出力されないこと）を確認してください。

kubectl get pods -n my-namespace -o wide

＜コマンドの実行結果の例＞

No resources found in my-namespace namespace.

ページの先頭へ

3.8.3 Kubernetesコントロールプレーンでの作業

(1) 各種資材の配置

(2) Namespaceの作成

(3) TP1-Bridge、MediatorのgRPC通信機能の暗号化通信用シークレットの作成

(4) MediatorのConsensusLogの永続ボリュームおよびストレージクラスのデプロイ

(5) EADSの永続ボリュームのデプロイ（通常版限定）

(6) Elasticsearchのelasticユーザパスワード用シークレットの作成

(7) ElasticsearchのTLS通信用シークレットの作成

(8) Elasticsearchデータディレクトリの永続ボリュームおよびストレージクラスのデプロイ

(9) Elasticsearchリポジトリディレクトリの永続ボリュームおよびストレージクラスのデプロイ

(10) デプロイ依存関係チェック機能用ロールおよびロールバインディングのデプロイ

(11) コンテナログ収集用ロールおよびロールバインディングのデプロイ

(12) メトリクス収集用ロールおよびロールバインディングのデプロイ

(13) メトリクス向けKubernetesメタデータ付与用ロールおよびロールバインディングのデプロイ

(14) uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のデプロイ（通常版限定）

(15) Kubernetesアプリケーションのデプロイ

(16) Elasticsearchのスナップショットリポジトリの作成およびスナップショットライフサイクルポリシーの作成

(17) Elasticsearchのindex設定変更および削除

(a) 情報の確認方法

(b) 情報のロールオーバー設定の変更方法

(c) 情報の削除方法

(18) EADSのセットアップ（通常版限定）

(19) EADSのアンセットアップ（通常版限定）

(20) Kubernetesアプリケーションのアンデプロイ

3.8.3　Kubernetesコントロールプレーンでの作業

(1)　各種資材の配置

(2)　Namespaceの作成

(3)　TP1-Bridge、MediatorのgRPC通信機能の暗号化通信用シークレットの作成

(4)　MediatorのConsensusLogの永続ボリュームおよびストレージクラスのデプロイ

(5)　EADSの永続ボリュームのデプロイ（通常版限定）

(6)　Elasticsearchのelasticユーザパスワード用シークレットの作成

(7)　ElasticsearchのTLS通信用シークレットの作成

(8)　Elasticsearchデータディレクトリの永続ボリュームおよびストレージクラスのデプロイ

(9)　Elasticsearchリポジトリディレクトリの永続ボリュームおよびストレージクラスのデプロイ

(10)　デプロイ依存関係チェック機能用ロールおよびロールバインディングのデプロイ

(11)　コンテナログ収集用ロールおよびロールバインディングのデプロイ

(12)　メトリクス収集用ロールおよびロールバインディングのデプロイ

(13)　メトリクス向けKubernetesメタデータ付与用ロールおよびロールバインディングのデプロイ

(14)　uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のデプロイ（通常版限定）

(15)　Kubernetesアプリケーションのデプロイ

(16)　Elasticsearchのスナップショットリポジトリの作成およびスナップショットライフサイクルポリシーの作成

(17)　Elasticsearchのindex設定変更および削除

(a)　情報の確認方法

(b)　情報のロールオーバー設定の変更方法

(c)　情報の削除方法

(18)　EADSのセットアップ（通常版限定）

(19)　EADSのアンセットアップ（通常版限定）

(20)　Kubernetesアプリケーションのアンデプロイ