day-log

지난주에 우리 팀 OpenTelemetry Collector 파드들이 갑자기 OOMKill 잔치를 벌였다. 평소 워킹셋이 1.2GB 정도였는데, 어느 날 새벽부터 4GB까지 치솟더니 limit(6GB)을 넘기고 죽기 시작했다. 트래픽이 갑자기 늘어난 것도 아니고 설정을 건드린 것도 아니었다. 그라파나 패널 보면서 "아 이거 또 시작이네" 싶었다.결론부터 말하자면 batch processor의 send_batch_size를 잘못 키운 게 시작이었고, 거기에 exporter queue가 백프레셔를 못 받아주면서 메모리가 무한정 쌓였다. 글 안에 다 풀어쓰겠지만, 비슷한 증상 보시는 분들은 일단 memory_limiter부터 위에 끼워두시는 걸 권한다.증상 — 처음 3시간 동안 본 것오전 5시 23분에 첫 페..

kubectl describe pod에서 Pulling image "..."가 한참 머물러 있을 때, 그 안에서 무슨 일이 벌어지고 있는지 정확히 설명할 수 있는 사람이 의외로 적다. 나도 그랬다. "registry에서 layer 받아서 디스크에 풀고 mount한다" 정도가 내가 가진 모델의 전부였다. 근데 작년 말부터 ARC runner들이 콜드 스타트에서 한참 깔리는 문제를 디버깅하면서, 이 흐름을 좀 진지하게 들여다봐야겠다는 생각이 들었다. fetch가 느린 건지, unpack이 느린 건지, snapshotter가 느린 건지 분리해서 보지 못하면 튜닝 포인트가 없다.이 글은 containerd 2.x 기준으로 image pull 한 번이 어떤 단계를 거치는지, 각 단계에서 무엇을 디스크에 쓰는지, ..

지난주 화요일 새벽 2시 47분알림이 울렸다. 캐시 레이어 P99가 평소 8ms 수준에서 4초까지 튀었다는 것이다. 멘탈이 나갔다. 침대에서 노트북을 펴는데 손이 약간 떨렸다.원인은 Redis Cluster slot resharding이었다. 평소처럼 야간 저트래픽 시간대에 노드 두 대를 추가하고 슬롯을 옮기는 작업이 돌아가고 있었는데, 이게 그냥 평범하게 끝나지 않았다. 몇 시간 동안 로그와 메트릭을 뒤지면서 알게 된 것들을 정리해둔다.우리 환경24노드 Redis Cluster (마스터 12, 레플리카 12). EKS 위에서 StatefulSet으로 운영 중이고, 키 수는 약 1.2억개, 메모리는 노드당 평균 28GB. 샤드 수가 늘어 일부 노드가 메모리 한계에 다다라서 노드를 추가하기로 했다. 새 노..

이미지 서명을 안 하는 팀은 이제 거의 없을 거다. 빌드 파이프라인에 cosign 한 줄 박는 건 어렵지도 않으니까. 문제는 검증 쪽이다. 누가 서명 안 된 이미지를 클러스터에 푸시해도 그냥 굴러간다. 결국 admission 단에서 막아야 하는데, 이걸 가장 깔끔하게 해주는 게 Kyverno의 ImageValidatingPolicy다.올해 초 Kyverno에서 기존 ClusterPolicy의 verifyImages 규칙을 ImageValidatingPolicy(IVP) 라는 별도 타입으로 분리하면서 정책 작성이 좀 더 명시적으로 바뀌었다. 우리 팀에서도 4월 초에 ClusterPolicy 기반 검증을 IVP로 옮겼는데, 옮기면서 정리한 내용을 가이드 형태로 풀어본다.사전 준비물Kubernetes 1.28..

지난주 새벽 3시, 알람으로 깨서 백업 잡이 또 깨진 걸 확인했다. PVC 30개 짜리 워크로드 백업이 두 시간 째 매달려 있었고, node-agent 데몬셋의 메모리는 8Gi를 찍고 OOM. 이게 벌써 이번 분기 들어 세 번째다. 1.14에서 1.15로 올린 다음부터 백업 패턴이 이상해졌고, 솔직히 말하면 우리 팀은 한 달 가까이 이 마이그레이션을 우습게 봤다.원인은 단순하지 않았다. Velero 1.15에서 데이터 업로드 액션이 node-agent에서 떨어져 나와 DataUpload 단위 마이크로서비스 파드로 분리됐는데, 그 변화가 우리 클러스터 토폴로지와 안 맞았다. 이 글은 그 한 달간의 삽질을 정리한 노트다.처음에 뭐가 바뀐 건지 제대로 안 봤다릴리즈 노트를 한 번은 읽었다. "data move..

