[클라우드 응용 SW 개발] 11, 12주차

1. Docker란 무엇인가

Docker는 애플리케이션과 그 실행에 필요한 모든 종속성을 컨테이너라는 표준화된 단위로 패키징하여, 어디서든 동일한 환경으로 실행할 수 있게 해주는 오픈소스 플랫폼이다.

 

Docker의 핵심 워크플로우는 단순하다.

Dockerfile  →  (docker build)  →  Image  →  (docker run)  →  Container
                                      ↓
                                 (docker push)
                                      ↓
                              Registry (Docker Hub / ECR 등)

• Dockerfile : 이미지 빌드 과정을 코드로 정의한 명세서
• Image : Dockerfile로 만들어진 불변의 실행 환경 스냅샷
• Container : Image를 실행한 인스턴스 (여러 개 동시 실행 가능)
• Registry : 이미지를 저장하고 배포하는 저장소

이미지 이름 구조

Docker 이미지 이름은 아래 형식을 따른다.

Registry / Namespace / ImageName : TAG

예시)
docker.io/library/nginx:latest    ← 공식 이미지
docker.io/library/nginx:1.12.1   ← 버전 고정
private_reg/myapp:1.0             ← 사설 레지스트리

💡 TAG를 생략하면 latest가 기본값이 된다. 운영 환경에서는 버전을 명시하는 게 좋다.

---

2. VM vs Container, 그리고 Layer 구조

VM vs Container

구분                                  Virtual Machine                                                                            Container

격리 단위	하드웨어 수준	프로세스 수준
OS	각 VM마다 Guest OS 필요	호스트 OS 공유
시작 시간	분 단위	초 단위
리소스	무겁다	가볍다
격리 강도	강함	상대적으로 약함

VM은 Hypervisor 위에 Guest OS를 각각 올리기 때문에 무겁다.
컨테이너는 OS를 공유하고 Container Engine 위에서 프로세스를 격리하므로 훨씬 가볍고 빠르다.

Docker Layer 구조

Docker 이미지는 레이어(Layer)를 쌓는 방식으로 만들어진다.

[web app image]
  ├── web app source  ← 추가한 레이어
  ├── nginx           ← 추가한 레이어
  ├── Layer C         ┐
  ├── Layer B         ├─ ubuntu base 레이어 (공유됨)
  └── Layer A         ┘

[Container 실행 시]
  R/W Layer  ← 컨테이너마다 독립적인 쓰기 레이어
  ─────────
  Image Layers (읽기 전용, 공유)

• 공통 레이어는 디스크에 한 번만 저장되어 여러 이미지가 재사용한다
• 컨테이너를 실행하면 이미지 레이어 위에 쓰기 가능한 R/W 레이어가 추가된다
• 컨테이너가 삭제되면 R/W 레이어도 사라진다 (데이터 영속성이 필요하면 Volume 사용)

---

3. Docker 핵심 명령어

이미지 관련

# 레지스트리에서 이미지 다운로드
docker pull ubuntu:18.04

# 로컬 이미지 목록 조회
docker images

# 이미지 삭제
docker rmi ubuntu

컨테이너 실행 / 관리

# 컨테이너 실행 (인터랙티브 터미널)
docker run -it --name demo1 ubuntu:18.04 /bin/bash

# 백그라운드로 실행 (-d)
docker run -it -d --name demo2 ubuntu:18.04

# 실행 중인 컨테이너 목록
docker ps

# 중단된 것 포함 전체 조회
docker ps -a

실행 중인 컨테이너 접속 / 로그

# 실행 중인 컨테이너 내부 접속
docker exec -it demo2 /bin/bash

# 컨테이너 로그 확인
docker logs demo3

# 실시간 로그 스트리밍
docker logs demo3 -f

컨테이너 중단 / 삭제

# 컨테이너 중단
docker stop demo1

# 컨테이너 삭제 (중단 후 삭제)
docker rm demo1

💡 run vs exec 헷갈리지 말자
docker run → 새 컨테이너를 만들어서 실행
docker exec → 이미 실행 중인 컨테이너에 접속

