9.5. Kafka 업그레이드


Cluster Operator를 2.2로 업그레이드한 다음 다음 단계는 모든 Kafka 브로커를 지원되는 최신 Kafka 버전으로 업그레이드하는 것입니다.

Kafka 브로커의 롤링 업데이트를 통해 Kafka 업그레이드는 Cluster Operator에서 수행합니다.

Cluster Operator는 Kafka 클러스터 구성을 기반으로 롤링 업데이트를 시작합니다.

Expand
Kafka.spec.kafka.config 에…​이 포함된 경우Cluster Operator가…​을 시작합니다.

inter.broker.protocol.versionlog.message.format.version 둘 다

단일 롤링 업데이트 업데이트 후 inter.broker.protocol.version 을 수동으로 업데이트하고 그 뒤에 log.message.format.version 이 설치되어 있어야 합니다. 각각을 변경하면 추가 롤링 업데이트가 트리거됩니다.

inter.broker.protocol.version 또는 log.message.format.version.version입니다.

롤링 업데이트 2개

inter.broker.protocol.version 또는 log.message.format.version 에 대한 구성이 없습니다.

롤링 업데이트 2개

중요

Kafka 3.0.0에서 inter.broker.protocol.version3.0 이상으로 설정되면 log.message.format.version 옵션이 무시되고 설정할 필요가 없습니다. 브로커의 log.message.format.version 속성과 토픽에 대한 message.format.version 속성은 더 이상 사용되지 않으며 Kafka의 향후 릴리스에서 제거됩니다.

Kafka 업그레이드의 일부로 Cluster Operator는 ZooKeeper에 대한 롤링 업데이트를 시작합니다.

  • 단일 롤링 업데이트는 ZooKeeper 버전이 변경되지 않은 경우에도 발생합니다.
  • 새로운 버전의 Kafka에 새로운 ZooKeeper 버전이 필요한 경우 추가 롤링 업데이트가 수행됩니다.

9.5.1. Kafka 버전

Kafka의 로그 메시지 형식 버전 및broker 간 프로토콜 버전은 각각 메시지에 추가된 로그 형식 버전 및 클러스터에 사용된 Kafka 프로토콜 버전을 지정합니다. 올바른 버전을 사용하려면 업그레이드 프로세스에는 기존 Kafka 브로커를 구성하고 클라이언트 애플리케이션(소유자 및 생산자)에 대한 코드를 변경해야 합니다.

다음 표는 Kafka 버전의 차이점을 보여줍니다.

Expand
표 9.1. Kafka 버전 차이점
Kafka 버전inter-broker 프로토콜 버전로그 메시지 형식 버전zookeeper 버전

3.2.3

3.2

3.2

3.6.3

3.1.0

3.1

3.1

3.6.3

inter-broker 프로토콜 버전

Kafka에서broker 간 통신에 사용되는 네트워크 프로토콜을 인스턴스 간 프로토콜 이라고 합니다. Kafka의 각 버전에는broker 간 프로토콜의 호환 버전이 있습니다. 프로토콜의 마이너 버전은 일반적으로 이전 표에 표시된 Kafka의 마이너 버전과 일치하도록 증가합니다.

inter-broker 프로토콜 버전은 Kafka 리소스에서 cluster wide을 설정합니다. 이를 변경하려면 Kafka.spec.kafka.config 에서 inter.broker.protocol.version 속성을 편집합니다.

로그 메시지 형식 버전

생산자가 Kafka 브로커에 메시지를 보내면 특정 형식을 사용하여 메시지가 인코딩됩니다. 형식은 Kafka 릴리스 간에 변경될 수 있으므로 메시지는 인코딩된 메시지 형식의 버전을 지정합니다.

특정 메시지 형식 버전을 설정하는 데 사용되는 속성은 다음과 같습니다.

  • topic의 message.format.version 속성
  • Kafka 브로커의 log.message.format.version 속성

Kafka 3.0.0에서 메시지 형식 버전 값은 inter.broker.protocol.version 과 일치하는 것으로 간주되며 설정할 필요가 없습니다. 값은 사용된 Kafka 버전을 반영합니다.

Kafka 3.0.0 이상으로 업그레이드할 때 inter.broker.protocol.version 을 업데이트할 때 이러한 설정을 제거할 수 있습니다. 그렇지 않으면 업그레이드할 Kafka 버전에 따라 메시지 형식 버전을 설정합니다.

