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

(1)　各種資材の配置

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

ページの先頭へ

(2)　Namespaceの作成

kubectl create namespace my-namespace

namespace/my-namespace created

oc new-project my-project

Now using project "my-project" on server "https://api.example.openshift.com:6443".
 
You can add applications to this project with the 'new-app' command. For example, try:
 
    oc new-app rails-postgresql-example
 
to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:
 
    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.43 -- /agnhost serve-hostname

ページの先頭へ

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

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

Kubernetesコントロールプレーンの任意のパスへ、次のとおりHMP-PCTOのgRPC通信機能の暗号化通信に必要なファイルを準備してください。

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

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

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

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

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

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

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

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 \
  -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=client.crt=./participant/client.crt \
  --from-file=client.key=./participant/client.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 \
  --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ユーザパスワード用シークレットの作成

この作業は、Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合でElasticsearchのTLS通信を行うときだけ実施します。

Elasticsearchのelasticユーザのパスワードを設定するためのシークレットを作成してください。

次の例で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通信用シークレットの作成

この作業は、Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合でElasticsearchのTLS通信を行うときだけ実施します。

Kubernetesコントロールプレーンの任意のパスへ、次のとおりElasticsearchのTLS通信に必要なファイルを準備してください。

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

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

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

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

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

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データディレクトリの永続ボリュームおよびストレージクラスのデプロイ

Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合は、次の手順を実施してください。

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

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

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

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

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

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

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データディレクトリの永続ボリュームだけを記載しています。実行環境によっては、そのほかに存在する永続ボリュームも一覧に表示されます。

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

ページの先頭へ

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

Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合は、次の手順を実施してください。

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

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

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

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

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

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

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

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

ページの先頭へ

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

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

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

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

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

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

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

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

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

ページの先頭へ

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

Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合は、次の手順を実施してください。

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

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

kubectl apply -f ./filebeat-role.yaml

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

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

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

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

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

ページの先頭へ

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

Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合は、次の手順を実施してください。

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

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

kubectl apply -f ./prometheus-role.yaml

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

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

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

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

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

ページの先頭へ

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

Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合は、次の手順を実施してください。

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

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

kubectl apply -f ./metricbeat-role.yaml

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

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

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

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

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

ページの先頭へ

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

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

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

kubectl apply -f ./ucars-snapshots.yaml

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

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

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

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

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

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

kubectl get pv

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

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

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

ページの先頭へ

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

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

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

1. Elasticsearch^※1

2. Logstash^※1、Jaeger-query^※1、Jaeger-collector^※1、Prometheus^※1、Metricbeat^※1、Filebeat^※1

3. Mediator、EADSサーバ（通常版だけ）^※2、Ext-Cons（トライアル版だけ）、Participantが使用するDB/外部サービス

4. Relay-Service、Entity-Service(TCC)、Entity-Service(SQL)、TP1-Bridge^※3

5. Orchestrator-Service、Orchestrator-Service(SQL)、Alternate-Service、Alternate-Service(SQL)

注※1

これらのKubernetesアプリケーションは、Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合だけデプロイしてください。

注※2

EADSサーバをデプロイしたあとに「(21)　EADSのセットアップ（通常版限定）」を実施してから、Participantの機能を使用するKubernetesアプリケーションをデプロイしてください。

注※3

TP1連携機能を使用する場合、TP1-Bridgeをデプロイする前に、OpenTP1のrapリスナーとrapサーバを起動してください。

メモ

上記以外の順序でデプロイした場合^※

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

そのあとで、EADSサーバとParticipantの機能を使用するKubernetesアプリケーションをアンデプロイして、正しい順序でデプロイし直してください。

注※　「(25)　Kubernetesアプリケーションのアンデプロイ」を実施しないでクラスタを再起動する場合も含みます。

デプロイしたKubernetesアプリケーションの起動に失敗したとき、KubernetesのERRORメッセージが出力されることがあります。詳細については、「(25)　Kubernetesアプリケーションのアンデプロイ」の「Kubernetesアプリケーションの停止時に出力されるKubernetesのERRORメッセージについて」を参照してください。

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

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

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

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

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

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

HMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーションのうち、Prometheusは、ユーザ任意の方法でデプロイしてください。kubectlコマンドでデプロイするコマンド例を次に示します。

kubectl apply -f ./deployment.yaml

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と接続できることを確認してください。この手順はElastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合に実施してください。

• 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のスナップショットリポジトリの作成およびスナップショットライフサイクルポリシーの作成

Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合は、次の手順を実施してください。

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設定変更および削除

Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合は、次の手順を実施してください。

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

■情報の確認方法

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

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

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

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

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

