Docker
컨테이너를 생성하고 실행하는 플랫폼
• 컨테이너화 기술을 제공하는 도구
• 애플리케이션을 컨테이너 단위로 패키징하고 실행
• 개발 환경과 운영 환경을 일관되게 유지 가능
• docker run, docker build 등의 명령어로 컨테이너를 관리
• 주로 단일 서버에서 컨테이너를 실행하는 데 적합
Kubernetes(K8s): 컨테이너 오케스트레이션 도구
• 여러 개의 Docker 컨테이너를 클러스터 환경에서 자동으로 관리
• 로드 밸런싱, 스케일링(확장), 자동 복구, 서비스 디스커버리 등의 기능 제공
• 컨테이너가 죽으면 자동으로 다시 실행하고, 트래픽을 분산하여 안정성 확보
• YAML 파일을 사용하여 배포 (kubectl apply -f deployment.yaml)
• 다중 서버(노드)에서 컨테이너를 관리하는 데 최적화
📌 비유하자면?
• Docker = “컨테이너를 만드는 공장”
• Kubernetes = “컨테이너를 효율적으로 관리하는 컨테이너 항만 시스템(운영체제)”
즉, Docker는 컨테이너를 실행하는 도구, Kubernetes는 여러 컨테이너를 운영하고 관리하는 시스템입니다.
k8s에서 Docker를 어떻게 쓰고 있는가?
Kubernetes 자체는 컨테이너를 직접 실행하지 않음 → 컨테이너 실행은 컨테이너 런타임이 담당.
과거에는 Kubernetes가 Docker만 지원했지만, 지금은 containerd, CRI-O 같은 CRI 호환 런타임을 사용합니다.
컨테이너 런타임(Container Runtime)의 역할
컨테이너를 실제로 실행하고 관리하는 프로그램
- Kubernetes의 명령을 받아서 컨테이너를 생성, 시작, 중지, 삭제하는 역할.
- 컨테이너 내부의 네트워크, 볼륨, 이미지 다운로드 등을 처리.
- 대표적인 컨테이너 런타임: containerd, CRI-O, Docker(과거 사용).
🎯 Kubernetes와 컨테이너 런타임의 관계
Kubernetes (컨테이너 오케스트레이션 시스템)
├── kubelet (각 노드에서 컨테이너 실행을 담당)
│ ├── CRI (Container Runtime Interface, 표준 인터페이스)
│ │ ├── containerd (기본 컨테이너 런타임)
│ │ ├── CRI-O (RedHat 계열에서 주로 사용)
│ │ ├── 기타 (gVisor, Kata Containers 등)
│ │
│ ├── 컨테이너 (Pod 내에서 실행)
│
├── 여러 개의 노드 (각 노드에서 containerd 실행)- Kubernetes는 kubelet을 통해 컨테이너 실행을 요청.
- kubelet은 CRI(Container Runtime Interface) 를 통해 컨테이너 런타임과 통신.
- **컨테이너 런타임(containerd)이 컨테이너를 실행하고 관리
k8s 클러스터 구조
Kubernetes Cluster
├── [Master Node] (클러스터를 관리)
│ ├── API Server (k8s의 중심, 모든 요청 처리)
│ ├── Controller Manager (노드/파드 관리 자동화)
│ ├── Scheduler (어느 노드에 컨테이너를 배치할지 결정)
│ ├── etcd (클러스터의 모든 상태 저장)
│
├── [Worker Nodes] (컨테이너를 실행)
│ ├── kubelet (노드에서 컨테이너 실행 관리)
│ ├── Container Runtime (containerd 또는 CRI-O)
│ ├── Kube Proxy (네트워크 관리)
│ ├── 실제 컨테이너들 (Pod 내에서 실행)✅ kubelet의 역할
• 각 Worker Node에서 실행되며, Master Node가 API Server를 통해 kubelet에 명령을 보내고, kubelet이 컨테이너 런타임(containerd 등)과 통신하여 컨테이너를 실행함.
• 지정된 Pod가 실행 중인지 확인하고, 문제가 생기면 재시작
과거에는? (Docker + Kubernetes)
예전에는 Kubernetes가 Docker 엔진(Docker Daemon) 을 직접 사용해서 컨테이너를 실행했습니다.
하지만 Kubernetes는 CRI(Container Runtime Interface) 라는 표준을 따르는데, Docker는 CRI를 직접 지원하지 않았습니다.
그래서 중간에 dockershim이라는 Docker-Cri 변환 계층을 두고 Kubernetes가 Docker를 사용하게 했습니다.
k8s v1.23이하
Kubernetes API Server
└── kubelet
└── dockershim (Docker ↔ CRI 변환)
└── Docker Engine
└── containerd
└── 실제 컨테이너 실행Kubernetes가 Docker를 쓰긴 했지만, Docker도 내부적으로 containerd를 사용
지금은? (Docker 지원 중단, CRI 기반)
Kubernetes는 v1.24부터 dockershim을 완전히 제거했고, 이제 직접 Docker 엔진을 사용할 수 없습니다.
대신 containerd, CRI-O 같은 CRI 호환 런타임을 사용합니다.
k8s v1.24 이상
Kubernetes API Server
└── kubelet
└── CRI (Container Runtime Interface)
├── containerd (기본 선택)
├── CRI-O (주로 OpenShift에서 사용)
├── 다른 CRI 호환 런타임들- 이제 Kubernetes는 Docker 엔진 없이도 컨테이너를 실행할 수 있음
- 하지만 Docker로 만든 이미지는 여전히 사용할 수 있음 (OCI 표준이므로 문제 없음)
CRI(Container Runtime Interface) 기반 런타임이란?
CRI(Container Runtime Interface) 는 Kubernetes가 다양한 컨테이너 런타임을 사용할 수 있도록 표준화한 인터페이스입니다.
즉, Kubernetes가 특정 컨테이너 런타임(Docker, containerd 등)에 의존하지 않고 컨테이너를 실행할 수 있게 해주는 역할을 합니다.
대표적인 CRI 기반 런타임
✅ 1. containerd (default)
- Docker에서 분리된 경량 컨테이너 런타임
- 현재 Kubernetes에서 가장 널리 사용됨
- docker 명령어는 없지만, 내부적으로 Docker와 동일한 컨테이너 실행 방식
- 원래 Docker의 내부 컴포넌트였지만, 독립적인 컨테이너 런타임으로 발전.
✅ 2. CRI-O (Red Hat, OpenShift에서 주로 사용)
- Kubernetes용으로 최적화된 컨테이너 런타임
- Docker 엔진이 필요 없음
- 성능이 가볍고 Kubernetes와의 통합이 뛰어남
✅ 3. Kata Containers, gVisor (보안 특화)
- 가상 머신과 컨테이너를 결합하여 보안성을 강화한 런타임
🎯 컨테이너 실행 과정 (kubelet → CRI → 컨테이너 런타임)
🏗 1. Master Node가 컨테이너 실행 요청
- 사용자가 kubectl apply -f deployment.yaml 실행
- Master Node의 Scheduler가 컨테이너를 실행할 적절한 Worker Node를 선택
- 선택된 Worker Node의 kubelet에 Pod 생성 요청 전송
🚀 2. kubelet이 CRI를 통해 컨테이너 런타임 호출
- kubelet이 CRI의 gRPC API를 통해 컨테이너 런타임에 컨테이너 생성 요청
service RuntimeService {
rpc RunPodSandbox (RunPodSandboxRequest) returns (RunPodSandboxResponse);
rpc CreateContainer (CreateContainerRequest) returns (CreateContainerResponse);
rpc StartContainer (StartContainerRequest) returns (StartContainerResponse);
}⚙️ 3. 컨테이너 런타임이 컨테이너 실행
- containerd 또는 CRI-O가 실행 요청을 받고, 컨테이너를 생성
- 필요한 Docker/OCI 이미지를 레지스트리에서 Pull
- 컨테이너를 실행하고, 네트워크 설정을 구성
- kubelet에 컨테이너 실행 완료 상태를 응답
런타임 직접 확인해보기
- kubectl
kubectl get node -o wide
// 결과의 CONTAINER-RUNTIME
NAME STATUS ROLES AGE VERSION INTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
node-1 Ready <none> 50d v1.27.1 192.168.1.10 Ubuntu 22.04.1 LTS 5.15.0-75-generic containerd://1.6.15
node-2 Ready <none> 45d v1.27.1 192.168.1.11 Ubuntu 22.04.1 LTS 5.15.0-75-generic cri-o://1.24.2- crictl info (CRI 기반 런타임 상세 확인)
Kubernetes에서 사용 중인 CRI 런타임의 정보를 더 자세히 보려면 crictl(Container Runtime Interface CLI)을 사용합니다.
crictl info | jq '.runtimeType'
// containerd 사용 시
"containerd"
// cri-o 사용 시
"cri-o"- 노드에 접속해서 확인
// containerd가 실행 중인지 확인
systemctl status containerd
// CRI-O가 실행 중인지 확인
systemctl status crio📡 4. kubelet이 컨테이너 상태를 지속적으로 모니터링
- kubelet은 주기적으로 컨테이너 런타임에게 컨테이너 상태 확인 요청 (ListContainers, ContainerStatus)
- 만약 컨테이너가 비정상 종료되면 다시 실행
