29.3. 영구 볼륨에서 클러스터 복구


PV(영구 볼륨)가 여전히 존재하는 경우 Kafka 클러스터를 복구할 수 있습니다.

예를 들어 다음과 같은 작업을 수행할 수 있습니다.

  • 네임스페이스가 의도하지 않게 삭제됨
  • 전체 OpenShift 클러스터가 손실되었지만 PV는 인프라에 남아 있습니다.

29.3.1. 네임스페이스 삭제에서 복구

영구 볼륨과 네임스페이스 간의 관계로 인해 네임스페이스 삭제로 인한 복구가 가능합니다. PV( PersistentVolume )는 네임스페이스 외부에 있는 스토리지 리소스입니다. PV는 네임스페이스 내에 있는 PVC( PersistentVolumeClaim )를 사용하여 Kafka Pod에 마운트됩니다.

PV의 회수 정책은 네임스페이스를 삭제할 때 클러스터에 작동하는 방법을 지시합니다. 회수 정책이 다음과 같이 설정된 경우

  • 삭제 (기본값), 네임스페이스 내에서 PVC가 삭제되면 PV가 삭제됩니다.
  • 네임스페이스를 삭제할 때 PV가 삭제되지 않음

의도하지 않게 삭제된 경우 PV에서 복구하려면 persistentVolumeReclaimPolicy 속성을 사용하여 PV 사양의 Delete 에서 Retain 으로 정책을 재설정해야 합니다.

apiVersion: v1
kind: PersistentVolume
# ...
spec:
  # ...
  persistentVolumeReclaimPolicy: Retain
Copy to Clipboard Toggle word wrap

또는 PV는 관련 스토리지 클래스의 회수 정책을 상속할 수 있습니다. 스토리지 클래스는 동적 볼륨 할당에 사용됩니다.

스토리지 클래스에 대한 reclaimPolicy 속성을 구성하면 스토리지 클래스를 사용하는 PV가 적절한 회수 정책으로 생성됩니다. 스토리지 클래스는 storageClassName 속성을 사용하여 PV에 구성됩니다.

apiVersion: v1
kind: StorageClass
metadata:
  name: gp2-retain
parameters:
  # ...
# ...
reclaimPolicy: Retain
Copy to Clipboard Toggle word wrap
apiVersion: v1
kind: PersistentVolume
# ...
spec:
  # ...
  storageClassName: gp2-retain
Copy to Clipboard Toggle word wrap
참고

Retain 을 회수 정책으로 사용하지만 전체 클러스터를 삭제하려면 PV를 수동으로 삭제해야 합니다. 그렇지 않으면 삭제되지 않으며 리소스에 대한 불필요한 문제가 발생할 수 있습니다.

29.3.2. OpenShift 클러스터 손실에서 복구

클러스터가 손실되면 디스크/볼륨의 데이터를 사용하여 인프라 내에 보존된 경우 클러스터를 복구할 수 있습니다. 복구 절차는 PV를 복구하고 수동으로 생성할 수 있다고 가정하면 네임스페이스 삭제와 동일합니다.

29.3.3. 영구 볼륨에서 삭제된 클러스터 복구

다음 절차에서는 PV(영구 볼륨)에서 삭제된 클러스터를 복구하는 방법을 설명합니다.

이 경우 Topic Operator는 Kafka에 항목이 존재하지만 KafkaTopic 리소스가 존재하지 않습니다.

클러스터를 다시 생성하는 단계에 도달하면 다음 두 가지 옵션이 있습니다.

  1. 모든 KafkaTopic 리소스를 복구할 수 있는 경우 옵션 1 을 사용합니다.

    따라서 KafkaTopic 리소스는 Topic Operator에서 해당 주제를 삭제하지 않도록 클러스터를 시작하기 전에 복구해야 합니다.

  2. 모든 KafkaTopic 리소스를 복구할 수 없는 경우 옵션 2 를 사용합니다.

    이 경우 Topic Operator 없이 클러스터를 배포하고 Topic Operator 주제 저장소 메타데이터를 삭제한 다음 Topic Operator를 사용하여 Kafka 클러스터를 재배포하여 해당 주제에서 KafkaTopic 리소스를 다시 생성할 수 있습니다.

참고

Topic Operator가 배포되지 않은 경우 PVC( PersistentVolumeClaim ) 리소스만 복구해야 합니다.

