1. 컨테이너와 쿠버네티스

Kubernetes 개요 정리 (컨테이너 & Docker 중심)

1) Kubernetes란?

• Kubernetes(K8s): 컨테이너를 배포/확장/관리하기 위한 대표적인 오픈소스 컨테이너 오케스트레이션 기술
• Google이 프로덕션에서 컨테이너를 운영하던 경험을 바탕으로 발전
• 쿠버네티스를 이해하려면 먼저 아래 2가지를 알아야 함
  1. 컨테이너(Container)
  2. 오케스트레이션(Orchestration)
• 이번 파트는 그중 컨테이너, 특히 Docker에 집중

---

2) Docker가 필요한 이유 (문제 상황)

예전 프로젝트에서 다양한 구성요소로 엔드투엔드 스택을 구성해야 했음:

• 웹 서버(Node.js)
• DB(MongoDB)
• 메시징/캐시(Redis)
• 오케스트레이션 도구(Ansible) 등

이때 발생한 대표적인 문제들:

(1) OS 호환성 지옥

• 각 서비스/도구가 OS 버전과 호환되는지 계속 확인해야 함
• 어떤 서비스 버전은 특정 OS에서 안 돌아가서 OS를 다시 선택해야 하는 경우도 생김

(2) 라이브러리/의존성 충돌

• 서비스마다 필요한 라이브러리 버전이 달라 충돌 발생
• 시간이 지나면서 아키텍처 변경/업그레이드 시마다 다시 호환성 검증 필요
• → 흔히 “지옥에서 온 매트릭스(compatibility matrix)” 문제

(3) 신규 개발자 온보딩이 어려움

• 환경 세팅을 위해 수백 개의 명령/가이드를 따라야 함
• OS, 각 구성요소 버전까지 모두 맞춰야 해서 재현성이 떨어짐

(4) 개발/테스트/프로덕션 환경 불일치

• 개발자마다 OS가 달라서 “내 PC에서는 됨” 문제가 발생
• 결과적으로 배포/운영이 매우 어려워짐

---

3) Docker로 해결되는 방식

• 각 구성요소를 별도 컨테이너로 분리
• 컨테이너 안에 해당 구성요소의 의존성/라이브러리를 함께 포함
• 개발자는 OS에 상관없이 Docker만 설치되어 있으면 동일한 방식으로 실행 가능
• 한 번 이미지를 만들어두면 어디서나 동일하게 실행됨
• → 환경 재현성 + 배포 단순화 + 변경의 독립성 확보

---

4) 컨테이너란?

• 컨테이너는 완전히 격리된 환경
• VM처럼:
  • 자체 프로세스/서비스
  • 자체 네트워크 인터페이스
  • 자체 마운트(파일 시스템) 등을 가질 수 있음
• 단, VM과 다른 핵심:
• ✅ 컨테이너는 호스트와 OS 커널을 공유함

컨테이너 자체는 Docker가 처음 만든 개념이 아니라, LXC/LXD 등 오래전부터 존재했음.

Docker는 이런 저수준 기술을 사용하기 쉽게 만들어 대중화시킴.

---

5) “커널 공유”가 의미하는 것

OS는 크게:

• OS 커널(kernel): 하드웨어와 상호작용 (Linux 커널은 공통)
• 유저 공간 소프트웨어: UI, 드라이버, 컴파일러, 툴 등 (배포판마다 차이)

Docker는:

• 호스트의 커널을 그대로 사용
• 컨테이너에는 OS를 구분 짓는 **추가 소프트웨어(유저 공간)**만 들어감

그래서 가능한 것:

• Ubuntu 호스트에서 Debian/Fedora/CentOS 기반 컨테이너 실행 가능(리눅스 커널 공유 조건)

불가능한 것:

• Linux 호스트에서 Windows 컨테이너 실행 불가(커널이 다름)
• Windows에서 Linux 컨테이너 실행은 실제로는 내부에서 Linux VM을 띄워서 그 위에서 실행하는 방식

---

6) VM vs Docker 컨테이너 차이

Docker 컨테이너 구조

• HW → Host OS → Docker → (컨테이너들: 앱 + 의존성)

VM 구조

• HW → Hypervisor → (VM들: 각자 OS + 앱 + 의존성)

차이점 요약:

• VM은 각 VM마다 OS를 포함 → 무겁고 디스크 많이 사용(GB 단위), 부팅 느림(분 단위)
• 컨테이너는 OS 커널 공유 → 가볍고 디스크 적음(MB 단위), 부팅 빠름(초 단위)
• 격리성:
  • VM: OS 자체가 분리되어 격리 강함
  • 컨테이너: 커널 공유로 상대적으로 격리 약함