■情報のロールオーバー設定の変更方法

標準出力の情報およびメトリクスの情報は、それぞれ「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"
            }
          }
        }
      }
    },
(略)
  }
}

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

＜説明＞

1. ロールオーバーする上限の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}

■情報の削除方法

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

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

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

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

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

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

まず、現在のILMポリシーの内容を確認します。確認の方法は「■情報のロールオーバー設定の変更方法」を参照してください。

indexを自動的に削除するためには、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)　Azure Monitorの設定

Microsoft Azure環境を使用してトラブルシュート情報を収集する場合は、Azure Monitorの設定をしてください。

HMP-PCTOがAzure Monitorに出力する情報は、Azure Monitorのワークスペースに格納されます。保存量、保持期間、ライフサイクルなどの詳細はAzure Monitorの公式ドキュメントを参照してください。

ページの先頭へ

(19)　Cloud Logging、Cloud TraceおよびCloud Monitoringの設定

Google Cloud Platform環境を使用してトラブルシュート情報を収集する場合は、Cloud Logging、Cloud TraceおよびCloud Monitoringの設定をしてください。

Cloud Logging、Cloud TraceおよびCloud Monitoringの保存量や保存期間の詳細については、Google Cloud Platformの公式ドキュメントを参照してください。

ページの先頭へ

(20)　New Relicの設定

New Relic使用時のトラブルシュート情報の保存量や保持期間の詳細については、New Relicの公式ドキュメントを参照してください。

ページの先頭へ

(21)　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

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

ページの先頭へ

(22)　EADSの生存監視ツールの起動

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

生存監視ツールは、縮退状態のEADSサーバを検知して自動で復旧を実行するツールです。生存監視ツールの詳細については、取扱説明書「EADS コンテナオーケストレーションツール対応機能」を参照してください。

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

helm -n my-namespace install eads-health ./eads-health-cronjob-chart.tgz -f ./eads-values.yaml

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

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

NAME: eads-health
LAST DEPLOYED: Tue Jun 27 17:46:25 2023
NAMESPACE: my-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None

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

ページの先頭へ

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

「(25)　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

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

ページの先頭へ

(24)　EADSの生存監視ツールの停止

「(25)　Kubernetesアプリケーションのアンデプロイ」でEADSをアンデプロイする前、EADSの生存監視ツールを停止してください。

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

helm -n my-namespace uninstall eads-health

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

release "eads-health" uninstalled

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

ページの先頭へ

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

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

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

1. Orchestrator-Service、Orchestrator-Service(SQL)、Alternate-Service、Alternate-Service(SQL)

2. Entity-Service(TCC)、Entity-Service(SQL)、Relay-Service、TP1-Bridge^※1

3. Mediator、EADSサーバ（通常版だけ）、Ext-Cons（トライアル版だけ）、Participantが使用するDB/外部サービス

4. Logstash^※2、Jaeger-query^※2、Jaeger-collector^※2、Prometheus^※2、Metricbeat^※2、Filebeat^※2

5. Elasticsearch^※2

注※1

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

注※2

これらのKubernetesアプリケーションは、Elastic Stack、JaegerおよびPrometheusを使用してトラブルシュート情報を収集する場合だけデプロイしています。

クラスタを停止する前には、上記の順序でアンデプロイしてください。アンデプロイする前にクラスタを停止した場合は、クラスタを再起動したあとに、アンデプロイしてから「(15)　Kubernetesアプリケーションのデプロイ」で示す順序で再デプロイしてください。

重要

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

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

注※　アンデプロイする前にクラスタを停止する場合も含みます。

Kubernetesアプリケーションの停止時に出力されるKubernetesのERRORメッセージについて

Kubernetesアプリケーションの停止時（起動失敗時を含む）に、KubernetesアプリケーションのメッセージログにKubernetesのclientでjava.lang.InterruptedExceptionが発生したことを示すERRORメッセージが出力されることがあります。このメッセージは出力されても問題ないため、無視してください。

ERRORメッセージの出力例の一部を次に示します。

■メッセージ出力例１

ERROR sql-participant-dc47fd869-khlgp pool-13-thread-1 io.kubernetes.client.informer.cache.ProcessorListener 87 processor interrupted: {}

■メッセージ出力例２

ERROR sql-participant-dc47fd869-khlgp informer-controller-V1Endpoints io.kubernetes.client.informer.cache.Controller 87 DefaultController#processLoop get interrupted null

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

helm△uninstall△<リリース名>

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

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

HMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーションのうち、Prometheusはユーザ任意の方法でアンデプロイしてください。

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

kubectl delete -f ./deployment.yaml

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.

ページの先頭へ