day-log

지난 주말에 클러스터 노드 OS 패치 작업이 있었다. 24대짜리 워커 노드를 하나씩 cordon → drain → 재부팅 → uncordon 하는 흔한 작업이다. 자동화 스크립트도 있고, 평소엔 노드 한 대당 5분 정도면 끝난다. 그런데 그날따라 9번째 노드에서 kubectl drain 명령이 멈췄다. 30분이 지나도 진척이 없었다. 새벽 2시였고, 나는 졸린 눈으로 터미널을 노려보고 있었다.일단 진정하고 상태 확인부터drain 로그를 보니 이런 메시지가 반복되고 있었다.evicting pod default/payment-api-7c8d9-x4k2perror when evicting pods/"payment-api-7c8d9-x4k2p" -n default(will retry after 5s): Cann..

Kustomize components, 모르는 분 많더라오늘 동료 PR 리뷰하다가 발견한 건데, base/overlay만 쓰고 components를 안 쓰는 분이 의외로 많다. Kustomize 공식 문서에도 들어있고 1.21 이후로는 stable인데 잘 안 알려진 듯. 짧게 정리해둔다.어떤 상황에서 쓰면 좋냐흔한 패턴 — base 하나에 overlay가 dev / staging / prod 이렇게 있다고 치자. 어느 날 누가 "prod랑 staging에는 sidecar 하나 붙여줘"라고 한다. 그러면 보통은 두 overlay에 같은 patch를 복붙한다. 며칠 뒤 또 다른 feature가 prod/staging 공통으로 들어오면? 또 복붙.이게 쌓이다 보면 overlay 디렉터리가 patch 파일 모음..

오늘 후배가 distroless 이미지로 돌아가는 파드를 디버깅하느라 새벽까지 헤매고 있길래 옆에서 한마디 했다. "그냥 --profile=netadmin 붙여." 그랬더니 표정이 묘했다. "그게 뭔데요?" 아... 이거 1.27에서 들어온 게 벌써 3년이 다 돼가는데 의외로 안 쓰는 사람이 많다. 짧게 정리한다.무슨 문제를 푸는가kubectl debug로 ephemeral container를 띄울 때 기본값은 권한이 거의 없다. 그래서 tcpdump나 iptables -L 같은 걸 돌리면 그냥 막힌다. 우리 팀에서도 처음엔 sidecar로 netshoot을 띄워놓던 시절이 있었는데, 그건 그것대로 메모리 잡아먹고 보안팀이 싫어한다.--profile 플래그는 이런 류의 권한 세트를 미리 정의해놓은 프리셋..

Knative activator는 왜 데이터 경로에 끼어들까 — KPA 내부 동작서버리스를 K8s 위에 얹어보려고 Knative Serving을 한 분기 정도 운영 중이다. 처음엔 그냥 "0에서 N으로 자동 스케일되는 마법" 같은 거였는데, 정작 cold start P99가 800ms를 찍기 시작하면서 내부를 안 뜯어볼 수가 없었다. 사실 KPA(Knative Pod Autoscaler) 문서를 읽어도 표면만 도는 느낌이라, 컴포넌트들이 실제로 어떤 흐름으로 협업하는지 직접 추적해봤다.이 글은 activator가 왜 데이터 경로에 들어왔다 빠졌다 하는지, EBC(Excess Burst Capacity)라는 값이 그 결정을 어떻게 끌어내는지, 그리고 panic window라는 약간 무서운 이름의 윈도우가 ..

우리가 깐 구성지난주 화요일 새벽에 알림이 울렸다. 정확히는 알림이 안 울려서 문제였다. 이미지 변환 워커가 SQS 큐의 메시지를 잘 먹고 있는 줄 알았는데, 다음 날 아침에 보니 "어제 업로드한 썸네일이 안 나와요"라는 CS 티켓이 17건 쌓여 있었다. SQS DLQ에 들어간 것도 아니고 그냥 큐 어디에도 없었다. 처리는 안 됐는데 사라졌다는 게 가장 큰 문제였다.원인은 KEDA였다. 정확히는 KEDA가 잘못한 건 아닌데, scaleToZero를 너무 공격적으로 설정한 우리 팀이 잘못했다. 이 글은 그 이야기다.배경부터 정리하면, 우리 팀은 이미지 변환 파이프라인을 KEDA + SQS로 운영하고 있다. 사용자가 이미지를 업로드하면 S3 트리거가 SQS로 메시지를 보내고, 워커 파드가 그걸 받아서 리사이..

