day-log

작년부터 우리 팀에서도 신규 서비스에는 Vault 대신 OpenBao를 깔기 시작했다. 처음 도입할 때만 해도 "그냥 Vault 1.14 그대로 박제된 거 아니냐"는 의심이 컸는데, 막상 1년 가까이 운영해보니 그 평가는 좀 수정해야겠다는 생각이 든다. 특히 올해 2월에 나온 2.5에서 namespace와 horizontal read scaling이 들어가면서, 단순히 Vault의 OSS 미러가 아니라 자기 방향성을 갖기 시작했다.이 글은 "OpenBao 도입 가이드"가 아니다. 그건 이미 충분히 많다. 대신 내부 구조가 Vault와 어디서 갈라지기 시작했는지, 운영자 입장에서 어느 지점을 신경 써서 봐야 하는지를 정리한다.포크 시점이 결정한 것들OpenBao는 Vault 1.14.0에서 갈라져 나왔다...

작년 말 GA 된 EKS Auto Mode를 우리 팀도 새 클러스터에 적용했다. 몇 주 굴려보고 운영에서 부딪힌 부분들이 꽤 있어서, 도입을 고민하는 분들에게 도움이 될 만한 실무 가이드를 정리했다. 마케팅 문구가 아닌 "현실에서 뭐가 좋고 뭐가 아픈가" 관점이다.처음 듣는 분을 위해 간단히 설명하면, EKS Auto Mode는 컴퓨트(노드), 네트워킹(VPC CNI/로드밸런서), 스토리지(EBS CSI), Karpenter, Pod Identity Agent 같은 클러스터 구성요소를 AWS가 관리형으로 묶어서 제공하는 모드다. 우리가 직접 Helm chart를 깔고 IRSA를 매핑하던 작업이 거의 사라진다. 대신 자유도는 줄어든다.1. 사전 준비: 우리 클러스터가 적합한가도입 전에 다음 체크리스트를 먼..

작년 봄에 우리 팀 CI/CD 표준을 정리하면서 GitHub Actions의 Reusable Workflow와 Composite Action을 둘 다 도입했다. 그땐 "쓰임새가 다르니까 둘 다 쓰자"가 결론이었는데, 1년 굴려보니 둘의 경계가 처음 생각보다 훨씬 명확하게 갈렸다. 그리고 최근 GitHub이 2026 Actions 보안 로드맵을 발표하면서 Composite action의 nested dependency 노출 방식, scoped secrets 같은 변경이 들어오기 시작해서, 이참에 한번 정리해두면 좋을 것 같다.이 글은 단순히 둘의 문법 차이를 비교하는 글은 아니다. 실제로 우리 팀이 어떤 기준으로 갈라 썼고, 어디서 후회했고, 지금 어떻게 운영하는지에 대한 회고에 가깝다.단도직입적으로, 우..

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

증상이런 경험 다들 한 번쯤 있을 거다. Pod가 Running까지 가는 데 2-3분, 심하면 5분 넘게 걸린다. 이벤트 찍어봐도 별다른 에러 없고, ImagePull도 끝났고, PV Attach/Mount도 정상 완료. 그런데 컨테이너가 시작을 안 한다. kubectl describe pod 해보면 그냥 조용히 멈춰 있다.이때 kubelet 로그를 보면 이런 라인이 줄줄이 찍히고 있을 가능성이 높다.SetVolumeOwnership ... took 142.3s범인은 fsGroup이다. SecurityContext에 fsGroup: 1000 같은 거 설정해두면, kubelet이 PV를 마운트할 때 그 안의 모든 파일을 chown/chmod로 훑는다. 파일이 10만 개면 10만 번. 그게 NFS나 EFS ..