• 이기종 OS:
  • VM: Linux/Windows 등 다른 OS도 같은 하드웨어에서 동시 운영 가능
  • 컨테이너: 같은 커널 계열 내에서만 가능

---

7) 현실적인 운영 형태: VM + 컨테이너 함께 사용

• 대규모 환경에서는 보통:
  • VM으로 Docker 호스트를 유연하게 프로비저닝/해제
  • 그 위에서 컨테이너를 빠르게 배포/확장
• 즉, 가상화(VM)의 유연성 + 컨테이너의 민첩성을 결합

---

8) 이미지(Image)와 컨테이너(Container)

• 이미지(Image): 템플릿/패키지 (VM의 템플릿처럼)
• 컨테이너(Container): 이미지를 실행한 인스턴스 (격리된 실행 환경 + 프로세스)

---

9) Docker Hub로 쉬운 배포

• 많은 제품/도구가 이미 컨테이너 이미지로 제공됨 (Docker Hub/Docker Store)
• Docker 설치 후 docker run <image> 처럼 실행하면 바로 서비스 기동 가능
• 인스턴스를 여러 개 띄우고 앞에 로드밸런서 두는 식으로 확장도 가능
• 장애 시 해당 컨테이너를 버리고 새로 띄우는 방식으로 대응 가능

---

10) 개발팀-운영팀 협업 방식 변화

기존:

• 개발자가 앱 개발 → 운영팀에게 배포 가이드 전달 → 운영팀이 환경 구축/배포
• (문제 생기면 운영팀이 파악 어려움)

Docker 이후:

• 개발 + 운영이 함께 배포 가이드를 Dockerfile로 표준화
• Dockerfile로 이미지 생성
• 운영팀은 Docker가 설치된 어디서든 이미지 실행만 하면 됨
• “개발에서 되던 게 운영에서 안 되는” 문제를 크게 줄임

---

Windows에서 Linux 컨테이너가 동작하는 원리

• Windows에서 docker 명령을 치더라도, Linux 컨테이너는 Linux 커널이 있어야 실행됨.
• 그래서 실제 컨테이너 실행/관리는 WSL2 또는 Linux VM 쪽에서 돌아가는 Docker Daemon이 담당하고,
• Windows의 docker CLI는 그 Daemon에 명령만 전달하는 구조임.

“Hyper-V 격리” 용어가 헷갈리는 이유

• Hyper-V isolation은 보통 Windows 컨테이너에서 쓰는 격리 모드(프로세스 격리 vs Hyper-V 격리)를 말하는 경우가 많음.
• Linux 컨테이너는 Hyper-V isolation 옵션으로 Windows 커널 위에서 직접 도는 게 아니라, 결국 Linux 커널(WSL2/VM) 위에서 실행됨.

하이퍼바이저 Type 1 vs Type 2 정리

Type 1 (베어메탈/하이퍼바이저가 “OS 아래”)

• 하드웨어 위에 하이퍼바이저가 직접 올라가고 그 위에 VM들이 동작
• 장점: 성능/격리/안정성 유리(서버/운영 환경에 적합)
• 예시:
  • Hyper-V(활성화 시 Windows도 하이퍼바이저 위 “파티션”으로 올라가는 구조)
  • VMware ESXi

Type 2 (호스트형/하이퍼바이저가 “OS 위” 앱처럼)

• 하드웨어 → 호스트 OS → 그 위에서 가상화 소프트웨어가 동작
• 장점: 설치/사용이 편하고 데스크톱 개발·테스트에 적합
• 예시:
  • VMware Workstation, VMware Fusion
  • (일반적으로) VirtualBox 등

참고로 “Type 1/2”는 현실에선 경계가 완전 딱 떨어지진 않지만, **개념적으로 ‘가상화 레이어가 OS 아래냐 위냐’**로 이해하면 정확해.

Hyper-V 기반 Linux VM vs WSL2 차이

• 공통: 둘 다 내부적으로 가상화로 Linux 커널을 제공함.
• Hyper-V 기반(Linux VM): 사용자가 VM을 직접 만들고 운영(설치/네트워크/리소스 관리 등).
• WSL2: Windows가 경량 Linux VM을 자동 관리하고 개발 환경 통합이 좋아서 보통 더 편함.

Hyper-V vs VMware 차이(요약)

• 둘 다 가상화 기술이지만 성격이 다름.
• Hyper-V: Windows 내장형, WSL2/Docker 같은 기능과 깊게 통합.
• VMware: 제품군이 다양
  • ESXi(서버용 Type1), Workstation/Fusion(PC용 Type2 성격) 등.

핵심 한 줄 요약

Docker는 “환경/의존성/배포” 문제를 컨테이너 이미지로 표준화해서 해결하고, Kubernetes는 그 컨테이너들을 **대규모로 자동 운영(오케스트레이션)**하기 위한 플랫폼이다.