새벽 3시 7분에 진동이 왔다새벽 3시 7분. 폰이 진동했다. etcd_mvcc_db_total_size_in_bytes 가 6GiB를 넘었다는 알람이었다. 우리 클러스터는 컨트롤플레인이 EKS가 아니라 자체 운영이고, etcd quota를 8GiB로 잡아놨다. 8GiB를 넘기는 순간 클러스터가 read-only로 떨어진다. 일어났다.평소에는 etcd db size가 1.2~1.5GiB 사이를 왔다 갔다 한다. 그게 6GiB라는 건 어딘가가 단단히 잘못됐다는 뜻이다. 처음엔 그냥 defrag 한번 돌리면 되겠지 했는데, 이게 그렇게 단순한 얘기가 아니었다.일단 무슨 일이 일어났는지부터 봤다ssh로 컨트롤플레인 노드 3대에 붙어서 etcdctl로 상태를 봤다.ETCDCTL_API=3 etcdctl \ -..

1.36 Pod-level in-place resize, 사이드카 많은 Pod일수록 의미가 크다지난달 Kubernetes 1.36이 나오면서 In-Place Pod Resize에 한 가지 작은 게이트가 추가됐다. InPlacePodLevelResourcesVerticalScaling. 1.35에서 컨테이너 단위 in-place resize가 GA 된 직후라 잘 안 보이지만, 사이드카가 덕지덕지 붙은 Pod를 운영하는 입장에선 이게 더 반갑다. 오늘은 그 얘기를 짧게.뭐가 달라졌나기존 in-place resize는 컨테이너 하나하나의 resources.requests/limits를 따로 바꿔야 했다. Pod에 컨테이너가 3개면 patch도 3번. 그것도 모자라서, 사이드카가 자기 limit에 먼저 걸려 t..

상황운영 중인 파드가 한 개 있다. 베이스 이미지는 gcr.io/distroless/static:nonroot. 셸은커녕 ls도 없다. 그런데 갑자기 이 파드만 외부 API 호출이 실패하기 시작한다. DNS 문제인지, 라우팅 문제인지, 인증서 문제인지 확인하고 싶다. 파드를 재시작하면 증상이 사라질 수도 있으니 살아있는 상태에서 보고 싶다. 자, 어떻게 할까?이거 모르는 분 꽤 많더라. 어제 후배가 "프로덕션 파드에 들어가서 curl 좀 찍어보고 싶은데 distroless라서 kubectl exec가 안 먹힌다"라고 슬랙에 글 올린 거 보고 깜짝 놀랐다. kubectl debug가 GA 된 게 1.25 (2022년 후반) 인데, 2026년 지금까지도 의외로 안 쓰는 사람이 많은 것 같아서 짧게 정리한다...

오늘 알게 된 건데, 의외로 Job spec에서 podFailurePolicy 안 쓰는 팀이 꽤 많더라. 같이 일하는 분이 "야 우리 배치가 새벽에 6번 OOM 나고 죽었는데 알람이 한 번에 6번 왔어"라고 메시지를 보내서 들여다봤다. 코드는 멀쩡한데 메모리 한도가 빡빡했고, backoffLimit: 6만 박혀 있었다. 그게 다였다.근데 이게 별거 아닌 것 같아도 비용/알람/멘탈 다 갉아먹는다. 잠깐만 짚고 가자.backoffLimit만 있을 때 무슨 일이 벌어지나Job spec이 이렇게만 돼 있다고 치자.apiVersion: batch/v1kind: Jobmetadata: name: nightly-reportspec: backoffLimit: 6 template: spec: rest..

지난 분기에 ML 팀이랑 한바탕했다. 정확히 말하면 싸운 건 아니고, 슬랙 채널에서 매주 같은 문장이 반복됐다. "노드 비어있어요?", "어제 학습 잡 중간에 죽었는데 누가 뺏어갔나요?", "공정하게 좀 합시다."우리 팀에서 운영하는 GPU 노드 풀은 A100 8장씩 박힌 노드 6대. ML 팀이 4개 프로젝트로 나뉘어 있고, 각 프로젝트마다 학습 잡을 그냥 kubectl apply -f job.yaml 식으로 던지고 있었다. 누가 먼저 던지면 임자. 누군가가 8장짜리 잡을 큐잉 없이 던지면 한 노드 통째로 점유, 그 다음 사람은 Pending. 이게 P0 잡이든 실험성 잡이든 구분이 없었다.결국 Kueue를 도입했다. 3개월 지난 지금, 슬랙에서 그 문장들이 사라졌다. 도입 과정에서 삽질도 많았고, 처음..