작년 말부터 컨테이너 이미지 서명을 본격적으로 강제하기 시작했다. 사내 정책상 프로덕션에 들어가는 모든 이미지는 서명되어 있어야 하고, admission controller에서 검증에 실패하면 배포가 막힌다. 그때 첫 번째로 부딪힌 질문이 "그래서 Cosign 쓸 거야, Notation 쓸 거야?" 였다.둘 다 OCI 아티팩트로 서명을 저장하고, 둘 다 표준화된 사양을 따른다. 그런데 막상 PoC 들어가니까 결이 꽤 달랐다. 5개월 정도 양쪽 다 운영해 본 입장에서 정리해본다.키 관리 모델이 가장 큰 분기점Cosign의 강점은 누가 뭐래도 keyless 서명이다. GitHub Actions의 OIDC 토큰을 Fulcio가 받아서 짧은 수명(보통 10분)의 X.509 인증서를 발급하고, 그걸로 서명한 뒤 ..

이거 모르는 분 의외로 많더라. 어제도 사내 슬랙에서 비슷한 질문이 올라왔다. "etcd defrag CronJob 돌리는데 가끔 API 서버가 잠깐 죽어요." 그럴 만했다.오늘은 짧게 한 가지만 정리한다. etcd defragmentation을 CronJob으로 자동화할 때 빠뜨리기 쉬운 포인트.compaction과 defrag는 다른 거다먼저 용어부터. 둘이 같은 줄 알고 쓰는 사람이 꽤 있다.compaction: 오래된 revision을 논리적으로 지운다. 디스크 파일은 안 줄어든다. 자동으로 돌릴 수 있다 (--auto-compaction-mode=periodic --auto-compaction-retention=8h 같은 식). kube-apiserver가 5분마다 자동 compaction을 호..

며칠 전 새벽 2시 반쯤, 핸드폰이 또 울렸다. 또 otel-collector 파드 OOMKilled 알람. 이번 주만 네 번째다.처음에는 그냥 메모리 limit이 작다고 생각해서 1Gi → 2Gi → 4Gi 까지 올렸다. 그래도 죽었다. 8Gi로 올렸더니 죽기 직전까지 가서 GC가 미친듯이 돌면서 export 큐가 밀리고, 결국 백엔드(Tempo)로 가는 trace 데이터가 통째로 30분쯤 누락됐다. 멘탈이 나갔다.상황우리 환경은 좀 흔하다. EKS 1.30, otel-collector v0.115 (contrib), DaemonSet으로 노드 28대에 깔려있고, Receiver는 OTLP gRPC/HTTP, Processor는 batch + memory_limiter + resource, Export..

1. Ambient로 옮기기 전에 확인할 것Ambient mode가 Istio 1.24에서 GA로 찍힌 게 작년 말이다. 그동안 1.25, 1.26을 거치면서 production 사용 사례도 꽤 쌓였고, 2026년 초부터는 "이제 슬슬 옮겨도 되겠다"는 분위기가 우리 팀 안에서도 잡혔다. 사이드카가 안 좋아서가 아니라, Pod 하나당 envoy 컨테이너 하나씩 붙는 모델이 노드 수 200대 넘어가면서 점점 답답해졌다. 메모리 사용량의 상당 부분이 사이드카 envoy였고, 무엇보다 사이드카 버전 올릴 때마다 전체 Pod restart가 필요한 게 가장 큰 문제였다.이 글은 "Ambient 좋다, 옮겨라"는 류의 이야기는 아니다. 어떻게 끊김 없이 옮길지에 대한 실전 절차를 정리한다. 단번에 바꾸지 않는다...

지난주 화요일 새벽 3시쯤. 휴대폰이 울렸다. 온콜 알림이었다. prod의 메인 API가 503을 뱉고 있다는. 솔직히 그날따라 몸이 너무 무거워서 한 5분쯤은 침대에서 멍하니 알림을 봤다. 그 5분이 정말 길었다.원인을 미리 말하자면, 전날 머지된 PR에서 ArgoCD argocd.argoproj.io/sync-wave 값을 한 줄 바꾼 게 문제였다. app-of-apps 패턴을 쓰는 우리 클러스터에서, 그 한 줄이 컨트롤 플레인 컴포넌트보다 워크로드를 먼저 띄우게 만들었다. 결과적으로 cert-manager가 뜨기 전에 ingress webhook이 호출돼서 발급이 꼬였고, 그게 ALB target health check를 흔들었고, 503이 떴다.새벽 3시반에 침대에서 일어나면서 든 생각: "syn..