day-log

3월 20일자로 ingress-nginx가 공식 EOL이 됐다. 같은 날 ingress2gateway 1.0이 GA로 풀렸다. 두 이벤트가 같은 날 풀린 게 우연이 아니다 — 업스트림에서 "이제 진짜 옮길 때다"라고 못박은 거다.EOL 전부터 우리 팀도 마이그레이션을 시도했는데, 0.x 시절 ingress2gateway는 ingress-nginx 어노테이션을 3개밖에 못 바꿨다. 그래서 일단 미뤄두고 있었는데 1.0이 나오면서 30개 이상 지원으로 확 늘었다. 마침 옮길 만한 시점이다 싶어서, 지난 2주간 스테이징 → 프로덕션 일부 클러스터까지 옮겨봤다. 그 과정 정리.옮기기 전에 알아둘 것Gateway API는 Ingress 리소스 하나에 다 욱여넣었던 라우팅 + 어노테이션 정글을 두 단계로 쪼갠다. ..

NetworkPolicy를 처음 도입할 때 가장 답답한 게 뭐냐고 물으면, 나는 망설임 없이 "왜 막혔는지 모르겠다"고 답한다. kubectl logs를 봐도 connection timeout만 보이고, 정작 어느 정책이 그 트래픽을 끊었는지는 알려주지 않는다. 예전엔 cilium monitor를 노드 단위로 띄워서 한참을 들여다봤는데, Hubble이 들어오고 나서는 이 과정이 꽤 깔끔해졌다.이 글은 Cilium 1.19.x 환경에서 Hubble을 가지고 네트워크 정책을 디버깅하는 워크플로우를 정리한 거다. 우리 팀에서 정책을 새로 추가할 때마다 반복적으로 쓰는 절차이고, 신규 입사자한테도 이 순서대로 보여준다.Hubble flow를 보기 전에 확인할 것먼저 Hubble이 활성화돼 있어야 한다. 의외로 ..

들어가며OOMKill은 K8s 운영하면서 가장 자주 마주치는 종류의 죽음 중 하나다. 그런데 막상 "왜 죽었냐"고 물으면 Last State: OOMKilled 로그 한 줄 외엔 잘 못 말하는 경우가 많다. 사실 나도 그랬다. 우리 팀 내부 논의에서 "메모리 limit 부족이지" 정도로 넘기던 게 한 90% 였고, 정작 그 직전 kernel과 kubelet이 어떤 신호를 주고 받았는지는 들여다본 적이 별로 없었다.이번 글에서는 cgroup v2 환경에서 Pod의 메모리가 limit 근처까지 차오를 때 노드 안에서 어떤 흐름이 도는지를 정리한다. K8s 1.28부터 cgroup v2 동작이 한 단계 정리됐고, 1.34에서 PSI 메트릭이 Beta로 올라오면서 이 영역의 운영 가시성이 꽤 좋아진 시점이다.m..

지난달에 SQS 기반 워커 파드를 KEDA로 옮겼다. HPA의 CPU 메트릭만으로는 큐가 쌓일 때 늦게 반응하는 게 계속 거슬려서, 큐 길이로 직접 스케일하는 게 자연스러워 보였다. KEDA는 2.19가 최근에 떨어졌고(2026-02), SQS scaler에 scaleOnDelayed 같은 옵션도 정리돼 있어서 큰 고민 없이 시작했는데, 정작 일주일 동안 새벽에 두 번 호출되고 나서야 정신을 차렸다. 그 과정 정리.시작은 정상이었다워크로드는 단순하다. 외부 이벤트 → SQS → 워커 파드(Go 단일 바이너리)가 메시지 하나씩 받아 처리. 평소엔 큐가 비어 있고, 1시간 단위로 큐가 수만 건씩 쌓이는 burst 패턴이다. 한 메시지 처리에 평균 2초, P99 8초.처음 달았던 ScaledObject는 거의..

쿠버네티스에서 시크릿을 어떻게 가져올 것이냐. 이 질문은 보통 회사가 어느 정도 커지고 클러스터가 두세 개 늘어나는 시점에 한 번 크게 부딪힌다. 우리 팀도 그랬다. 작년 초까지는 그냥 kubectl create secret으로 박아 넣고 헬름 차트에 손으로 옮기는 식이었는데, 클러스터가 4개로 늘고 환경별로 시크릿 동기화 누락이 두 번쯤 사고로 이어지면서 더는 못 미루겠다는 결론이 났다.후보는 사실상 두 개였다. External Secrets Operator(이하 ESO)와 HashiCorp의 Vault Agent Injector. 둘 다 충분히 성숙했고 사례도 많다. 그런데 막상 비교하기 시작하면 "어느 게 더 좋은가" 자체가 잘못된 질문이라는 게 금방 드러난다. 결국 우리 팀이 어떤 시크릿을 다루고..

