1️⃣ Kubernetes는 어떻게 동작할까?
이전 글에서 **Kubernetes의 기본 개념(Cluster, Node, Pod)**을 배웠습니다.
이제 Kubernetes 클러스터의 전체 아키텍처를 깊이 있게 분석해 보겠습니다.
Kubernetes는 **Master Node(제어부)**와 **Worker Node(실행부)**로 구성됩니다.
Master Node는 클러스터의 “두뇌” 역할을, Worker Node는 “일꾼” 역할을 수행합니다.
아래 다이어그램을 보며 함께 살펴볼까요? 👀
2️⃣ Kubernetes 아키텍처 개요
📌 Kubernetes 아키텍처의 주요 구성 요소
+--------------------------+ +---------------------------+
| 🏢 Master Node | | 🚀 Worker Node 1 |
|--------------------------| |---------------------------|
| 📡 API Server | <-> | 🔌 Kubelet |
| 📦 etcd (Storage) | <-> | 🛰️ Kube-proxy |
| 🎯 Scheduler | | 🏗️ Pod 1 (Nginx) |
| 📊 Controller Manager | | 🏗️ Pod 2 (Redis) |
+--------------------------+ +---------------------------+
+---------------------------+
| 🚀 Worker Node 2 |
|---------------------------|
| 🔌 Kubelet |
| 🛰️ Kube-proxy |
| 🏗️ Pod 3 (MongoDB) |
+---------------------------+
✅ Master Node → 클러스터를 관리하고 명령을 내림
✅ Worker Node → 실제 컨테이너(Pod)를 실행
✅ API Server → 모든 통신의 중심
✅ Scheduler → Pod의 배치를 결정
✅ Controller Manager → 시스템의 상태를 지속적으로 감시
✅ etcd → 클러스터 데이터를 저장
3️⃣ Master Node의 구성 요소
Master Node는 Kubernetes 클러스터의 두뇌 역할을 합니다.
각 컴포넌트가 어떻게 작동하는지 살펴보겠습니다.
✅ 3.1 API Server (kube-apiserver)
Kubernetes의 모든 요청을 처리하는 중앙 관제탑 🚦
📌 API Server의 역할
• kubectl 명령어를 받아들이고 클러스터와 통신
• Kubernetes의 모든 내부 서비스가 API Server를 통해 데이터 교환
• JSON 및 YAML을 사용해 클러스터 리소스를 관리
📌 실제 예제
kubectl get pods # -> API Server가 요청을 처리
✅ API Server는 Kubernetes의 입구(Gateway) 역할을 한다.
✅ 3.2 etcd (클러스터 상태 저장소)
Kubernetes의 데이터베이스, 모든 상태 정보 저장 🗄
📌 etcd의 역할
• 클러스터의 모든 상태 정보(배포된 Pod, 노드 상태 등)를 저장
• key-value 형태로 데이터를 저장
• Master Node가 클러스터의 상태를 유지하는 핵심 요소
📌 etcd에 저장된 데이터 예시
{
"nodes": {
"worker-node-1": { "status": "Ready" },
"worker-node-2": { "status": "NotReady" }
}
}
✅ API Server는 etcd에 데이터를 읽고/쓰기 때문에 매우 중요한 요소!
✅ 3.3 Scheduler (Pod 배치 담당)
Pod가 어디에서 실행될지 결정하는 역할 🎯
📌 Scheduler의 역할
• 새로운 Pod가 생성될 때, 적절한 Worker Node를 선택
• CPU, 메모리, 리소스 가용성을 고려하여 배치
📌 실제 예제 (Pod가 생성될 때 스케줄링 과정)
kubectl run nginx --image=nginx
✅ Scheduler가 적절한 Worker Node를 찾아 Pod를 배치!
✅ 3.4 Controller Manager (자동 복구 및 관리)
Kubernetes 시스템의 지속적인 상태 감시 및 복구 🛠
📌 Controller Manager의 역할
• ReplicaSet을 관리하여 Pod 개수 자동 유지
• 노드 장애 발생 시 새로운 Pod를 다른 노드에 배치
• 서비스 디스커버리와 네트워크 설정 조정
📌 Controller Manager의 자동 복구 예제
kubectl scale deployment my-app --replicas=3
✅ Pod 하나가 삭제되면 Controller Manager가 자동으로 새로운 Pod 생성!
4️⃣ Worker Node의 구성 요소
Worker Node는 애플리케이션을 실행하는 노드입니다.
여기에서 Kubelet, Kube-proxy, 컨테이너 런타임이 핵심 역할을 합니다.
✅ 4.1 Kubelet (Node의 핵심 관리자)
Worker Node에서 Pod를 실행하고 상태를 모니터링하는 Agent 🤖
📌 Kubelet의 역할
• API Server와 지속적으로 통신
• Pod을 생성하고 컨테이너 상태를 체크
• 컨테이너가 정상적으로 실행되지 않으면 자동 복구
📌 Kubelet 로그 확인 예제
journalctl -u kubelet -f
✅ Kubelet이 없으면 Kubernetes는 Pod를 실행할 수 없다!
✅ 4.2 Kube-proxy (네트워크 트래픽 관리)
Worker Node에서 네트워크 트래픽을 라우팅하는 역할 🛰
📌 Kube-proxy의 역할
• 클러스터 내부의 네트워크 트래픽을 관리
• 서비스 간 통신을 위한 로드 밸런싱 제공
📌 Pod 간 통신을 위한 Kube-proxy 설정 예제
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
✅ Kube-proxy가 Pod와 서비스 간 트래픽을 자동으로 라우팅!
✅ 4.3 컨테이너 런타임 (Container Runtime)
Pod 내부에서 컨테이너를 실행하는 역할 🐳
📌 Container Runtime의 역할
• Docker, containerd, CRI-O 등의 컨테이너 실행 엔진을 통해 Pod 내부의 컨테이너 실행
• Kubelet과 연동하여 컨테이너 상태 관리
📌 컨테이너 런타임 종류
• Docker
• containerd
• CRI-O
✅ Kubernetes는 다양한 컨테이너 런타임을 지원!
📌 결론: Kubernetes 아키텍처 요약
구성 요소역할
API Server | 클러스터의 모든 요청을 처리 |
etcd | 클러스터의 상태를 저장 |
Scheduler | Pod를 적절한 Worker Node에 배치 |
Controller Manager | 클러스터의 상태를 지속적으로 감시 |
Kubelet | Worker Node에서 Pod 실행 및 관리 |
Kube-proxy | 네트워크 트래픽을 라우팅 |
🔥 Kubernetes는 자동화된 컨테이너 오케스트레이션을 제공하는 강력한 플랫폼!
'Kubernetes > Kubernetes Basics' 카테고리의 다른 글
📌 Kubernetes Ingress: 도메인 기반 트래픽 관리 이해하기 (0) | 2025.03.03 |
---|---|
📌 Kubernetes Service: 로드 밸런싱과 네트워크 설정 이해하기 (0) | 2025.03.03 |
📌 Kubernetes 핵심 개념: Pod, Node, Cluster 에 대한 이해 (0) | 2025.03.02 |
📌 Monolithic vs. Microservices: Kubernetes가 왜 마이크로서비스와 잘 맞을까? (0) | 2025.03.02 |
📌 Kubernetes의 필요성: 컨테이너 운영 자동화가 왜 필요할까? (0) | 2025.03.02 |