day-log

오늘 후배가 kubectl get events --sort-by='.metadata.creationTimestamp' -n prod 를 또 한참 두드리고 있길래 옆에서 한마디 했다. "그거 그냥 kubectl events -n prod 하면 돼요." 진짜 표정이 굳더라. 의외로 모르는 분 꽤 많아서 짧게 정리한다.kubectl events, 그게 뭔데kubectl events 는 events.k8s.io/v1 API 가 v1.19에서 들어오면서 별도로 추가된 명령어다. 처음에는 alpha였는데 이제는 우리가 운영하는 1.32 정도 클러스터에서는 그냥 당연히 쓸 수 있다. kubectl get events 가 events.k8s.io/v1 와 core/v1 둘 다 보여주는 만능 명령이라면, kubectl ..

ndots가 뭐길래지난주 화요일이었다. 외부 API 호출이 많은 워크로드 하나가 P99 레이턴시가 갑자기 700ms를 넘기 시작했다. APM 그래프를 보니 외부 API 자체는 멀쩡한데 우리 쪽 클라이언트에서 응답을 받기 전까지의 시간이 길었다. 처음엔 또 NAT Gateway냐 싶었는데, 그건 아니었다.원인은 결국 DNS였다. 정확히는 ndots:5 였다. 그리고 그걸 ndots:1로 내리는 한 줄짜리 패치를 만들었다가, 다음날 아침에 멘탈이 나갔다.쿠버네티스에서 파드가 뜨면 /etc/resolv.conf에 기본적으로 이런 게 들어간다.search default.svc.cluster.local svc.cluster.local cluster.localnameserver 10.96.0.10options nd..

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

지난주 화요일 새벽 3시, 슬랙 알림이 미친 듯이 울렸다. 결제 DB의 P99 레이턴시가 평소 12ms에서 280ms로 튀어 올랐다. 폰을 더듬어 잡고 일어나면서 머리가 멍했다. 트래픽은 한산한 시간대인데 왜?처음엔 단순한 락 경합인 줄 알았다. pg_stat_activity 봤는데 long-running 쿼리도 없고, pg_locks도 깨끗했다. 근데 디스크 IOPS는 평소 대비 4배. 뭔가 백그라운드에서 디스크를 갈아먹고 있는 게 분명한데 보이질 않았다. 멘탈이 살짝 나갔다.pg_stat_io를 켰다작년에 PG16으로 올리면서 pg_stat_io 뷰를 알게 됐었는데, 평상시엔 잘 안 보던 거였다. 이번 같은 상황에서 진가를 발휘하는 뷰다. context 컬럼에 bulkread, bulkwrite, v..

운영 환경에서 Pod가 CrashLoopBackOff에 빠지거나, 네트워크 연결이 안 되거나, 파일시스템 상태를 확인해야 할 때가 있습니다. 문제는 대부분의 프로덕션 컨테이너 이미지에는 curl, dig, netstat 같은 디버깅 도구가 없다는 것입니다.distroless 이미지나 최소화된 Alpine 기반 이미지를 사용하면 보안과 이미지 크기 면에서 이점이 있지만, 장애 상황에서 원인을 파악하기가 까다로워집니다. kubectl debug는 이런 상황을 위해 만들어진 도구입니다.이 글에서는 kubectl debug의 세 가지 모드를 실전 예제와 함께 살펴보겠습니다.Ephemeral Container로 실행 중인 Pod 디버깅가장 많이 쓰이는 패턴입니다. 실행 중인 Pod에 임시 컨테이너(Ephemera..

들어가며Kubernetes 클러스터를 운영하다 보면 가장 자주 마주치는 에러 중 하나가 바로 CrashLoopBackOff입니다. Pod가 시작되자마자 죽고, 다시 시작되고, 또 죽는 무한 루프에 빠진 상태죠. 특히 새벽에 알림이 울릴 때 이 상태를 보면 심장이 철렁합니다.문제는 CrashLoopBackOff 자체가 원인이 아니라 증상이라는 점입니다. 실제 원인은 OOMKilled, 설정 오류, 의존성 실패 등 다양합니다. 오늘은 실무에서 이 상태를 체계적으로 진단하고 해결하는 방법을 정리합니다.CrashLoopBackOff란?Kubernetes는 컨테이너가 비정상 종료되면 restartPolicy에 따라 자동으로 재시작합니다. 그런데 컨테이너가 반복적으로 실패하면 kubelet은 재시작 간격을 점점 늘..