day-log

ArgoCD ApplicationSet Progressive Sync 실무 가이드멀티 클러스터로 ArgoCD를 굴리다 보면 한 번은 겪는 상황이 있다. 앱 매니페스트를 하나 바꿨는데 그게 20개 클러스터에 동시에 동기화되면서, 하필 그 변경이 문제였을 때 20개가 같이 뻗어버리는 케이스. 우리 팀도 지난 분기에 한 번 크게 데었고, 그 이후로 ApplicationSet Progressive Sync를 프로덕션에 도입했다.이 글은 도입하면서 정리한 내용이다. 문서만 보고 따라 하면 놓치기 쉬운 부분 위주로 적었다. Progressive Sync 자체는 2026년 현재 Beta로 승격됐는데, 여전히 experimental 플래그로 활성화해야 한다는 점을 먼저 짚어둔다.Progressive Sync가 뭘 하는..

Trivy를 처음 붙였을 때 우리 팀은 CVE 몇천 개짜리 리포트 앞에서 멘탈이 나갔다. CVSS 9.8이 수백 개인데 이걸 다 이번 스프린트에 잡으라니. 근데 그게 진짜로 다 위험한 걸까? 결론부터 말하면 아니다. CVSS는 "이 취약점이 뚫리면 얼마나 아플까"만 알려주지, "누가 지금 이걸 실제로 뚫고 있냐"는 답하지 않는다.이 글은 CVSS 하나로만 우선순위를 매기다가 지친 팀을 위한 실무 가이드다. EPSS로 실제 익스플로잇 확률을, KEV로 이미 공격당하고 있는 CVE를 걸러내서 컨테이너 이미지 스캔 결과를 실행 가능한 수준으로 줄이는 방법을 다룬다.세 지표가 서로 다른 질문에 답한다먼저 각 지표가 뭐에 답하는 도구인지 정리하자.CVSS는 "이론적으로 얼마나 심각한가"에 답한다. 인증 없이 원격..

쿠버네티스 admission 정책 엔진 이야기가 나오면 결국 Kyverno와 OPA Gatekeeper 두 개로 좁혀진다. 몇 년 전에는 "Gatekeeper 쓰면 뭔가 있어 보인다"는 분위기였는데, 최근 우리 팀에서 클러스터 3개에 적용해보고 나니 생각이 좀 바뀌었다. 이번 글은 그 판단 근거를 정리한 것이다.결론부터 말하면, 순수 K8s admission만 필요한 상황에서는 지금 시점에 Kyverno가 손이 훨씬 덜 간다. 다만 그렇다고 Gatekeeper가 죽은 프로젝트냐 하면 그건 또 아니다.정책 언어부터 갈린다Gatekeeper는 Rego를 쓴다. OPA 진영에서 오래 굴려온 언어라 표현력은 확실히 강력하다. 대신 팀 안에 Rego 아는 사람이 한두 명이면 그 사람이 병목이 된다. 실제로 우리 ..

