day-log

상황운영 중인 파드가 한 개 있다. 베이스 이미지는 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개월 지난 지금, 슬랙에서 그 문장들이 사라졌다. 도입 과정에서 삽질도 많았고, 처음..

지난주 화요일 새벽 2시. 슬랙 알림 한 통에 잠이 깼다. P99 레이턴시가 800ms를 찍었고, 한 가용영역의 한 노드만 CPU가 95%를 치고 있었다. 다른 두 노드는 30%. 분명히 우리는 topologySpreadConstraints 를 걸어뒀는데, 왜 한 쪽으로만 쏠렸을까.결론부터 말하면, matchLabelKeys 를 안 써서 그렇다. 그게 무슨 소리인지 정리해보겠다.우리 환경EKS 1.32, 노드 12대(3 AZ × 4대), Deployment replicas 18. 매니페스트의 spread 설정은 이렇게 생겼었다.topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisf..

Pod resize, kubelet은 사실 어떻게 하는가 — 1.35 GA 내부 동작작년 12월 1.35에서 in-place pod resize가 드디어 GA로 올라왔다. 1.27 알파(2023년 봄), 1.33 베타(2025년 봄)를 거쳐 약 2년 반 만이다. 베타 시점부터 우리 팀 일부 워크로드에 켜놨고, GA 이후엔 좀 더 적극적으로 쓰고 있다. 그런데 운영하다 보면 "왜 이건 resize가 한 번에 안 되지?", "왜 어떤 컨테이너는 restart 되고 어떤 건 안 되지?" 같은 질문이 자꾸 나온다.사실 내부적으로는 kubelet이 꽤 복잡한 상태 머신을 돌리고 있다. KEP-1287과 1.33/1.35 GA 변경분을 같이 읽어보면 그림이 좀 잡힌다. 이 글에서는 kubelet → CRI → 컨테..

새벽 3시 47분. 핸드폰이 미친 듯이 울렸다.PagerDuty가 동시에 네 건. P99 레이턴시, 5xx 비율, 큐 적체, 그리고 결제 워커 alive 체크 실패까지 줄줄이 빨간색. 잠이 깰 새도 없었다. 노트북을 열고 Grafana부터 켰는데, 노드 수가 떡 하니 23대에서 6대로 떨어져 있었다. 누가 그랬을까. 범인은 나였다. 정확히는, 일주일 전 내가 만진 Karpenter 설정이.무슨 짓을 했길래배경부터. 우리 팀은 EKS에서 Karpenter로 노드를 굴린다. NodePool 두 개 — 일반 워크로드용 default, 그리고 결제/주문 같은 stability-sensitive 워크로드용 payments. 한 달 전쯤 FinOps 압박이 들어왔다. "비용 너무 많이 나온다, 야간에 트래픽 적은 ..

우리 팀이 자주 쓰는 형태오늘 점심에 동료가 "운영 Pod에 strace 한 번만 떠보면 알 것 같은데 못 들어간다"고 한참 끙끙대길래 옆에서 봤다. distroless 이미지라 shell이 없고, 그렇다고 ephemeral container를 그냥 띄우자니 같은 PID namespace가 아니라 프로세스가 안 보인다는 거였다. 사실 이거 의외로 많이들 모르고 지나가더라.kubectl debug에 --copy-to랑 --share-processes를 같이 주면 거의 다 해결된다. 1.30 GA 이후로 옵션 동작도 안정돼서 운영에서 그냥 쓰면 된다.원본 Pod는 그대로 두고, 동일한 spec의 복제 Pod에 디버그 컨테이너를 끼워넣는 방식. 트래픽 받는 Pod 직접 손대지 않아도 된다.kubectl deb..

KEDA로 Kafka consumer를 오토스케일링하는 건 ScaledObject 하나 적용하면 끝나는 것처럼 보인다. 실제로 키워드만 보면 그렇다. 근데 트래픽 패턴이 살짝만 비대칭이거나 consumer가 commit을 게으르게 하는 순간 스케일러가 엉뚱한 방향으로 움직인다. 우리 팀에서 지난 분기에 partition 24개짜리 topic 두 개를 KEDA 기반으로 옮기면서 정리한 내용을 가이드 형태로 풀어둔다. 최근 KEDA 2.19 기준이다.0. 기본 ScaledObject부터Sarama 기반 기본 스케일러는 deprecated 경고가 종종 뜨므로, 신규 도입이면 apache-kafka 트리거(Go 클라이언트 기반) 쪽을 권장한다. 가장 단순한 형태는 이렇다.apiVersion: keda.sh/v1..

지난주 화요일 새벽 4시쯤 전화가 울렸다. 메시지 큐 컨슈머 한 대가 S3 PutObject에서 ExpiredTokenException 을 계속 뱉고 있다고. 멘탈이 살짝 나갔다. IRSA로 깔끔하게 인증 붙여놨다고 믿고 있던 워크로드였는데.결론부터 말하면 ServiceAccount projected token이 만료된 뒤 kubelet이 새 토큰을 디스크에 갈아 끼웠는데, 우리 컨슈머 안에 들어있던 SDK는 이걸 다시 읽지 않고 죽은 토큰을 1년 가까이 메모리에 들고 있었다. 정확히는 캐시가 너무 충실했던 게 문제였다.우리가 잘못 알고 있던 부분Kubernetes 1.22 이후로 BoundServiceAccountTokenVolume 이 GA되면서 Pod이 마운트하는 토큰은 모두 projected 형태..

증상이런 경험 다들 한 번쯤 있을 거다. Pod가 Running까지 가는 데 2-3분, 심하면 5분 넘게 걸린다. 이벤트 찍어봐도 별다른 에러 없고, ImagePull도 끝났고, PV Attach/Mount도 정상 완료. 그런데 컨테이너가 시작을 안 한다. kubectl describe pod 해보면 그냥 조용히 멈춰 있다.이때 kubelet 로그를 보면 이런 라인이 줄줄이 찍히고 있을 가능성이 높다.SetVolumeOwnership ... took 142.3s범인은 fsGroup이다. SecurityContext에 fsGroup: 1000 같은 거 설정해두면, kubelet이 PV를 마운트할 때 그 안의 모든 파일을 chown/chmod로 훑는다. 파일이 10만 개면 10만 번. 그게 NFS나 EFS ..