오늘 알게 된 건 아니고, 최근에 팀원이 Karpenter 설정 PR을 올렸길래 리뷰하다가 "어 이게 v1.0부터 바뀌었는데 모르는 분들 꽤 많겠네" 싶어서 짧게 정리해둔다.WhenUnderutilized 라는 이름은 이제 없다Karpenter 1.0 GA 이후로 WhenUnderutilized는 WhenEmptyOrUnderutilized로 이름이 바뀌었다. 옛날 블로그 글이나 사내 위키 보고 그대로 복붙하면 NodePool apply가 깨진다. 지난주에 1.12.0이 나왔는데도 검색하면 아직 옛날 이름이 상위에 뜨더라.그리고 더 중요한 변화 — 1.0부터는 consolidateAfter를 WhenEmptyOrUnderutilized에서도 쓸 수 있다. 이전에는 WhenEmpty에서만 동작해서, "노드..

지난주 화요일 새벽 2시 17분에 페이저가 울렸다. 결제 API의 P99 레이턴시가 1.2초를 찍고 있었다. 보통 80ms대로 노는 애가 갑자기 15배가 됐는데, 이게 가끔 한 번씩 튀고 끝나는 게 아니라 5분 동안 꾸준히 그 모양이었다. 멘탈이 살짝 나갔다. 결제는 트래픽 자체는 크지 않은데 도미노가 한번 시작되면 SLO 까먹는 속도가 가차 없는 구간이라.결론부터 적자면, 그날 밤 범인은 애플리케이션도, DB도, 네트워크 장비도 아니었다. CoreDNS와 conntrack이었다. 며칠 뒤 NodeLocal DNSCache를 깐 후로는 같은 증상이 안 났는데, 이 일을 글로 정리해두고 싶었다. 비슷한 패턴은 의외로 흔한 것 같아서.처음에 의심한 것들알람 받자마자 떠오른 후보는 셋이었다. 결제 DB의 락,..

클러스터가 늘어나고 환경이 늘어나면 어느 시점에 Application YAML이 폭발한다. 우리 팀도 그랬다. 클러스터 6개에 환경(dev/stg/prod) 3개, 거기에 공통으로 들어가는 플랫폼 컴포넌트 8개를 곱하니 144개의 Application 리소스가 git에 쌓였다. 사람이 손으로 관리할 수 있는 규모를 넘은 지 오래였다.이걸 ApplicationSet의 matrix generator로 정리한 과정을 적어둔다. Argo CD 공식 문서에는 패턴이 짧게만 소개돼 있고 실전에서 부딪히는 디테일은 잘 안 보여서, 우리 팀이 정착시킨 구성을 그대로 옮긴다. Argo CD 3.0 기준이지만 2.10 이상이면 거의 동일하게 동작한다.왜 matrix generator인가ApplicationSet에는 Lis..

지난달에 결국 Karpenter로 갈아탔다. 팀에서 반년 넘게 "다음 분기에 해야지" 하며 미뤄왔던 숙제였는데, 예상대로 쉽지 않았다. 이 글은 자랑이 아니라 그냥 기록이다. 비슷한 고민 하는 분들에게 조금이라도 도움이 됐으면 해서 적는다.Karpenter가 v1.0 GA 찍은 지도 벌써 한참 됐고, 최근에는 OCI provider까지 GA 나오면서 더 이상 "AWS 전용 실험 프로젝트" 소리는 못 듣는 상황이다. 그래도 막상 프로덕션에 올려보면 문서에 안 나오는 함정이 꽤 있다.왜 옮겼나솔직히 Cluster Autoscaler(CAS)가 못 쓸 물건은 아니다. 노드 18대 규모에서 몇 년을 잘 돌았다. 문제는 배치 잡 비중이 커지면서부터였다.우리 팀은 데이터 파이프라인 일부가 Kubernetes Job..

클러스터가 3개를 넘어가면서 ArgoCD Application 매니페스트를 하나하나 만들어 관리하는 게 현실적으로 불가능해진 경험이 있을 것이다. dev, staging, production에 각각 마이크로서비스 10개만 배포해도 Application YAML이 30개다. 여기에 리전별 클러스터까지 추가되면 관리 포인트가 기하급수적으로 늘어난다.ArgoCD ApplicationSet Controller는 이 문제를 정면으로 해결한다. 템플릿 하나로 여러 클러스터, 여러 환경에 Application을 자동 생성하고 라이프사이클까지 관리할 수 있다. 이 글에서는 실무에서 바로 적용할 수 있는 ApplicationSet 패턴들을 다룬다.ApplicationSet이 필요한 이유기존 방식에서는 새 클러스터를 추가..