day-log

오늘 알게 된 건데, 아직도 노드마다 /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 한 번이 어떤 단계를 거치는지, 각 단계에서 무엇을 디스크에 쓰는지, ..