항목에 대한 message.format.version 의 기본값은 Kafka 브로커에 설정된 log.message.format.version 에 의해 정의됩니다. 주제 구성을 수정하여 topic.version of a topic를 수동으로 설정할 수 있습니다.

9.5.2. 클라이언트 업그레이드 전략

클라이언트 애플리케이션 업그레이드( Kafka Connect 커넥터 포함)에 대한 올바른 방법은 특정 상황에 따라 달라집니다.

애플리케이션 사용에서는 이해할 수 있는 메시지 형식으로 메시지를 수신해야 합니다. 다음 두 가지 방법 중 하나로 이 문제를 방지할 수 있습니다.

  • 생산자를 업그레이드하기 전에 항목에 대한 모든 소비자를 업그레이드합니다.
  • 브로커를 다운-일치하는 이전 형식으로 메시지를 되돌리도록 합니다.

브로커 다운-conversion을 사용하면 브로커에 추가 로드가 발생하므로 장기간에 걸쳐 모든 주제의 다운 컨버전에 의존하는 것이 이상적이지 않습니다. 브로커가 최적으로 수행되려면 메시지 변환이 중단되어서는 안 됩니다.

broker down-conversion은 다음 두 가지 방법으로 구성됩니다.

  • topic-level message.format.version 은 단일 항목에 대해 구성합니다.
  • broker-level log.message.format.version 은 topic-level message.format.version 이 구성되지 않은 항목의 기본값입니다.

브로커는 소비자에게 메시지를 수신할 때가 아니라 생산자에서 메시지를 수신할 때 다운버전을 수행하기 때문에 새 버전의 항목에 게시된 메시지가 소비자에게 표시됩니다.

클라이언트를 업그레이드하는 데 사용할 수 있는 일반적인 전략은 다음과 같습니다. 클라이언트 애플리케이션을 업그레이드하기 위한 다른 전략도 가능합니다.

중요

Kafka 3.0.0 이상으로 업그레이드할 때 각 전략에 설명된 단계는 약간 변경됩니다. Kafka 3.0.0에서 메시지 형식 버전 값은 inter.broker.protocol.version 과 일치하는 것으로 간주되며 설정할 필요가 없습니다.

브로커 수준 소비자 첫 번째 전략

  1. 모든 사용 애플리케이션을 업그레이드합니다.
  2. broker-level log.message.format.version 을 새 버전으로 변경합니다.
  3. 모든 생성 애플리케이션을 업그레이드합니다.

이 전략은 간단하며 브로커의 다운스버전을 피할 수 있습니다. 그러나 조직의 모든 소비자는 조정된 방식으로 업그레이드할 수 있으며 소비자와 생산자 둘 다의 애플리케이션에는 작동하지 않는 것으로 가정합니다. 업그레이드된 클라이언트에 문제가 있는 경우 이전 소비자 버전으로 되돌릴 수 없도록 메시지 로그에 새 형식 메시지가 추가될 수도 있습니다.

주제 수준 소비자 첫 번째 전략

각 주제의 경우:

  1. 모든 사용 애플리케이션을 업그레이드합니다.
  2. topic-level message.format.version 을 새 버전으로 변경합니다.
  3. 모든 생성 애플리케이션을 업그레이드합니다.

이 전략은 모든 브로커의 다운-conversion을 피하고, 주제별로 진행할 수 있음을 의미합니다. 소비자와 동일한 주제의 생산자 모두에 해당하는 애플리케이션은 작동하지 않습니다. 다시 말해 업그레이드된 클라이언트에 문제가 있는 경우 새 형식 메시지가 메시지 로그에 추가될 수 있다는 위험이 있습니다.

주제 수준 소비자 첫 번째 전략 다운 변환

각 주제의 경우:

  1. topic-level message.format.version 을 이전 버전으로 변경합니다(또는 broker-level log.message.format.version).
  2. 모든 소비 및 생성 애플리케이션을 업그레이드합니다.
  3. 업그레이드된 애플리케이션이 제대로 작동하는지 확인합니다.
  4. topic-level message.format.version 을 새 버전으로 변경합니다.

이 전략에는 브로커의 다운-conversion이 필요하지만 한 번에 하나의 주제 (또는 소규모 주제 그룹)에만 필요하므로 브로커의 부하가 최소화됩니다. 또한 소비자와 동일한 주제의 생산자 모두에 해당하는 애플리케이션에도 작동합니다. 이 방법을 사용하면 새 메시지 형식 버전을 사용하기 전에 업그레이드된 생산자와 소비자가 제대로 작동하는지 확인합니다.

