Strimzi 1.3.0: 달라진 운영 기본값과 보안 설정의 선택지

Kubernetes에서 Kafka의 배포와 운영을 관리하는 Strimzi가 한국 시각 2026년 10월 13일 1.3.0을 출시했습니다. 이번 버전은 Kubernetes 최소 버전을 높이고, Connect 이미지 빌드와 롤링 업데이트의 기본 동작을 바꿉니다. 내부 통신 보안과 인증서 발급에도 새로운 선택지가 생겼습니다.

업그레이드를 준비한다면 기존 설정에 영향을 주는 변화부터 확인하면 됩니다. 내부 보안 설정과 cert-manager 연동은 아직 Early Access이므로 별도 시험 환경에서 평가할 기능입니다. 이 글은 공식 릴리스와 1.3.0 태그의 문서를 바탕으로, 각 변경의 의미와 적용 전에 확인할 내용을 정리합니다.

먼저 확인할 변화

영역	1.3.0에서 달라진 점	확인할 대상
실행 환경	Kubernetes 최소 버전이 1.32로 상향	1.30·1.31 클러스터
Kafka Connect 빌드	Buildah GA, Kaniko 제거	Strimzi 내장 이미지 빌드
롤링 업데이트	Pod의 background 삭제 기본 활성화	네트워크 플러그인과 정상 종료 동작
내부 보안	암호화·인증 설정을 Early Access로 제공	내부 연결의 보안 요구사항
인증서	cert-manager 연동 Early Access	인증서 발급·갱신 체계

각 변경의 전체 목록은 1.3.0 변경 기록에서 확인할 수 있습니다.

Kubernetes와 Kafka 버전을 따로 확인한다

1.3.0은 Kubernetes 1.32 이상을 지원하며, 공식 테스트 범위는 1.32~1.37입니다. 이전 1.2.0의 테스트 범위가 1.30~1.36이었으므로 Kubernetes 1.30이나 1.31을 사용한다면 플랫폼 업그레이드가 선행돼야 합니다.

Kafka는 4.2.2 지원이 추가됐습니다. 전체 지원 목록은 4.2.0, 4.2.1, 4.2.2, 4.3.0, 4.3.1입니다. 4.3.1 지원은 이전 Strimzi 1.2.0부터 이어집니다. 공식 버전 호환표

업그레이드 검토는 현재 상태를 기록하는 것부터 시작할 수 있습니다. 다음 명령은 조회만 하며, kafka는 실제 Kafka 리소스가 있는 네임스페이스로 바꿉니다.

kubectl version -o yaml
kubectl get kafka -n kafka \
  -o custom-columns='NAME:.metadata.name,KAFKA:.spec.kafka.version,IMAGE:.spec.kafka.image'
kubectl get kafkaconnect -n kafka \
  -o custom-columns='NAME:.metadata.name,KAFKA:.spec.version,IMAGE:.spec.image'

IMAGE가 비어 있으면 해당 사용자 정의 리소스(CR)에 이미지가 직접 지정되지 않은 것입니다. 이때는 실제 Pod 이미지와 Operator의 이미지 매핑을 확인합니다. Operator, Kafka, 사용자 이미지의 기반 버전을 함께 기록해 두면 업그레이드 전후를 비교하기 쉽습니다.

0.x에서 올라오는 환경은 CRD API도 확인해야 합니다. v1만 지원하는 정책은 1.0.0부터 적용된 기존 요구사항입니다. v1beta2 등을 사용한다면 리소스와 CRD 변환을 포함한 별도의 업그레이드 절차를 먼저 확인합니다. 릴리스의 API 전환 안내

Connect 내장 빌드는 Buildah만 사용한다

UseConnectBuildWithBuildah가 정식 지원 단계(GA)가 되면서, Strimzi의 Connect 이미지 빌드 도구가 Buildah로 고정됐습니다. Kaniko는 제거됐고 feature gate로 되돌릴 수도 없습니다. 적용 대상은 KafkaConnect.spec.build로 플러그인을 포함한 이미지를 만드는 환경입니다. 1.3.0 변경 기록

