[k8s] 쿠버네티스의 기본 구성 요소 / 쿠버네티스 클러스터 구조

Ⅰ. 쿠버네티스⭐클러스터⭐구조

🤔 쿠버네티스 클러스터란? 

• 클러스터는 서버(노드)들을 묶어 하나의 시스템처럼 동작하도록 만든 집합체
• 즉, 여러 대의 서버가 하나의 거대한 컴퓨터처럼 동작하는 구조

쿠버네티스 클러스터는 컨테이너화된 애플리케이션을 배포하고 관리하는 환경이며,
하나의 클러스터는 두 가지 주요 구성 요소로 나뉜다. ⤵️

구성 요소	역할
Node (워커 노드)	실제 컨테이너(Pod)를 실행하는 물리적/가상 서버
Control Plane (컨트롤 플레인)	클러스터의 제어부, 클러스터 전체 상태를 관리하고 조율

✅ 쿠버네티스 클러스터 구조 (Control Plane + Node)

클릭하면 출처로 이동..

1️⃣ Control Plane

✍🏻클러스터 전체를 관리하는 관리자 역할이다.

• kube-apiserver: 모든 요청이 이곳을 거쳐서 처리됨 (클러스터의 게이트웨이)
• etcd: 클러스터 상태 정보를 저장하는 분산 키-값 DB
• scheduler: 새로운 파드를 적절한 노드에 배치
• controller manager: 클러스터 상태를 의도한 상태로 유지
• cloud-controller-manager: 클라우드 벤더와 연동 (AWS, GCP 같은 클라우드 리소스 관리)

2️⃣ Node (워커 노드)

✍🏻 실제로 컨테이너가 배포되고 동작하는 서버다.

• kubelet: 컨트롤 플레인의 명령을 받아서 파드를 실행하고 상태를 보고 Node Service Daemon
• kube-proxy: 서비스 IP와 실제 Pod IP 간의 라우팅 처리 Node Service Daemon
• Pod: 컨테이너가 동작하는 최소 단위 // 글 아래 Ⅱ 쿠버네티스 기본 용어 참고!!
• CRI(Container Runtime Interface): 실제 컨테이너를 실행하는 엔진 (Docker, containerd 등)

⭐쿠버네티스에서 클러스터의 구성 방식 = 마스터 노드 + 워커 노드 ⭐

마스터 노드(Control Plane)
: 클러스터 상태 감시, 스케줄링, 자원 배분 등 제어 기능 담당
워커 노드(Node)
: 실제 컨테이너가 실행되는 환경 제공 (여러 개의 Pod를 실행함)

---

✅ 클러스터의 특징

1. 확장성 (Scalability)
   → 노드를 추가하면 자동으로 워크로드 분산 가능
2. 고가용성 (High Availability)
   → 노드가 죽어도 서비스 지속, 컨트롤 플레인도 이중화 가능
3. 자원 격리 (Resource Isolation)
   → Namespace, ResourceQuota로 팀/서비스 단위 자원 제한 가능
4. 셀프힐링 (Self-Healing)
   → 파드가 죽으면 자동으로 다시 생성하는 오토 힐링 기능

✅ 클러스터 운영에서 고려할 점

• 노드 장애 대비: 노드가 죽었을 때 자동으로 파드를 옮길 수 있도록 디자인
• 모니터링 필수: 클러스터 전체 상태를 항상 확인해야 함 (Prometheus + Grafana 많이 씀)
• 오토 스케일링: 트래픽에 맞게 자동으로 노드를 추가하거나 줄이는 기능 사용 (HPA, VPA, Cluster Autoscaler)

쿠버네티스 클러스터 동작 흐름 예시 ⤵️

1. 사용자가 애플리케이션 배포 요청 (kubectl apply -f)
2. kube-apiserver가 요청 수신
3. etcd 상태 확인 및 저장
4. scheduler가 적합한 노드에 Pod 배치 결정
5. 해당 노드의 kubelet이 컨테이너 실행
6. kube-proxy가 서비스와 연결하여 외부 트래픽 처리

---

---

Ⅱ 쿠버네티스 기본 용어🐋

용어	설명
Namespace	하나의 물리 클러스터 안의 논리적 분할 공간 (팀/프로젝트/환경 구분)
Master	클러스터 전체를 제어하는 컨트롤 플레인 핵심 노드
Node	실제 컨테이너(Pod)가 배포되고 실행되는 서버
Control Plane	클러스터를 통제하는 중앙 시스템 (Master + kubelet 등)
Object	클러스터에 존재하는 모든 리소스를 나타내는 단위
Controller	오브젝트를 관리하고 상태를 자동으로 유지하는 관리자 역할
Pod	하나 이상의 컨테이너가 모여 실행되는 최소 단위
Service	Pod 집합에 대한 네트워크 접근을 제공하는 추상화

각각의 자세한 설명은 더보기란 ⤵️

① Namespace (네임스페이스)

• 하나의 물리 클러스터 안에서 여러 개의 가상 클러스터처럼 사용할 수 있도록 논리적으로 구분
• 용도별로 개발, 운영, 테스트 환경을 구분해서 관리 가능
  (예) 개발팀은 CPU 100개 네임스페이스, 운영팀은 400개 네임스페이스 사용하면서 Pod나 서비스를 나눠서 관리할 수 있다.
  👉 네임스페이스별로 포드나 서비스를 나누면 클러스터 자원을 효율적으로 관리 가능

② Master (마스터)

• 클러스터의 중심 노드로 클러스터 전체를 제어
• 다음 3개의 주요 프로세스를 실행한다:
  1. kube-apiserver
  2. kube-controller-manager
  3. kube-scheduler

③ Node (노드)

• 실제 컨테이너가 동작하는 서버
• 각 노드에서는 아래의 주요 프로세스가 실행된다:
  1. kubelet
  2. kube-proxy

