개발 창고/Server

Kubernetes 아키텍처: 쿠버네티스는 어떻게 동작할까?

로이제로 2025. 7. 14. 22:00
반응형

들어가며

Kubernetes를 공부하다 보면 수많은 개념과 용어에 둘러싸이게 됩니다. 지난 시간에는 각 개념을 하나씩 뜯어보며 기본기를 다졌다면, 이번 시간에는 그 퍼즐 조각들을 어떻게 맞춰야 하나를 배워야 할 차례입니다. 즉, Kubernetes 전체 아키텍처 구조를 통해 전체 그림을 그려보는 것이 목표입니다.

“Pod, Node, Service, Deployment… 다 알 것 같은데, 이게 어떻게 연결돼 있는 거지?”

그 물음에 정확하게 답할 수 있어야 진짜 Kubernetes 입문을 성공했다고 할 수 있습니다. 이 글을 통해 Kubernetes 클러스터가 어떻게 구성되고, 요청이 어떻게 처리되며, 각 컴포넌트가 어떤 역할을 하는지 이해하게 될 것입니다.

1. 쿠버네티스는 클러스터 기반 구조다

Kubernetes는 기본적으로 클러스터 기반 구조입니다. 클러스터는 여러 대의 서버(노드)로 구성되며, 각 노드는 물리 서버이거나 가상 머신일 수 있습니다.

클러스터는 크게 두 종류의 노드로 구성됩니다.

종류 설명
Control Plane (제어 플레인) 전체 클러스터를 관리하고 통제하는 컴포넌트 집합
Worker Node (작업 노드) 실제로 애플리케이션이 실행되는 공간

즉, 사용자는 Control Plane을 통해 Kubernetes에 명령을 내리고, Kubernetes는 이를 Worker Node에 전달해 애플리케이션을 배포하거나 삭제하는 식입니다.

2. 아키텍처를 한눈에 그려보자

아래는 쿠버네티스의 전체적인 구조를 텍스트로 표현한 그림입니다:

+-----------------------------------------------------------+
|                       Control Plane                       |
|                                                           |
|  +------------+     +---------------+    +--------------+ |
|  |  APIServer | <-> | Scheduler     | -> | Controller    | |
|  |            |     |               |    | Manager       | |
|  +------------+     +---------------+    +--------------+ |
|          |                                         ^      |
|          v                                         |      |
|      etcd (DB)                                     |      |
+-----------------------------------------------------------+
           |
           v
+-----------------------------------------------------------+
|                     Worker Nodes (N개)                    |
|                                                           |
|  +-------------+   +-------------+   +-------------+      |
|  | Node 1      |   | Node 2      |   | Node 3      | ...  |
|  |             |   |             |   |             |      |
|  | +---------+ |   | +---------+ |   | +---------+ |      |
|  | |  kubelet | |   | |  kubelet | |   | |  kubelet | |      |
|  | +---------+ |   | +---------+ |   | +---------+ |      |
|  | |  Pods    | |   | |  Pods    | |   | |  Pods    | |      |
|  | +---------+ |   | +---------+ |   | +---------+ |      |
|  | |kube-proxy| |   | |kube-proxy| |   | |kube-proxy| |      |
|  +-------------+   +-------------+   +-------------+      |
+-----------------------------------------------------------+

3. Control Plane의 구성 요소

1) API Server

쿠버네티스의 입구입니다. 모든 요청은 이곳을 거쳐 들어오며, kubectl 명령어도 결국 API Server에 전달됩니다.

  • 사용자와 클러스터의 인터페이스
  • REST API 형태로 통신
  • 인증/인가/검증 로직 수행

비유: 쿠버네티스의 “정문” 또는 “프론트 데스크”

2) etcd

etcd는 쿠버네티스 클러스터의 상태를 저장하는 고가용성 분산 Key-Value 데이터베이스입니다.

  • 클러스터 전체 설정, 상태, 오브젝트 정보 저장
  • 고가용성(H.A.) 보장
  • API Server가 가장 자주 접근하는 저장소

비유: 공장의 모든 설비 및 재고 기록을 저장하는 ERP 시스템

3) Scheduler

새로운 Pod가 생성되면, Scheduler는 이를 어느 Node에 배치할지 결정합니다.

  • 자원 사용률, Affinity, Taints/Tolerations 등을 고려하여 노드 선택
  • Pod 스펙만 보고 실행은 하지 않음