GitHub-hosted runner 비용이 슬슬 부담스러워서 self-hosted로 갈아탈 때, 요즘은 거의 ARC(Actions Runner Controller) + Karpenter 조합이 정석처럼 굳어가는 분위기다. 우리 팀도 작년 말부터 이 구성으로 전환했고, 그 과정에서 정리해둔 내용을 가이드로 풀어본다.작년 6월에 ARC 0.12가 나오면서 ephemeral runner 설치가 큐잉되고 실패 시 5번까지 재시도하는 식으로 바뀌었다. 노드 스케일 다운 도중에 러너 파드가 휘말려 죽는 케이스에서 체감이 꽤 좋아졌다. 이 글은 0.12 이상 기준이다.왜 Karpenter랑 묶나처음엔 Cluster Autoscaler로도 충분하지 않을까 했었다. 결론부터 말하면, CI 워크로드 특성상 Karpent..

지난주에 사내 보안팀에서 state 파일 감사를 돌렸다. 결과 보고서를 받아보니 우리 팀 모듈 몇 개에 RDS master password가 평문으로 박혀 있었다. random_password로 만들어서 aws_db_instance.password에 넘긴 건데, 그 흐름을 타는 모든 값이 state에 그대로 적힌다. KMS로 백엔드 암호화는 해뒀어도, 누가 terraform show만 치면 그냥 보이는 거라 좀 찜찜했다.이거 사실 1.11부터 들어온 write-only argument로 우회할 수 있다. 1.10에서 ephemeral resource가 먼저 들어왔고, 1.11에서 write-only가 따라 들어온 건데, 모르고 계신 분이 의외로 많길래 짧게 정리해본다.동작 방식1.10의 ephemeral..

요즘 사내에서 sidecar 없는 서비스 메시 이야기가 자주 나온다. 우리 팀도 작년 4분기에 Istio sidecar 모드를 운영하다가 메모리 footprint와 업그레이드 부담에 지쳐서 sidecarless 옵션을 진지하게 검토하기 시작했다. 후보는 두 개로 좁혀졌다. Istio Ambient Mode와 Cilium Service Mesh.둘 다 sidecar를 없앤다는 큰 그림은 같은데 접근 방식이 꽤 다르다. 어느 쪽이 우리 팀에 맞는지 판단하기까지 두 달 정도 PoC를 돌렸고, 그 과정에서 알게 된 것들을 정리한다. 결론부터 말하면 우리는 아직 한쪽을 완전히 못 정했다. 그래서 이 글은 깔끔한 권고문이 아니다.데이터 플레인이 어디서 도는가가장 큰 차이는 트래픽이 처리되는 위치다.Istio Amb..

쿠버네티스 클러스터가 어느 정도 커지면 DNS가 가장 먼저 비명을 지른다. 우리 팀도 노드 80대 규모 EKS에서 CoreDNS QPS가 2만을 넘기면서 P99 레이턴시가 200ms 가까이 튀는 걸 보고 나서야 손을 댔다. NodeLocal DNSCache는 들어봤는데, autopath는 의외로 안 쓰는 팀이 많더라. 이 둘을 같이 써야 진짜 효과가 난다.이 글은 두 컴포넌트를 같이 도입하는 가이드다. 각각의 역할, 설정 순서, 그리고 같이 쓸 때 주의할 점까지 정리했다.ndots:5가 만드는 N+1 쿼리 문제쿠버네티스 파드에 들어가서 cat /etc/resolv.conf를 찍어보면 이런 게 나온다.search default.svc.cluster.local svc.cluster.local cluster...

SLO 알림 한 번 손봤다가 두 달을 끌었다. 이게 뭐 그리 복잡하다고. 처음엔 그렇게 생각했다.우리 팀은 작년 가을부터 핵심 API 다섯 개에 대해 SLO 기반 알림을 운영하고 있다. 가용성 99.9%, 레이턴시 P99 300ms 이하. 알림은 Prometheus + Alertmanager 조합. Google SRE Workbook에 나온 multi-window multi-burn-rate(MWMBR)를 그대로 베껴 쓰고 있었다. 처음엔 만족스러웠다. 그런데 올해 초부터 슬슬 문제가 보이기 시작했다.1차 시도: Workbook 그대로 베끼기처음 셋업할 때는 SRE Workbook 표를 그대로 옮겼다. 4개 티어, 각 티어마다 short/long 두 윈도우.- alert: HighErrorBudgetBu..