day-log

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,..

상황운영 중인 파드가 한 개 있다. 베이스 이미지는 gcr.io/distroless/static:nonroot. 셸은커녕 ls도 없다. 그런데 갑자기 이 파드만 외부 API 호출이 실패하기 시작한다. DNS 문제인지, 라우팅 문제인지, 인증서 문제인지 확인하고 싶다. 파드를 재시작하면 증상이 사라질 수도 있으니 살아있는 상태에서 보고 싶다. 자, 어떻게 할까?이거 모르는 분 꽤 많더라. 어제 후배가 "프로덕션 파드에 들어가서 curl 좀 찍어보고 싶은데 distroless라서 kubectl exec가 안 먹힌다"라고 슬랙에 글 올린 거 보고 깜짝 놀랐다. kubectl debug가 GA 된 게 1.25 (2022년 후반) 인데, 2026년 지금까지도 의외로 안 쓰는 사람이 많은 것 같아서 짧게 정리한다...

왜 단일화를 시도했나작년 가을부터 클러스터 런타임 보안 도구를 다시 들여다보고 있었다. 그전까지 우리 팀은 Falco만 돌리고 있었는데, 알람이 너무 시끄러웠다. 새벽에 페이지가 울리면 열에 아홉은 false positive였고, 나머지 한 번도 사실 우리가 미처 룰을 안 다듬어서 생긴 노이즈였다. 보안팀이 받는 신뢰도가 점점 떨어지는 게 보였다.그래서 Tetragon을 검토 후보로 올렸다. Isovalent(현재는 Cisco) 쪽에서 미는 eBPF 기반 도구고, Cilium을 이미 쓰고 있던 우리 환경이랑 잘 맞는다는 얘기가 컨퍼런스마다 나왔다. 결론부터 말하면 6개월 동안 둘을 병행해서 돌렸고, 지금은 둘 다 운영 중이다. 한쪽으로 단일화하려다가 다시 두 개 다 유지하기로 했는데, 그 과정에서 알게 ..

작년 말에 우리 팀이 EKS Auto Mode로 갈아탔다. 정확히는 새로 만드는 서비스 클러스터 한 대를 Auto Mode로 띄워서 운영해본 게 6개월 정도 됐다. 기존 클러스터들은 Karpenter + 자체 노드 그룹으로 굴리고 있었고, 솔직히 큰 불만은 없었다. 그런데 신규 팀에서 클러스터를 자꾸 늘리는 상황이 되니까, 모든 클러스터마다 Karpenter 버전 맞추고, CoreDNS HPA 손보고, VPC CNI 업그레이드 줄 세우는 게 점점 부담이었다. "이거 AWS가 다 해주겠다는데 한번 맡겨보자"는 분위기였다.6개월 동안 잘 굴러간 부분도 있고, 새벽에 멘탈이 나간 부분도 있어서 정리해둔다. 누가 똑같은 선택을 앞두고 있다면 이 글이 조금이라도 시간을 아껴주면 좋겠다.도입 직후 — "이거 너무 ..

작년 말부터 트레이스 양이 폭증했다. 서비스가 늘어난 것도 있고, 한 요청이 마이크로서비스 7~8개를 거치다 보니 한 트랜잭션에 span이 200개 가까이 붙는 케이스도 생겼다. 그대로 Tempo에 다 밀어 넣었더니 스토리지 비용이 분기마다 1.6배씩 뛰었다. 샘플링을 손봐야 한다는 결론은 너무 자명했는데, 막상 head냐 tail이냐를 고르는 자리에선 팀 안에서도 의견이 갈렸다.결론부터 말하면 우리는 두 개를 섞었다. 그래서 이 글은 어느 한쪽이 정답이라는 얘기가 아니다. 각각의 결을 보고, 어디서 어떤 걸 골랐는지 정리한다.Head sampling — 빠르고 가난한 선택지Head sampling은 트레이스가 시작되는 시점, 그러니까 SDK가 root span을 만들 때 보낼지 말지를 결정한다. Par..