👉 Pod를 호스팅하고 클러스터에 컴퓨팅 파워 제공

④ Control Plane (컨트롤 플레인)

• 마스터와 노드의 kubelet으로 구성
• 클러스터를 제어하는 두뇌 역할 수행

⑤ Object (오브젝트)

• 쿠버네티스에서 관리하는 리소스의 추상화 개념
  예시) Pod, Service, Volume, Namespace 등

⑥ Controller (컨트롤러)

• 오브젝트를 지속적으로 관리하고 클러스터 상태를 조정하는 고수준 추상화
• 예시) ReplicaSet, Deployment, StatefulSet, DaemonSet, Job

⑦ Pod (파드)

• 컨테이너의 집합으로 가장 작은 배포 단위
• 하나 이상의 컨테이너를 포함하고, 이 컨테이너들은 네트워크와 볼륨을 공유
• Pod는 클러스터 내에서 실행되는 프로세스를 의미하며, 하나의 고유한 IP를 사용

⑧ Service (서비스)

• 논리적인 Pod 집합과 접근 정책을 정의한 추상화 개념
• Pod의 IP가 동적으로 바뀌어도, 클라이언트가 안정적으로 접근할 수 있도록 도와준다

---

그 외 네트워크 용어

용어	설명
Cluster IP	클러스터 내부에서 사용하는 내부 IP
External IP	외부에서 접근 가능한 IP
NodePort	노드에서 노출된 포트 번호
TargetPort	Pod 내에서 서비스가 노출되는 포트
Endpoints	Pod IP + TargetPort 조합 주소

---

Ⅲ 쿠버네티스의 핵심 컴포넌트  #클러스터_구조

쿠버네티스 아키텍처는 크게 컨트롤 플레인과 노드로 나뉜다는 것을 아까 Ⅰ에서 살펴보았다.

---

Ⅲ-1. 컨트롤 플레인 (마스터 노드)

Control Plane 클러스터를 관리하고, 상태를 지속적으로 유지시키는 제어부

①etcd, ②kube-apiserver, ③kube-controller-manager, ④kube-scheduler

1️⃣ etcd

• 클러스터 상태와 설정 데이터를 저장하는 분산 키-값 저장소
• 고가용성을 위해 보통 3개에서 5개 노드의 etcd 클러스터 구성

2️⃣ kube-apiserver

• 모든 API 요청의 진입점
• 요청을 검증하고 etcd에 업데이트
  → 클러스터 전체에 변경 사항을 반영하는 역할

3️⃣ kube-controller-manager

• 여러 컨트롤러를 통합 관리
• 주요 컨트롤러:
  • 노드 컨트롤러: 노드가 다운되면 대응
  • 레플리케이션 컨트롤러: 파드 수 유지
  • 엔드포인트 컨트롤러: 서비스와 파드 연결 관리
  • 서비스 어카운트 & 토큰 컨트롤러: 네임스페이스 기본 계정 및 API 접근 토큰 생성

4️⃣ kube-scheduler

• 스케줄링되지 않은 파드를 적절한 노드에 배치
• 노드의 가용 자원과 조건을 보고 결정

---

Ⅲ-2. 노드 서비스 데몬

• 노드는 Pod가 실제로 실행되는 공간이다.
• 노드 서비스 데몬은 노드 서버에서 실행되는 필수적인 쿠버네티스 프로세스이다. ①kubelet, ②kube-proxy

1️⃣ kubelet

• 노드에 존재하는 Pod를 관리하고 상태 정보를 Control Plane에 보고
• 주요 기능:
  • API 서버에서 명령 수신
  • Secret 다운로드
  • 볼륨 마운트
  • Pod 생성 및 실행
  • 상태 보고 및 감시

2️⃣ kube-proxy

• 네트워크 프록시 및 로드 밸런서 역할
• 서비스가 클러스터 내부와 외부에서 통신할 수 있도록 지원
• 클러스터 IP를 DNS나 환경변수를 통해 찾아서 서비스 요청을 Endpoints로 연결해준다.

---

Ⅳ 쿠버네티스 오브젝트(Object)  #클러스터_상태

Ⅳ-1. 개요

🧑🏻‍🏫 쿠버네티스 오브젝트란?

• 쿠버네티스 오브젝트는 클러스터 상태를 나타낸다.
• "컨테이너가 어디서 어떻게 동작하고 있는지", "어떤 리소스를 사용할 수 있는지", "재구동 정책, 업그레이드와 내고장성은 어떻게 되는지" 등을 정의하고 관리한다.

✍🏻오브젝트 명세(Spec)과 상태(Status)

• Spec: 사용자가 정의한 의도 상태 (설정값). 오브젝트의 특성 (설정정보)을 기술한 것.
• Status: 쿠버네티스 시스템이 보여주는 오브젝트의 실제 상태

Ⅳ-2. 오브젝트 관리 방법: ⓐ 명령어로 관리 ⓑ YAML 파일로 관리

ⓐ 명령어로 관리

예시    nginx 배포

# 예시 | Nginx 배포
kubectl create deployment nginx --image nginx

ⓑ YAML 파일로 관리

예시    nginx 배포

1) nginx 배포 yaml 파일 작성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

• minReadySeconds: 새로 생성된 파드가 준비됐다고 간주되기까지 대기 시간(초)
• selector.matchLabels: 배포할 파드 선택 기준
• containers: 실제로 실행될 컨테이너 정의

2) 적용하기

# dashboard UI를 사용하면 명령어를 직접 입력하지 않아도 된다!
kubectl apply -f nginx-deployment.yml

 

---

참고 자료

• 쿠버네티스 공식 컴포넌트 개념 문서
• etcd 클러스터 구성 가이드