day-log

시크릿 관리는 처음엔 SealedSecret로 시작했다가, SOPS로 갔다가, 결국 External Secrets Operator(ESO)에 정착하는 팀이 꽤 많다. 우리도 비슷한 경로를 걸었다. 이 글은 ESO를 도입한 뒤 한참을 SecretStore 기반으로 운영하다가 ClusterSecretStore로 갈아탄 과정에서 정리한 내용이다.ESO 자체 입문 글은 검색하면 많이 나오는데, 막상 운영에 들어가면 "네임스페이스마다 SecretStore를 만들어야 하나, 아니면 ClusterSecretStore 하나로 묶어야 하나" 같은 부분에서 한참을 헤맨다. 어제도 신규 팀이 와서 같은 질문을 했길래, 그동안 정리한 내용을 한번 풀어본다.언제 ClusterSecretStore를 쓰는가SecretStore는 ..

오늘 후배가 distroless 이미지로 돌아가는 파드를 디버깅하느라 새벽까지 헤매고 있길래 옆에서 한마디 했다. "그냥 --profile=netadmin 붙여." 그랬더니 표정이 묘했다. "그게 뭔데요?" 아... 이거 1.27에서 들어온 게 벌써 3년이 다 돼가는데 의외로 안 쓰는 사람이 많다. 짧게 정리한다.무슨 문제를 푸는가kubectl debug로 ephemeral container를 띄울 때 기본값은 권한이 거의 없다. 그래서 tcpdump나 iptables -L 같은 걸 돌리면 그냥 막힌다. 우리 팀에서도 처음엔 sidecar로 netshoot을 띄워놓던 시절이 있었는데, 그건 그것대로 메모리 잡아먹고 보안팀이 싫어한다.--profile 플래그는 이런 류의 권한 세트를 미리 정의해놓은 프리셋..

지난달에 우리 팀이 운영하던 EKS 클러스터 두 개를 Auto Mode로 갈아탔다. "노드 관리 안 해도 된다", "Karpenter 직접 안 만져도 된다", 이런 얘기 듣고 한 달만에 슬쩍 옮긴 건데, 첫 달 청구서 받고 멘탈이 살짝 나갔다. 결론부터 말하면 망한 건 아니다. 다만 예상하고 옮긴 그림이랑은 꽤 달랐다는 얘기다.어떻게 옮겼나원래 우리 클러스터는 Karpenter 0.37로 NodePool 4개 돌리고 있었다. 일반 워크로드, batch job용 spot, GPU 추론, 그리고 좀 큰 메모리 잡아먹는 streaming consumer용. 인스턴스 타입은 직접 골랐다. m6i.2xlarge, r6i.4xlarge, g5.xlarge 이런 식으로. 한 1년 운영하면서 어떤 패밀리가 어디에 잘 ..

Knative activator는 왜 데이터 경로에 끼어들까 — KPA 내부 동작서버리스를 K8s 위에 얹어보려고 Knative Serving을 한 분기 정도 운영 중이다. 처음엔 그냥 "0에서 N으로 자동 스케일되는 마법" 같은 거였는데, 정작 cold start P99가 800ms를 찍기 시작하면서 내부를 안 뜯어볼 수가 없었다. 사실 KPA(Knative Pod Autoscaler) 문서를 읽어도 표면만 도는 느낌이라, 컴포넌트들이 실제로 어떤 흐름으로 협업하는지 직접 추적해봤다.이 글은 activator가 왜 데이터 경로에 들어왔다 빠졌다 하는지, EBC(Excess Burst Capacity)라는 값이 그 결정을 어떻게 끌어내는지, 그리고 panic window라는 약간 무서운 이름의 윈도우가 ..

들어가며작년 말부터 트레이싱 백엔드를 갈아엎자는 얘기가 팀 내부에서 계속 나왔다. 직접적인 계기는 Jaeger v1이 2025년 12월 31일부로 EOL을 맞은 것이었다. 어차피 손을 대야 한다면 Jaeger v2로 갈지, Tempo로 옮길지 둘 중 하나를 골라야 했다. 결론부터 말하면 우리는 Tempo로 갔다. 그런데 솔직히 말해서 이 결정이 모든 팀에 정답은 아니다.두 솔루션이 지금 어디쯤 와 있는지Jaeger v2는 2024년 11월에 정식 릴리즈됐는데, 기존 코드베이스를 거의 다 버리고 OpenTelemetry Collector 위에 다시 쌓아 올린 구조다. 그러니까 Jaeger v2는 사실 "Jaeger 구성요소가 추가된 OTel Collector distribution"에 가깝다. 최근 2.1..