ECR pull rate limit에 한 번이라도 당해봤다면, 이 글이 도움이 될 거다. Spegel은 클러스터 안에서 노드끼리 이미지를 공유하게 해주는 stateless P2P OCI registry mirror다. 어느 노드 하나가 이미지를 받아두면, 같은 클러스터의 다른 노드들은 그 노드에서 끌어다 쓴다. 외부 레지스트리 호출이 확 줄어든다.최근 3월에 CoreWeave가 자기네 매니지드 쿠버네티스(CKS)에서 Spegel 튜토리얼을 공식 문서로 내놓을 정도로 P2P 이미지 분배는 더 이상 실험 단계가 아니다. K3s, RKE2는 아예 임베디드로 들어가 있고, AKS/EKS에서도 Helm으로 깔아서 잘 굴러간다. 우리 팀에서도 노드 80대 EKS 클러스터에 두 달째 돌리고 있는데, 한번 정리해두면 ..

새벽 1시쯤 알람이 울렸다. 정확히는 PagerDuty가 두 번 울렸고 그 다음엔 슬랙이 폭주했다. "kubectl이 다 timeout 난다"는 메시지가 #infra 채널에 5명한테서 동시에 올라왔다. 그날 저녁에 마지막으로 한 일이 Kyverno에 ClusterPolicy 하나를 새로 올린 거였다. 그게 거의 확정이라는 느낌이 왔다.이 글은 그날 새벽 한 시간 반 동안 무엇을 잘못했고 무엇을 배웠는지에 대한 회고다. 결론부터 말하면, failurePolicy: Fail을 너무 가볍게 봤다.무슨 정책을 올렸냐별 거 아닌 정책이었다. 워크로드에 app.kubernetes.io/name 레이블이 없으면 deployment를 막는 정책. 보안팀이 자산 인벤토리 정리하면서 요구한 거였고, 우리는 "이거 그냥 라..

오늘 알게 된 건데, 의외로 Job spec에서 podFailurePolicy 안 쓰는 팀이 꽤 많더라. 같이 일하는 분이 "야 우리 배치가 새벽에 6번 OOM 나고 죽었는데 알람이 한 번에 6번 왔어"라고 메시지를 보내서 들여다봤다. 코드는 멀쩡한데 메모리 한도가 빡빡했고, backoffLimit: 6만 박혀 있었다. 그게 다였다.근데 이게 별거 아닌 것 같아도 비용/알람/멘탈 다 갉아먹는다. 잠깐만 짚고 가자.backoffLimit만 있을 때 무슨 일이 벌어지나Job spec이 이렇게만 돼 있다고 치자.apiVersion: batch/v1kind: Jobmetadata: name: nightly-reportspec: backoffLimit: 6 template: spec: rest..

클러스터 트래픽이 늘 때 우리 팀이 가장 먼저 듣는 얘기는 보통 이거다. "노드 부족한 거 아니에요?" 근데 막상 들여다보면 노드는 멀쩡한데 DNS 쪽에서 병목이 생긴 경우가 절반쯤 된다. 특히 EKS에서 default 설정 그대로 굴리고 있으면 CoreDNS는 2개 파드로 묶여서 같은 AZ에 떨어져 있는 일도 흔하다.이 글은 EKS CoreDNS를 운영하면서 트래픽이 늘기 시작했을 때 가장 먼저 점검해야 하는 3가지를 정리한 가이드다. 정말로 노드를 더 붙이기 전에, DNS 레이어부터 들여다보자는 얘기.1. CoreDNS 파드 분산 — topologySpreadConstraints이게 의외로 묻혀 있는 변화인데, EKS의 CoreDNS add-on이 v1.9.3-eksbuild.11 그리고 v1.10...

작년 이맘때 Terraform 협업 도구를 새로 고르느라 한참 헤맸다. 그동안은 GitHub Actions 위에 얇은 래퍼 스크립트로 plan/apply를 돌렸는데, 모듈이 80개를 넘어가면서부터는 한계가 보였다. PR 코멘트에 plan 결과가 뒤죽박죽 붙고, 누가 언제 apply를 눌렀는지 추적이 안 되고, 가끔 두 사람이 같은 워크스페이스에 동시에 apply를 날려서 state lock 충돌이 나기도 했다.결국 후보를 Atlantis와 Spacelift로 좁혔다. 둘 다 후보로 올린 이유는 단순했다. Atlantis는 공짜고 자체 운영이 익숙했고, Spacelift는 영업 미팅 한 번 했을 때 "이 정도면 우리 페인 포인트는 다 풀리겠다" 싶은 인상을 받았기 때문이다. 1년이 지난 지금 시점에서 솔직..