---

4. Dockerfile과 이미지 빌드

Dockerfile 주요 명령어

명령어 역할 예시

FROM	베이스 이미지 지정 (필수, 시작점)	FROM ubuntu:18.04
RUN	빌드 시점에 명령 실행 (레이어 생성)	RUN apt-get update
COPY	호스트 파일을 이미지로 복사	COPY ./app /app
WORKDIR	이후 명령의 작업 디렉토리 설정	WORKDIR /home/demo
ENV	환경변수 설정	ENV LANG ko_KR.UTF-8
EXPOSE	컨테이너가 사용할 포트 선언	EXPOSE 8080
CMD	컨테이너 시작 시 실행할 기본 명령	CMD ["echo", "Hello"]

간단한 Dockerfile 예시

# 베이스 이미지: ubuntu 18.04
FROM ubuntu:18.04

# 패키지 업데이트
RUN apt-get update

# 컨테이너 시작 시 출력
CMD ["echo", "Hello FastCampus"]

빌드 및 레지스트리 Push

# Dockerfile이 있는 경로에서 빌드
docker build -t my-image:v1.0.0 .

# 빌드된 이미지 확인
docker images | grep my-image

# 컨테이너 실행
docker run my-image:v1.0.0

# 로컬 레지스트리 실행
docker run -d -p 5000:5000 --name registry registry

# 이미지 태깅 후 push
docker tag my-image:v1.0.0 localhost:5000/my-image:v1.0.0
docker push localhost:5000/my-image:v1.0.0

# 레지스트리에 저장된 이미지 확인
curl -X GET http://localhost:5000/v2/_catalog

💡 레이어 순서 최적화 팁
자주 바뀌는 레이어(소스코드 COPY 등)는 Dockerfile 아래쪽에 배치해야
캐시를 최대한 활용해서 빌드 속도를 높일 수 있다.

---

5. Kubernetes란 무엇인가

**Kubernetes(K8s)**는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼이다.

• 2014년 Google이 공개
• 현재는 CNCF(Cloud Native Computing Foundation) 에서 관리

Docker 하나로도 단일 서버에서 컨테이너를 운영할 수 있다.
하지만 서버가 수십 대, 컨테이너가 수백 개가 되면 아래 문제가 생긴다.

문제                                    Docker 단독                                                      Kubernetes

트래픽 급증 시	사람이 직접 docker run 추가	HPA가 자동으로 Pod 수 조절
컨테이너 죽었을 때	--restart 옵션으로 단순 재시작만 가능	비정상 Pod 감지 → 다른 노드로 자동 재스케줄
인프라 관리	명령형 (어떻게 실행할지 직접 지시)	선언형 (원하는 상태만 선언, 시스템이 수렴)

Kubernetes 주요 특징

① 자동화된 배포 · 스케일링
HPA(Horizontal Pod Autoscaler)가 CPU/메모리 메트릭을 감시하다가 임계치 초과 시 Pod를 자동으로 늘리고 줄인다.

② Self-Healing (자동 복구)
Liveness Probe로 컨테이너 상태를 지속 감시하다가 비정상 Pod를 감지하면 재시작하거나 다른 정상 노드로 재스케줄링한다.

③ 선언적 구성 (Declarative)
YAML에 replicas: 3처럼 원하는 최종 상태만 선언하면, 현재 상태와 비교해 시스템이 스스로 수렴한다.
Git으로 인프라 상태를 관리하는 GitOps가 가능해지는 이유다.

④ 서비스 디스커버리 · 로드밸런싱
DNS 이름이나 IP로 컨테이너를 노출하고, 트래픽을 여러 Pod에 자동 분산한다.

⑤ 스토리지 오케스트레이션
로컬 또는 클라우드 스토리지(AWS EBS, GCE PD 등)를 컨테이너에 자동으로 마운트한다.

---

6. 쿠버네티스 핵심 리소스

K8s는 YAML 파일로 리소스를 정의한다. 가장 자주 쓰는 4가지를 정리한다.