비유: 작업 지시서를 보고 어떤 직원이 처리할지 결정하는 관리자

4) Controller Manager

클러스터 상태를 감시하고, 실제 상태와 원하는 상태를 일치시키기 위해 동작하는 자동화 로직을 수행합니다.

  • DeploymentController, ReplicaSetController 등 다양한 서브 컨트롤러 포함
  • 상태 불일치 감지 시 자동 복구 시도

비유: 스케줄에 따라 작업자가 작업을 빠뜨리지 않았는지 확인하는 감독관

4. Worker Node의 구성 요소

1) kubelet

Node 안에서 Pod를 실행하고 관리하는 핵심 에이전트입니다.

  • API Server로부터 명령 수신
  • Pod 실행, 상태 모니터링
  • 상태를 주기적으로 API Server에 보고

비유: 일꾼(Node)에게 구체적인 작업 지시서를 전달하고, 작업 완료 여부를 보고하는 팀장

2) kube-proxy

Kubernetes의 네트워크 통신을 담당하는 컴포넌트입니다.

  • Pod 간 네트워크 연결 설정
  • Service IP와 Pod 간 연결
  • IP 테이블 기반 포워딩

비유: 각 부서 간 문서를 전달해주는 메신저

3) Container Runtime

실제로 컨테이너를 실행하는 프로그램입니다. Docker, containerd, CRI-O 등이 여기에 해당합니다.

5. 실제 요청 흐름은 어떻게 되나?

kubectl apply -f app.yaml 명령을 실행한다고 가정해봅시다. 내부 흐름은 다음과 같습니다:

  1. kubectl이 API Server에 요청 전송
  2. API Server가 etcd에 오브젝트 저장
  3. Scheduler가 적절한 Node를 선택
  4. 선택된 Node의 kubelet이 Pod를 생성
  5. Pod가 실행되고, kube-proxy가 네트워크 연결

6. 쿠버네티스는 선언형(Declarative)이다

쿠버네티스는 명령형이 아니라 선언형입니다. 즉, “어떻게”가 아니라 “무엇을 원하는지”를 선언합니다.

apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
    - name: app
      image: nginx

위 파일을 apply하면 쿠버네티스는 자동으로 해당 상태를 유지하려고 노력합니다. 이를 위해 Controller들이 지속적으로 상태를 감시하며 복구합니다.

7. 고가용성과 이중화

Control Plane 구성 요소는 단일 장애 지점을 만들 수 있으므로 다중 마스터 구성으로 고가용성을 보장할 수 있습니다.

  • etcd는 다수결로 결정 (Raft Consensus)
  • Control Plane도 복제 가능
  • 노드 실패 시 Pod는 다른 노드로 재배포

8. 클라우드 vs 온프레미스 아키텍처 차이

Kubernetes는 어디서든 구동 가능하지만, 구성 방식이 조금 다릅니다.

구분 온프레미스 클라우드
LoadBalancer 직접 구성 자동 제공
Storage NFS 등 수동 연결 EBS, GCP Disk 등 자동
노드 추가 수동 설정 필요 자동 스케일링 가능
H.A 구성 복잡 관리형 Kubernetes에서 기본 제공

9. 정리: Kubernetes 아키텍처 요약

구성 요소 역할
API Server 요청 수신 및 인증, 상태 저장 요청 처리
etcd 클러스터 상태 저장소
Scheduler Pod → Node 배치 결정
Controller Manager 실제 상태 유지
kubelet Pod 생성 및 상태 보고
kube-proxy 네트워크 라우팅 및 포워딩
Container Runtime 컨테이너 실행

마무리

이번 글에서는 쿠버네티스의 내부 구조와 각 구성 요소들이 어떤 역할을 맡고 어떻게 상호작용하는지를 살펴보았습니다. 전체적인 큰 그림을 이해하는 것은 앞으로 학습을 이어가는 데 매우 중요한 발판이 됩니다.

다음 시간에는 쿠버네티스의 특징과 장점들에 대해 이야기해보겠습니다. “도대체 왜 이렇게 복잡한 구조를 써야 하나요?”에 대한 답을 드릴 차례입니다.

반응형
저작자표시 비영리 변경금지 (새창열림)