<aside>

☁️ 클라우드웨이브 시리즈 · W02 · 5/5 · 예상 읽기 6~8분

</aside>

이 글에서 확인할 것

컨테이너를 명령어 묶음으로만 보다가, 결국 프로세스·파일·포트·로그라는 Linux 질문이 더 넓은 경계로 확장된다는 점을 알게 됐다.

핵심 개념

이미지는 실행 설계도이고 컨테이너는 그 설계도로 만든 실행 인스턴스다. Kubernetes는 여러 인스턴스를 원하는 상태로 유지하고 배치·복구·서비스 연결을 조정한다. 따라서 호스트와 컨테이너 양쪽에서 상태를 관찰해야 한다.

확인 순서

이미지, 실행 상태, 포트 연결, 로그, 서비스 노출 순서로 확인한다. 목록 조회와 상세 설명은 관찰이고 배포 변경은 상태를 바꾸는 일이다.

docker run --name web-example -p 8080:80 httpd
kubectl get pods
kubectl describe pod example-pod

흐름으로 연결하기

flowchart LR
 A["관찰"] --> B["원인 분리"]
 B --> C["안전한 변경"]
 C --> D["다시 확인"]

실무로 이어지는 질문

다음 주에는 이미지가 어떻게 재현성을 만들고 컨테이너가 어떤 경계를 가지는지 확인한다. 수동 수정 대신 이미지와 배포 흐름으로 되돌릴 수 있는 운영을 질문한다.

헷갈렸던 점

컨테이너가 가상 머신과 같다고 생각했지만 같은 방식의 완전한 운영체제를 제공하는 개념은 아니다. 실행 중인 컨테이너를 손으로 고치는 것도 재현성을 약하게 만들 수 있다.

Linux 운영 기초에서 이어지는 공통 질문

컨테이너와 Kubernetes를 관찰할 때도 Linux에서 익힌 질문은 그대로 남는다. 무엇이 실행 중인지, 어느 사용 주체와 프로세스가 동작하는지, 필요한 파일과 권한이 맞는지, 어떤 포트로 연결되는지, 로그에 최초 오류가 무엇으로 남았는지를 먼저 묻는다. 컨테이너에서는 호스트와 컨테이너의 경계를 나누어 상태를 보고, Kubernetes에서는 이미지와 실행 인스턴스, 서비스 노출을 구분해 본다. 목록 조회는 관찰이고 배포 변경은 상태를 바꾸는 일이라는 점도 같다. 익숙한 Linux 질문을 더 넓은 경계에 적용하면 이미지·컨테이너·파드의 문제를 단계적으로 좁힐 수 있다.

Linux 질문이 컨테이너로 이동한 과정