Hitachi

Hitachi Microservices Platform - Paxos Commit Transaction Orchestrator ユーザーズガイド

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

〈この項の構成〉

(1)　各種資材の配置

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

表3‒12　Kubernetesコントロールプレーンに配置する資材の一覧

資材

備考

MediatorのConsensusLogの永続ボリュームおよびストレージクラスのKubernetesマニフェスト

「3.4.2　MediatorのConsensusLogの永続ボリュームおよびストレージクラスのKubernetesマニフェストの作成」で作成したもの

MediatorのHelmチャートパッケージファイル(mediator-V.R.S.tgz)

HMP-PCTO提供物

MediatorのHelmチャートのvalues.yaml

「3.5.2　MediatorのHelmチャートのカスタマイズ」でカスタマイズしたもの

EADSの永続ボリュームのKubernetesマニフェスト

「3.4.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.5.3　EADSのHelmチャートのカスタマイズ（通常版限定）」でカスタマイズしたもの

Ext-ConsのHelmチャートパッケージファイル(ext-cons-V.R.S.tgz)

HMP-PCTO提供物

Ext-ConsのHelmチャートのvalues.yaml

「3.5.4　Ext-ConsのHelmチャートのカスタマイズ（トライアル版限定）」でカスタマイズしたもの

FilebeatのHelmチャートのパッケージファイル(filebeat-V.R.S.tgz)

HMP-PCTO提供物

FilebeatのHelmチャートのvalues.yaml

「3.5.5　FilebeatのHelmチャートのカスタマイズ」でカスタマイズしたもの

Jaeger-queryのHelmチャートのパッケージファイル(jaeger-query-V.R.S.tgz)

HMP-PCTO提供物

Jaeger-queryのHelmチャートのvalues.yaml

「3.5.6　Jaeger-queryのHelmチャートのカスタマイズ」でカスタマイズしたもの

Jaeger-collectorのHelmチャートのパッケージファイル(jaeger-collector-V.R.S.tgz)

HMP-PCTO提供物

Jaeger-collectorのHelmチャートのvalues.yaml

「3.5.7　Jaeger-collectorのHelmチャートのカスタマイズ」でカスタマイズしたもの

PrometheusのHelmチャートのパッケージファイル(prometheus-V.R.S.tgz)

HMP-PCTO提供物

PrometheusのHelmチャートのvalues.yaml

「3.5.8　PrometheusのHelmチャートのカスタマイズ」でカスタマイズしたもの

MetricbeatのHelmチャートのパッケージファイル(metricbeat-V.R.S.tgz)

HMP-PCTO提供物

MetricbeatのHelmチャートのvalues.yaml

「3.5.9　MetricbeatのHelmチャートのカスタマイズ」でカスタマイズしたもの

Elasticsearchデータディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェスト

「3.4.3　Elasticsearchデータディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェストの作成」で作成したもの

Elasticsearchリポジトリディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェスト

「3.4.4　Elasticsearchリポジトリディレクトリの永続ボリュームおよびストレージクラスのKubernetesマニフェストの作成」で作成したもの

ElasticsearchのHelmチャートのパッケージファイル(elasticsearch-V.R.S.tgz)

HMP-PCTO提供物

ElasticsearchのHelmチャートのvalues.yaml

「3.5.10　ElasticsearchのHelmチャートのカスタマイズ」でカスタマイズしたもの

LogstashのHelmチャートのパッケージファイル(logstash-V.R.S.tgz)

HMP-PCTO提供物

LogstashのHelmチャートのvalues.yaml

「3.5.11　LogstashのHelmチャートのカスタマイズ」でカスタマイズしたもの

デプロイ依存関係チェック機能用ロールおよびロールバインディングのKubernetesマニフェスト

「3.4.6　デプロイ依存関係チェック機能用ロールおよびロールバインディングのKubernetesマニフェストの作成」で作成したもの

次のどちらかのKubernetesアプリケーションをデプロイするための作業時に配置します。

  • ユーザ責務のKubernetesアプリケーション

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

コンテナログ収集用ロールおよびロールバインディングのKubernetesマニフェスト

「3.4.7　コンテナログ収集用ロールおよびロールバインディングのKubernetesマニフェストの作成」で作成したもの

メトリクス収集用ロールおよびロールバインディングのKubernetesマニフェスト

「3.4.8　メトリクス収集用ロールおよびロールバインディングのKubernetesマニフェストの作成」で作成したもの

メトリクス向けKubernetesメタデータ付与用ロールおよびロールバインディングのKubernetesマニフェスト

「3.4.9　メトリクス向けKubernetesメタデータ付与用ロールおよびロールバインディングのKubernetesマニフェストの作成」で作成したもの

uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のKubernetesマニフェスト

「3.4.10　uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のKubernetesマニフェストの作成（通常版限定）」で作成したもの

次のどちらかのKubernetesアプリケーションをデプロイするための作業時に配置します。

  • ユーザ責務のKubernetesアプリケーション

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

ページの先頭へ

(2)　Namespaceの作成

HMP-PCTOのKubernetesアプリケーションをデプロイするNamespaceを作成してください。この作業は、次のどちらかの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)　MediatorのgRPC通信機能の暗号化通信用シークレットの作成

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

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

表3‒13　HMP-PCTOのgRPC通信機能の暗号化通信に必要なファイルの一覧

ファイル

備考

接続先サーバのサーバ証明書を発行したCAの証明書(PEM形式)ファイル

必ず準備します。

自サーバ証明書（PEM形式）ファイル

必ず準備します。

自サーバ証明書を作成した秘密鍵ファイル

必ず準備します。

自クライアント証明書ファイル（PEM形式）

クライアント認証を行う場合だけ準備します。

自クライアント証明書を作成した秘密鍵ファイル

クライアント認証を行う場合だけ準備します。

接続元クライアント（Orchestrator、Participant）)の秘密鍵が格納されているキーストア（pkcs12、またはJKS）ファイル

クライアント認証を行う場合だけ準備します。

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

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

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

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

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

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

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

表3‒14　MediatorのgRPC通信機能の暗号化通信用シークレットの作成要領

キー名

ファイル

ca.crt

接続先サーバのサーバ証明書を発行したCAの証明書（PEM形式）ファイル

server.crt

自サーバ証明書（PEM形式）ファイル

server.key

自サーバ証明書を作成した秘密鍵ファイル

client.crt

自クライアント証明書ファイル（PEM形式）

client.key

自クライアント証明書を作成した秘密鍵ファイル

keystore

接続元クライアント（Orchestrator、Participant）の秘密鍵が格納されているキーストア（pkcs12、またはJKS）ファイル

keystore_password

キーストアファイルのパスワード

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

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

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 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/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ユーザパスワード用シークレットを作成するコマンド例を示します。

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‒15　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‒16　ElasticsearchのTLS通信用シークレットの作成要領

キー名

ファイル

ca.crt

接続先サーバのサーバ証明書を発行したCAの証明書(PEM形式)ファイル

elastic.crt

自サーバ証明書(PEM形式)ファイル

elastic.key

自サーバ証明書を作成した秘密鍵ファイル

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

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つのファイル内に定義されている例としています。

もし、各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リポジトリディレクトリの永続ボリュームマウント用ディレクトリの作成

Elasticsearchリポジトリディレクトリの永続ボリュームマウント用ディレクトリを、次の要領でNFSやクラウドストレージなどの全ワーカーノードで共有可能な場所に作成してください。

Elasticsearchリポジトリディレクトリの永続ボリュームマウント用ディレクトリの作成要領

  • ディレクトリのグループにGID「0」(root)を設定してください。

  • ディレクトリのパーミッションにグループの書き込み権限を付与してください。

Elasticsearchリポジトリディレクトリの永続ボリュームマウント用ディレクトリを作成するコマンド例を次に示します。

mkdir -p /elasticsearch-repo-volume
chown 1000:0 /elasticsearch-repo-volume
chmod g+w /elasticsearch-repo-volume

次のコマンド例のように、Elasticsearchリポジトリディレクトリの永続ボリュームマウント用ディレクトリが期待どおり作成されていることを確認してください。

ls -ld /elasticsearch-repo-volume

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

drwxrwxr-x 2 user root 6  5月 10 12:34 /elasticsearch-repo-volume

ページの先頭へ

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

「(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オブジェクトのさらに詳細な情報を参照できます。

ページの先頭へ

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

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

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

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オブジェクトの作成に成功したメッセージが出力されていることを確認してください。

ページの先頭へ

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

「(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オブジェクトの作成に成功した旨のメッセージが出力されていることを確認してください。

ページの先頭へ

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

「(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オブジェクトの作成に成功した旨のメッセージが出力されていることを確認してください。

ページの先頭へ

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

「(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オブジェクトの作成に成功した旨のメッセージが出力されていることを確認してください。

ページの先頭へ

(15)　uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームマウント用ディレクトリ作成（通常版限定）

uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームマウント用ディレクトリを下記要領で全ワーカーノードで共有可能なNFSに作成してください。この作業は、ユーザ責務のKubernetesアプリケーション、またはHMP-PCTOのコントロールプレーンおよびRASのKubernetesアプリケーションのどちらかをデプロイするための作業時に実施します。

この作業は、NFSにアクセスできる任意の環境で実施できます。

ここでは、Kubernetesコントロールプレーンで作業する例を記載します。

＜uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームマウント用ディレクトリの作成要領＞

次にuCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームマウント用ディレクトリを作成するコマンド例を示します。

mkdir -p /ucars-snapshots
chgrp 0 /ucars-snapshots
chmod g+w /ucars-snapshots

次のコマンド例のように、uCosminexus Application Runtime with Java for Spring Bootスナップショットログの永続ボリュームマウント用ディレクトリが期待どおり作成されていることを確認してください。

ls -ld /ucars-snapshots

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

drwxrwxr-x 2 root root 6  5月 10 12:34 /ucars-snapshots

ページの先頭へ

(16)　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つのファイル内に定義されている例としています。

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

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

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スナップショットログの永続ボリュームだけを記載しています。実行環境によっては、そのほかに存在する永続ボリュームも一覧に表示されます。

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

ページの先頭へ

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

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

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

  1. Elasticsearch

  2. Logstash、Jaeger-query、Jaeger-collector、Prometheus、Metricbeat、Filebeat

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

  4. Participant

  5. Orchestrator

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

各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‒17　helmコマンドに指定するコマンド引数

Kubernetesアプリケーション

リリース名

Helmチャートパッケージファイル名

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-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と接続できることを確認してください。

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

kubectl get pods -n my-namespace -o wide

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

[図データ]

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

[図データ]

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

ページの先頭へ

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

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

コマンド例を次に示します（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のスナップショットライフサイクルポリシーを作成して、リポジトリにスナップショットを定期的に取得するように設定してください。

コマンド例を次に示します（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
    }
  }
}

ページの先頭へ

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

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

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

ページの先頭へ

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

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

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

ページの先頭へ

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

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

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

  1. Orchestrator

  2. Participant

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

  4. Logstash、Jaeger-query、Jaeger-collector、Prometheus、Metricbeat、Filebeat

  5. Elasticsearch

    重要

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

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

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.

ページの先頭へ

All Rights Reserved. Copyright (C) 2024, Hitachi, Ltd.