day-log

3월 24일에 ingress-nginx가 공식적으로 EOL 됐다. 이제는 CVE 패치도 안 나온다. 우리 팀도 절반이 아직 ingress-nginx를 쓰고 있어서 지난 두 달 동안 대체제 검토를 이어왔다. Envoy Gateway, Cilium Gateway, Traefik, kgateway. 이 네 개를 실제로 클러스터에 붙여봤고, 그 중 하나로 결정을 내렸다. 결정 자체보다는 각각 뭐가 다른지, 어디서 삽질했는지를 정리해보려 한다.전제 조건부터 짚자. 우리는 EKS 위에서 돌아가고, 노드는 대략 90대. 트래픽은 RPS 8k 정도이고 대부분 gRPC와 HTTP/2. 사내 서비스 60여개가 하나의 Ingress 컨트롤러 뒤에 붙어있는 형태다. 만약 여러분 환경이 GKE 매니지드 게이트웨이를 그냥 켜면 ..

작년 여름부터 팀 회의 때마다 반복해서 나오는 주제가 있다. "우리도 Valkey로 옮겨야 하지 않을까요?" 처음에는 라이선스 이슈 정도로 가볍게 봤는데, 2026년이 되니 이야기가 좀 달라졌다. AWS ElastiCache 기본값이 Valkey로 바뀌고, Aiven이 15,000대 서버를 옮겼다는 얘기까지 들리니 무시하기 어려워졌다.우리 팀은 캐시 클러스터 40여 대, 세션 스토어 12대, 그리고 실시간 랭킹용 소규모 Redis 몇 개를 굴리고 있다. 각각의 워크로드가 조금씩 달라서 하나의 결론을 내기가 애매했다. 이 글은 그동안 실무자로서 두 진영을 비교하면서 정리한 내용이다. 결론부터 말하면 "무조건 갈아타야 한다"도 아니고 "굳이?"도 아니다.라이선스, 이게 진짜 이슈였다Redis 7.2까지는 B..

Karpenter 얘기는 이제 새롭지 않다. AWS re:Invent 때마다 나오고, 트위터에서도 마이그레이션 후기가 쏟아진다. 얼마 전 Salesforce가 1,000개 넘는 EKS 클러스터를 Karpenter로 옮겼다는 소식도 있었고. 그런데 우리 팀은 좀 늦게 결정한 편이다. 작년에 Cluster Autoscaler(이하 CA)에서 Karpenter로 넘겼고, 반년 정도 운영해봤다. 결론부터 말하면 이득은 있었다. 다만 처음 예상했던 이유들과는 조금 달랐다.왜 넘어갔나원래 이유는 명확했다. 노드 스케일링이 느리다. CA는 ASG 기반이라 unschedulable 파드가 생기면 → CA가 감지 → ASG desired capacity 조정 → EC2 프로비저닝 → kubelet join. 이 사이클이..

지난주에 몇 년 방치된 AWS 계정 정리를 맡았다. 상태 파일이랑 실물 리소스가 서로 다른 우주에 있는 그런 계정. 늘 하던 대로 콘솔에서 목록 뽑아서 `terraform import`를 한 줄씩 돌리려다가 옆 팀 시니어가 "요즘 그거 안 써도 돼요, `terraform query` 있잖아요" 하길래 처음 알았다. 지난해 11월 GA된 Terraform 1.14 신규 기능인데, 소문만 들었지 실제로 안 써봤었다. 써보고 나서 후회했다. 이거 진작에 알았어야 했다.`.tfquery.hcl`이 하는 일이름 그대로 새로운 파일 타입이다. 확장자가 `.tfquery.hcl`이어야 인식한다. 안에는 `list` 블록이 들어간다. import 블록이 "이 리소스를 상태로 끌어와줘"라면, list 블록은 "일단 계정..

왜 지금 넘어가야 하나Grafana Agent(Static/Flow/Operator)가 2025년 11월 1일에 공식적으로 EOL을 맞았다. 우리 팀도 그 전에 다 넘겨야 했는데, 막상 문서를 보면 "convert 명령어 쓰세요" 정도로 뭉뚱그려져 있어서 실무에서 걸리는 지점이 꽤 있었다. 이 글은 프로덕션 클러스터 3개(스테이징 1, 프로덕션 2 — 노드 합쳐서 80대 정도)에서 넘긴 기록을 정리한 것이다.Alloy는 이제 단순히 Agent 후속작이 아니라 Grafana Labs가 OpenTelemetry Collector를 자기네 방식으로 배포하는 형태에 가깝다. 이게 왜 중요하냐면, 기존에 metrics {}, logs {} 블록으로 쪼개 놓던 것이 otelcol.* 파이프라인과 나란히 놓이면서 c..

