day-log

Kafka 3.9를 다리 삼아 KRaft로 넘어가는 법

Kafka 4.0이 나오면서 ZooKeeper 지원이 완전히 잘려나갔다. 더 정확히는, 3.9가 ZK를 지원하는 마지막 버전이고 4.0부터는 KRaft 전용이다. 우리 팀도 3.7에서 한동안 버티고 있었는데, 보안 패치 백포팅이 점점 줄어드는 게 보여서 결국 마이그레이션 일정을 잡았다. 클러스터 8대(브로커 24개, ZK 5노드 앙상블)를 다운타임 없이 옮겨야 하는 상황이라, 정리 차원에서 절차를 적어둔다.왜 3.9를 거쳐야 하는가4.0으로 직행이 안 된다. 공식 가이드에서도 명시적으로 "3.x에서 KRaft로 먼저 옮긴 다음 4.0으로 올려라"라고 못 박는다. 그 이유는 마이그레이션 도구 자체가 3.x 브로커 안에 들어있기 때문이다. 3.4에서 처음 등장했고, 3.7부터 production-ready,..

3월 20일자로 ingress-nginx가 공식 EOL이 됐다. 같은 날 ingress2gateway 1.0이 GA로 풀렸다. 두 이벤트가 같은 날 풀린 게 우연이 아니다 — 업스트림에서 "이제 진짜 옮길 때다"라고 못박은 거다.EOL 전부터 우리 팀도 마이그레이션을 시도했는데, 0.x 시절 ingress2gateway는 ingress-nginx 어노테이션을 3개밖에 못 바꿨다. 그래서 일단 미뤄두고 있었는데 1.0이 나오면서 30개 이상 지원으로 확 늘었다. 마침 옮길 만한 시점이다 싶어서, 지난 2주간 스테이징 → 프로덕션 일부 클러스터까지 옮겨봤다. 그 과정 정리.옮기기 전에 알아둘 것Gateway API는 Ingress 리소스 하나에 다 욱여넣었던 라우팅 + 어노테이션 정글을 두 단계로 쪼갠다. ..

작년 KubeCon Salt Lake City 끝나고 팀에서 한참 얘기가 나왔던 게 EKS Pod Identity였다. 우리 팀은 그동안 IRSA(IAM Roles for Service Accounts)를 잘 쓰고 있었는데, 클러스터를 4개 운영하다 보니 OIDC provider를 클러스터마다 다 등록하고, 신뢰 정책에 sub 조건을 박아놓는 방식이 점점 귀찮아졌다. 멀티 클러스터 환경에서 같은 워크로드에 같은 권한을 주려면 클러스터마다 trust policy를 다르게 써야 했고, 새 클러스터를 띄울 때마다 이걸 반복했다.그래서 최근 2주에 걸쳐 dev → staging 클러스터를 차례로 Pod Identity로 옮겼다. prod는 다음 주 작업 예정이다. 이 글은 그 작업을 정리한 가이드다. 이미 운영..