CI에서 컨테이너 빌드가 매번 5분 넘게 걸리면 슬슬 화가 난다. 우리 팀에서도 Rust 서비스 하나 빌드하는 데 평균 5분 40초가 찍히길래, 며칠 시간 내서 BuildKit cache mount를 제대로 정리했다. 결과는 36초. 그래서 오늘은 이 과정을 정리해두려고 한다.이 글은 BuildKit cache mount 자체의 동작 원리부터, CI 환경(특히 GitHub Actions처럼 runner가 ephemeral한 환경)에서 캐시를 살려두는 패턴까지 다룬다. Dockerfile 잘 쓰는 법은 인터넷에 널려 있지만, “CI에서 cache mount가 왜 안 살아남는지”를 한 번에 정리한 글이 의외로 잘 없어서 한번 써본다.cache mount는 layer cache와 뭐가 다른가일반적인 Docke..

우리가 깐 구성지난주 화요일 새벽에 알림이 울렸다. 정확히는 알림이 안 울려서 문제였다. 이미지 변환 워커가 SQS 큐의 메시지를 잘 먹고 있는 줄 알았는데, 다음 날 아침에 보니 "어제 업로드한 썸네일이 안 나와요"라는 CS 티켓이 17건 쌓여 있었다. SQS DLQ에 들어간 것도 아니고 그냥 큐 어디에도 없었다. 처리는 안 됐는데 사라졌다는 게 가장 큰 문제였다.원인은 KEDA였다. 정확히는 KEDA가 잘못한 건 아닌데, scaleToZero를 너무 공격적으로 설정한 우리 팀이 잘못했다. 이 글은 그 이야기다.배경부터 정리하면, 우리 팀은 이미지 변환 파이프라인을 KEDA + SQS로 운영하고 있다. 사용자가 이미지를 업로드하면 S3 트리거가 SQS로 메시지를 보내고, 워커 파드가 그걸 받아서 리사이..

CNI 교체는 사실 자주 할 일이 아니다. 한 번 들어가면 클러스터 수명 내내 같이 가는 컴포넌트라 잘못 고르면 두고두고 후회한다. 우리 팀은 작년 4분기에 Calico로 운영하던 프로덕션 클러스터 3개를 Cilium으로 옮겼고, 그 후 약 8개월을 양쪽 다 운영해봤다. 아직 일부 레거시 클러스터는 Calico를 그대로 두고 있어서 비교가 가능한 상황이다.이번 KubeCon EU에서도 Cilium 세션이 절반은 되더라. CNCF 2025 연간 서베이에서 Cilium이 Calico랑 Flannel을 제치고 프로덕션 CNI 1위를 먹었다는 발표가 있었는데, 우리 팀이 옮길 때만 해도 그 정도까진 아니었다. 1년 사이에 분위기가 꽤 바뀐 셈이다.왜 옮겼는가솔직히 처음부터 옮길 생각은 없었다. Calico는 안..

오늘 알게 된 건 아닌데, 의외로 안 걸어둔 팀이 꽤 있더라. idle_in_transaction_session_timeout 얘기다.내용은 단순하다. BEGIN 떠놓고 클라이언트가 다음 쿼리 안 보내고 가만히 있는 세션을 지정 시간 지나면 서버가 죽인다. 기본값이 0(비활성)이라 그냥 둔 클러스터가 많은데, 한 번 사고 겪고 나면 절대 안 빼게 된다.왜 굳이 켜야 하나문제는 두 갈래다.첫째, 락 점유. 누가 어딘가에서 UPDATE 치고 COMMIT 안 한 채 자리 비우면 그 행은 계속 잠긴 채로 다른 쿼리들이 줄을 선다. 우리 팀에선 예전에 어드민 페이지에서 BEGIN; UPDATE ... WHERE id=?; 까지 가놓고 응답 안 돌아온 세션 하나 때문에 결제 트래픽 P99가 8초까지 튀었다.둘째, ..

지난주 화요일 새벽 3시쯤이었다. 슬랙 oncall 채널에 "그라파나 대시보드 일부 패널이 No data로 뜬다"는 핑이 올라왔다. 자다가 받은 알림이라 멘탈이 좀 나간 상태에서 노트북을 열었는데, 진짜로 우리 결제 서비스 P99 레이턴시 그래프가 새벽 1시 47분부터 약 한 시간 동안 비어 있었다.문제는 Prometheus 자체는 멀쩡했다는 거다. up{} 메트릭도 정상이고 로컬 쿼리도 잘 됐다. 그런데 Thanos를 통해 보던 장기 보관 대시보드에서만 그 구간이 통째로 비어 있었다. 결론부터 말하면 remote_write 큐가 막혀서 WAL에서 읽기가 블록됐고, 그 사이에 들어온 샘플들이 일부 누락됐다. 이게 내가 새벽 4시까지 깨어 있었던 이유다.처음 의심한 것들 (다 틀렸음)가장 먼저 의심한 건 ..