day-log

PR 올라올 때마다 리뷰어한테 "로컬에서 띄워서 봐줘"라고 말하는 게 한두 번이지, 매번 그러기 좀 그렇다. 우리 팀은 PR 하나당 stage 환경에 임시로 배포해서 QA가 직접 클릭해보고 댓글 다는 흐름을 원했는데, 그래서 결국 ArgoCD ApplicationSet의 Pull Request generator를 붙였다.처음엔 "그냥 GitHub Actions로 helm install 돌리면 되는 거 아냐?"라고 생각했는데, 막상 정리되고 나니 GitOps의 일관성이라는 게 꽤 크게 다가왔다. PR 닫으면 알아서 지워주고, 상태도 ArgoCD UI에 그대로 보이고. 이번 글에서는 셋업 과정과 실제로 굴려보면서 부딪힌 몇 가지를 정리한다.PR Generator가 하는 일ApplicationSet은 한 번에..

지난주 화요일 새벽이었다. EKS 클러스터 1.32 → 1.33 업그레이드를 돌리는 중이었는데, 노드 드레인이 4시간째 안 끝나고 있다는 슬랙 알림을 받았다. 새벽 3시였고, 솔직히 처음엔 드레인이 원래 좀 오래 걸리니까 그러려니 했다. 4시간이라는 숫자를 본 순간 멘탈이 한 번 흔들렸다.평소 같으면 워커 노드 한 대 드레인하는 데 길어야 10분 정도였다. 그런데 이번엔 한 노드에 박혀서 안 빠지는 파드가 있었고, 그 파드 하나가 전체 업그레이드 파이프라인을 막고 있었다. 결국 원인은 PDB(PodDisruptionBudget) 하나였다. 짧게 말하면 그렇고, 길게 말하면 우리 팀의 PDB 관리 방식 전체가 문제였다.처음 발견한 증상노드를 cordon하고 drain을 돌렸는데 이런 메시지가 계속 떴다.e..

우리 환경에서의 처리량과 자원우리 팀은 2024년 말부터 Fluent Bit을 메인 로그 수집기로 쓰고 있다. 그전에는 Fluentd였고, 메모리 때문에 갈아탄 거였다. 그리고 작년쯤부터 일부 노드 그룹에 Vector를 같이 굴리고 있다. 이유는 좀 단순한데, 특정 워크로드의 로그가 너무 거칠어서 변환 규칙이 복잡해졌고, Fluent Bit의 Lua filter로 이걸 다 처리하기엔 가독성이 너무 떨어졌기 때문이다.그 상태로 1년 넘게 양쪽을 같이 운영했다. 최근 팀 내부에서 "그냥 한쪽으로 통일하자"는 얘기가 다시 올라와서, 진지하게 다시 비교해봤다. 이 글은 결론이 정해진 비교가 아니다. 솔직히 우리도 아직 한쪽으로 못 정했다.숫자부터 봤다우리 EKS 클러스터는 worker 노드가 약 110대 정도,..

