컨테이너란?
app.js 라는 프로그램을 실행할 때, nodeJs를 설치해야 한다.
어떤 환경에서든 실행하고 싶을 때 nodeJs를 설치하고 app.js를 넣어둔 컨테이너 환경을 만들고, 실행하면 간편하게 프로그램을 실행할 수 있다.
컨테이너를 실행할 때 도커 등의 '컨테이너 플랫폼'을 활용해 실행할 수 있다.
가상머신 vs 컨테이너
가상 머신(VM)과 컨테이너는 모두 애플리케이션을 격리된 환경에서 실행할 수 있게 해주지만,
가상 머신은 하드웨어 수준에서 가상화를 통해 전체 운영체제를 구동하는 반면,
컨테이너는 운영체제 수준에서 애플리케이션과 필요한 종속성만 격리하여 실행한다.
따라서 컨테이너는 가상 머신보다 가볍고 시작 속도가 빠르며 리소스 효율성이 높다.
가상 머신 (VM):
- 하드웨어 가상화: 물리 서버의 하드웨어를 가상화하여 각 가상 머신에 독립적인 운영체제(OS)를 설치
- 자원 소비: 각각의 가상 머신이 자체 OS를 가지고 있어 자원(CPU, 메모리, 저장 공간)을 많이 사용
- 시작 시간: OS를 부팅해야 하므로 시작 시간이 오래 걸림
- 격리성: 강력한 격리성을 제공하여 보안에 유리하지만, 자원 낭비가 심할 수 있음
컨테이너:
소스 코드와 베이스 환경만 들어있는 컨테이너 -> 훨씬 용량이 가벼워 빠르고 유연함(확장/축소) -> 컨테이너의 주 목적 : 배포(deploy)
- 운영체제 공유: 호스트 운영체제의 커널을 공유하여 각 컨테이너는 필요한 애플리케이션과 종속 라이브러리만 포함
- 자원 효율성: 가상 머신보다 가볍고, 공유 커널을 사용하므로 리소스를 효율적으로 사용
- 시작 시간: 컨테이너는 가상 머신보다 훨씬 빠르게 시작하고 중지할 수 있음
- 이식성: 컨테이너 이미지를 사용하여 어느 환경에서나 동일하게 실행할 수 있음
- 격리성: 격리성이 가상 머신에 비해 낮지만, 애플리케이션 수준의 격리는 충분히 제공
쿠버네티스(Kubernetes, K8s)
배포의 발전
전통적인 배포 시대
초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책으로 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행할 수도 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으며, 조직이 많은 물리 서버를 유지하는 데에 높은 비용이 들었다.
가상화된 배포 시대
그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.
각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.
컨테이너 개발 시대
컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 유명해졌다.
- 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적이다.
- 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
- 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
- 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
- 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
- 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
- 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
- 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
- 리소스 격리: 애플리케이션 성능을 예측할 수 있다.
- 리소스 사용량: 고효율
컨테이너 오케스트레이션
- 자동화된 컨테이너 배포, 스케일링과 관리
- 쿠버네티스(K8s)는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템
- 쿠버네티스 용어의 의미는 그리스어로 '조타수'를 의미 - 주어진 명령을 핸들에 의해 반복 실행됨을 의미
컨테이너 계층구조
쿠버네티스 특징
- 워크로드 분리
- 어디서나 실행가능 - 온프레미스, 퍼블릭 클라우드(AKS, EKS, GKE 등)
- 선언적 API
명령 : 쿠버네티스야 나 웹서버 3개 실행해줘! -> control plane이 판단해 처리함
하드웨어 위에서 애플리케이션이 잘 동작될 수 있게 해주는 성격 때문에 쿠버네티스를 OS라고 부르기도 한다.
🌊 쿠버네티스(Kubernetes) 기본 구성요소 한눈에 이해하기
쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션을 자동으로 배포하고 관리하는 플랫폼입니다.
하지만 초보자 입장에서는 수많은 구성요소가 복잡하게 느껴지죠.
그래서 이 글에서는 쿠버네티스를 ‘항구와 배’에 비유해서 쉽게 설명해보려 합니다.
- 쿠버네티스 클러스터 = 항구 시스템
- 컨테이너 = 화물
- 노드 = 배 (화물을 실어 나름)
- 마스터 노드 = 항만 본부(관리실)
- 워커 노드 = 실제 배들이 움직이는 곳
🗺️ 쿠버네티스란?
쿠버네티스 클러스터는 컨테이너(화물) 를 싣고 다니는 배(노드) 들이 모여 있는 항구 시스템입니다.
마스터 노드는 이 항구의 컨트롤 타워 역할을 하며, 워커 노드는 실제로 컨테이너를 실어 나르는 배의 역할을 합니다.
🔧 쿠버네티스 구성요소 비유로 쉽게 이해하기
✅ 컨테이너와 노드
- 컨테이너: 실행되는 애플리케이션 (🚚 화물)
- 노드(Node): 컨테이너를 호스팅하는 컴퓨터 (🛳️ 배)
- 쿠버네티스 클러스터: 여러 대의 노드가 모여 있는 시스템 (🚢 항구)
호스팅이란? 웹사이트나 애플리케이션을 운영하기 위해 필요한 서버 공간이나 자원을 다른 사람에게 임대해 주는 서비스
Cluster / Node / Pod 비교 정리
| 구분 | Cluster | Node | Pod |
|---|---|---|---|
| 정의 | 쿠버네티스 전체 시스템 | 클러스터 안의 서버(물리/가상 머신) | 컨테이너를 실행하는 가장 작은 단위 |
| 구성 요소 | Control Plane + Worker Nodes | kubelet, kube-proxy, container runtime, Pod 실행 환경 | 하나 이상의 컨테이너 |
| 역할 | 여러 Node를 묶어 관리하는 단위 | Pod를 실행하는 물리적/가상 실행 환경 | 애플리케이션 컨테이너 실행 |
| 예시 | 개발 클러스터, 운영 클러스터 | Worker Node1, Worker Node2 | nginx Pod, redis Pod, mysql Pod |
| 비유 | 회사 | 부서 | 직원 |
관계 구조
Cluster
├── Node(Worker) 1
│ ├── Pod A (nginx)
│ └── Pod B (redis)
│
├── Node(Worker) 2
│ └── Pod C (mysql)
│
└── Control Plane Node
├── API Server
├── Scheduler
└── etcd
🧠 마스터 노드 (Master Node, = Control Plane) – 항만 본부
쿠버네티스를 총괄 지휘하는 지휘 본부입니다.
| 구성요소 | 역할 | 비유 |
|---|---|---|
| API 서버 (API Server) | 모든 요청과 명령을 받는 입구 | 📞 전화 교환기 |
| etcd | 클러스터의 상태 및 설정 저장소 | 📖 비서의 기록장 |
| 스케줄러 (Scheduler) | 어떤 노드에 컨테이너를 배치할지 결정 | 🏗️ 크레인 |
| 컨트롤러 매니저 (Controller Manager) | 원하는 상태를 유지하도록 지속적으로 확인 | 🧑🏭 부서 관리자 |
💡 예시:
사용자가 "웹 서버 컨테이너를 배포해줘"라고 요청하면
→ API 서버가 수신하고
→ etcd에 저장한 후
→ 스케줄러가 적절한 배를 찾고
→ 컨트롤러가 상태를 관리합니다.
🛳️ 워커 노드 (Worker Node) – 실제로 컨테이너가 실행되는 곳
워커 노드는 컨테이너(화물) 를 실제로 운반하고 실행하는 배입니다.
| 구성요소 | 역할 | 비유 |
|---|---|---|
| 파드(Pod) | 컨테이너의 실행 단위 (하나 또는 여러 개 포함) | 📦 화물 묶음 |
| Kubelet | 해당 노드를 관리하고 API 서버 명령 실행 | 🧑✈️ 선장 |
| Kube Proxy | 네트워크 통신을 가능하게 하는 컴포넌트 | 📡 무선 통신기 |
💡 예시:
컨테이너가 "배포"되면, Kubelet이 그 노드에서 Pod를 실행하고
→ Kube Proxy가 다른 노드와의 통신을 설정합니다.
< k8s >
Node (1:1 = docker와 같은 툴)
ㄴ Pods
ㄴㄴ Containers
하나의 노드(VM or 물리서버) 하위에,
여러 파드들이 올 수 있고, 각 파드는 독립적인 IP를 가지며,
파드 안에서는 어플리케이션이 컨테이너(들)로 실행된다.
컨테이너(파드)를 외부에서 접근하려면 Service(=VIP)로 접근한다!
하나의 Pod에는 1개 이상의 Container가 들어갈 수 있지만, 보통 1:1 구조로 사용 (k8s - msa 지향)
kubectl run webserver --image=nginx
→ webserver라는 Pod 생성, 내부에 nginx 컨테이너 1개 포함
🔄 전체 작동 흐름 요약
- 사용자가
kubectl로 명령을 보냄 → API 서버 수신 - API 서버는 요청을 etcd에 저장하고
- 스케줄러가 적절한 노드(배)를 선택
- 컨트롤러가 상태를 모니터링하며 유지
- Kubelet이 Pod를 실행하고
- Kube Proxy가 통신을 담당
📌 요약 비유 테이블
| 쿠버네티스 요소 | 비유 | 설명 |
|---|---|---|
| 컨테이너 | 화물 | 실제 실행되는 애플리케이션 |
| 파드 | 화물 묶음 | 컨테이너들의 실행 단위 |
| 워커 노드 | 배 | 컨테이너를 실행하는 곳 |
| 마스터 노드 | 항만 본부 | 전체 시스템을 관리 |
| API 서버 | 전화교환기 | 명령을 받고 처리함 |
| etcd | 기록장 | 모든 정보 저장소 |
| 스케줄러 | 크레인 | 적절한 배(노드)를 선택 |
| 컨트롤러 | 부서장 | 상태를 유지하고 조정 |
| Kubelet | 선장 | 노드에서 명령 수행 |
| Kube Proxy | 무선 통신기 | 네트워크 연결 지원 |
💎 기본 구성 요소 설명
컨테이너와 노드
- 쿠버네티스 클러스터는 애플리케이션이 호스팅되는 노드로 구성
- 애플리케이션을 컨테이너 형태로 호스팅하고 자동화
마스터 노드 (Master Node)
- 클러스터의 관리 및 계획, 스케줄링, 노드 모니터링을 담당
- 쿠버네티스 클러스터의 전반적인 정보를 저장
- 배를 관리하고 감독하는 컨트롤쉽에 비유 가능
워커 노드 (Worker Nodes)
- 컨테이너 형태로 애플리케이션을 호스트
- 컨테이너를 실어 나르는 배와 같은 역할
- 물리적 또는 가상일 수 있으며 온프레미스 또는 클라우드에 위치
- 컨테이너를 싣고 다니는 역할을 수행
ETCD - 클러스터 정보 저장
- 쿠버네티스 클러스터의 모든 데이터를 담고 있는 key-value 데이터베이스
- 컨테이너에 대한 정보 및 클러스터 상태를 유지하기 위해 ETCD 사용
- 컨테이너가 어떤 배에, 언제 실렸는지와 같은 정보 저장
스케줄러 - 컨테이너 배치 노드 선택
- 적절한 노드를 찾아 컨테이너를 배치하는 책임
- 컨테이너의 리소스 요구사항과 노드의 용량 등을 고려하여 가장 적합한 노드 선택
- 컨테이너를 배에 실을 때 적절한 배를 선택하는 크레인의 역할과 유사
컨트롤러 - 각 작업 관리
- 다양한 컨트롤러가 각각의 작업이나 부서에 대응
- 노드 컨트롤러는 노드 관리, 복제 컨트롤러는 원하는 수의 컨테이너가 실행되도록 보장
- 항구에서 각 부서가 자신의 업무를 수행하는 것과 비슷
Kube API 서버 - 작업 조정
- 클러스터 내 모든 작업을 조정하는 주요 관리 컴포넌트
- 외부 사용자가 클러스터를 관리하기 위해 호출하는 API 제공
- 각 사무실 간의 통신을 책임지는 역할
Kubelet - 각 노드의 컨테이너 관리
- 모든 노드에 설치된 Kubelet은 해당 노드 상태 모니터링 및 Kube API 서버로부터의 지시 수행
- 컨테이너 배치 및 관리
- 배의 선장이 배에서 모든 활동을 관리하는 것과 유사
Kube Proxy - 서비스 간 통신 지원
- 컨테이너 간의 통신을 가능하게 해줌
- 웹 서버가 다른 노드의 데이터베이스 서버와 통신할 수 있도록 규칙 설정
- 여러 배들 간의 정보 통신을 담당하는 역할
🧠 마무리
쿠버네티스의 내부 구성은 복잡할 수 있지만, 이렇게 비유를 활용하면 큰 흐름을 쉽게 이해할 수 있습니다.
처음엔 어렵더라도 각 요소의 역할을 항구 시스템처럼 이미지화하면 실무에서도 큰 도움이 됩니다.
✅ 궁금한 부분이나 이해 안 가는 점이 있다면 댓글로 남겨주세요 😊