Pod

쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위다.

• 하나 이상의 컨테이너를 감싸는 단위
• 같은 Pod 안의 컨테이너들은 네트워크와 스토리지를 공유
• K8s는 Pod 단위로 스케줄링, 로드밸런싱, 스케일링을 수행

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args: [/bin/sh, -c, 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']

Deployment

Pod와 ReplicaSet에 대한 관리를 제공하는 단위다.

• 원하는 Pod 복제본 수(replicas)를 선언하면 자동으로 유지
• Self-healing, Scaling, 무중단 Rollout / Rollback 포함

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3            # Pod 3개를 항상 유지
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Service

쿠버네티스에 배포한 Pod를 외부에서 접근하기 쉽게 추상화한 리소스다.

• Pod IP는 재시작마다 바뀌기 때문에 고정 IP를 가진 Service를 통해 접근
• Service 타입: ClusterIP(클러스터 내부), NodePort(노드 포트), LoadBalancer(외부 LB)

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
spec:
  type: NodePort
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: nginx

PVC (PersistentVolumeClaim)

Pod가 영구적으로 데이터를 보존하고 싶을 때 사용하는 리소스다.

• Pod 내부 데이터는 기본적으로 Pod가 죽으면 사라진다
• PVC를 Pod에 마운트하면 Pod가 재시작돼도 데이터가 유지됨
• Docker의 -v 볼륨 옵션과 같은 역할

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
  - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Mi
  storageClassName: standard

💡 리소스 관계 한 줄 정리
Pod(최소 실행 단위) → Deployment(Pod 관리) → Service(외부 노출) → PVC(데이터 영속성)

---

7. 쿠버네티스 배포판 종류

유형 배포판 특징

표준	Vanilla Kubernetes	CNCF 공식, 다른 배포판의 기준
관리형 (클라우드)	Amazon EKS	AWS 인프라와 긴밀하게 통합
관리형 (클라우드)	Google GKE	K8s 원조 구글의 전문성
관리형 (클라우드)	Microsoft AKS	Azure 서비스와 통합
엔터프라이즈	Red Hat OpenShift	CI/CD, Helm 차트 내장, RHEL 기반
멀티클러스터	Rancher	온프레미스/클라우드 혼용 환경에 강점
로컬/학습	Minikube	단일 노드, 경량, 학습 및 테스트 목적

Minikube

로컬 머신에서 단일 노드 K8s 클러스터를 실행하는 경량 도구다.

• Linux, macOS, Windows 모두 지원
• DNS, NodePorts, ConfigMaps, Secrets, 대시보드 등 핵심 기능 지원
• 개발·테스트·학습 목적으로 최적

[Minikube Architecture]
  VM
  ├── Master (K8s 제어 플레인)
  └── Node
        ├── Docker (컨테이너 런타임)
        └── Container Runtime

💡 kubectl은 Minikube와 함께 설치하는 K8s CLI다.
클라우드 환경(EKS, GKE 등)에서도 동일한 kubectl 명령어를 그대로 사용한다.

---

8. 정리

키워드 핵심 내용

Docker	Dockerfile → Image → Container 흐름. 환경을 코드로 정의하고 어디서든 동일하게 실행
Container vs VM	OS 공유로 훨씬 가볍고 빠름. 레이어 구조로 이미지를 효율적으로 재사용
Kubernetes	대규모 컨테이너 오케스트레이션. 자동 확장 · 자가 복구 · 선언적 인프라
핵심 리소스	Pod → Deployment → Service → PVC 순으로 이해
배포판	학습은 Minikube, 실무는 EKS/GKE/AKS 등 관리형 서비스 활용

 

Docker의 활용도가 높아지면서 이를 대규모로 관리하기 위한 Kubernetes가 등장했다.
컨테이너 하나를 다루는 Docker와, 수백 개의 컨테이너를 자동으로 운영하는 Kubernetes — 이 두 가지를 함께 이해하는 것이 현대 클라우드 개발의 기본이다.