Docker 대 Kubernetes를 검색하면 둘 중 하나를 선택해야 한다는 것을 알 수 있지만 이러한 프레이밍은 많은 혼란을 야기합니다. 이는 선적 컨테이너를 수천 개의 컨테이너를 정리하는 항구와 비교하는 것과 비슷합니다. 이들은 서로 다른 수준에서 작동하며 종종 나란히 사용됩니다.

이 가이드는 각각의 기능을 설명하고, 두 앱 모두에서 동일한 작은 앱을 보여주며, 실용적인 결정 방법으로 끝납니다. 여기에 있는 명령과 파일은 이 기사에서 실행하지 않은 표준 예제이므로 설치한 버전과 비교하여 확인하세요.

짧은 대답

Docker는 애플리케이션과 해당 종속성을 이미지로 패키징한 다음 해당 이미지를 컨테이너로 실행하는 플랫폼입니다. “이 앱을 어디에서나 동일한 방식으로 실행하려면 어떻게 해야 합니까?”라는 질문에 답합니다.

K8s로 자주 작성되는 Kubernetes는 컨테이너 오케스트레이터입니다. 여러 머신에서 컨테이너가 실행되는 위치를 결정하고, 실패하면 다시 시작하며, 수요에 따라 확장합니다. “수백 개의 컨테이너를 안정적으로 실행하려면 어떻게 해야 합니까?”라는 질문에 답합니다.

Docker와 Kubernetes를 나란히 놓고

도커가 하는 일

컨테이너 이전에는 “내 컴퓨터에서 작동한다”는 것이 일상적인 문제였습니다. 서버마다 모든 버전이 다르기 때문입니다. Docker는 코드, 런타임, 라이브러리를 하나의 이미지로 묶습니다. 해당 이미지의 실행 복사본은 컨테이너이며 호스트의 커널을 공유하므로 전체 가상 머신보다 더 빠르게 시작되고 더 적은 메모리를 사용합니다.

워크플로에는 세 가지 단계가 있습니다.

1. 빌드: a Dockerfile에서는 이미지를 만드는 방법을 설명합니다.
2. 배송: Docker Hub와 같은 레지스트리에 이미지를 푸시합니다.
3. 실행: 호환되는 머신의 해당 이미지에서 컨테이너를 시작합니다.

직접 사용해 보려면 초보자를 위한 Docker 튜토리얼부터 시작한 다음 Dockerfile 모범 사례를 읽어보세요.

쿠버네티스가 하는 일

한 서버의 Docker는 해당 서버에 장애가 발생하거나 트래픽이 초과되거나 조정해야 할 서비스가 수십 개 있을 때까지 잘 작동합니다. Kubernetes는 다음과 같은 운영 작업을 처리합니다.

• 스케줄링: 여유 용량이 충분한 머신에 컨테이너를 배치합니다.
• 자가 복구: 실패한 컨테이너를 교체하고 실패한 노드에서 작업을 이동합니다.
• 확장: 수동으로 또는 측정항목을 기준으로 복사본을 추가하거나 제거합니다.
• 서비스 검색: 변화하는 컨테이너 그룹에 하나의 안정적인 이름을 제공합니다.
• 순차적 업데이트: 간단한 롤백을 통해 점진적으로 새 버전을 출시합니다.
• 구성: 이미지와 별도로 설정 및 비밀을 관리합니다.

핵심 아이디어는 원하는 상태입니다. 당신은 3개의 사본이 있어야 한다고 선언하고, 컨트롤러는 이를 계속해서 현실과 비교하고 차이점을 수정합니다. 초보자를 위한 Kubernetes 튜토리얼은 로컬 클러스터에서 이를 안내합니다.

Docker와 Kubernetes가 함께 작동하는 방식

개발자의 노트북에서 프로덕션까지의 일반적인 경로는 다음과 같습니다.

1. 개발자는 Dockerfile을 작성하고 로컬에서 컨테이너를 테스트합니다.
2. CI/CD 파이프라인은 이미지를 빌드하고 테스트를 실행합니다.
3. 파이프라인은 버전이 지정된 이미지를 레지스트리에 푸시합니다.
4. 해당 이미지 버전을 사용하도록 Kubernetes 매니페스트가 업데이트됩니다.
5. Kubernetes는 이미지를 가져와서 클러스터 전체에 롤아웃합니다.

따라서 Docker의 작업은 Kubernetes가 시작되기 전에 대부분 완료됩니다. 이미지는 그들 사이의 핸드오버 지점입니다.

하나의 앱으로 양방향

다음은 작은 웹 서비스입니다. 이미지는 어떤 도구에서 실행하든 동일한 방식으로 구축됩니다.

# Dockerfile
FROM python:3.13-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

Docker로 실행하기

docker build -t shop-api:1.0 .
docker run -d --name shop -p 8080:8000 --restart unless-stopped shop-api:1.0

두 개의 명령이 실행 중입니다. 이는 간단하고 많은 소규모 프로젝트에 적합합니다. 그러나 한 머신에는 하나의 사본이 있으며, 머신이 죽으면 서비스도 함께 진행됩니다.

Kubernetes로 실행하기