Istio Ambient mode가 1.24에서 GA 된 게 벌써 1년 반 전이다. 우리 팀도 사이드카 지옥에서 벗어나려고 작년 말부터 조금씩 옮겨왔는데, 처음에는 그냥 "사이드카가 사라진 서비스 메시" 정도로 이해하고 시작했다. 그러다 프로덕션에서 이상한 이슈 몇 개 만나면서 결국 ztunnel 내부를 뜯어보게 됐다. 이 글은 그 과정에서 정리한 내용이다.한 가지 미리 얘기하자면, 이 글은 "Ambient가 좋다/나쁘다" 얘기는 아니다. 내부 동작이 어떻게 되어 있는지, 그리고 왜 그렇게 설계됐는지에 대한 노트에 가깝다.ztunnel은 왜 노드마다 하나만 뜨는가Ambient mode의 첫 번째 특징은 데이터 플레인이 두 층으로 쪼개져 있다는 것이다. L4(TCP, mTLS)는 ztunnel이, L7(H..

HPA(Horizontal Pod Autoscaler)를 쓰다 보면 어느 순간 벽에 부딪히는 순간이 온다. CPU가 안 튀는데 큐가 밀리거나, 새벽에는 파드가 0개여도 되는데 굳이 1개는 떠 있어야 한다거나, 아예 커스텀 메트릭 어댑터를 붙이자니 설정이 지저분해지는 그런 순간들.우리 팀도 6개월쯤 CPU 기반 HPA로 버티다가 결국 KEDA로 넘어왔다. 이 글은 그 과정에서 정리한 실무 가이드다. 최근 0.35 코어 의존성으로 올라오면서 events.k8s.io API로 이벤트를 남기는 방식이 바뀌었는데, 이런 세부 변화들도 같이 짚고 넘어가겠다.HPA로 왜 부족한가HPA는 리소스(CPU/메모리)나 커스텀 메트릭을 기반으로 파드 수를 조정한다. 문제는 이게 "지금 파드가 얼마나 힘든가"를 기반으로 한다는..

오늘 알게 된 건데, 아직도 Istio sidecar나 Vault agent를 그냥 containers[]에 박아넣고 쓰시는 분들 꽤 많더라. 우리 팀도 그랬다. 근데 최근 클러스터 1.33 올리면서 native sidecar (초기 컨테이너 restartPolicy: Always)로 싹 옮겼는데, 딱 하나 함정이 있어서 공유한다.뭐가 좋아졌나원래 sidecar 패턴의 고질병이 두 개였다. 하나는 앱 컨테이너보다 sidecar가 늦게 뜨면 초기 요청이 실패하는 거. 또 하나는 Job에서 sidecar가 안 죽어서 Pod가 Completed로 안 넘어가는 거. Vault agent injector 쓰는 팀이면 다들 겪어봤을 거다.Kubernetes 1.33에서 native sidecar가 stable 됐고..

작년 이맘때까지 우리 EKS 클러스터는 Cluster Autoscaler로 잘 돌아가고 있었다. 노드 그룹 세팅도 안정적이었고, 크게 불만도 없었다. 그런데 반년 전쯤 트래픽 패턴이 바뀌면서 상황이 달라졌다. 낮에는 몰리고 밤에는 뚝 떨어지는 변동 폭이 커졌고, 갑자기 배포되는 배치 잡도 늘었다. 그때부터 노드가 이상하게 많이 뜨기 시작했고, 청구서를 볼 때마다 한숨이 나왔다.결국 Karpenter로 옮겼다. 최근에 v1이 정식으로 나오면서 API도 정리됐고, 실전에 쓸 만하다는 얘기가 많아진 시점이었다. 옮기고 나서 두 달쯤 지난 지금, 그 비교를 정리해두려고 한다.스케줄링 철학이 다르다이게 제일 큰 차이다. Cluster Autoscaler는 노드 그룹 단위로 사고한다. 어떤 파드가 pending이면..

Grafana Agent가 작년 11월에 공식 EOL 된 지 벌써 9개월이 넘었는데, 우리 팀은 부끄럽지만 지난주에야 Alloy로 완전히 넘어왔다. 마감 압박 없으면 이런 마이그레이션은 자꾸 미뤄지는 게 사람 심리인 것 같다. 로그/메트릭 수집기가 노드에서 22대, 사이드카로 40개 넘게 떠 있는 환경이라 무섭기도 했고.결론부터 말하면 큰 사고는 없었지만, 문서만 보고 넘어갔다가는 새벽에 한 번쯤 페이지 받을 수 있는 함정이 몇 개 있었다. 정리해 둔다.storage.path 하나 때문에 메트릭이 20분간 안 왔다Alloy는 --storage.path 기본값이 data-alloy/로 바뀌었다. Agent Flow는 data-agent/였고. 이게 컨버터가 자동으로 안 바꿔주는 항목이라 문제였다.WAL이 ..

작년쯤부터 팀 클러스터에 PriorityClass를 슬금슬금 붙이기 시작했다. 배치 잡이 야간 스케줄러를 물고 늘어져서 온라인 워크로드가 스케줄이 안 되는 일이 종종 생겼고, 그때마다 "그냥 우선순위 붙이면 되지 않나?" 하는 이야기가 나왔다. 문서 그대로 priority: 1000000 짜리 클래스를 만들고 붙였는데, 실제로 클러스터가 밀릴 만한 상황이 왔을 때 예상대로 안 밀린 경우가 몇 번 있었다. 그래서 kube-scheduler의 preemption 코드를 찬찬히 뜯어봤고, 그 과정에서 "아, 이래서 이게 안 됐구나" 싶은 지점이 몇 개 나왔다. 오늘은 그 내용을 정리해보려고 한다.이 글은 사용법이 아니라 안쪽 이야기다. Preemption이 어떤 순서로, 어떤 기준으로 pod들을 죽일 후보로 ..

CoreDNS NXDOMAIN 캐시가 만든 30초 지옥, ndots:5의 그림자지난주 화요일 새벽 4시쯤, 온콜 알림이 울렸다. checkout-service 의 외부 결제사 API 콜 P99 레이턴시가 갑자기 5초, 10초를 찍고 있었다. 눈이 번쩍 떠졌다. 결제 흐름이라 반쯤 정신이 나간 채로 노트북을 열었다.결론부터 말하면 범인은 CoreDNS의 NXDOMAIN 네거티브 캐시였다. 그런데 이게 그냥 캐시 문제가 아니라, ndots:5랑 얽혀서 아주 재미없게 터졌다. 몇 시간 동안 헤맨 이야기를 정리해둔다.처음엔 결제사 문제인 줄 알았다첫 반응은 당연히 "결제사 쪽에서 뭐 하나" 였다. 상태 페이지 열어봤다. 정상. 결제사 담당자한테 슬랙 DM 날렸다. "저희 쪽 아무 이슈 없는데요."그럼 우리 클러..