kubernetes 181

kube-scheduler Preemption 내부 동작, 왜 내 PriorityClass는 예상대로 안 미나

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

IT/Kubernets 2026.08.19

CoreDNS NXDOMAIN 캐시가 만든 30초 지옥, ndots:5의 그림자

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

IT/기타 2026.08.19

PDB 잘못 걸어놓고 새벽 3시에 노드 드레인이 멈춘 이야기

지난주 화요일 새벽이었다. EKS 컨트롤 플레인 마이너 버전 업그레이드에 맞춰 노드 그룹 rolling 교체를 걸어놨는데, 새벽 3시쯤 슬랙에 "노드 3대가 30분째 SchedulingDisabled 상태로 안 빠진다"는 알림이 떴다. 새벽에 눈이 번쩍 떠졌다.원인은 결국 우리가 반년 전쯤 붙여둔 PodDisruptionBudget 이었다. 그런데 이게 왜 하필 이번 업그레이드에서 터졌는지, 어디서 계산이 어긋났는지를 정리해두려고 이 글을 쓴다.뭐가 문제였나우리 팀은 결제 관련 워크로드 몇 개에 minAvailable: 2 로 PDB를 걸어뒀다. 처음 붙일 때 replica가 4~5개였고, "최소 2개는 살아있어야 한다"는 서비스 팀 요구를 반영한 값이었다.문제는 그 사이에 트래픽 특성이 바뀌면서 몇몇 ..

IT/SRE 2026.08.16

In-place Pod Resize, GA는 됐지만 우리 팀은 아직 조심스럽게 쓴다 — 내부 동작과 함정

작년 12월 1.35에서 In-place Pod Resize가 드디어 GA로 승격됐다. KEP-1287, alpha가 1.27에서 붙었으니 거의 3년을 굴러 온 셈이다. 사내에서도 "이제 VPA를 Recreate 없이 돌릴 수 있는 거냐"는 얘기가 나왔고, 실제로 몇 개 워크로드에는 붙여봤다. 근데 붙여보고 나서 든 생각은, 스펙 문서만 보고 판단하기엔 내부 동작이 좀 미묘하다는 거였다.이 글은 우리 팀이 실제로 어떤 지점에서 걸렸고, 왜 GA인데도 아직 전 클러스터 롤아웃을 안 했는지에 대한 이야기다. 스펙 요약이 아니라 kubelet과 컨테이너 런타임 경계에서 실제로 무슨 일이 벌어지는지를 파고들어 본다.리사이즈 요청이 실제로 통과하는 경로kubectl로 파드 리소스를 patch하면, 그 요청은 po..

IT/Kubernets 2026.08.16

Fluent Bit vs Vector, 로그 수집기 뭘 쓸까

로그 파이프라인 재설계 얘기가 팀 내부에서 다시 나왔다. 3년 전에 Fluentd로 깔아둔 걸 언제까지 끌고 갈지, 지금 시점에서 갈아탄다면 Fluent Bit이냐 Vector냐. 두 도구 모두 몇 달씩 붙잡고 굴려봤기 때문에 이 참에 정리해두려고 한다.결론부터 말하면 "무조건 이거"는 없다. 다만 우리 팀이 어떤 상황에서 뭘 골랐는지, 왜 그랬는지는 명확하게 얘기할 수 있다.두 도구를 다시 보자Fluent Bit은 C로 짜였고 CNCF 공식 프로젝트다. Kubernetes 생태계 안에서는 사실상 표준처럼 자리잡은 지 오래다. 바이너리 크기 작고, 메모리 몇십 MB로 노드마다 DaemonSet으로 깔아둬도 티가 안 난다. Kubernetes metadata filter가 안정적이고, tail input의..

IT/모니터링 2026.08.15

Karpenter consolidation 내부 동작 파헤치기 — 노드가 사라지기까지

Karpenter 1.x가 굴러가는 클러스터를 몇 개 운영해보니, "왜 이 노드가 갑자기 사라졌지?" 하는 질문이 종종 나온다. 특히 consolidation 정책을 WhenEmptyOrUnderutilized로 두면 (1.x 기본값이다) 반쯤 차 있는 노드도 사라진다. 사실 내부적으로는 꽤 정교한 시뮬레이션을 돌리고 있는데, 이걸 모르면 로그만 봐도 무슨 소린지 모르겠다.이 글은 Karpenter가 노드 하나를 지우기로 결정하기까지 내부에서 무슨 일이 벌어지는지, 코드 구조와 로그를 따라가면서 풀어본다. 우리 팀에서 Karpenter를 도입한 지 반년쯤 됐는데, 이 흐름을 이해하고 나니 disruption budget 튜닝이 훨씬 편해졌다.disruption controller가 하는 일Karpente..