기존 플러그인 목록으로 이미지를 다시 빌드해 보면 영향을 확인할 수 있습니다. 빌드 Pod 생성부터 플러그인 다운로드, 레지스트리 인증·업로드, 완성된 이미지의 커넥터 로딩까지 이어서 검증합니다. 특히 Kaniko 사용을 유지하려고 -UseConnectBuildWithBuildah를 명시해 둔 배포 설정은 정리 대상입니다.

사용자 이미지를 쓰는 환경에서는 시작 스크립트와 JMX 설정도 확인합니다. 빌드가 성공했더라도 Connect 실행과 메트릭 수집이 정상인지까지 봐야 검증이 끝납니다.

롤링 업데이트에서 Pod 삭제 방식이 바뀐다

UseBackgroundPodDeletion은 Beta로 올라가 기본 활성화됩니다. 롤링 업데이트에서 Pod를 삭제할 때 background deletion propagation을 사용하도록 바뀌는 것입니다.

일부 Kubernetes 네트워크 플러그인(CNI)은 Pod 삭제 중 네트워크를 너무 일찍 정리해 Kafka의 정상 종료 통신을 끊을 수 있습니다. 이 기능은 그런 환경에서 종료 통신이 끝날 때까지 네트워크를 유지하려는 변경입니다. 롤링 업데이트를 시험할 때는 Pod의 Ready 상태와 함께 브로커 종료 로그, 컨트롤러 통신, 동기화된 복제본 집합(ISR)의 복구 시간을 비교합니다. CNI와 종료 동작에 관한 배경은 공식 기능 설명을 참고할 수 있습니다.

필요하면 Cluster Operator의 기존 STRIMZI_FEATURE_GATES 값에 다음 항목을 반영해 비활성화할 수 있습니다. 아래는 Deployment 컨테이너 환경 변수의 일부이며, 다른 feature gate 설정이 있다면 함께 유지합니다.

env:
  - name: STRIMZI_FEATURE_GATES
    value: "-UseBackgroundPodDeletion"

문서의 기본값 표기: 2026년 10월 14일 기준 배포 문서의 개별 설명에는 기본 비활성화라는 문구가 남아 있습니다. 이 글은 릴리스 노트와 1.3.0의 FeatureGates.java에 명시된 기본 활성화를 기준으로 설명합니다.

내부 통신의 암호화와 인증을 선택할 수 있다

strimzi.io/internal-cluster-security 어노테이션으로 내부 통신의 암호화와 인증 방식을 선택할 수 있습니다. 별도로 설정하지 않으면 기존과 같은 **TLS 암호화 + 인증서 기반 상호 인증(mTLS)**을 사용합니다. 애플리케이션이 접속하는 클라이언트 리스너의 보안은 별도로 설정합니다.

새 선택지 중 하나는 Kubernetes ServiceAccount 토큰을 이용한 내부 인증입니다. 인증서 대신 Kubernetes의 서비스 계정으로 내부 구성 요소를 인증할 수 있게 됩니다. 이 기능은 Early Access이며 어노테이션도 향후 바뀔 수 있는 임시 설정 방식입니다. 토큰 인증을 시험하기 전에는 필요한 권한(RBAC)과 토큰 발급자(issuer) 조건을 확인합니다. 내부 보안 설정과 전제조건

운영에서 가장 중요한 제약은 기존 클러스터의 내부 보안 방식을 바꾸는 절차에 중단 시간이 필요하다는 것입니다. 어노테이션만 바꾸면 기록된 .status.clusterSecurity와 충돌해 Operator의 상태 조정(reconciliation)이 실패합니다. 공식 절차는 상태 조정 일시 중지, 클러스터 정지, 보안 상태 재설정을 포함합니다. 일반적인 롤링 설정 변경으로 취급하지 말고 별도의 유지보수 작업으로 계획해야 합니다. 기존 클러스터의 보안 변경 절차

cert-manager에 인증서 발급을 맡길 수 있다