Helm lookup 함수, ArgoCD랑 같이 쓰면 함정 있다오늘 동료가 PR 리뷰 부탁한다고 해서 봤는데, Helm chart에서 lookup 함수를 쓰는 부분이 있었다. 클러스터에 이미 떠 있는 ConfigMap을 읽어서 그 값을 기반으로 다른 리소스를 만드는 패턴. 코드는 깔끔했고 로컬 helm install로도 잘 돌았는데, 내가 한 마디 했다. "이거 ArgoCD에서 안 될걸요."근데 동료는 "어 저번에 다른 차트에서도 비슷하게 썼는데 됐는데?"라고 했고, 결국 같이 한 번 더 들여다보기로 했다. 그 김에 정리.lookup이 뭐였더라lookup은 Helm 3에서 추가된 템플릿 함수다. 차트 렌더링 시점에 K8s API 서버를 쳐서 기존 리소스를 읽어올 수 있다. 예를 들면 이런 식.{{- $e..

지난주 금요일 오후 4시. 평화롭던 사무실에 메신저 알림이 떴다. "스테이징 클러스터 새로 만든 거 거의 다 됐는데, ArgoCD가 SealedSecret 못 푼다고 에러 토하는 중인데 좀 봐주실 수 있어요?" 그 메시지를 본 순간 명치가 싸늘해졌다.왜냐면 그 이전 클러스터의 sealed-secrets controller에서 발급된 master key를 백업해뒀는지 기억이 안 났거든. 결론부터 말하면 안 해놨다. 그래서 그날 퇴근은 새벽 1시였다.무슨 일이 벌어진 건가상황을 좀 정리해보자. 우리 팀은 EKS 1.28 → 1.31 업그레이드를 in-place로 안 하고 새 클러스터를 만들어서 옮기는 방식으로 진행하고 있었다. 스테이징부터. 매니페스트는 ArgoCD GitOps로 관리되니까 그냥 ArgoCD..

왜 굳이 eBPF인가Pyroscope 2.0이 정식 릴리즈되면서 우리 팀도 한 번 손을 대봤다. 결론부터 말하면 — eBPF 기반으로 깔면 코드 한 줄 안 건드리고 P99 튀는 핫스팟을 잡을 수 있다. 다만 처음 깔 때 알아둬야 할 함정이 몇 개 있어서 정리한다.이 글은 EKS 1.31 클러스터(노드 약 60대) 기준이고, Grafana Alloy로 eBPF 프로파일러를 띄우는 방식을 기준으로 쓴다. Java/Go/Python 워크로드가 섞여 있는 환경이다.기존 SDK 방식으로 깔아도 되긴 한다. Java면 async-profiler, Go면 pprof endpoint, Python이면 pyspy를 사이드카로... 근데 워크로드 수가 100개 넘어가면 이걸 다 일일이 깔고 유지하는 게 일이다. 우리 팀에..

지난 한 달 반 동안 우리 팀 컨테이너 이미지 베이스를 alpine에서 Wolfi로 거의 다 갈아치웠다. 처음엔 한 주 잡고 시작한 일이었는데, 막상 들어가보니 musl/glibc 차이부터 시작해서 빌드 캐시, CI 시간, 배포 호환성까지 줄줄이 엮여 있어서 결국 6주 가까이 걸렸다. 솔직히 시작할 때 알았으면 일정을 더 넉넉하게 잡았을 거다.이 글은 그 과정에서 마주친 문제들과 해결한 방법, 그리고 아직 풀지 못한 것들에 대한 기록이다.왜 옮겼나원래 우리는 거의 모든 서비스 베이스가 alpine:3.19 였다. 30MB도 안 되는 사이즈가 매력적이었고, 5년 가까이 큰 문제 없이 잘 써왔다. 근데 작년 4분기부터 보안팀이 들고 온 Trivy 리포트가 점점 두꺼워지기 시작했다. 특히 CVE 누적 속도가 ..

지난 분기에 컨트롤 플레인 한 노드에서 etcd defrag을 잘못 돌리다가 API 서버가 5초간 5xx를 토해낸 적이 있다. 그 뒤로 팀 내부에서 "etcd 만지지 말자"는 분위기가 잠깐 있었는데, 사실 그건 답이 아니다. defrag을 안 돌리면 결국 디스크가 커지고 read latency가 슬금슬금 올라간다. 문제는 동작 원리를 잘 모르는 상태에서 그냥 cron만 돌리는 거였다.이 글에서는 etcd가 MVCC를 어떻게 구현하는지, compaction과 defrag이 정확히 무슨 일을 하는지, 그리고 K8s API 서버 입장에서 그 영향이 어디서 어떻게 보이는지 정리해본다. 운영 가이드 글은 인터넷에 차고 넘치는데, 정작 "왜"가 빠져있어서 매번 어색하게 cron 주기만 조정하게 된다.MVCC, 그러..

오늘 알게 된 것도 아니고, 알고는 있는데 막상 새벽에 장애 터지면 까먹는 옵션 하나를 정리해두려고 한다. kubectl debug --target. 같이 일하는 주니어한테 알려주니까 "어 이게 되네요?" 하길래.흔한 상황운영 중인 Pod에서 네트워크가 이상하다. DNS는 되는데 특정 외부 IP로만 connect timeout. 컨테이너는 distroless라서 kubectl exec로 들어가도 쉘이 없다. 사이드카로 디버깅 컨테이너 박아서 재배포? 새벽 두 시에 그건 좀 그렇다.이럴 때 쓰는 게 ephemeral container, 그리고 kubectl debug다. K8s 1.25에서 GA된 후로 죽 안정적이다. 근데 의외로 --target 옵션을 안 쓰고 그냥 띄워서 "어 왜 안 보이지" 하는 경우..