day-log

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"..

우리 팀은 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 ..

이거 모르는 분 꽤 많더라. 우리 팀도 작년 말까지 모르고 있었고, 우연히 디플로이 파이프라인 디버깅하다가 발견했다.concurrency: 블록을 workflow 레벨에 걸어 둔 상태에서 matrix strategy로 OS 3개를 동시에 돌리면 어떻게 될까. 정답은 3개가 서로를 취소시킨다.name: teston: [push]concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: truejobs: test: strategy: matrix: os: [ubuntu-latest, macos-latest, windows-latest] runs-on: ${{ matrix.os }} ..

큐가 갑자기 쌓일 때 HPA(CPU 기반)는 거의 도움이 안 된다. 워커 파드의 CPU는 정작 한가한데 메시지는 계속 쌓이는 상황, 한 번쯤 겪어봤을 것이다. 이런 경우엔 큐 길이 자체를 메트릭으로 써야 한다. KEDA가 그걸 표준화해준다.이 글은 RabbitMQ 컨슈머를 KEDA로 스케일링할 때 실제로 챙겨야 하는 설정들을 정리한 가이드다. KEDA 2.17 기준이고, 운영하면서 한 번씩 발 걸렸던 항목 위주로 적었다.왜 HPA만으로는 부족한가전형적인 큐 워커는 메시지 하나 처리에 I/O 대기가 많다. 외부 API 콜, DB 조회, S3 업로드 같은 것들. 이런 워커는 CPU가 30%만 찍혀도 큐는 만 건씩 쌓일 수 있다. CPU 50%를 임계로 HPA를 걸어두면 영원히 안 늘어난다.큐 길이를 직접 보..

작년 이맘때쯤 progressive delivery를 본격적으로 도입하기로 결정했다. 그 때만 해도 우리 팀은 "둘 다 비슷한 거 아니야?"라는 분위기였고, 사실 데모만 보면 정말 비슷해 보였다. 캐너리, 블루그린, 메트릭 기반 자동 promotion. 똑같은 단어들이 양쪽 문서에 다 나온다.그래서 우리는 좀 무책임한 결정을 했다. 둘 다 써보기로 했다. 일부 서비스는 Flagger, 일부는 Argo Rollouts. 1년이 지난 지금, 한쪽으로 통일하기로 했고, 그 과정에서 알게 된 차이들을 정리해 본다.시작 환경우리 환경을 먼저 짧게 적는다. 비교는 결국 환경 의존적이라서.EKS 1.32 클러스터 두 대 (스테이지/프로덕션)서비스 메시는 Istio (ambient 아니고 sidecar)GitOps는 ..

관측성 파이프라인 한 번이라도 운영해본 사람이면 다 비슷한 고민을 한다. "에이전트는 뭘로 깔지?" 예전에는 Prometheus + Promtail + Tempo agent 같은 식으로 컴포넌트별로 따로 깔거나, 통합하려면 OpenTelemetry Collector 한 장 깔거나, 그것도 아니면 Grafana Agent 깔거나. 그런데 Grafana Agent가 Alloy로 리브랜딩된 이후, 그리고 그 사이에 OTel Collector contrib도 계속 두꺼워지면서 선택지가 다시 흐릿해졌다.우리 팀에서도 작년 말에 한 번 정리하고 갔는데, 최근 Alloy v1.16 시리즈가 나오고 OTel Collector 쪽도 컴포넌트가 또 바뀌면서 다시 비교할 필요가 생겼다. 이번 글은 그 정리 노트다. 어느 쪽..

containerd 2.0이 나오면서 NRI(Node Resource Interface)가 기본 enable 상태가 됐다. 그동안 "kubelet의 device plugin이나 CDI랑 뭐가 다르냐"는 질문을 꽤 많이 받았는데, 막상 코드를 따라가 보면 NRI는 컨테이너 라이프사이클 hook을 user-space 프로세스로 빼낸 RPC 인터페이스에 가깝다. CPU pinning, NUMA-aware allocation, GPU annotation 같은 걸 runtime을 건드리지 않고 끼워넣을 수 있는 곳. 우리 팀에서도 최근 AI 워크로드 노드에 NRI 기반 토폴로지 플러그인을 깔면서 처음으로 코드를 깊이 봤다. 이 글에서는 NRI가 어디서 호출되고, 플러그인이 어떻게 컨테이너 스펙을 조작하며, 왜 s..