cert-manager가 Kafka 구성 요소의 인증서를 발급하도록 연동할 수 있습니다. 공식 릴리스는 이 기능이 Early Access이며 프로덕션 사용을 권장하지 않는다고 명시합니다. 릴리스 안내

연동할 때는 CA 유형을 cert-manager로 정하고 generateCertificateAuthority: false를 지정합니다. 여기에 인증서를 발급할 Issuer 또는 ClusterIssuer 참조와 신뢰할 CA 인증서를 제공합니다.

클라이언트 인증서는 사용자가 cert-manager로 발급하고, KafkaUser에는 tls-external 인증을 설정합니다. 발급뿐 아니라 갱신된 인증서를 클라이언트가 다시 읽는지도 검증해야 합니다. 기존 클러스터를 전환할 때는 여러 단계의 롤링 재시작이 발생합니다. cert-manager 설정 절차

CA 전환 후 리소스가 남는 문제도 알려져 있습니다. cert-manager CA에서 custom CA로 전환하면 기존 Certificate 리소스가 남아 수동 삭제가 필요합니다. 전환을 시험할 때는 되돌리기 절차와 남은 리소스 정리도 함께 확인합니다. 1.3.0 Known issues

함께 챙길 운영 변경

나머지 변경은 사용 중인 기능에 맞춰 확인하면 됩니다. 아래 항목은 1.3.0 변경 기록에 정리돼 있습니다.

• Projected ServiceAccount 토큰: Strimzi 관리 Pod에 마운트할 수 있습니다. 이 기능만으로 Kafka 인증이 자동 전환되지는 않습니다. 추가 projected volume에서 현재 지원하는 소스는 ServiceAccount 토큰입니다.
• PKCS12 사용 중단 예고(deprecated): 1.3.0에서는 계속 사용할 수 있습니다. 향후 릴리스에서 STRIMZI_PKCS12_KEYSTORE_GENERATION 기본값을 false로 바꿀 예정이므로 .p12 파일에 의존하는 클라이언트와 배포 스크립트를 미리 찾아두면 좋습니다.
• Kafka Exporter 1.10.0, HTTP Bridge 1.2.0: 해당 구성 요소를 사용한다면 메트릭 수집과 HTTP 연동을 검증 항목에 넣습니다.
• 예제 Grafana 대시보드 보강: fenced broker, offline replica, ISR 축소·확대·갱신 실패 패널이 추가됐습니다. 기존에 가져온 대시보드는 새 예제와 비교해 반영할 항목을 골라야 합니다.

업그레이드 검토 순서

이번 릴리스를 적용한다면 다음 순서로 변경을 나누어 검증하는 것을 권합니다.

1. Kubernetes 버전, CRD API, Kafka 버전과 사용자 이미지의 호환성을 확인합니다.
2. 현재 feature gate 설정에서 Buildah 비활성화 옵션과 Pod 삭제 방식의 명시적 재정의를 찾습니다.
3. 시험 환경에서 Connect 이미지 빌드와 Kafka 롤링 업데이트를 수행하고, 종료·복구 시간과 클라이언트 오류를 비교합니다.
4. PKCS12 의존성과 Exporter·Bridge·대시보드 변경을 확인합니다.
5. 내부 보안 방식 변경과 cert-manager 도입은 별도 실험으로 검증합니다.

실제 적용 순서는 설치 방식별 Strimzi 1.3.0 업그레이드 문서를 따릅니다. 위 목록은 검토 기준이며, 이 글에서 실제 클러스터 업그레이드를 실행해 검증한 결과는 아닙니다.

함께 읽기 좋은 글

• Strimzi를 안전하게 확장하는 Kafka 이미지는 무엇을 지켜야 할까: 사용자 이미지를 갱신할 때 보존해야 할 실행·관측 경계를 설명합니다.
• Kafka Broker가 느려졌지만 Kafka가 원인은 아니었다: ISR 변화를 네트워크·스토리지 계층의 신호와 함께 해석하는 사례입니다.