day-log

컨테이너 이미지를 pull하고 시작할 때, 표면적으로는 그냥 kubectl apply 한 방이면 끝나는 것처럼 보인다. 근데 사실 그 아래에서는 containerd가 snapshotter라는 놈을 통해 파일시스템 레이어를 조립하고 마운트하는 꽤 정교한 과정이 돌아간다. 대부분은 overlay2를 그냥 쓰고 지나가지만, 몇 달 전부터 우리 팀에서 콜드스타트 지연을 잡느라 stargz-snapshotter를 검토하면서, 이 계층이 실제로 뭘 하고 있는지 다시 파헤쳐볼 일이 생겼다.지난 2월에 stargz 관련 lazy pulling이 다시 주목받으면서 관련 글이 여럿 올라왔는데, 대부분 "빠르다"에서 멈춰 있다. 사실 내부적으로 뭐가 바뀌는지 짚어봐야 언제 써야 하는지 판단할 수 있다. 그래서 이번 글에서는..

요즘 팀 슬랙에 EKS 노드 스케일 아웃 후 파드가 Running까지 도달하는 데 걸리는 시간 얘기가 자주 올라온다. GPU 노드에 20GB짜리 추론 이미지를 올려야 하는데, 이미지 pull에만 3분 넘게 걸린다. 트래픽 스파이크가 오고 나서야 노드가 뜨기 시작하면 사실상 늦다.이 문제 해결책으로 몇 년 전부터 계속 언급되는 게 lazy pulling이다. 이미지 전체를 미리 받지 않고, 컨테이너가 실제로 파일을 요청할 때만 해당 range를 원격 registry에서 가져다가 마운트해주는 방식. 개념은 단순한데 내부 동작이 꽤 재밌어서 이번에 SOCI(Seekable OCI) snapshotter 코드를 좀 뜯어봤다. 정리해둔다.OCI 이미지가 어떻게 생겨먹었길래 lazy pulling이 되는가우선 왜 ..

오늘 알게 된 건데, 아직도 노드마다 /etc/containerd/config.toml 안에 레지스트리별 auth를 박아두고 운영하는 팀이 생각보다 많다. 우리 팀도 작년까지 그랬다. 사내 Harbor, ECR, GHCR, Docker Hub 미러까지 네 개를 한 파일에 우겨넣다 보니 누가 한 줄만 잘못 건드려도 컨테이너런타임 재시작이 필요했다.근데 containerd 1.5에서 추가되고 1.7 이후로는 사실상 표준이 된 config_path 방식 쓰면 이 짓을 안 해도 된다. 노드 재시작 없이, hot reload로 레지스트리 설정만 바꿀 수 있다.핵심은 디렉터리 구조/etc/containerd/config.toml에는 딱 한 줄만 둔다.[plugins."io.containerd.grpc.v1.cri"..

containerd 2.0이 나오면서 NRI(Node Resource Interface)가 기본 enable 상태가 됐다. 그동안 "kubelet의 device plugin이나 CDI랑 뭐가 다르냐"는 질문을 꽤 많이 받았는데, 막상 코드를 따라가 보면 NRI는 컨테이너 라이프사이클 hook을 user-space 프로세스로 빼낸 RPC 인터페이스에 가깝다. CPU pinning, NUMA-aware allocation, GPU annotation 같은 걸 runtime을 건드리지 않고 끼워넣을 수 있는 곳. 우리 팀에서도 최근 AI 워크로드 노드에 NRI 기반 토폴로지 플러그인을 깔면서 처음으로 코드를 깊이 봤다. 이 글에서는 NRI가 어디서 호출되고, 플러그인이 어떻게 컨테이너 스펙을 조작하며, 왜 s..

ECR pull rate limit에 한 번이라도 당해봤다면, 이 글이 도움이 될 거다. Spegel은 클러스터 안에서 노드끼리 이미지를 공유하게 해주는 stateless P2P OCI registry mirror다. 어느 노드 하나가 이미지를 받아두면, 같은 클러스터의 다른 노드들은 그 노드에서 끌어다 쓴다. 외부 레지스트리 호출이 확 줄어든다.최근 3월에 CoreWeave가 자기네 매니지드 쿠버네티스(CKS)에서 Spegel 튜토리얼을 공식 문서로 내놓을 정도로 P2P 이미지 분배는 더 이상 실험 단계가 아니다. K3s, RKE2는 아예 임베디드로 들어가 있고, AKS/EKS에서도 Helm으로 깔아서 잘 굴러간다. 우리 팀에서도 노드 80대 EKS 클러스터에 두 달째 돌리고 있는데, 한번 정리해두면 ..

kubectl describe pod에서 Pulling image "..."가 한참 머물러 있을 때, 그 안에서 무슨 일이 벌어지고 있는지 정확히 설명할 수 있는 사람이 의외로 적다. 나도 그랬다. "registry에서 layer 받아서 디스크에 풀고 mount한다" 정도가 내가 가진 모델의 전부였다. 근데 작년 말부터 ARC runner들이 콜드 스타트에서 한참 깔리는 문제를 디버깅하면서, 이 흐름을 좀 진지하게 들여다봐야겠다는 생각이 들었다. fetch가 느린 건지, unpack이 느린 건지, snapshotter가 느린 건지 분리해서 보지 못하면 튜닝 포인트가 없다.이 글은 containerd 2.x 기준으로 image pull 한 번이 어떤 단계를 거치는지, 각 단계에서 무엇을 디스크에 쓰는지, ..