[11-12주차 이론 정리]
1. 가상 머신(VM)을 넘어선 도커(Docker)의 혁신
도커는 애플리케이션과 그 실행에 필요한 모든 종속성(바이너리, 라이브러리 등)을 '컨테이너'라는 표준화된 유닛으로 패키징하는 오픈소스 플랫폼이다. 기존의 하이퍼바이저 기반 가상 머신(VM)은 무거운 Guest OS를 일일이 설치해야 했지만, 도커는 Host OS의 커널을 공유하면서 Container Engine 위에서 독립적인 공간만 할당받아 실행된다. 덕분에 훨씬 가볍고 빠르게 애플리케이션을 구축하고 배포할 수 있다.
2. 도커 이미지(Image)와 레이어(Layer) 아키텍처
도커의 핵심은 '이미지'와 '컨테이너'다. Dockerfile이라는 명세서를 바탕으로 빌드하면 불변(Immutable)의 도커 이미지가 생성되고, 이 이미지를 실행한 동적인 상태가 바로 도커 컨테이너다. 흥미로운 점은 이미지가 통짜 파일이 아니라 겹겹이 쌓인 '레이어(Layer)' 구조로 이루어져 있다는 것이다. 베이스 OS(Ubuntu 등) 위에 웹 서버(Nginx), 그 위에 소스 코드 레이어가 차곡차곡 쌓이며, 컨테이너가 실행될 때는 이 읽기 전용 레이어들 위에 쓰기 가능한(R/W) 레이어가 하나 추가되어 작동한다. 이 구조 덕분에 저장 공간을 효율적으로 사용하고 이미지를 빠르게 빌드할 수 있다.
3. 컨테이너 오케스트레이션의 지휘자, 쿠버네티스(Kubernetes)
컨테이너의 수가 적을 때는 도커만으로 충분하지만, 수십~수백 개의 컨테이너가 운영되는 마이크로서비스 환경에서는 이야기가 달라진다. 구글이 오픈소스로 공개한 쿠버네티스(K8s)는 이러한 컨테이너들을 자동화하여 배포하고, 트래픽에 따라 스케일링하며, 장애가 발생하면 스스로 복구(Self-healing)하는 오케스트레이션 플랫폼이다.
4. 쿠버네티스를 구성하는 핵심 리소스 (Pod, Deployment, Service, PVC)
쿠버네티스는 시스템의 상태를 선언적(Declarative)으로 관리하며, 이를 위해 여러 리소스 단위를 사용한다.
- Pod (파드): 쿠버네티스에서 배포 가능한 가장 작은 컴퓨팅 단위다. 한 개 이상의 컨테이너를 감싸고 있으며, 내부 컨테이너끼리 자원과 네트워크를 공유한다.
- Deployment (디플로이먼트): Pod의 복제본(Replica) 개수를 유지하고, 애플리케이션의 무중단 업데이트(Rollout)나 롤백을 관리하는 상위 컨트롤러다.
- Service (서비스): Pod은 생성과 소멸을 반복하며 IP가 계속 바뀌기 때문에 고정된 접근 지점이 필요하다. Service는 Pod들을 묶어 단일한 고정 IP와 도메인을 제공하고 트래픽을 로드밸런싱한다.
- PVC (Persistent Volume Claim): Pod이 삭제되더라도 데이터가 영구적으로 보존되어야 할 때(ex. DB 데이터) 사용하는 스토리지 요청 리소스다.
[11-12주차 실습 정리]
이번 실습은 도커와 쿠버네티스의 기본 명령어를 익히고, 로컬 환경에서 직접 클러스터를 구성해 보는 형태로 진행되었다.
1. Dockerfile 작성 및 도커 이미지 빌드:
먼저 텍스트 편집기를 이용해 Dockerfile을 작성했다. FROM ubuntu:18.04로 베이스 이미지를 지정하고, RUN apt-get update로 패키지를 업데이트한 뒤, CMD 명령어로 컨테이너 실행 시 동작할 커맨드를 지정했다. 작성된 파일을 바탕으로 docker build 명령어를 통해 나만의 커스텀 도커 이미지를 생성했다. 이후 docker run으로 컨테이너를 실행하고, docker exec로 동작 중인 컨테이너 내부에 접속해 환경을 확인하는 과정까지 실습했다. 로컬 환경에 도커 레지스트리 컨테이너를 띄워 빌드한 이미지를 push하는 테스트도 진행했다.
2. 미니쿠베(Minikube) 설치 및 YAML 기반 리소스 배포:
쿠버네티스 실습을 위해 로컬 개발용 단일 노드 클러스터인 Minikube를 설치했다. 쿠버네티스는 kubectl이라는 CLI 도구를 통해 조작하며, 모든 설정은 데이터 직렬화 양식인 YAML(.yaml) 파일로 정의한다. 실습에서는 apiVersion, kind, metadata, spec 계층에 맞춰 직접 Nginx 웹 서버를 띄우는 Deployment와 Service의 YAML 파일을 작성했다. 특히 Service의 타입을 NodePort로 설정하여 외부 웹 브라우저에서 로컬 쿠버네티스 클러스터 내부에 떠 있는 Nginx Pod으로 실제로 접속해 보는 경험을 할 수 있었다.
3.중요한 점
- Pod의 휘발성 (Ephemeral)에 대한 이해: 쿠버네티스의 Pod은 언제든 죽고 다시 살아날 수 있는 소모적인 존재다. 따라서 로컬 파일 시스템에 중요한 데이터를 저장하면 안 되며, 상태 유지가 필요한 데이터는 반드시 PVC를 통해 외부 영구 볼륨(PV)에 마운트해야 한다는 점을 체감했다.
- Service의 절대적인 필요성: Pod이 재생성될 때마다 내부 IP가 변경되기 때문에, Pod IP를 직접 바라보게 아키텍처를 짜면 통신 오류가 발생한다. 반드시 고정된 진입점인 Service 리소스를 앞단에 배치하여 컴포넌트 간 통신을 구성해야 한다.
- YAML 작성 시 들여쓰기의 중요성: 쿠버네티스에 배포할 YAML 파일을 작성할 때, 띄어쓰기(Indentation)가 조금만 틀려도 문법 오류가 발생하여 배포에 실패했다. 계층 구조를 명확히 맞춰 작성하는 꼼꼼함이 필요하다.
[정리]
- 도커(Docker)는 애플리케이션과 종속성을 이미지와 컨테이너라는 독립적이고 표준화된 레이어 구조로 패키징하는 기술이다.
- 쿠버네티스(Kubernetes)는 수많은 컨테이너의 배포, 확장, 자동 복구를 선언적 방식으로 관리해 주는 오케스트레이션 플랫폼이다.
- 쿠버네티스 환경에서는 기능에 따라 Pod(실행 최소 단위), Deployment(상태 및 배포 관리), Service(네트워크 엔드포인트 제공), PVC(영구 스토리지 관리)를 조합하여 아키텍처를 설계한다.
다음 >> https://mehannah.tistory.com/12