이 접근 방식의 주요 단점은 많은 주제와 애플리케이션이 있는 클러스터에서 관리하기가 복잡할 수 있다는 것입니다.

참고

또한 여러 전략을 적용할 수 있습니다. 예를 들어 처음 몇 개의 애플리케이션과 주제별로 "분위원별 소비자" 전략을 먼저 사용할 수 있습니다. 이것이 다른 것으로 입증되면 더 효율적인 전략을 대신 사용할 수 있는 것으로 간주할 수 있습니다.

9.5.3. Kafka 버전 및 이미지 매핑

Kafka를 업그레이드할 때 STRIMZI_KAFKA_IMAGES 환경 변수 및 Kafka.spec.kafka.version 속성에 대한 설정을 고려하십시오.

  • Kafka 리소스는 Kafka.spec.kafka.version 을 사용하여 구성할 수 있습니다.
  • Cluster Operator의 STRIMZI_KAFKA_IMAGES 환경 변수는 Kafka 버전과 해당 버전이 지정된 Kafka 리소스에서 요청할 때 사용할 이미지 간 매핑을 제공합니다.

    • Kafka.spec.kafka.image 가 구성되지 않은 경우 지정된 버전의 기본 이미지가 사용됩니다.
    • Kafka.spec.kafka.image 가 구성된 경우 기본 이미지가 재정의됩니다.
주의

Cluster Operator는 이미지에 실제로 예상 버전의 Kafka 브로커가 포함되어 있는지 확인할 수 없습니다. 지정된 이미지가 지정된 Kafka 버전에 해당하는지 확인합니다.

9.5.4. Kafka 브로커 및 클라이언트 애플리케이션 업그레이드

다음 절차에서는 AMQ Streams Kafka 클러스터를 지원되는 최신 Kafka 버전으로 업그레이드하는 방법을 설명합니다.

현재 Kafka 버전과 비교하여 새 버전이 더 높은 로그 메시지 형식 버전 또는 broker 간 프로토콜 버전 또는 둘 다를 지원할 수 있습니다. 필요한 경우 이러한 버전을 업그레이드하려면 단계를 따르십시오. 자세한 내용은 9.5.1절. “Kafka 버전”의 내용을 참조하십시오.

또한 클라이언트 업그레이드를 위한 전략을 선택해야 합니다. Kafka 클라이언트는 이 절차의 6단계에서 업그레이드됩니다.

사전 요구 사항

Kafka 리소스를 업그레이드하려면 다음을 확인합니다.

  • Kafka의 두 버전을 모두 지원하는 Cluster Operator가 실행 중입니다.
  • Kafka.spec.kafka.config 에는 새 Kafka 버전에서 지원되지 않는 옵션이 포함되어 있지 않습니다.

