day-log

Kubernetes Secret을 base64로 관리하는 시대는 이제 좀 지나갔다. etcd에 평문으로 들어가는 걸 감안하면 그냥 인코딩된 문자열일 뿐이다. 그래서 대부분 팀은 외부 시크릿 매니저(AWS Secrets Manager, Vault, GCP Secret Manager 등)로 옮겨간다.문제는 이걸 어떻게 Pod까지 안전하게, 그리고 회전(rotation)까지 자동으로 반영되도록 연결하냐는 것이다. External Secrets Operator(이하 ESO)가 이 자리를 채운다. 올해 초 나온 ESO 2026 가이드들을 훑어보면 대부분 "설치하고 SecretStore 만들고 ExternalSecret 정의하면 끝"이라고 쓰여있는데, 실제 프로덕션에 넣어보면 IRSA 권한, refreshInter..

지난주 새벽에 겪은 이야기다. 프로덕션 EKS 두 개 중 한 쪽에서 신규 파드가 시크릿을 못 읽는다는 알림이 왔다. 처음엔 대수롭지 않게 봤는데, 결국 External Secrets Operator(ESO) 전체 sync가 멈춰 있는 상태였다. 우리 팀이 ESO를 IRSA + AWS Secrets Manager 조합으로 3년 넘게 쓰고 있는데, 이런 식으로 죽는 건 처음이었다.증상은 조용했다관측 가능한 신호가 애매했다. kubectl get externalsecret -A 를 찍으면 상태는 죄다 SecretSyncedError 였다. 근데 컨트롤러 파드는 살아 있고, CPU도 정상이고, 리더 election 로그도 잘 남고 있었다. Prometheus에서 externalsecret_sync_calls_e..

EKS 쓰다 보면 언젠가 한 번은 부딪히는 질문. 파드가 AWS 리소스에 접근할 때 IAM을 어떻게 붙일 것인가. 예전에는 답이 하나였다. IRSA. 근데 몇 년 전 Pod Identity가 나오고, 올해 초 우리 팀은 결국 이걸로 옮겼다. 왜 옮겼는지, 뭐가 좋고 뭐가 애매한지 정리해본다.IRSA는 그동안 잘 써왔는데솔직히 IRSA에 큰 불만은 없었다. OIDC provider 만들어놓고, ServiceAccount에 어노테이션 붙이고, IAM 역할의 trust policy에 그 SA를 넣어주면 끝. 몇 년째 잘 굴러왔다.문제는 클러스터가 늘어나면서 시작됐다. 우리 팀은 dev/staging/prod로 클러스터가 세 개, 여기에 데이터 팀이 요청한 별도 클러스터 하나가 더 붙어서 총 네 개다. 각 클러..

Kubernetes에 시크릿을 어떻게 넣을지 팀 내부에서 얘기가 몇 번 오갔다. Sealed Secrets는 GitOps랑 궁합이 좋긴 한데 로테이션이 귀찮고, kubectl create secret은 GitOps 원칙에 어긋난다. 결국 우리 팀은 External Secrets Operator(ESO) + AWS Secrets Manager 조합으로 갔다. 6개월 정도 운영해보니 손이 덜 가서 만족스럽다.이 글은 ESO를 처음 도입할 때 필요한 IRSA 설정, ClusterSecretStore/SecretStore 결정, 그리고 실무에서 자주 걸리는 몇 가지 함정을 정리했다. 최근 v0.10 대에서 문법이 조금씩 바뀐 부분도 반영했다.왜 ESO인가간단히 말하면 AWS Secrets Manager를 원본(..

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

Pod Identity가 정식으로 나온 지 이제 2년 반쯤 됐다. 그동안 우리 팀에서는 IRSA로 굴러가는 클러스터 4개, Pod Identity로 새로 띄운 클러스터 3개를 운영해봤다. 솔직히 처음에는 "OIDC 트러스트 한 줄 더 박는 게 그렇게 귀찮은 일인가?" 싶었는데, 클러스터가 늘어나면서 생각이 좀 바뀌었다.최근 6월 기준으로 Medium에 다시 비교 글이 올라오길래(이게 또 새로 입사하는 친구들이 가장 많이 찾는 주제다) 우리 팀 내부 결정 기록을 정리해서 공유한다. 결론부터 적으면, 새 워크로드는 Pod Identity, 단 Fargate에 띄울 거면 IRSA. 그리고 둘은 같은 클러스터에서 공존시켜도 별 문제 없다.트러스트 정책의 무게IRSA의 진짜 비용은 IAM role 자체가 아니라 ..

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

지난주 화요일 새벽 4시쯤 전화가 울렸다. 메시지 큐 컨슈머 한 대가 S3 PutObject에서 ExpiredTokenException 을 계속 뱉고 있다고. 멘탈이 살짝 나갔다. IRSA로 깔끔하게 인증 붙여놨다고 믿고 있던 워크로드였는데.결론부터 말하면 ServiceAccount projected token이 만료된 뒤 kubelet이 새 토큰을 디스크에 갈아 끼웠는데, 우리 컨슈머 안에 들어있던 SDK는 이걸 다시 읽지 않고 죽은 토큰을 1년 가까이 메모리에 들고 있었다. 정확히는 캐시가 너무 충실했던 게 문제였다.우리가 잘못 알고 있던 부분Kubernetes 1.22 이후로 BoundServiceAccountTokenVolume 이 GA되면서 Pod이 마운트하는 토큰은 모두 projected 형태..

작년에 신규 EKS 클러스터를 띄우면서 한 가지 결정을 미뤘다. 워크로드 IAM을 IRSA로 갈지 Pod Identity로 갈지. 그때는 "어차피 둘 다 지원되니까 나중에 보자"고 미뤘는데, 올해 들어 클러스터가 4개로 늘어나면서 더는 미룰 수 없는 상태가 됐다.지난 두 달 동안 stage 환경 전체를 Pod Identity로 옮겨보고, prod의 일부 워크로드도 마이그레이션을 시작했다. 결론부터 말하면 우리 팀은 신규 워크로드는 전부 Pod Identity로, 기존 IRSA는 천천히 전환 중이다. 왜 그런 결정을 했는지, 어떤 케이스에서는 IRSA가 더 나았는지 정리해본다.비교의 배경: 우리는 어떤 환경이었나먼저 우리 팀 환경을 짧게 적어둔다. 비교 결과는 환경에 따라 다르게 읽힐 수 있어서다.EKS ..

작년 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는 다음 주 작업 예정이다. 이 글은 그 작업을 정리한 가이드다. 이미 운영..