day-log

External Secrets Operator(ESO)를 처음 도입하면 보통 ExternalSecret 리소스부터 만든다. AWS Secrets Manager나 Vault에 있는 시크릿을 Kubernetes Secret으로 끌어오는 흐름. 이 정도는 어렵지 않다. 그런데 운영을 6개월쯤 하다 보면 다음 두 가지가 슬슬 필요해진다.첫째, 클러스터에서 생성한 시크릿(예: 앱이 동적으로 만든 API 키)을 외부 시크릿 저장소로 밀어 올리고 싶어진다. 둘째, 클러스터 단위로 한 번만 SecretStore를 정의하고 여러 네임스페이스에서 공유하고 싶어진다. 전자가 PushSecret, 후자가 ClusterSecretStore다.이 글은 두 리소스를 실무에 적용할 때 빠지기 쉬운 함정과, 우리 팀에서 정착시킨 패턴..

autovacuum이 돌고 있는 줄 알았다지난주에 PostgreSQL 디스크가 갑자기 부풀어오르는 사건이 있었다. 정확히는 이미 며칠 전부터 부풀고 있었는데, 우리가 늦게 알아챈 거다.처음에는 단순히 "데이터가 많아져서 그렇겠지" 생각했다. 그런데 dead tuple 비율을 찍어보니 40%를 넘기고 있었다. 어떤 테이블은 60%. 라이브 row보다 죽은 row가 더 많은 상태였다. autovacuum 로그를 뒤져보니 마지막 vacuum이 4일 전에 멈춰 있었다. 그리고 그 사이에 누가 무엇을 했는지 추적이 시작됐다.pg_stat_activity가 말해준 것pg_stat_activity 뷰를 열어보니 한 세션이 4일째 살아 있었다. state는 idle in transaction. xact_start는 월..

ArgoCD ApplicationSet은 보통 "여러 클러스터에 같은 앱을 자동으로 배포해주는 도구" 정도로 설명된다. 우리 팀도 처음엔 그렇게 썼다. List generator로 환경 별 파라미터 넘기고, 템플릿에 변수 박아 넣고. 잘 돌아갔다. 문제가 터지기 전까지는.작년 가을, 멀티 리전에 깔린 60개 가까운 Application이 사일런트하게 drift나기 시작했다. ApplicationSet 매니페스트는 그대로인데 일부 Application만 sync 상태가 이상했다. 그때 처음으로 ApplicationSet 컨트롤러 코드를 직접 까봤다. 그러고 보니 이 컨트롤러, 생각보다 단순하지 않다.reconcile 루프의 4단계ApplicationSet 컨트롤러를 한 줄로 요약하면 "Application..

오늘 알게 된 건데, 이거 모르는 분 의외로 많더라. kubectl debug 쓸 때 --copy-to 옵션 말이다.distroless 컨테이너 디버깅 글들 검색하면 거의 다 --copy-to 예제가 나온다. 근데 운영 파드를 진짜로 디버깅해본 분들은 알겠지만, 이게 좀 위험하다.두 가지 모드, 뭐가 다른가kubectl debug는 크게 두 가지로 쓸 수 있다.1. ephemeral container 주입 (기본)kubectl debug -it my-pod \ --image=busybox:1.36 \ --target=app원본 파드에 임시 컨테이너를 하나 더 끼워 넣는다. PID/network namespace를 공유하니까 ps, netstat, /proc/$PID/... 다 보인다. 원본 컨테이너는..

