백엔드 공부를 시작하면서 첫 배포 때 도커를 찍먹했다.
운영체제와 인프라를 공부하고 나서 컨테이너와 쿠버네티스를 시스템 관점에서 재정리했다.
구조와 동작 원리 중심으로 이해하려고 노력 했다.
1. Container 용어
- Dockerfile: 컨테이너 이미지를 생성하기 위한 설정 파일. 애플리케이션 실행에 필요한 환경을 정의
- entrypoint: 컨테이너가 실행될 때 가장 먼저 실행되는 프로세스. ENTRYPOINT로 지정된 명령은 컨테이너 실행 흐름 제어
- Docker: 컨테이너 이미지 생성, 실행 플랫폼. 하나의 서버에서도 여러 컨테이너를 격리된 환경에서 실행
- Docker Hub: 컨테이너 이미지 저장소. 만들어진 이미지를 가져오거나(pull), 업로드 (push) 가능
2. Container 사용 목적
- 배포 효율성: 컨테이너는 애플리케이션을 경량화된 형태로 패키징해 빠르게 배포하고 실행 가능
- 스케일링: 컨테이너는 여러 서버에 분산 배치하기 쉬워 수평 확장(Scale-out) 용이
3. Docker의 한계와 Kubernetes 등장
- Docker의 한계점
- Docker 데몬이 죽으면 컨테이너들도 같이 죽음
- 수백 개의 컨테이너를 수동으로 배체, 운영하기 어려움
- 여러 노드에 분산하려면 관리자가 직접 구성 필요
- Container Orchestration System: 컨테이너들을 자동 배포, 실행, 복구하는 시스템. (ex. Autoscaling, 자동 재시작, 장애 복구)
- Orchestration Tool: Kubernetes
4. 인프라 계층 구조
- 물리 인프라 (1계층): 실제 서버 하드웨어
- 가상 인프라 (2계층): VM이 서버 위에서 동작
- 운영체제 (3계층): Linux가 VM 위에서 실행
- 컨테이너 엔진 (4계층): Docker 실행
- 오케스트레이션 (5계층): Kubernetes가 Container 스케줄링, 복구
- 애플리케이션 배포 (6계층): OpenShift, ArgoCD가 배포 자동화, 파이프라인 관리
5. Kubernetes 특징
- 워크로드 분산: 여러 대의 Node에 Pod(Container) 분산 실행. 각 Node는 독립적으로 관리되며, Pod 간에는 네트워크를 통해 통신 가능
- 환경 독립성: 온프레미스, 퍼블릭 클라우드(EKS 등) 어디서든 실행 가능. 특정 인프라에 종속되지 않음
- 선언적 API 기반 운영: 원하는 상태를 선언하면, Kubernetes가 지속적으로 현재 상태를 모니터링하며 상태와 일치되도록 Node들을 자동 조정 (ex. "컨테이너 2개 유지"를 정의 시, 컨테이너 하나가 죽으면 자동 재생성)
운영체제와의 유사점
- OS(운영체제): 하드웨어 위에서 프로세스 스케줄링, CPU, Memory 관리
- Kubernetes: 컨테이너 위에서 앱(Pod) 스케줄링, Network, Storage 관리
CNI (Container Network Interface)
- Kubernetes가 여러 Node에서 동작하는 Pod 간 통신을 하기 위해 사용
- VxLAN 기반 Overlay 네트워크: 기존 네트워크 위에 새로운 가상 네트워크를 추가해서 다른 네트워크 간 연결하는 기술, Pod들이 서로 다른 Node에 있어도 IP 주소로 통신 가능
- 대표 CNI 플러그인: flannel, calico, weavenet
Kubernetes Cluster 구조
- Control Plane (또는 Master Node): 클러스터 전체 상태 관리. (Pod를 Node에 스케줄링, 클러스터 설정 변경, 상태 모니터링, 장애 복구)
- Worker Nodes: Pod를 실행하는 Node. (각 Worker Node에는 containerd 컨테이너 런타임이 설치되어, Control Plane 지시에 따라 Pod를 실행)