OpenShift에서 AMQ Streams 2.2 릴리스 정보
OpenShift Container Platform에서 AMQ Streams 릴리스의 새로운 기능 및 주요 변경 사항
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
1장. 기능
AMQ Streams 2.2 및 후속 패치 릴리스에서는 이 섹션에 설명된 기능을 소개합니다.
OpenShift의 AMQ Streams 2.2는 Kafka 3.2.3 및 Strimzi 0.29.x를 기반으로 합니다.
이 릴리스에서 해결된 모든 개선 사항 및 버그를 보려면 AMQ Streams Jira 프로젝트를 참조하십시오.
1.1. AMQ Streams 2.2.x (Long Term Support)
AMQ Streams 2.2.x는 AMQ Streams에 대한 LTSS(Long Term Support)입니다.
최신 패치 릴리스는 AMQ Streams 2.2.1입니다. AMQ Streams 제품 이미지가 버전 2.2.1로 변경되었습니다. 지원되는 Kafka 버전은 3.2.3으로 유지됩니다.
LTS 이용 약관에 대한 자세한 내용은 AMQ Streams LTS 지원 정책을 참조하십시오.
1.2. OpenShift Container Platform 지원
AMQ Streams 2.2는 OpenShift Container Platform 4.8에서 4.11로 지원됩니다.
지원되는 플랫폼 버전에 대한 자세한 내용은 AMQ Streams Supported Configurations 를 참조하십시오.
1.3. Kafka 3.2.3 지원
AMQ Streams는 이제 Apache Kafka 버전 3.2.3을 지원합니다.
AMQ Streams는 Kafka 3.2.3을 사용합니다. Red Hat에서 빌드한 Kafka 배포판만 지원됩니다.
브로커 및 클라이언트 애플리케이션을 Kafka 3.2.3으로 업그레이드하기 전에 Cluster Operator를 AMQ Streams 버전 2.2로 업그레이드해야 합니다. 업그레이드 지침은 AMQ Streams 업그레이드를 참조하십시오.
자세한 내용은 Kafka 3.1.0,Kafka 3.2.0,Kafka 3.2.1 및 Kafka 3.2.3 릴리스 노트를 참조하십시오.
Kafka 3.1.x는 AMQ Streams 2.2로 업그레이드할 때만 지원됩니다.
지원되는 버전에 대한 자세한 내용은 AMQ Streams Component Details 를 참조하십시오.
Kafka 3.2.3에서는 Kafka 3.1.0과 동일한 버전인 ZooKeeper 버전 3.6.3을 사용합니다.
1.4. v1beta2 API 버전 지원
모든 사용자 정의 리소스의 v1beta2 API 버전은 AMQ Streams 1.7에서 도입되었습니다. AMQ Streams 1.8의 경우 KafkaTopic 및 KafkaUser 이외의 모든 AMQ Streams 사용자 정의 리소스에서 v1alpha1 및 v1beta1 API 버전이 제거되었습니다.
사용자 정의 리소스를 v1beta2 로 업그레이드하면 Kubernetes v1.22에 필요한 Kubernetes CRD v1 로 이동할 수 있도록 AMQ Streams가 준비됩니다.
버전 1.7 이전의 AMQ Streams 버전에서 업그레이드하는 경우:
- AMQ Streams 1.7로 업그레이드
-
사용자 정의 리소스를
v1beta2로 변환합니다. - AMQ Streams 1.8로 업그레이드
AMQ Streams 버전 2.2로 업그레이드하기 전에 API 버전 v1beta2 를 사용하려면 사용자 정의 리소스를 업그레이드해야 합니다.
AMQ Streams 배포 및 업그레이드를 참조하십시오.
1.4.1. 사용자 정의 리소스를 v1beta2로 업그레이드
사용자 정의 리소스를 v1beta2 로의 업그레이드를 지원하기 위해 AMQ Streams는 AMQ Streams 소프트웨어 다운로드 페이지에서 다운로드할 수 있는 API 변환 툴 을 제공합니다.
사용자 정의 리소스 업그레이드를 두 단계로 수행합니다.
1 단계: 사용자 정의 리소스의 형식을 변환
API 변환 도구를 사용하여 사용자 정의 리소스의 형식을 두 가지 방법 중 하나로 v1beta2 에 적용할 수 있는 형식으로 변환할 수 있습니다.
- AMQ Streams 사용자 정의 리소스의 구성을 설명하는 YAML 파일 변환
- 클러스터에서 직접 AMQ Streams 사용자 정의 리소스 변환
또는 각 사용자 정의 리소스를 v1beta2 에 적용되는 형식으로 수동으로 변환할 수 있습니다. 사용자 정의 리소스를 수동으로 변환하는 지침은 설명서에 포함되어 있습니다.
2단계: CRD를 v1beta2로 업그레이드
다음으로 crd-upgrade 명령과 함께 API 변환 툴을 사용하여 v1beta2 를 CRD의 스토리지 API 버전으로 설정해야 합니다. 이 단계는 수동으로 수행할 수 없습니다.
전체 지침은 AMQ Streams 업그레이드를 참조하십시오.
1.5. IBM Z 및 LinuxONE 아키텍처 지원
AMQ Streams 2.2가 IBM Z 및 LinuxONE s390x 아키텍처에서 실행되도록 사용할 수 있습니다.
IBM Z 및 LinuxONE에 대한 지원은 OpenShift Container Platform 4.10 이상에서 Kafka와 함께 실행되는 AMQ Streams에 적용됩니다.
1.5.1. IBM Z 및 LinuxONE 요구사항
- OpenShift Container Platform 4.10 이상
1.5.2. IBM Z 및 LinuxONE에서 지원되지 않음
- 연결이 끊긴 OpenShift Container Platform 환경의 AMQ Streams
- AMQ Streams OPA 통합
1.6. IBM Power 아키텍처 지원
AMQ Streams 2.2가 IBM Power ppc64le 아키텍처에서 실행되도록 사용할 수 있습니다.
IBM Power에 대한 지원은 OpenShift Container Platform 4.9 이상에서 Kafka와 함께 실행되는 AMQ Streams에 적용됩니다.
1.6.1. IBM Power 요구사항
- OpenShift Container Platform 4.9 이상
1.6.2. IBM Power에서 지원되지 않음
- 연결이 끊긴 OpenShift Container Platform 환경의 AMQ Streams
1.7. UseStrimziPodSets 기능 게이트 (기술 프리뷰)
UseStrimziPodSets 기능 게이트는 StrimziPodSet 이라는 Pod를 관리하기 위한 리소스를 제어합니다. 기능 게이트를 사용하면 이 리소스가 StatefulSets 대신 사용됩니다. AMQ Streams는 OpenShift 대신 포드 생성 및 관리를 처리합니다. StatefulSets 대신 StrimziPodSets를 사용하면 기능을 더 많이 제어할 수 있습니다.
기능 게이트는 완성의 알파 수준에 있으므로 기술 프리뷰로 처리해야 합니다.
프리뷰에서는 StrimziPodSet 리소스를 테스트할 수 있는 기회를 제공합니다. 이 기능은 릴리스 2.3에서 기본적으로 활성화됩니다.
기능 게이트를 활성화하려면 Cluster Operator 구성에서 +UseStrimziPodSets 를 STRIMZI_FEATURE_GATES 환경 변수 값으로 지정합니다.
UseStrimziPodSets 기능 게이트 활성화
env:
- name: STRIMZI_FEATURE_GATES
value: +UseStrimziPodSets
UseStrimziPodSets 기능 게이트 및 Feature gate 릴리스를 참조하십시오.
1.8. UseKRaft 기능 게이트(개발 프리뷰)
Kafka 클러스터 관리자는 Cluster Operator 배포 구성에서 기능 게이트를 사용하여 기능의 하위 집합을 설정 및 해제할 수 있습니다.
Apache Kafka는 ZooKeeper의 필요성을 제거하는 중입니다. 새로운 UseKRaft 기능 게이트를 사용하면 ZooKeeper없이 KRaft (Kafka Raft metadata) 모드에서 Kafka 클러스터를 배포할 수 있습니다.
이 기능 게이트는 완성의 알파 수준에 있지만 개발 프리뷰로 처리해야 합니다.
이 기능 게이트는 실험적으로 개발 및 테스트용으로 만 사용되며 프로덕션 환경에는 사용하도록 설정되어서는 안 됩니다.
UseKRaft 기능 게이트를 활성화하려면 Cluster Operator 구성에서 STRIMZI_FEATURE_GATES 환경 변수 값으로 +UseKRaft 및 +USeStrimziPodSets 를 지정합니다. UseKRaft 기능 게이트는 UseStrimziPodSets 기능 게이트에 따라 다릅니다.
UseKRaft 기능 게이트 활성화
env:
- name: STRIMZI_FEATURE_GATES
value: +UseKRaft, +USeStrimziPodSets
현재 AMQ Streams의 KRaft 모드에는 다음과 같은 주요 제한 사항이 있습니다.
- ZooKeeper가 있는 Kafka 클러스터에서 KRaft 클러스터로 이동하거나 다른 방법으로는 지원되지 않습니다.
- Apache Kafka 버전 또는 AMQ Streams Operator의 업그레이드 및 다운그레이드는 지원되지 않습니다. 사용자가 클러스터를 삭제하고, Operator를 업그레이드하고 새 Kafka 클러스터를 배포해야 할 수 있습니다.
-
Entity Operator (사용자 Operator 및 주제 연산자 포함)는 지원되지 않습니다.
spec.entityOperator속성은Kafka사용자 정의 리소스에서 제거해야 합니다. -
간단한권한 부여는 지원되지 않습니다. - SCRAM-SHA-512 인증은 지원되지 않습니다.
-
JBOD 스토리지는 지원되지 않습니다.
type: jbod스토리지를 사용할 수 있지만 JBOD 어레이는 하나의 디스크만 포함할 수 있습니다. - liveness 및 readiness 프로브가 비활성화됩니다.
-
모든 Kafka 노드에는
컨트롤러및브로커KRaft 역할이 모두 있습니다. 별도의컨트롤러및브로커노드가 있는 Kafka 클러스터는 지원되지 않습니다.
UseKRaft 기능 게이트 및 Feature gate 릴리스를 참조하십시오.
1.9. Cruise Control의 일반 가용성
Cruise Control은 기술 프리뷰에서 GA(General Availability)로 이동합니다. Cruise Control 을 배포하고 이를 사용하여 CPU, 디스크, 네트워크 로드 등에 최적화 목표를 사용하여 Kafka 클러스터를 재조정할 수 있습니다. 균형 있는 Kafka 클러스터에서 워크로드는 브로커 Pod에 더 균등하게 분산됩니다.
Cruise Control은 Kafka 리소스의 일부로 구성 및 배포됩니다. 기본 최적화 목표를 사용하거나 요구 사항에 맞게 수정할 수 있습니다. Cruise Control의 YAML 구성 파일의 예는 예제/cruise-control/ 에서 제공됩니다.
Cruise Control이 배포되면 KafkaRebalance 사용자 정의 리소스를 다음과 같이 생성할 수 있습니다.
- 여러 최적화 목표에서 최적화 제안 생성
- 최적화 제안에 따라 Kafka 클러스터 재조정
다른 Cruise Control 기능은 현재 지원되지 않습니다. (예: 이상한 탐지, 알림, 쓰기-유효 목표), 주제 복제 요소 변경을 포함하여 현재 지원되지 않습니다.
클러스터 재조정은 Cruise Control 에서 참조하십시오.
1.10. cruise 제어 스케일링 및 재조정 모드
이제 다음 모드 중 하나에서 작업 재조정에 대한 최적화 제안을 생성할 수 있습니다.
-
full -
add-brokers -
remove-brokers
이전에는 복제본이 클러스터의 모든 브로커 간에 이동할 수 있는 전체 모드에서 제안이 생성되었습니다. 이제 add-brokers 및 remove-brokers 모드를 사용하여 확장 및 축소 작업을 고려합니다.
확장 후 add-brokers 모드를 사용합니다. 새 브로커를 지정하고 재조정 작업이 기존 브로커에서 새로 추가된 브로커로 복제본을 이동합니다. 이는 전체 클러스터를 재조정하는 것보다 더 빠른 옵션입니다.
축소하기 전에 remove-brokers 모드를 사용합니다. 제거할 브로커를 지정합니다. 즉, 리밸런스 작업에서 해당 브로커의 모든 복제본이 이동됩니다.
1.11. 변경 데이터 캡처 통합을 위한 Debezium
Red Hat Debezium은 분산 변경 데이터 캡처 플랫폼입니다. 데이터베이스의 행 수준 변경 사항을 캡처하고, 변경 이벤트 레코드를 생성하며, 해당 레코드를 Kafka 주제로 스트리밍합니다. Debezium은 Apache Kafka를 기반으로 합니다. Debezium을 AMQ Streams와 함께 배포하고 통합할 수 있습니다. AMQ Streams를 배포한 후 Kafka Connect를 통해 Debezium을 커넥터 구성으로 배포합니다. Debezium은 변경 이벤트 레코드를 OpenShift의 AMQ Streams에 전달합니다. 애플리케이션은 이러한 변경 이벤트 스트림을 읽고 발생한 순서대로 변경 이벤트에 액세스할 수 있습니다.
Debezium에는 다음과 같은 여러 용도가 있습니다.
- 데이터 복제
- 캐시 및 검색 인덱스 업데이트
- 모놀리식 애플리케이션 간소화
- 데이터 통합
- 스트리밍 쿼리 활성화
Debezium에서는 다음과 같은 일반적인 데이터베이스에 대한 커넥터( Kafka Connect 기반)를 제공합니다.
- Db2
- MongoDB
- MySQL
- PostgreSQL
- SQL Server
AMQ Streams를 사용한 Debezium 배포에 대한 자세한 내용은 제품 설명서 를 참조하십시오.
1.12. 서비스 레지스트리
서비스 레지스트리를 데이터 스트리밍을 위한 서비스 스키마의 중앙 집중식 저장소로 사용할 수 있습니다. Kafka의 경우 서비스 레지스트리를 사용하여 Apache Avro 또는 JSON 스키마를 저장할 수 있습니다.
서비스 레지스트리는 서버 측 엔드포인트를 통해 클라이언트 애플리케이션에서 스키마를 등록하고 쿼리하는 REST API 및 Java REST 클라이언트를 제공합니다.
서비스 레지스트리를 사용하면 클라이언트 애플리케이션 구성에서 스키마 관리 프로세스를 분리합니다. 클라이언트 코드에서 URL을 지정하여 레지스트리의 스키마를 사용하도록 애플리케이션을 활성화합니다.
예를 들어 메시지를 직렬화 및 역직렬화할 수 있는 스키마는 레지스트리에 저장할 수 있으며, 이 스키마는 전송 및 수신하는 메시지가 해당 스키마와 호환되는지 확인하는 애플리케이션에서 참조됩니다.
Kafka 클라이언트 애플리케이션은 런타임 시 서비스 레지스트리에서 스키마를 내보내거나 가져올 수 있습니다.
AMQ Streams와 함께 서비스 레지스트리를 사용하는 방법에 대한 자세한 내용은 서비스 레지스트리 설명서 를 참조하십시오.
2장. 기능 개선
AMQ Streams 2.2에는 여러 개선 사항이 추가되었습니다.
2.1. Kafka 3.2.3 개선 사항
Kafka 3.2.0, 3.2.1, 3.2.3에서 도입된 개선 사항에 대한 개요는 Kafka 3.2.0 릴리스 노트,Kafka 3.2.1 릴리스 노트 및 Kafka 3.2.3 릴리스 노트 를 참조하십시오.
2.2. 명령줄에서 Cruise Control 상태 추적
이제 최적화 제안의 상태를 확인하는 것이 더 쉬워졌습니다. 리소스 구성 YAML을 검사하는 대신 명령줄에서 상태를 확인할 수 있습니다.
제안서를 실행할 때 다음 명령을 실행하고 최적화 제안의 상태가 ProposalReady 로 변경될 때까지 기다립니다.
oc get kafkarebalance -o wide -w -n <namespace>PendingProposal-
PendingProposal상태는 리밸런스 Operator가 Cruise Control API를 폴링하여 최적화 제안이 준비되었는지 확인합니다. ProposalReady-
ProposalReady상태는 최적화 제안이 검토 및 승인을 위해 준비되었음을 의미합니다.
상태가 ProposalReady 로 변경되면 최적화 제안은 승인할 준비가 된 것입니다.
최적화 제안 생성 및 최적화 제안 승인 에서 참조하십시오.
2.3. 유지 관리 기간 동안 사용자 인증서 갱신
유지 관리 시간 창을 사용하면 Kafka 및 ZooKeeper 클러스터의 특정 롤링 업데이트를 편리하게 시작할 수 있습니다. 이제 User Operator에서 유지 관리 기간이 지원됩니다. 독립 실행형 Operator가 아닌 Cluster Operator를 사용하여 User Operator를 배포한 경우 사용자 인증서의 자동 갱신이 스케줄에 포함됩니다.
독립 실행형 User Operator를 배포하는 경우 사용자 인증서가 갱신되는 동안 유지 관리 시간 기간을 구성할 수 있습니다. STRIMZI_MAINTENCE_TIME_ ECDHEDOWS 환경 변수의 Cron 표현식으로 시간 창을 지정합니다.
독립 실행형 사용자 Operator 배포를 참조하십시오.
2.4. Cruise Control 주제 이름 변경
이제 Cruise Control에 의해 자동으로 생성되는 메트릭과 관련된 주제의 이름을 변경할 수 있습니다. 다음 Cruise Control 구성 속성을 사용하여 이름을 변경할 수 있습니다.
Cruise Control 주제 이름 변경 예
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
# ...
cruiseControl:
# ...
config: 1
# ...
metric.reporter.topic: cruise-control-metrics-reporter-topic-name
partition.metric.sample.store.topic: cruise-control-partitions-metrics-name
broker.metric.sample.store.topic: cruise-control-broker-metrics
# ...
# ...
기존 배포의 주제 이름을 변경하는 경우 이전 이름이 있는 항목을 수동으로 제거해야 합니다.
2.5. ZooKeeper 없이 Cruise Control 사용
이제 Cruise Control은 Kafka API를 사용하여 ZooKeeper 없이 실행됩니다. ZooKeeper와의 보안 통신에 사용된 TLS 사이드카가 제거되었습니다.
Kafka 리소스의 Cruise Control에 대한 TLS 사이드카 구성이 더 이상 필요하지 않습니다. 이러한 이유로 .spec.cruiseControl.tlsSidecar 및 .spec.cruiseControl.template.tlsSidecar 속성은 더 이상 사용되지 않습니다.
2.6. MirrorMaker 2.0에 대한 랙 인식 설정
MirrorMaker 2.0 리소스 설정에서 랙 인식 기능을 활성화할 수 있습니다. 이는 리전이 아닌 동일한 위치 내의 배포를 위한 특수 옵션입니다. 리더 복제본이 아닌 가장 가까운 복제본에서 커넥터를 사용하도록 하려면 이 옵션을 사용할 수 있습니다.
rack 구성의 topologyKey 는 rack ID가 포함된 노드 레이블과 일치해야 합니다. 다음 예에서는 표준 topology.kubernetes.io/zone 레이블이 지정됩니다.
MirrorMaker 2.0의 Rack 구성
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
name: my-mirror-maker2
spec:
version: 3.2.3
# ...
rack:
topologyKey: topology.kubernetes.io/zone
가장 가까운 복제본에서 사용하려면 Kafka 브로커 구성에서 RackAwareReplicaSelector 도 활성화해야 합니다.
복제본 인식 선택기가 활성화된 rack 구성의 예
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
kafka:
# ...
rack:
topologyKey: topology.kubernetes.io/zone
config:
# ...
replica.selector.class: org.apache.kafka.common.replica.RackAwareReplicaSelector
# ...
Kafka MirrorMaker 2.0 및 Rack 스키마 참조 구성을 참조하십시오.
2.7. 사용 가능한 메모리의 백분율에 따라 힙 크기 설정
구성에 힙 크기를 지정하지 않으면 Cluster Operator에서 기본 힙 크기를 자동으로 적용합니다. Cluster Operator는 메모리 리소스 구성의 백분율에 따라 기본 최대값 및 최소 힙 값을 설정합니다. 기본적으로 할당된 사용 가능한 메모리는 이제 다음 표에 표시된 수준으로 설정됩니다.
표 2.1. 구성 요소의 기본 힙 설정
| 구성 요소 | 힙에 할당된 사용 가능한 메모리의 백분율 | 최대 제한 |
|---|---|---|
| Kafka | 50% | 5GB |
| ZooKeeper | 75% | 2GB |
| Kafka Connect | 75% | 없음 |
| MirrorMaker 2.0 | 75% | 없음 |
| MirrorMaker | 75% | 없음 |
| 크루즈 컨트롤 | 75% | 없음 |
| Kafka 브리지 | 50% | 31 Gi |
3장. 기술 프리뷰
기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있으므로 프로덕션 환경에서 기술 프리뷰 기능을 구현하는 것을 권장하지 않습니다. 이 기술 프리뷰 기능을 사용하면 향후 제품 혁신에 빠르게 액세스할 수 있으므로 개발 과정에서 기능을 테스트하고 피드백을 제공할 수 있습니다. 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
3.1. 새로운 기능 게이트
UseKRaft 및 UseStrimziPodSets 기능 게이트의 미리 보기를 사용할 수 있습니다.
1장. 기능을 참조하십시오.
3.2. Kafka 정적 할당량 플러그인 구성
Kafka 정적 할당량 플러그인을 사용하여 Kafka 클러스터의 브로커에 대한 처리량 및 스토리지 제한을 설정합니다. 플러그인을 활성화하고 Kafka 리소스를 구성하여 제한을 설정합니다. 브로커와 상호 작용하는 클라이언트에 제한을 두도록 바이트 비율 임계값 및 스토리지 할당량을 설정할 수 있습니다.
Kafka 정적 할당량 플러그인 구성의 예
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
kafka:
# ...
config:
client.quota.callback.class: io.strimzi.kafka.quotas.StaticQuotaCallback
client.quota.callback.static.produce: 1000000
client.quota.callback.static.fetch: 1000000
client.quota.callback.static.storage.soft: 400000000000
client.quota.callback.static.storage.hard: 500000000000
client.quota.callback.static.storage.check-interval: 5
4장. Kafka 중단 변경
이 섹션에서는 계속 작동하려면 AMQ Streams에 대한 해당 변경이 필요한 Kafka 변경 사항에 대해 설명합니다.
4.1. Kafka의 예제 파일 커넥터 사용
Kafka에는 기본적으로 CLASSPATH 및 plugin.path 에 예제 파일 ConnectorSource Connector 및ECDHE Sink Connector가 포함되어 있지 않습니다. 이러한 예제 커넥터를 계속 사용할 수 있도록 AMQ Streams가 업데이트되었습니다. 이제 모든 커넥터와 같이 플러그인 경로에 예제를 추가해야 합니다.
두 가지 예제 커넥터 구성 파일이 제공됩니다.
-
examples/connect/kafka-connect-은 파일 커넥터로 새 Kafka Connect 이미지를 빌드하기 위해 배포할 수 있는 Kafka Connect 빌드 구성을 제공합니다.build.yaml -
examples/connect/source-connector.yaml은 파일 커넥터를KafkaConnector리소스로 배포하는 데 필요한 구성을 제공합니다.
KafkaConnector 리소스 배포 및 커넥터 플러그인을 사용하여 Kafka Connect 확장 에서 참조하십시오.
5장. 더 이상 사용되지 않는 기능
이 릴리스에서 더 이상 사용되지 않는 기능은 아래에 설명되어 있으며 이전 AMQ Streams 릴리스에서 지원되는 기능은 다음과 같습니다.
5.1. OpenTracing
OpenTracing에 대한 지원은 더 이상 지원되지 않습니다.
이제 Jaeger 클라이언트가 사용 중지되고 OpenTracing 프로젝트가 아카이브됩니다. 따라서 향후 Kafka 버전에 대한 지원을 보장할 수 없습니다. OpenTelemetry 프로젝트를 기반으로 새로운 추적 구현이 도입되었습니다.
5.2. Java 8
Java 8에 대한 지원은 Kafka 3.0.0 및 AMQ Streams 2.0에서 더 이상 사용되지 않습니다. Java 8은 향후 클라이언트를 포함한 모든 AMQ Streams 구성 요소에 대해 지원되지 않습니다.
AMQ Streams는 Java 11을 지원합니다. 새 애플리케이션을 개발할 때 Java 11을 사용합니다. 현재 Java 8을 사용하는 애플리케이션을 Java 11으로 마이그레이션할 계획입니다.
5.3. Kafka MirrorMaker 1
Kafka MirrorMaker는 데이터 센터 내 또는 여러 데이터 센터 간에 두 개 이상의 활성 Kafka 클러스터 간에 데이터를 복제합니다. Kafka MirrorMaker 1은 Kafka 3.0.0에서 더 이상 사용되지 않으며 Kafka 4.0.0에서 제거됩니다. MirrorMaker 2.0은 사용 가능한 유일한 버전입니다. MirrorMaker 2.0은 클러스터 간 데이터 전송을 관리하는 Kafka Connect 프레임워크를 기반으로 합니다.
그 결과 Kafka MirrorMaker 1을 배포하는 데 사용되는 AMQ Streams KafkaMirrorMaker 사용자 정의 리소스가 더 이상 사용되지 않습니다. Kafka 4.0.0이 채택되면 KafkaMirrorMaker 리소스가 AMQ Streams에서 제거됩니다.
MirrorMaker 1을 AMQ Streams 설명서에서 MirrorMaker 와 마찬가지로 사용하는 경우 IdentityReplicationPolicy 와 함께 KafkaMirrorMaker2 사용자 정의 리소스를 사용합니다. MirrorMaker 2.0 대상 클러스터에 복제된 항목의 이름을 바꿉니다. IdentityReplicationPolicy 구성이 자동 이름 변경을 덮어씁니다. 이를 사용하여 MirrorMaker 1과 동일한 활성/패시 방향 복제를 생성합니다.
Kafka MirrorMaker 2.0 클러스터 구성을 참조하십시오.
5.4. Cruise Control TLS 사이드카 속성
이번 릴리스에서는 Cruise Control TLS 사이드카가 제거되었습니다. 결과적으로 .spec.cruiseControl.tlsSidecar 및 .spec.cruiseControl.template.tlsSidecar 속성이 더 이상 사용되지 않습니다. 속성은 무시되며 나중에 제거됩니다.
5.5. ID 복제 정책
ID 복제 정책은 원격 주제의 자동 이름 변경을 재정의하기 위해 MirrorMaker 2.0과 함께 사용됩니다. 소스 클러스터 이름 앞에 이름 앞에 추가하지 않고 주제에서 원래 이름을 유지합니다. 이 선택적 설정은 활성/수동 백업 및 데이터 마이그레이션에 유용합니다.
AMQ Streams Identity Replication Policy 클래스(io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy)는 더 이상 사용되지 않으며 향후 제거될 예정입니다. Kafka의 자체 ID 복제 정책(class org.apache.kafka.connect.mirror.IdentityReplicationPolicy)을 사용하도록 업데이트할 수 있습니다.
Kafka MirrorMaker 2.0 클러스터 구성을 참조하십시오.
5.6. ListenerStatus type 속성
ListenerStatus 의 type 속성은 더 이상 사용되지 않으며 나중에 제거됩니다. ListenerStatus 는 내부 및 외부 리스너의 주소를 지정하는 데 사용됩니다. 유형을 사용하는 대신 주소는 이제 이름으로 지정됩니다.
ListenerStatus 스키마 참조를 참조하십시오.
5.7. Cruise Control 용량 구성
disk 및 cpuUtilization 용량 구성 속성은 더 이상 사용되지 않고 무시되며 나중에 제거됩니다. 이 속성은 리소스 기반 최적화 목표를 손상시키는지 결정하기 위해 최적화 제안에서 용량 제한을 설정하는 데 사용되었습니다. 이제 디스크 및 CPU 용량 제한이 AMQ Streams에서 자동으로 생성됩니다.
크루즈 제어 구성을 참조하십시오.
6장. 해결된 문제
다음 섹션에서는 AMQ Streams 2.2.x에서 수정된 문제를 나열합니다. Red Hat은 최신 패치 릴리스로 업그레이드할 것을 권장합니다.
Kafka 3.2.0, 3.2.1, 3.2.3에서 수정된 문제에 대한 자세한 내용은 Kafka 3.2.0 릴리스 노트,Kafka 3.2.1 릴리스 노트 및 Kafka 3.2.3 릴리스 노트 를 참조하십시오.
6.1. AMQ Streams 2.2.1의 수정된 문제
AMQ Streams 2.2.1 패치 릴리스(Long Term Support)를 사용할 수 있습니다.
AMQ Streams 2.2.1에서 해결된 문제에 대한 자세한 내용은 AMQ Streams 2.2.x 해결 문제를 참조하십시오.
6.2. AMQ Streams 2.2.0 관련 문제 해결
표 6.1. 해결된 문제
| 문제 번호 | 설명 |
|---|---|
| [KAFKA] MirrorMaker 2.0 부정적인 지연 | |
| Topic Operator 시작 중 "VertxException: Thread 차단" | |
| Bridge는 slf4j-api 및 log4j-api를 동시에 사용해서는 안 됩니다. | |
| KafkaRoller의 로깅 개선 | |
| StrimziPodSet 리소스의 무차별 삭제 수정 | |
| KafkaConnector 리소스의 조정 실패가 Operator 메트릭에 계산되지 않음 | |
| Rolling update force-rolls pods during cluster startup | |
| 밀리바이트 단위로 스토리지 구문 분석 지원 추가 | |
| 잘못된 스토리지 장치를 사용할 때 조정 실패 | |
| Cruise Control 배포의 불필요한 롤링 업데이트 방지 | |
| Pod에 대한 주석 ANNO_STRIMZI_IO_CLUSTER_CA_CERT_GENERATION이 없으면 Kafka 조정 중에 CO 로그에 오류가 발생합니다. | |
| curl 다운로드가 실패하면 Kafka Connect Build가 실패합니다. | |
| KafkaRebalance 사용자 정의 리소스의 오류가 올바르게 기록되지 않음 | |
| AMQ Streams Drain 정리에서 FIPS 모드 처리 | |
| [KAFKA] 인증되지 않은 클라이언트가 브로커에서 OutOfMemoryError를 유발할 수 있습니다. |
표 6.2. CVE(Common vulnerabilities and exposures) 수정
| 문제 번호 | 설명 |
|---|---|
| CVE-2020-36518 jackson-databind: 중첩 객체의 대규모 깊이를 통한 서비스 거부 | |
| CVE-2022-24823 netty: 중요한 데이터를 포함하는 세계에서 읽을 수 있는 임시 파일 | |
| CVE-2022-25647 com.google.code.gson-gson: 신뢰할 수 없는 데이터의 설명 com.google.code.gson-gson |
7장. 확인된 문제
이 섹션에는 OpenShift에서 AMQ Streams 2.2에 대한 알려진 문제가 나열되어 있습니다.
7.1. IPv6 클러스터의 AMQ Streams Cluster Operator
AMQ Streams Cluster Operator는 IPv6(Internet Protocol 버전 6) 클러스터에서 시작되지 않습니다.
해결방법
이 문제에는 두 가지 해결방법이 있습니다.
해결방법 1: KUBERNETES_MASTER 환경 변수 설정
OpenShift Container Platform 클러스터의 Kubernetes 마스터 노드의 주소를 표시합니다.
oc cluster-info Kubernetes master is running at <master_address> # ...마스터 노드의 주소를 복사합니다.
모든 Operator 서브스크립션을 나열합니다.
oc get subs -n <operator_namespace>AMQ Streams의
서브스크립션리소스를 편집합니다.oc edit sub amq-streams -n <operator_namespace>spec.config.env에서KUBERNETES_MASTER환경 변수를 추가하고 Kubernetes 마스터 노드의 주소로 설정합니다. 예를 들면 다음과 같습니다.apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: amq-streams namespace: <operator_namespace> spec: channel: amq-streams-1.8.x installPlanApproval: Automatic name: amq-streams source: mirror-amq-streams sourceNamespace: openshift-marketplace config: env: - name: KUBERNETES_MASTER value: MASTER-ADDRESS
- 편집기를 저장한 후 종료합니다.
서브스크립션이 업데이트되었는지 확인합니다.oc get sub amq-streams -n <operator_namespace>새 환경 변수를 사용하도록 Cluster Operator 배포가 업데이트되었는지 확인합니다.
oc get deployment <cluster_operator_deployment_name>
해결 방법 2: 호스트 이름 확인 비활성화
모든 Operator 서브스크립션을 나열합니다.
oc get subs -n <operator_namespace>AMQ Streams의
서브스크립션리소스를 편집합니다.oc edit sub amq-streams -n <operator_namespace>spec.config.env에서KUBERNETES_DISABLE_HOSTNAME_VERIFICATION환경 변수를 추가하고true로 설정합니다. 예를 들면 다음과 같습니다.apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: amq-streams namespace: <operator_namespace> spec: channel: amq-streams-1.8.x installPlanApproval: Automatic name: amq-streams source: mirror-amq-streams sourceNamespace: openshift-marketplace config: env: - name: KUBERNETES_DISABLE_HOSTNAME_VERIFICATION value: "true"- 편집기를 저장한 후 종료합니다.
서브스크립션이 업데이트되었는지 확인합니다.oc get sub amq-streams -n <operator_namespace>새 환경 변수를 사용하도록 Cluster Operator 배포가 업데이트되었는지 확인합니다.
oc get deployment <cluster_operator_deployment_name>
7.2. cruise 제어 CPU 사용률 추정
AMQ Streams에 대한 크루즈 컨트롤에는 CPU 사용률 추정 계산과 관련된 알려진 문제가 있습니다. CPU 사용률은 브로커 Pod의 정의된 용량의 백분율로 계산됩니다. 이 문제는 다양한 CPU 코어가 있는 노드에서 Kafka 브로커를 실행할 때 발생합니다. 예를 들어 node1에는 두 개의 CPU 코어가 있을 수 있으며 node2에는 4개의 CPU 코어가 있을 수 있습니다. 이 경우 Cruise Control은 브로커의 CPU 부하를 강조하고 과대 추정할 수 있습니다. 이 문제로 인해 Pod가 부하가 많은 경우 클러스터 재조정을 방지할 수 있습니다.
해결방법
이 문제에는 두 가지 해결방법이 있습니다.
해결방법 1: Equal CPU 요청 및 제한
Kafka.spec.kafka.resources 에서 CPU 제한과 동일한 CPU 요청을 설정할 수 있습니다. 이렇게 하면 모든 CPU 리소스가 미리 예약되며 항상 사용할 수 있습니다. 이 구성을 통해 Cruise Control은 CPU 목표에 따라 리밸런스 제안을 준비할 때 CPU 사용률을 적절하게 평가할 수 있습니다.
해결 방법 2: CPU 목표를 제외
Cruise Control 구성에 지정된 하드 및 기본 목표에서 CPU 목표를 제외할 수 있습니다.
CPU 목표 없이 Cruise Control 구성의 예
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
kafka:
# ...
zookeeper:
# ...
entityOperator:
topicOperator: {}
userOperator: {}
cruiseControl:
brokerCapacity:
inboundNetwork: 10000KB/s
outboundNetwork: 10000KB/s
config:
hard.goals: >
com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.MinTopicLeadersPerBrokerGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal
default.goals: >
com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.MinTopicLeadersPerBrokerGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.PotentialNwOutGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskUsageDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundUsageDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundUsageDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.TopicReplicaDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.LeaderReplicaDistributionGoal,
com.linkedin.kafka.cruisecontrol.analyzer.goals.LeaderBytesInDistributionGoal
자세한 내용은 Insufficient CPU capacity 를 참조하십시오.
7.3. 사용자 Operator 확장성
User Operator는 동시에 여러 사용자를 생성할 때 시간 초과할 수 있습니다. 조정에 시간이 오래 걸릴 수 있습니다.
해결방법
이 문제가 발생하면 동시에 생성 중인 사용자 수를 줄입니다. 더 많은 사용자를 생성하기 전에 준비가 될 때까지 기다리십시오.
8장. Red Hat 제품과의 통합 지원
AMQ Streams 2.2는 다음 Red Hat 제품과의 통합을 지원합니다.
- Red Hat Single Sign-On
- OAuth 2.0 인증 및 OAuth 2.0 권한 부여를 제공합니다.
- Red Hat 3scale API Management
- Kafka 브리지를 보호하고 추가 API 관리 기능을 제공합니다.
- Red Hat Debezium
- 데이터베이스를 모니터링하고 이벤트 스트림을 생성합니다.
- Red Hat Service Registry
- 데이터 스트리밍을 위한 서비스 스키마의 중앙 집중식 저장소를 제공합니다.
이러한 제품에서 AMQ Streams 배포에 도입할 수 있는 기능에 대한 자세한 내용은 제품 설명서를 참조하십시오.
9장. 중요한 링크
2023-04-06에 최종 업데이트된 문서