1. 컨테이너 기술과 Docker의 구분 및 다른 구현 도구

컨테이너와 Docker의 관계

  1. 컨테이너 기술 (개념/본질): OS 레벨의 가상화 아키텍처.
    • 애플리케이션과 종속성을 격리된 환경으로 묶어 실행하는 기술 자체이며, Docker 탄생 이전부터 존재했음 (예: FreeBSD Jails, LXC).
  2. Docker (구현 도구): 컨테이너 기술을 대중화하고 표준화한 ‘하나의 소프트웨어’.
    • 복잡했던 리눅스 컨테이너 기술을 이미지 포맷, 레지스트리, API 형태로 규격화하여 개발자가 다루기 쉽게 만든 도구일 뿐, 컨테이너의 동의어가 아님.

Docker 외의 컨테이너 구현 도구

  • Podman: Docker와 명령어 체계가 호환되지만, 상시 실행되는 백그라운드 데몬(Daemon) 없이 독립적으로 동작하여 보안성이 높은 엔진.
  • containerd: 과거 Docker의 일부였으나 독립된 프로젝트로 분리되었으며, 컨테이너의 생명주기(실행 및 종료) 관리만 전담하는 경량 핵심 런타임.
  • CRI-O: Kubernetes 환경에서 컨테이너를 실행하기 위해 특별히 제작된 표준 규격(CRI) 기반의 경량 런타임.

2. 컨테이너 오케스트레이션의 개념 및 주요 해결 문제점

수십에서 수천 개의 컨테이너들의 배포, 관리, 스케일링, 네트워킹을 자동화하는 제어 시스템(예: Kubernetes). 수동 관리가 불가능한 다중 서버 분산 환경에서 필수적으로 요구됨.

Docker 단독 환경 대비 주요 해결 문제점 3가지

  1. 자동 확장 (Auto-scaling)
    • Docker 단독: 트래픽 증가 시 관리자가 서버 자원을 직접 모니터링하고 명령어를 통해 수동으로 컨테이너를 추가 배포해야 함.
    • 오케스트레이션: CPU, 메모리 등의 리소스 사용량을 감시하여 임계치 초과 시 시스템이 알아서 컨테이너 개수(Replica)를 늘리고, 여유로우면 다시 줄여 자원을 최적화함.
  2. 자가 복구 (Self-healing)
    • Docker 단독: 프로세스 오류나 노드(서버) 다운으로 컨테이너가 죽으면 관리자가 직접 접속하여 재시작할 때까지 서비스가 중단됨.
    • 오케스트레이션: 지속적으로 컨테이너 상태(Health Check)를 확인하여, 비정상 상태의 컨테이너를 폐기하고 다른 건강한 노드에 새 컨테이너를 자동 배치해 무중단 서비스를 유지함.
  3. 선언적 인프라 (Declarative Infrastructure)
    • Docker 단독: “A 컨테이너를 실행해라”와 같이 절차에 따라 순서대로 실행하는 명령형(Imperative) 인프라 관리 방식.
    • 오케스트레이션: “항상 A 컨테이너 3개를 유지해라”라는 최종 목표 상태(Desired State)를 YAML 파일 등에 선언하면, 제어기가 현재 상태를 지속 감시하며 목표 상태와 일치하도록 스스로 조치함.