옮기기 전에 체크할 것EKS Pod Identity가 GA된 게 2023년 말이니까 벌써 2년 반쯤 됐다. 처음 나왔을 때는 "굳이 IRSA에서 갈아탈 이유가 있나" 싶었는데, 클러스터 수가 10개를 넘어가면서 OIDC provider를 매번 등록하고 trust policy의 sub 클레임을 클러스터마다 갈아끼우는 게 슬슬 짜증나기 시작했다. 올해 들어 우리 팀도 본격적으로 옮기기 시작했고, 이제 절반쯤 마이그레이션한 상태다.이 글은 "왜 옮겨야 하나"보다는 "어떻게 옮기나"에 집중한다. 결론부터 말하면 한 번에 다 갈아엎을 필요는 없다. 같은 클러스터, 같은 네임스페이스에서 IRSA와 Pod Identity가 공존한다.먼저 마이그레이션을 시작하기 전에 확인해야 할 게 몇 가지 있다.EKS 클러스터 버전..

지난 4월쯤이었다. 슬랙에 누가 링크 하나를 던졌다. ingress-nginx 메인테이너들이 더 이상 best-effort 유지보수도 못한다고 공지를 올렸다는 거였다. 처음에는 "에이, 그래도 굴러는 가겠지" 했다. 우리 클러스터 8개에 다 깔려 있고, ingress 리소스만 200개가 넘는데. 근데 그 주에 보안팀에서 CVE 패치 일정을 묻는 메일이 왔고, 그제서야 정신이 들었다. 사실상 EOL 된 컨트롤러를 들고 가는 건 시간 문제일 뿐이라는 걸.그래서 Gateway API로 가기로 했다. 5월 초부터 6월 말까지, 약 두 달 동안 삽질한 이야기를 적어둔다. 누군가는 비슷한 상황일 테니까.처음에 안일하게 생각했던 것Gateway API가 v1.5까지 나왔고 standard로 거의 다 올라왔다는 글을 ..

요즘 사내 슬랙에 "Pod Identity로 갈아타야 하지 않냐"는 질문이 부쩍 늘었다. AWS가 작년부터 신규 워크로드에는 Pod Identity를 권장한다고 명시하고 있고, 최근 블로그들도 IRSA를 "레거시" 취급하는 분위기다. 그런데 막상 운영 중인 클러스터를 보면 IRSA가 멀쩡히 잘 돌아가고 있다. 굳이 옮겨야 하나?결론부터 말하면 모든 환경에 다 옮길 필요는 없다. 다만 새로 만드는 워크로드부터는 Pod Identity로 가는 게 맞고, 기존 워크로드는 옮길 만한 이유가 있을 때 옮기면 된다. 우리 팀에서 지난 두 달 동안 약 40개 ServiceAccount 중 절반쯤을 옮기면서 정리한 내용을 공유한다.IRSA, 뭐가 불편했나IRSA가 잘못된 건 아니다. OIDC provider만 등록해두..

마이그레이션 전에 점검할 것ingress-nginx가 결국 작년 3월에 EOL됐다. 깃허브 저장소는 archived 처리됐고, 보안 패치도 더 이상 안 나온다. 그동안 미루고 미뤘는데 이제는 정말 도망갈 데가 없다. 우리 팀도 6월 들어서야 본격적으로 Gateway API 마이그레이션을 시작했고, 이 글은 그 과정에서 정리한 가이드다.처음에는 막막했다. Ingress 리소스가 200개가 넘는데 이걸 일일이 손으로 옮긴다고? 다행히 SIG-Network에서 올해 3월에 ingress2gateway 1.0을 정식 릴리스했다. 이걸 쓰면 대부분의 Ingress 리소스가 자동으로 변환된다. 물론 자동 변환이 모든 걸 해결해주지는 않는다는 게 함정이지만.본격적으로 시작하기 전에 두 가지를 먼저 확인했다.첫 번째는..

EKS 클러스터에서 워크로드 권한 부여, 어떻게 바뀌고 있나EKS 클러스터에서 워크로드가 AWS API를 호출할 때 권한을 어떻게 주느냐는 꽤 오래된 주제다. 한참 동안은 IRSA(IAM Roles for Service Accounts)가 사실상의 표준이었는데, 2023년 말에 Pod Identity가 나오고 2024-2025년을 거치면서 AWS도 "신규 워크로드는 Pod Identity 권장"으로 톤이 바뀌었다. 우리 팀도 작년 말부터 클러스터 두 개를 점진적으로 옮겼는데, 그 과정에서 정리한 실무 노트다.IRSA를 완전히 버리는 건 아니다. Fargate는 여전히 IRSA만 지원하고, 어떤 도구들은 아직 Pod Identity 어노테이션 매핑이 어색하다. 그래도 "신규 SA는 Pod Identity,..