day-log

지난주 화요일 새벽 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 ..

이거 모르는 분 의외로 많더라. 어제도 사내 슬랙에서 비슷한 질문이 올라왔다. "etcd defrag CronJob 돌리는데 가끔 API 서버가 잠깐 죽어요." 그럴 만했다.오늘은 짧게 한 가지만 정리한다. etcd defragmentation을 CronJob으로 자동화할 때 빠뜨리기 쉬운 포인트.compaction과 defrag는 다른 거다먼저 용어부터. 둘이 같은 줄 알고 쓰는 사람이 꽤 있다.compaction: 오래된 revision을 논리적으로 지운다. 디스크 파일은 안 줄어든다. 자동으로 돌릴 수 있다 (--auto-compaction-mode=periodic --auto-compaction-retention=8h 같은 식). kube-apiserver가 5분마다 자동 compaction을 호..

EKS를 몇 년째 운영하다 보면 한 번쯤은 이런 순간이 온다. 누군가 kubectl delete ns prod-something을 잘못 쳤거나, GitOps 동기화가 꼬여서 ConfigMap이 통째로 날아갔거나. 우리 팀에서는 작년에 한 번 비슷한 사고가 났다. ArgoCD가 잘못된 브랜치를 source로 잡아서 네임스페이스 하나를 prune 해버린 거다. 다행히 ETCD 덤프가 있었지만, 복구하는 데 반나절을 썼다.그 사건 이후로 Velero를 정식으로 도입했다. 이번 글은 EKS 환경에서 Velero를 0에서부터 세팅하고 운영하는 실전 가이드다. 공식 문서에 나오는 기본 설치 말고, 실제 운영 들어갔을 때 부딪히는 부분 위주로 적었다.왜 Velero인가EKS 백업 옵션은 몇 가지가 있다. AWS Ba..

오늘 알게 된 건 아니지만, 최근에 팀 내부 트러블슈팅 가이드 다듬다가 다시 한 번 짚어둘 만하다 싶어서 짧게 적는다. kubectl debug로 ephemeral container 띄울 때 --target 빠뜨리고 쓰는 분들이 의외로 많다. 1.25부터 EphemeralContainers feature gate가 GA로 켜진 게 벌써 한참 됐는데도.무슨 문제냐면distroless 이미지를 쓰는 파드에 들어가서 curl이나 netstat 한 번 쳐보고 싶을 때 보통 이렇게 쓴다.kubectl debug -it my-pod -n prod --image=nicolaka/netshoot이걸로 컨테이너는 잘 붙는다. 근데 막상 들어가서 ps를 쳐보면 본인 프로세스만 보인다. 본 컨테이너의 PID가 안 보인다는 ..