사전 준비 사항

이 절차에서는 데이터 손상을 방지하려면 PV를 올바른 PVC에 마운트해야 합니다. volumeName 은 PVC에 지정되어 있으며 PV의 이름과 일치해야 합니다.

자세한 내용은 영구 스토리지를 참조하십시오.

참고

프로세스에는 수동으로 다시 생성해야 하는 KafkaUser 리소스의 복구가 포함되지 않습니다. 암호 및 인증서를 유지해야 하는 경우 KafkaUser 리소스를 생성하기 전에 시크릿을 다시 생성해야 합니다.

프로세스

  1. 클러스터의 PV에 대한 정보를 확인합니다.

    oc get pv
    Copy to Clipboard Toggle word wrap

    데이터가 있는 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
    Copy to Clipboard Toggle word wrap
    • NAME 에는 각 PV의 이름이 표시됩니다.
    • RECLAIM POLICY 는 PV가 유지되고 있음을 보여줍니다.
    • CLAIM 은 원래 PVC에 대한 링크를 보여줍니다.
  2. 원래 네임스페이스를 다시 생성합니다.

    oc create namespace myproject
    Copy to Clipboard Toggle word wrap
  3. 원래 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
    Copy to Clipboard Toggle word wrap
  4. 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
    Copy to Clipboard Toggle word wrap

    이 예제에서는 다음 속성이 삭제됩니다.

    claimRef:
      apiVersion: v1
      kind: PersistentVolumeClaim
      name: data-0-my-cluster-kafka-2
      namespace: myproject
      resourceVersion: "39113"
      uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea
    Copy to Clipboard Toggle word wrap
  5. Cluster Operator를 배포합니다.

    oc create -f install/cluster-operator -n my-project
    Copy to Clipboard Toggle word wrap
  6. 클러스터를 다시 생성합니다.

    클러스터를 다시 생성하는 데 필요한 모든 KafkaTopic 리소스가 있는지 여부에 따라 단계를 따르십시오.

    옵션 1: __consumer_offsets 의 커밋된 오프셋과 같은 내부 주제를 포함하여 클러스터를 손실하기 전에 존재하는 모든 KafkaTopic 리소스가 있는 경우 :

    1. 모든 KafkaTopic 리소스를 다시 생성합니다.

      클러스터를 배포하기 전에 리소스를 다시 생성해야 합니다. 그러지 않으면 Topic Operator에서 주제를 삭제해야 합니다.

    2. Kafka 클러스터를 배포합니다.

      예를 들면 다음과 같습니다.

      oc apply -f kafka.yaml
      Copy to Clipboard Toggle word wrap

    옵션 2: 클러스터를 손실하기 전에 존재하는 모든 KafkaTopic 리소스가 없는 경우:

    1. 첫 번째 옵션과 마찬가지로 Kafka 클러스터를 배포하지만, 배포하기 전에 Kafka 리소스에서 topicOperator 속성을 제거하여 Topic Operator 없이 Kafka 클러스터를 배포합니다.

      Topic Operator를 배포에 포함하는 경우 Topic Operator는 모든 주제를 삭제합니다.

    2. Kafka 클러스터에서 내부 주제 저장소 주제를 삭제합니다.

      oc run kafka-admin -ti --image=registry.redhat.io/amq-streams/kafka-37-rhel9:2.7.0 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete
      Copy to Clipboard Toggle word wrap

      명령은 Kafka 클러스터에 액세스하는 데 사용되는 리스너 및 인증 유형에 해당해야 합니다.

    3. topicOperator 속성으로 Kafka 클러스터를 재배포하여 KafkaTopic 리소스를 다시 생성하여 Topic Operator를 활성화합니다.

      예를 들면 다음과 같습니다.

      apiVersion: kafka.strimzi.io/v1beta2
      kind: Kafka
      metadata:
        name: my-cluster
      spec:
        #...
        entityOperator:
          topicOperator: {} 
      1
      
          #...
      Copy to Clipboard Toggle word wrap
    1
    여기서는 추가 속성이 없는 기본 구성을 보여줍니다. EntityTopicOperatorSpec 스키마 참조에 설명된 속성을 사용하여 필요한 구성을 지정합니다.
  7. KafkaTopic 리소스를 나열하여 복구를 확인합니다.

    oc get KafkaTopic
    Copy to Clipboard Toggle word wrap
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동