第16章 AMQ Streams の管理
本章では、AMQ Streams のデプロイメントを維持するタスクについて説明します。
16.1. カスタムリソースのステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、カスタムリソースのステータスを検出する方法を説明します。
前提条件
- OpenShift クラスターが必要です。
- Cluster Operator が稼働している必要があります。
手順
カスタムリソースを指定し、
-o jsonpathオプションを使用して標準の JSONPath 式を適用してstatusプロパティーを選択します。oc get kafka <kafka_resource_name> -o jsonpath='{.status}'oc get kafka <kafka_resource_name> -o jsonpath='{.status}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow この式は、指定されたカスタムリソースのすべてのステータス情報を返します。
status.listenersまたはstatus.observedGenerationなどのドット表記を使用すると、表示するステータス情報を微調整できます。
その他のリソース
- 「AMQ Streams カスタムリソースのステータス」
- JSONPath の使用に関する詳細は、「JSONPath support」を参照してください。
16.2. 永続ボリュームからのクラスターの復元 リンクのコピーリンクがクリップボードにコピーされました!
Kafka クラスターは、永続ボリューム (PV) が存在していれば、そこから復元できます。
たとえば、以下の場合に行います。
- namespace が意図せずに削除された後。
- OpenShift クラスター全体が失われた後でも PV がインフラストラクチャーに残っている場合。
16.2.1. namespace が削除された場合の復元 リンクのコピーリンクがクリップボードにコピーされました!
永続ボリュームと namespace の関係により、namespace の削除から復元することが可能です。PersistentVolume (PV) は、namespace の外部に存在するストレージリソースです。PV は、namespace 内部に存在する PersistentVolumeClaim (PVC) を使用して Kafka Pod にマウントされます。
PV の回収 (reclaim) ポリシーは、namespace が削除されるときにクラスターに動作方法を指示します。以下に、回収 (reclaim) ポリシーの設定とその結果を示します。
- Delete (デフォルト) に設定すると、PVC が namespace 内で削除されるときに PV が削除されます。
- Retain に設定すると、namespace の削除時に PV は削除されません。
namespace が意図せず削除された場合に PV から復旧できるようにするには、PV 仕様で persistentVolumeReclaimPolicy プロパティーを使用してポリシーを Delete から Retain にリセットする必要があります。
または、PV は、関連付けられたストレージクラスの回収 (reclaim) ポリシーを継承できます。ストレージクラスは、動的ボリュームの割り当てに使用されます。
ストレージクラスの reclaimPolicy プロパティーを設定することで、ストレージクラスを使用する PV が適切な回収 (reclaim) ポリシー で作成されます。ストレージクラスは、storageClassName プロパティーを使用して PV に対して設定されます。
Retain を回収 (reclaim) ポリシーとして使用しながら、クラスター全体を削除する場合は、PV を手動で削除する必要があります。そうしないと、PV は削除されず、リソースに不要な経費がかかる原因になります。
16.2.2. OpenShift クラスター喪失からの復旧 リンクのコピーリンクがクリップボードにコピーされました!
クラスターが失われた場合、ディスク/ボリュームのデータがインフラストラクチャー内に保持されていれば、それらのデータを使用してクラスターを復旧できます。PV が復旧可能でそれらが手動で作成されていれば、復旧の手順は namespace の削除と同じです。
16.2.3. 永続ボリュームからのクラスターの復旧 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、削除されたクラスターを永続ボリューム (PV) から復元する方法を説明します。
この状況では、Topic Operator はトピックが Kafka に存在することを認識しますが、KafkaTopic リソースは存在しません。
クラスター再作成の手順を行うには、2 つの方法があります。
すべての
KafkaTopicリソースを復旧できる場合は、オプション 1 を使用します。これにより、クラスターが起動する前に
KafkaTopicリソースを復旧することで、該当するトピックが Topic Operator によって削除されないようにする必要があります。すべての
KafkaTopicリソースを復旧できない場合は、オプション 2 を使用します。この場合、Topic Operator なしでクラスターをデプロイし、ZooKeeper で Topic Operator データを削除してからそのデータを再デプロイすることで、Topic Operator が該当するトピックから
KafkaTopicリソースを再作成できるようにします。
Topic Operator がデプロイされていない場合は、PersistentVolumeClaim (PVC) リソースのみを復旧する必要があります。
作業を始める前に
この手順では、データの破損を防ぐために PV を正しい PVC にマウントする必要があります。volumeName が PVC に指定されており、それが PV の名前に一致する必要があります。
詳細は以下を参照してください。
この手順には、手動での再作成が必要な KafkaUser リソースの復旧は含まれません。パスワードと証明書を保持する必要がある場合は、KafkaUser リソースの作成前にシークレットを再作成する必要があります。
手順
クラスターの PV についての情報を確認します。
oc get pv
oc get pvCopy to Clipboard Copied! Toggle word wrap Toggle overflow PV の情報がデータとともに表示されます。
この手順で重要な列を示す出力例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - NAME は各 PV の名前を示します。
- RECLAIM POLICY は PV が 保持される ことを示します。
- CLAIM は元の PVC へのリンクを示します。
元の namespace を再作成します。
oc create namespace myproject
oc create namespace myprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 元の PVC リソース仕様を再作成し、PVC を該当する PV にリンクします。
以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PV 仕様を編集して、元の PVC にバインドされた
claimRefプロパティーを削除します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、以下のプロパティーが削除されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster Operator をデプロイします。
oc apply -f install/cluster-operator -n my-project
oc apply -f install/cluster-operator -n my-projectCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターを再作成します。
クラスターの再作成に必要なすべての
KafkaTopicリソースがあるかどうかに応じて、以下の手順を実行します。オプション 1: クラスターを失う前に存在した
KafkaTopicリソースが すべて ある場合 (__consumer_offsetsからコミットされたオフセットなどの内部トピックを含む)。すべての
KafkaTopicリソースを再作成します。クラスターをデプロイする前にリソースを再作成する必要があります。そうでないと、Topic Operator によってトピックが削除されます。
Kafka クラスターをデプロイします。
以下に例を示します。
oc apply -f kafka.yaml
oc apply -f kafka.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション 2: クラスターを失う前に存在したすべての
KafkaTopicリソースがない場合。オプション 1 と同様に Kafka クラスターをデプロイしますが、デプロイ前に Kafka リソースから
topicOperatorプロパティーを削除して、Topic Operator がない状態でデプロイします。デプロイメントに Topic Operator が含まれると、Topic Operator によってすべてのトピックが削除されます。
execコマンドを Kafka ブローカー Pod の 1 つに実行し、ZooKeeper シェルスクリプトを開きます。たとえば、my-cluster-kafka-0 はブローカー Pod の名前になります。
oc exec my-cluster-kafka-0 bin/zookeeper-shell.sh localhost:2181
oc exec my-cluster-kafka-0 bin/zookeeper-shell.sh localhost:2181Copy to Clipboard Copied! Toggle word wrap Toggle overflow /strimziパス全体を削除して、Topic Operator ストレージを削除します。deleteall /strimzi
deleteall /strimziCopy to Clipboard Copied! Toggle word wrap Toggle overflow Kafka クラスターを
topicOperatorプロパティーで再デプロイして TopicOperator を有効にし、KafkaTopicリソースを再作成します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
- ここで示すデフォルト設定には、追加のプロパティーはありません。「
EntityTopicOperatorSpecスキーマ参照」に説明されているプロパティーを使用して、必要な設定を指定します。
KafkaTopicリソースのリストを表示して、復旧を確認します。oc get KafkaTopic
oc get KafkaTopicCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.3. AMQ Streams のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
この手順では、AMQ Streams をアンインストールし、デプロイメントに関連するリソースを削除する方法を説明します。
前提条件
この手順を実行するには、デプロイメント用に特別に作成され、AMQ Streams リソースから参照されるリソースを特定します。
このようなリソースには以下があります。
- シークレット (カスタム CA および証明書、Kafka Connect Secrets、その他の Kafka シークレット)
-
ロギング
ConfigMaps(タイプはexternal)
これらのリソースは、Kafka、KafkaConnect、KafkaConnectS2I、KafkaMirrorMaker、または KafkaBridge 設定によって参照されます。
手順
Cluster Operator の
Deployment、関連するCustomResourceDefinitionsおよびRBACリソースを削除します。oc delete -f install/cluster-operator
oc delete -f install/cluster-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 警告CustomResourceDefinitionsを削除すると、対応するカスタムリソース (Kafka、KafkaConnect、KafkaConnectS2I、KafkaMirrorMaker、またはKafkaBridge) 、およびそれらに依存するリソース (Deployments、StatefulSets、その他の依存リソース) のガベージコレクションが実行されます。- 前提条件で特定したリソースを削除します。