day-log

IRSA에서 EKS Pod Identity로 옮기는 법

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

Istio Ambient vs Sidecar, 6개월 검토 후 결론

작년 말부터 Istio Ambient Mode를 진지하게 보기 시작했다. 1.22에서 Beta로 올라오고, 1.24~1.25 거치면서 단일 클러스터 한정으로는 production ready라는 얘기가 공식 문서에도 들어갔다. 우리 팀에서도 "그러면 슬슬 옮겨야 하는 거 아니냐"는 얘기가 나왔고, 6개월 정도 PoC와 일부 트래픽 마이그레이션을 진행했다.결론부터 말하면 새 클러스터는 Ambient로 깔고, 기존 sidecar 클러스터는 당분간 그대로 둔다로 정리됐다. 그 과정에서 정리된 비교를 남긴다.데이터 플레인 구조의 차이Sidecar 모드는 다들 알다시피 Pod마다 envoy 컨테이너 하나 더 붙는다. 100개 Pod 띄우면 envoy도 100개. 메모리, CPU, 부팅 시간 다 곱하기 N이 된다.A..

ARC ephemeral runner로 갈아탔다가 새벽에 깬 이야기

지난주 화요일 새벽 2시쯤, 슬랙에 멘션이 떴다. "프론트엔드 빌드 파이프라인이 30분 넘게 안 끝나는데요?" 평소 7~8분이면 끝나던 잡이었다. 멘탈이 한 번 흔들렸고, 노트북을 열었다. 이게 이번 글 주제다.배경부터 짧게 말하면, 우리 팀은 지난달에 GitHub-hosted runner에서 ARC(Actions Runner Controller) 기반 self-hosted runner로 전환했다. 비용이랑 사내망 접근 때문에 어차피 가야 할 길이었고, 동료가 헬름 차트로 깔끔하게 셋업해놨다. ARC의 기본 모드인 ephemeral runner를 그대로 썼다. 잡 하나 끝나면 파드는 폐기되고 새 파드가 뜬다. 보안적으로도 깔끔하니 의심할 이유가 없었다.근데 그게 함정이었다.처음에 의심한 것들새벽 2시에 ..

Kyverno vs OPA Gatekeeper, 결국 뭘 골라야 하나

쿠버네티스에 정책 엔진 하나는 깔아야 한다는 얘기가 나온 게 벌써 몇 년째인지 모르겠다. 우리 팀도 처음엔 "PSP 사라지면 그때 가서 보자"고 미뤘는데, 결국 PSP 제거되고, NetworkPolicy 강제도 필요해지고, 이미지 서명 검증 요건까지 붙으면서 더 이상 미룰 수가 없었다.선택지는 사실상 둘이다. Kyverno 아니면 OPA Gatekeeper. 둘 다 CNCF 프로젝트고, 둘 다 어드미션 컨트롤러로 동작한다. 그래서 처음엔 "어차피 비슷하겠지" 싶었는데, 직접 양쪽을 작은 클러스터에 나눠 깔고 두어 달 굴려보니 꽤 결이 다른 도구라는 걸 알게 됐다. 이 글은 그 비교 노트다.정책을 어떻게 쓰는가 — YAML vs Rego이 차이가 가장 크다.Gatekeeper는 OPA를 베이스로 깔고 있어..