13.3.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

PV の情報がデータとともに表示されます。

この手順で重要な列を示す出力例:

NAME                                         RECLAIMPOLICY CLAIM
pvc-5e9c5c7f-3317-11ea-a650-06e1eadd9a4c ... Retain ...    myproject/data-my-cluster-zookeeper-1
pvc-5e9cc72d-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-my-cluster-zookeeper-0
pvc-5ead43d1-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-my-cluster-zookeeper-2
pvc-7e1f67f9-3317-11ea-a650-06e1eadd9a4c ... Retain ...    myproject/data-0-my-cluster-kafka-0
pvc-7e21042e-3317-11ea-9786-02deaf9aa87e ... Retain ...    myproject/data-0-my-cluster-kafka-1
pvc-7e226978-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-0-my-cluster-kafka-2

NAME は各 PV の名前を示します。
RECLAIM POLICY は PV が 保持される ことを示します。
CLAIM は元の PVC へのリンクを示します。

元の namespace を再作成します。
```
oc create namespace myproject
```

元の PVC リソース仕様を再作成し、PVC を該当する PV にリンクします。

以下に例を示します。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-0-my-cluster-kafka-0
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: gp2-retain
  volumeMode: Filesystem
  volumeName: pvc-7e1f67f9-3317-11ea-a650-06e1eadd9a4c

PV 仕様を編集して、元の PVC にバインドされた claimRef プロパティーを削除します。

以下に例を示します。

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    kubernetes.io/createdby: aws-ebs-dynamic-provisioner
    pv.kubernetes.io/bound-by-controller: "yes"
    pv.kubernetes.io/provisioned-by: kubernetes.io/aws-ebs
  creationTimestamp: "<date>"
  finalizers:
  - kubernetes.io/pv-protection
  labels:
    failure-domain.beta.kubernetes.io/region: eu-west-1
    failure-domain.beta.kubernetes.io/zone: eu-west-1c
  name: pvc-7e226978-3317-11ea-97b0-0aef8816c7ea
  resourceVersion: "39431"
  selfLink: /api/v1/persistentvolumes/pvc-7e226978-3317-11ea-97b0-0aef8816c7ea
  uid: 7efe6b0d-3317-11ea-a650-06e1eadd9a4c
spec:
  accessModes:
  - ReadWriteOnce
  awsElasticBlockStore:
    fsType: xfs
    volumeID: aws://eu-west-1c/vol-09db3141656d1c258
  capacity:
    storage: 100Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: data-0-my-cluster-kafka-2
    namespace: myproject
    resourceVersion: "39113"
    uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: failure-domain.beta.kubernetes.io/zone
          operator: In
          values:
          - eu-west-1c
        - key: failure-domain.beta.kubernetes.io/region
          operator: In
          values:
          - eu-west-1
  persistentVolumeReclaimPolicy: Retain
  storageClassName: gp2-retain
  volumeMode: Filesystem

この例では、以下のプロパティーが削除されます。

claimRef:
  apiVersion: v1
  kind: PersistentVolumeClaim
  name: data-0-my-cluster-kafka-2
  namespace: myproject
  resourceVersion: "39113"
  uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea

Cluster Operator をデプロイします。

oc apply -f install/cluster-operator -n my-project

クラスターを再作成します。
クラスターの再作成に必要なすべての KafkaTopic リソースがあるかどうかに応じて、以下の手順を実行します。
オプション 1: クラスターを失う前に存在した KafkaTopic リソースが すべて ある場合 (__consumer_offsets からコミットされたオフセットなどの内部トピックを含む)。
1. すべての KafkaTopic リソースを再作成します。
  クラスターをデプロイする前にリソースを再作成する必要があります。そうでないと、Topic Operator によってトピックが削除されます。
2. Kafka クラスターをデプロイします。
  以下に例を示します。
```
oc apply -f kafka.yaml
```
オプション 2: クラスターを失う前に存在したすべての KafkaTopic リソースがない場合。
1. オプション 1 と同様に Kafka クラスターをデプロイしますが、デプロイ前に Kafka リソースから topicOperator プロパティーを削除して、Topic Operator がない状態でデプロイします。
  デプロイメントに Topic Operator が含まれると、Topic Operator によってすべてのトピックが削除されます。
2. exec コマンドを Kafka ブローカー Pod の 1 つに実行し、ZooKeeper シェルスクリプトを開きます。
  たとえば、my-cluster-kafka-0 はブローカー Pod の名前になります。
```
oc exec my-cluster-kafka-0 bin/zookeeper-shell.sh localhost:2181
```
3. /strimzi パス全体を削除して、Topic Operator ストレージを削除します。
```
deleteall /strimzi
```
4. Kafka クラスターを topicOperator プロパティーで再デプロイして TopicOperator を有効にし、KafkaTopic リソースを再作成します。
  以下に例を示します。
```
apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  #...
  entityOperator:
    topicOperator: {} 1
    #...
```
1
ここで示すデフォルト設定には、追加のプロパティーはありません。「EntityTopicOperatorSpec スキーマ参照」に説明されているプロパティーを使用して、必要な設定を指定します。
KafkaTopic リソースのリストを表示して、復旧を確認します。
```
oc get KafkaTopic
```

13.3.3. 削除したクラスターの永続ボリュームからの復元

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links