오늘 알게 된 건데, 아직도 노드마다 /etc/containerd/config.toml 안에 레지스트리별 auth를 박아두고 운영하는 팀이 생각보다 많다. 우리 팀도 작년까지 그랬다. 사내 Harbor, ECR, GHCR, Docker Hub 미러까지 네 개를 한 파일에 우겨넣다 보니 누가 한 줄만 잘못 건드려도 컨테이너런타임 재시작이 필요했다.근데 containerd 1.5에서 추가되고 1.7 이후로는 사실상 표준이 된 config_path 방식 쓰면 이 짓을 안 해도 된다. 노드 재시작 없이, hot reload로 레지스트리 설정만 바꿀 수 있다.핵심은 디렉터리 구조/etc/containerd/config.toml에는 딱 한 줄만 둔다.[plugins."io.containerd.grpc.v1.cri"..

지난주 수요일 새벽이었다. 새벽 2시쯤 자다가 슬랙 멘션 알림에 깼다. "어제 오후 4시부터 지금까지 로그가 안 보여요." 운영팀 야간 담당자였다. 휴대폰 화면 밝기에 눈이 시리면서도 멘탈은 이미 깨어버린 상태. 우리 클러스터는 노드 80대 규모에 Loki 3.7.x를 미러 모드로 돌리고 있었고, 하루에 1.5TB 정도의 로그를 받는다. 그게 7시간 동안 사라졌다는 얘기다.솔직히 처음엔 좀 의심했다. "진짜 7시간 동안 아무도 모를 수가 있나?" 근데 확인해보니 진짜였다. Grafana에서 last 24h로 보면 오후 4시 지점에서 갑자기 라인이 뚝 끊겨 있었다. 그래프가 그렇게 정직하게 끊긴 건 처음 봤다.ingester pod 상태부터 봤다가장 먼저 한 일은 ingester pod의 상태 확인이었다...

우리 팀은 Python/Node 기반 마이크로서비스를 20개 가까이 굴리고 있다. GitHub Actions에서 평일 기준 하루 PR 빌드가 200건 정도 도는데, 빌드 한 번에 평균 6~7분이 걸렸다. PR 하나 머지하려면 빌드 큐에서 한참 기다리는 게 일상이었고, 러너 비용은 매달 슬금슬금 올라갔다.근데 솔직히 빌드 로그를 들여다보면 절반 이상이 pip install, npm ci, apt-get install 단계였다. 매 빌드마다 pypi 미러에서 똑같은 패키지를 다시 받고 있던 거다. 결국 BuildKit cache mount을 제대로 깔고 나서 빌드 시간이 7분에서 평균 40초로 줄었다. 이 글은 그 과정에서 정리한 패턴이다.왜 일반 레이어 캐시로는 부족했나원래 Dockerfile에서 pip ..

새벽에 burn rate 알람이 안 울렸다 — multiwindow SLO 알람 삽질 노트지난주 금요일, 정확히는 토요일 새벽 4시쯤에 한 통의 메시지로 잠에서 깼다. 새벽이라 페이저는 아니었다. 결제 팀 PL이 슬랙 DM으로 "혹시 새벽 2시 ~ 3시 사이에 결제 실패 폭주한 거 알고 있냐"고 물어본 게 시작이었다. 모니터링 알람은 한 통도 받지 못한 상태였다.대시보드를 켜보니 새벽 2시 12분부터 약 32분간 결제 API의 5xx 비율이 8%까지 튀었다가 자연 복구됐다. 우리 SLO는 가용성 99.9%, 즉 한 달에 약 43분의 에러 예산이 전부였다. 사실상 한 번의 사고로 한 달치를 다 태운 거다. 그런데 왜 burn rate 알람이 안 울렸지? 이날 알게 된 multiwindow burn rate..

오늘 알게 된 건데, 1.34부터 kuberc가 beta 승격됐다. 이게 뭐냐면, kubectl 전용 사용자 설정 파일이다. 별칭하고 기본 옵션을 따로 관리할 수 있게 해준다.솔직히 우리 팀은 ~/.zshrc나 ~/.bashrc에 alias k=kubectl, alias kgp='kubectl get pods' 같은 걸 한 30줄씩 박아두고 살았는데, 이거 좀 지저분하다. 새 노트북 받을 때마다 dotfiles 복사하고, 팀 신입한테 "이거 깔아라" 시키는 것도 일이다.kuberc는 그 자리를 대체할 수 있는 공식 방법이다. kubectl 자체가 읽어서 처리한다.어떻게 생겼나~/.kube/kuberc 한 파일이다. 위치만 약속하면 끝.apiVersion: kubectl.config.k8s.io/v1bet..

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