알고 보니 쿠버네티스 위였다

H100 워크스페이스를 운영하는 내내 이상한 동작들이 있었다. 재시작하면 설치한 파이썬이 증발하고, 볼륨에 둔 파일만 살아남고, SFTP 서버는 만들 때마다 포트가 바뀌었다. 그때는 "이 플랫폼은 원래 이런가 보다" 하고 각각 대응했는데, 어느 날 SFTP 서버 상세 화면에서 Pod와 Service라는 항목을 발견했다. 쿠버네티스 고유 오브젝트 이름이다. 그동안 겪은 모든 게 한 번에 설명되는 순간이었다.

증거들

플랫폼이 쿠버네티스 기반이라는 단서는 사실 처음부터 널려 있었다.

• 화면의 Pod / Service 항목. 내 SFTP 서버는 -해시가 붙은 Pod 이름을 갖고 있었다.
• SFTP 서버를 만들 때마다 4만~5만번대 고포트를 새로 배정받는 것. 쿠버네티스 NodePort 방식의 전형적인 동작이다.
• 컨테이너 안 sshd 설정에 박혀 있던 workspace-controller 경로. 재시작할 때마다 SSH 키와 sftp 설정을 다시 물려주는 주체가 이거였다.

찾아보니 이 플랫폼(AIPub)은 컨테이너 오케스트레이션 플랫폼 위에 GPU 자원 관리를 얹은 제품이었다. 직감이 맞았다.

이상 동작이 전부 정상 동작이었다

쿠버네티스라는 걸 알고 나서 그동안의 "이상한 동작"을 다시 보니, 하나도 이상한 게 없었다. 전부 교과서적인 동작이었다.

겪은 일	정체
재시작하면 파이썬·패키지 증발	Pod는 원래 쓰고 버리는(ephemeral) 것
볼륨 경로만 살아남음	Pod 밖의 PersistentVolume(NAS)
SFTP 포트가 생성마다 바뀜	Service 생성 시 NodePort 재배정
Pause / Delete 버튼	Pod 정지·삭제를 버튼으로 포장한 것
재시작 때마다 키·설정 자동 재주입	컨트롤러(오퍼레이터) 패턴
터미널은 root, SFTP는 aipub이라 권한 충돌	컨테이너별 사용자 격리
nvidia-smi에 남의 프로세스가 안 보임	PID 네임스페이스 격리

각각 따로 겪을 때는 플랫폼의 별난 제약이었는데, 쿠버네티스의 설계 철학이라는 렌즈를 끼우면 전부 한 원리에서 나온다. 환경은 언제든 갈아끼울 수 있게 버리고, 상태는 볼륨에만 남긴다. 개별 증상에 각각 대응하는 것과 원리를 이해하고 대응하는 것의 차이를 여기서 배웠다. 예를 들어 "중요한 건 볼륨에 저장"이라는 규칙은 원리를 알고 나면 외울 필요조차 없는 당연한 귀결이 된다.

"써봤다"와 "다뤄봤다"는 다르다

그럼 이력서에 "쿠버네티스 해봤습니다"라고 쓸 수 있을까. 여기는 정확하게 구분해야 한다고 생각한다.

• "쿠버네티스 기반 GPU 클러스터 환경에서 워크로드를 구성·운영했다" — 사실이다.
• "쿠버네티스를 다뤄봤다" — 아직 아니다. kubectl을 친 적도, 매니페스트를 쓴 적도 없다. 면접에서 한 방에 드러날 표현이다.

다만 전자도 생각보다 얕지 않다. Pod의 휘발성과 볼륨의 영속성을 구분해서 환경을 설계했고, NodePort의 동작을 접속 장애 디버깅으로 확인했고, 컨테이너 사용자 격리가 만든 권한 충돌을 잡았고, 그 위에서 공유 자원 운영 규칙을 세웠다. 개념을 문서로 배운 게 아니라 장애로 배운 셈이라, 각 개념이 왜 있는지는 설명할 수 있다.

그래서 다음 단계가 명확해졌다. 개념은 이미 몸에 있으니, 남은 건 조작이다. 이 사이트의 로드맵에 k3s 이전이 들어 있는 이유다. 지금은 Docker Compose로 굴리는 이 홈 클라우드를 직접 쿠버네티스로 옮기면서, "환경에서 써봤다"를 "다룰 줄 안다"로 바꾸는 게 목표다.

정리

플랫폼의 추상화는 편하지만, 그 아래가 뭔지 모르면 모든 제약이 임의의 규칙처럼 보인다. 한 꺼풀 아래를 확인한 순간 규칙들이 원리로 바뀌었고, 덤으로 내가 뭘 경험했고 뭘 아직 안 해봤는지의 경계도 선명해졌다. 관련된 GPU 쿼터 이야기는 이전 글에, 이 모든 것의 발단인 파일 전송 삽질은 운영기에 있다.