IT/Kubernets 2026.08.14

External Secrets Operator, IRSA로 시작하는 실전 가이드

Kubernetes Secret을 base64로 관리하는 시대는 이제 좀 지나갔다. etcd에 평문으로 들어가는 걸 감안하면 그냥 인코딩된 문자열일 뿐이다. 그래서 대부분 팀은 외부 시크릿 매니저(AWS Secrets Manager, Vault, GCP Secret Manager 등)로 옮겨간다.문제는 이걸 어떻게 Pod까지 안전하게, 그리고 회전(rotation)까지 자동으로 반영되도록 연결하냐는 것이다. External Secrets Operator(이하 ESO)가 이 자리를 채운다. 올해 초 나온 ESO 2026 가이드들을 훑어보면 대부분 "설치하고 SecretStore 만들고 ExternalSecret 정의하면 끝"이라고 쓰여있는데, 실제 프로덕션에 넣어보면 IRSA 권한, refreshInter..

IT/DevSecOps 2026.08.13

cgroup v2 memory.high — Pod가 OOM 없이 느려지는 진짜 이유

프로덕션에서 이상한 장애 하나를 잡으려고 며칠을 썼다. Pod는 살아있고, kubelet 이벤트에도 OOMKilled가 없다. 근데 P99 응답시간이 300ms에서 갑자기 2초를 찍는다. HPA는 CPU 기반이라 안 뜨고, memory usage 그래프는 limit 근처에서 톱니처럼 움직인다. 뭔가 죽지는 않는데 계속 밀린다.원인은 cgroup v2의 memory.high였다. K8s 1.36에서 Memory QoS 기능이 안정화되면서 kubelet이 이걸 자동으로 세팅하는 노드가 늘었는데, 그 동작을 모르면 지금 우리 클러스터에서 겪는 이런 "OOM 없는 느려짐"의 원인을 짚기 어렵다. 사실 내부적으로 커널이 어떻게 스로틀링하는지 이해하고 나면 튜닝 포인트가 명확해진다.memory.max와 memory..

IT/Kubernets 2026.08.13

Ingress-NGINX vs Gateway API, 우리 팀은 뭘 선택했나

Ingress-NGINX를 4년 넘게 써왔다. 그동안 별문제 없이 잘 굴러갔는데, 올해 초부터 팀 내부에서 Gateway API로 넘어가야 하는 것 아니냐는 이야기가 계속 나왔다. 근거는 나쁘지 않았다. Gateway API v1.5가 2026년 2월에 나오면서 상당수 기능이 Stable로 승격됐고, 6월에 v1.6까지 이어졌다. Ingress에 없던 표준 트래픽 분할, 리트라이 버짓, BackendTLSPolicy 같은 것들이 실제로 필요했다.두 달 넘게 검토했고, 결론은 "전면 이관은 아니고, 신규 서비스부터 단계적으로"였다. 그 결정에 이르기까지 뭘 봤는지 정리해둔다.뭐가 다른가가장 큰 차이는 리소스 모델이다. Ingress는 하나의 오브젝트가 라우팅과 컨트롤러 설정을 다 짊어진다. 그래서 어노테이..

IT/기타 2026.08.12

ApplicationSet Progressive Sync 도입하다가 반쯤 실패한 이야기

지난달 우리 팀에서 ArgoCD ApplicationSet의 Progressive Sync를 처음 붙여봤다. 클러스터 6대에 걸쳐 있는 인프라 성격의 앱들을 한 번에 롤아웃할 때 폭발 반경을 줄여보자는 목적이었는데, 결론부터 말하면 절반은 살렸고 절반은 원래 하던 대로 되돌렸다. 그 과정에서 배운 걸 좀 정리해둔다.왜 갑자기 Progressive Sync였나우리는 ApplicationSet의 cluster generator로 6개 EKS 클러스터에 fluent-bit, node-exporter, cert-manager, ExternalDNS 같은 인프라 워크로드를 뿌리고 있다. 문제는 이게 진짜로 6대에 동시에 나가버린다는 거였다. 지난 분기에 fluent-bit config를 잘못 바꿔서 6대 전부에서..

IT/CI CD 2026.08.11