# shop.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shop
  template:
    metadata:
      labels:
        app: shop
    spec:
      containers:
        - name: api
          image: registry.example.com/shop-api:1.0
          ports:
            - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
  ports:
    - port: 80
      targetPort: 8000

kubectl apply -f shop.yaml
kubectl get pods -l app=shop

작성해야 할 내용이 훨씬 더 많으며 이를 실행하려면 클러스터가 필요합니다. 그 대가로 안정적인 내부 주소와 자동 교체가 포함된 복사본 3개를 받게 됩니다. 이러한 절충안은 축소된 전체 결정입니다. 즉, 더 많은 탄력성을 대가로 더 많은 복잡성이 발생합니다.

컨테이너에 장애가 발생하면 어떻게 되나요?

도커심 혼란

“Kubernetes가 Docker를 삭제했습니다”라는 내용을 읽어보셨을 것입니다. 이것은 좁은 의미에서 사실이며, 불필요하게 많은 사람을 겁먹게 만들었습니다. Kubernetes는 컨테이너 런타임 인터페이스라는 표준을 통해 컨테이너를 실행합니다. Docker 엔진은 이를 직접 구현하지 않았으므로 Kubernetes에는 dockershim이라는 어댑터가 포함되었습니다. 해당 어댑터는 버전 1.24에서 제거되었습니다.

이제 클러스터는 일반적으로 Containerd 또는 CRI-O와 같은 런타임을 사용합니다. Docker로 빌드한 이미지는 OCI(Open Container Initiative) 이미지 표준을 따르기 때문에 여전히 작동합니다. 따라서 Docker를 사용하여 계속 빌드할 수 있으며 클러스터는 다른 런타임으로 결과를 실행합니다.

Docker Compose vs Swarm vs Kubernetes

보다 의미 있는 비교는 컨테이너를 조정하는 도구 간의 비교입니다.

Docker Compose는 하나의 파일에서 여러 관련 컨테이너를 시작하며 웹 앱과 노트북의 데이터베이스에 탁월합니다. Swarm은 Docker에 내장되어 있으며 Kubernetes보다 배우기가 훨씬 쉽지만 생태계가 훨씬 작습니다. Kubernetes는 가장 큰 커뮤니티와 도구를 보유하고 있으며 이것이 대규모 배포의 기본값이 된 이유 중 큰 부분을 차지합니다.

어느 것이 필요합니까?

일반적으로 다음과 같은 경우에는 Docker만으로도 충분합니다.

• 로컬에서 개발 중이거나 하나의 서버에서 작은 앱을 실행 중입니다.
• 소규모 팀이 있고 전담 운영 직원이 없습니다.
• 가끔씩 발생하는 짧은 가동 중지 시간은 허용됩니다.

Kubernetes는 다음과 같은 경우에 이해되기 시작합니다.

• 다양한 팀이 자체적으로 배포하는 많은 서비스를 실행합니다.
• 여러 머신 또는 영역에 걸쳐 고가용성이 필요합니다.
• 트래픽은 자동 조정으로 실제 비용을 절약할 수 있을 정도로 다양합니다.
• 이를 운영할 수 있는 기술이나 예산이 있습니다.

중간 지점도 있습니다. AWS Fargate, Google Cloud Run 또는 PaaS와 같은 관리형 컨테이너 플랫폼은 유지 관리할 클러스터 없이 Docker 이미지를 실행합니다. 성장하는 많은 기업의 경우 이는 바로 Kubernetes로 전환하는 것보다 올바른 다음 단계입니다.

경력상의 이유로 두 가지를 모두 배우고 싶다면 순서가 명확합니다. Docker를 먼저 배우고 Kubernetes를 그 다음으로 합니다. 이미지, 포트, 컨테이너 로그를 먼저 이해하지 않으면 포드를 편안하게 디버깅할 수 없습니다.

일반적인 실수

• Kubernetes를 너무 일찍 채택합니다. 거대 회사의 아키텍처를 복사하면 소규모 팀이 운영 작업에 파묻힐 수 있습니다.
• 프로덕션에서 latest 태그를 사용합니다. 실행 중인 항목이나 롤백하는 항목을 안정적으로 알 수 없습니다. 특정 버전 태그를 사용하세요.
• 컨테이너 내부에 데이터를 저장합니다. 컨테이너는 일회용이므로 볼륨이나 관리형 데이터베이스를 사용합니다.
• 상태 확인을 건너뜁니다. 준비 상태 및 활성 프로브가 없으면 Kubernetes는 앱에 대해 올바른 결정을 내릴 수 없습니다.
• 리소스 제한을 잊었습니다. 탐욕스러운 컨테이너 하나가 노드의 다른 모든 컨테이너를 굶길 수 있습니다.

마무리

Docker는 소프트웨어를 패키징하고 Kubernetes는 이를 대규모로 실행합니다. 어느 것이 더 나은지 묻기보다는 오늘 어떤 문제가 있는지 물어보세요. “내 앱을 설치하기 어렵습니다”라면 Docker를 사용하세요. “내 40개 서비스가 서버 장애에서 살아남아야 합니다”라면 Kubernetes를 살펴보세요. 실제 문제를 해결하는 가장 간단한 도구로 시작하고, 필요성이 확인되면 위로 올라갑니다.

자주 묻는 질문

계속 학습하세요