절차

  1. Kafka 클러스터 구성을 업데이트합니다.

    oc edit kafka my-cluster
    Copy to Clipboard Toggle word wrap
  2. 구성된 경우 Kafka.spec.kafka.configlog.message.format.versioninter.broker.protocol.version현재 Kafka 버전의 기본값으로 설정되어 있는지 확인합니다.

    예를 들어 Kafka 버전 3.1.0에서 3.2.3으로 업그레이드하는 경우 다음을 수행합니다.

    kind: Kafka
    spec:
      # ...
      kafka:
        version: 3.1.0
        config:
          log.message.format.version: "3.1"
          inter.broker.protocol.version: "3.1"
          # ...
    Copy to Clipboard Toggle word wrap

    log.message.format.versioninter.broker.protocol.version 이 구성되지 않은 경우 AMQ Streams는 다음 단계에서 Kafka 버전으로 업데이트한 후 이러한 버전을 현재 기본값으로 자동으로 업데이트합니다.

    참고

    log.message.format.versioninter.broker.protocol.version 의 값은 해당 값이 부동 소수점 숫자로 해석되지 않도록 문자열이어야 합니다.

  3. Kafka.spec.kafka.version 을 변경하여 새 Kafka 버전을 지정합니다. 현재 Kafka 버전의 기본값으로 log.message.format.versioninter.broker.protocol.version 을 그대로 둡니다.

    참고

    kafka.version 을 변경하면 클러스터의 모든 브로커가 새 브로커 바이너리를 사용하도록 업그레이드됩니다. 이 프로세스 중에 일부 브로커는 이전 바이너리를 사용하고 다른 브로커는 이미 새 바이너리로 업그레이드 중입니다. inter.broker.protocol.version 을 변경하지 않고 남겨 두면 브로커가 업그레이드 중에 서로 계속 통신할 수 있습니다.

    예를 들어 Kafka 3.1.0에서 3.2.3으로 업그레이드하는 경우 다음을 수행합니다.

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      # ...
      kafka:
        version: 3.2.3 
    1
    
        config:
          log.message.format.version: "3.1" 
    2
    
          inter.broker.protocol.version: "3.1" 
    3
    
          # ...
    Copy to Clipboard Toggle word wrap
    1
    Kafka 버전이 새 버전으로 변경되었습니다.
    2
    메시지 형식 버전은 변경되지 않습니다.
    3
    inter-broker 프로토콜 버전은 변경되지 않습니다.
    주의

    새 Kafka 버전의 inter.broker.protocol.version 이 변경되면 Kafka를 다운그레이드할 수 없습니다. The inter-broker protocol version determines the schemas used for persistent metadata stored by the broker, including messages written to __consumer_offsets. 다운그레이드된 클러스터는 메시지를 이해할 수 없습니다.

  4. Kafka 클러스터의 이미지가 Kafka 사용자 정의 리소스인 Kafka.spec.kafka. image 에 정의된 경우 새 Kafka 버전이 있는 컨테이너 이미지를 가리키도록 이미지를 업데이트합니다.

    Kafka 버전 및 이미지 매핑참조

  5. 편집기를 저장하고 종료한 다음 롤링 업데이트가 완료될 때까지 기다립니다.

    Pod 상태 전환을 확인하여 롤링 업데이트의 진행 상황을 확인합니다.

    oc get pods my-cluster-kafka-0 -o jsonpath='{.spec.containers[0].image}'
    Copy to Clipboard Toggle word wrap

    롤링 업데이트를 통해 각 Pod가 새 Kafka 버전에 브로커 바이너리를 사용하고 있는지 확인합니다.

  6. 클라이언트 업그레이드를 위한 선택한 전략에 따라 모든 클라이언트 애플리케이션을 업그레이드하여 새 버전의 클라이언트 바이너리를 사용합니다.

    필요한 경우 Kafka Connect 및 MirrorMaker의 version 속성을 Kafka의 새 버전으로 설정합니다.

    1. Kafka Connect의 경우 KafkaConnect.spec.version 을 업데이트합니다.
    2. MirrorMaker의 경우 KafkaMirrorMaker.spec.version 을 업데이트합니다.
    3. MirrorMaker 2.0의 경우 KafkaMirrorMaker2.spec.version 을 업데이트합니다.
  7. 구성된 경우 새 inter.broker.protocol.version 버전을 사용하도록 Kafka 리소스를 업데이트합니다. 그렇지 않으면 9 단계로 이동합니다.

    예를 들어 Kafka 3.2.3으로 업그레이드하는 경우 다음을 수행합니다.

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      # ...
      kafka:
        version: 3.2.3
        config:
          log.message.format.version: "3.1"
          inter.broker.protocol.version: "3.2"
          # ...
    Copy to Clipboard Toggle word wrap
  8. Cluster Operator가 클러스터를 업데이트할 때까지 기다립니다.
  9. 구성된 경우 새 log.message.format.version 버전을 사용하도록 Kafka 리소스를 업데이트합니다. 그렇지 않으면 10 단계로 이동합니다.

    예를 들어 Kafka 3.2.3으로 업그레이드하는 경우 다음을 수행합니다.

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      # ...
      kafka:
        version: 3.2.3
        config:
          log.message.format.version: "3.2"
          inter.broker.protocol.version: "3.2"
          # ...
    Copy to Clipboard Toggle word wrap
    중요

    Kafka 3.0.0에서 inter.broker.protocol.version3.0 이상으로 설정되면 log.message.format.version 옵션이 무시되고 설정할 필요가 없습니다.

  10. Cluster Operator가 클러스터를 업데이트할 때까지 기다립니다.

    • Kafka 클러스터 및 클라이언트는 이제 새 Kafka 버전을 사용합니다.
    • 브로커는 inter-broker 프로토콜 버전과 Kafka의 새 버전의 메시지 형식 버전을 사용하여 메시지를 전송하도록 구성됩니다.

필요한 경우 Kafka 업그레이드 후 다음을 수행할 수 있습니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat