Hitachi

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

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

〈この項の構成〉

(1)　各種資材の配置

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

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

資材

備考

ユーザ責務のKubernetesアプリケーションのKubernetesマニフェスト

Participantが使用するDB/外部サービスのKubernetesマニフェスト（Participantを使用する場合）

ユーザが適宜作成したもの

Kubernetesリソース取得用ロールおよびロールバインディングのKubernetesマニフェスト

「2.6.9　Kubernetesリソース取得用ロールおよびロールバインディングのKubernetesマニフェストの作成」で作成したもの

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

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

次のどちらかをデプロイするための作業時に配置します。

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

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

uCosminexus Application Runtime for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のKubernetesマニフェスト（通常版限定）

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

通常版の場合で、uCosminexus Application Runtime for Spring Bootを導入するときだけ実施します。次のどちらかをデプロイするための作業時に配置します。

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

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

ページの先頭へ

(2)　Namespaceの作成

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

詳細については、「(2)　Namespaceの作成」を参照してください。

ページの先頭へ

(3)　OrchestratorおよびParticipantのgRPC通信機能の暗号化通信用シークレットの作成

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

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

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

対象Kubernetesアプリケーション

対応するHMP-PCTOの機能

ファイル

備考

  • Orchestrator-Service

  • Orchestrator-Service(SQL)

  • Alternate-Service

  • Alternate-Service(SQL)

Orchestrator

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

必ず準備します。

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

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

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

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

  • Entity-Service(SQL)

  • Entity-Service(TCC)

  • Orchestrator-Service(SQL)

  • Alternate-Service(SQL)

Participant（SQL-Participant、TCC-Participant）

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

必ず準備します。

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

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

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

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

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

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

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

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

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

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

ユーザ責務のKubernetesアプリケーションのgRPC通信機能の暗号化通信用シークレットは、ユーザ要件に合わせて作成してください。

Orchestrator、SQL-Participant、およびTCC-ParticipantのgRPC通信機能の暗号化通信用シークレットを作成するコマンド例を次に示します。

ユーザ責務のKubernetesアプリケーションのgRPC通信機能の暗号化通信用シークレットの作成コマンドの一例です。ユーザ要件に合わせて作成してください。

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

kubectl create secret generic --save-config orchestrator-secret \
  --from-file=ca.crt=./ca.crt \
  -n 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 orchestrator-secret \
  --from-file=ca.crt=./ca.crt \
  --from-file=server.crt=./orchestrator/server.crt \
  --from-file=server.key=./orchestrator/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

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

secret/orchestrator-secret created
 
secret/participant-secret created

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

ページの先頭へ

(4)　Kubernetesリソース取得用ロールおよびロールバインディングのデプロイ

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

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

kubectl apply -f ./lb-role.yaml

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

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

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

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

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

ページの先頭へ

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

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

詳細については、「(10)　デプロイ依存関係チェック機能用ロールおよびロールバインディングのデプロイ」を参照してください。

ページの先頭へ

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

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

詳細については、「(14)　uCosminexus Application Runtime for Spring Bootスナップショットログの永続ボリュームおよび永続ボリューム要求のデプロイ（通常版限定）」を参照してください。

ページの先頭へ

(7)　ユーザ責務のKubernetesアプリケーションのデプロイ

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

なお、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(SQL)、Entity-Service(TCC)、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アプリケーションをアンデプロイして、正しい順序でデプロイし直してください。

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

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

ユーザ責務のKubernetesアプリケーションは、ユーザ任意の方法でデプロイしてください。

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

kubectl apply -f ./orchestrator.yaml

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

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

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

service/orchestrator created
serviceaccount/orchestrator-service-account created
deployment.apps/orchestrator created
configmap/orchestrator-config created
configmap/orchestrator-ucars-config created
configmap/orchestrator-filebeat-sidecar-config created

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

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

kubectl get pods -n my-namespace -o wide

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

[図データ]

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

[図データ]

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

ページの先頭へ

(8)　ユーザ責務のKubernetesアプリケーションのアンデプロイ

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

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

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

  2. Relay-Service、Entity-Service(SQL)、Entity-Service(TCC)、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を使用してトラブルシュート情報を収集する場合だけデプロイしてください。

クラスタを停止する前には、上記の順序でアンデプロイしてください。アンデプロイする前にクラスタを停止した場合は、クラスタを再起動したあとに、アンデプロイしてから「(7)　ユーザ責務の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

ユーザ責務のKubernetesアプリケーションは、ユーザ任意の方法でアンデプロイしてください。

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

kubectl delete -f ./orchestrator.yaml
重要

「--grace-period=0 --force」オプションの指定について

Kubernetesオブジェクトをすぐに削除する「--grace-period=0 --force」オプションは指定しないでください。このオプションを指定してKubernetesオブジェクトを削除した場合、トランザクション結果が不整合になるおそれがあります。

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

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

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

service/orchestrator deleted
serviceaccount/orchestrator-service-account deleted
deployment.apps/orchestrator deleted
configmap/orchestrator-config deleted
configmap/orchestrator-ucars-config deleted
configmap/orchestrator-filebeat-sidecar-config deleted

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

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

kubectl get pods -n my-namespace -o wide

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

No resources found in my-namespace namespace.

ページの先頭へ

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