[Kubernetes] Kubernetes 구조 및 기능과 역할

Kubernetes의 구조

쿠버네티스 객체 Overview ❘ https://inf.run/yW34

 

---

0. Kubernetes Cluster란?

여러 대의 서버(Node)를 묶어 하나의 통합된 시스템처럼 동작하게 만든 집합

Kubernetes는 클러스터를 통해 컨테이너를 자동으로 관리함

 

✅ Kubernetes Cluster의 구성 요소

구성 요소	설명
Master Node	클러스터 전체를 제어하고 관리하는 중심 노드
Worker Node	실제로 애플리케이션(Pod)을 실행하는 노드
네트워크 & 스토리지	노드 간 통신과 데이터 공유를 위한 인프라

 

---

1. Physical Machine이란?

쿠버네티스(Kubernetes) 클러스터는 여러 대의 물리적인 서버 위에서 동작한다.
이러한 물리 서버를 Kubernetes에 등록하면 "Node"로 인식된다.

 

*Node : kubelet이 설치되고 클러스터에 등록된 물리 머신

*kubelet : Node에서 실행되는 핵심 에이전트 / Pod를 실행하고 상태를 체크하는 역할

 

✅ 쿠버네티스에서의 Physical Machine 구성

쿠버네티스 클러스터는 보통 두 가지 유형의 노드로 나뉜다.

종류	설명	컴포넌트
Master Node	클러스터를 제어하고 관리하는 중앙 관리자 실제로 컨테이너를 실행하진 않는다.	kube-apiserver: 쿠버네티스의 모든 요청을 받는 진입점 controller-manager: 컨트롤러 동작 담당 (예: Pod 복구) scheduler: 새로 생성된 Pod를 어떤 노드에 배치할지 결정 etcd: 클러스터 상태를 저장하는 Key-Value 저장소
Worker Node	실제로 컨테이너(Pod)를 실행하는 서버	kubelet: 각 노드에서 Pod 상태를 관리하는 에이전트 kube-proxy: 네트워크 라우팅 담당 container runtime: 실제로 컨테이너를 실행하는 엔진 (예: Docker, container

 

---

2. Namespace란?

Kubernetes 클러스터 내부를 논리적으로 분리할 수 있는 공간 단위

 

- 여러 팀, 환경(개발/운영 등), 서비스를 하나의 클러스터에서 독립적으로 운영할 수 있게 도와줌
- 리소스 제한, 보안 분리, 네트워크 격리 등을 위한 기본 단위로 활용됨

 

✅ Namespace의 특징

기능	설명
리소스 격리	Pod, Service, ConfigMap 등은 기본적으로 네임스페이스 내에서만 접근 가능 서로 다른 네임스페이스의 Pod는 기본적으로 직접 통신 불가 같은 이름의 리소스(service, configmap)도 서로 다른 네임스페이스에서 중복 생성 가능 컨테이너 내부의 데이터는 휘발성이기 때문에, 공유가 필요하면 Volume을 통해 저장
리소스 제한	ResourceQuota나 LimitRange를 통해 네임스페이스 단위로 자원 제한 가능 ResourceQuota: 네임스페이스 전체에 적용되는 자원 사용 한계 (예: 총 CPU 2개, 메모리 4GiB) LimitRange: 네임스페이스 내 개별 Pod/Container에 적용되는 기본/최대 리소스 제한
서비스 구분	dev, staging, prod 등 환경별로 나누어 운영 가능 dev 네임스페이스: 개발 환경용 Pod, Service 구성 prod 네임스페이스: 실제 운영 환경용 Pod 구성 (리소스 제한 강하게 설정) team-a, team-b: 팀별 네임스페이스로 분리 운영, 충돌 없이 리소스 사용 가능
기본 네임스페이스	default, kube-system, kube-public 등은 기본 제공됨 default: 사용자가 아무 네임스페이스도 지정하지 않았을 때 기본으로 사용됨 kube-system: Kubernetes 내부에서 사용하는 리소스(Pod, Controller 등)가 배치되는 영역 kube-public: 모든 사용자가 접근 가능한 공개 네임스페이스 (일반적으로 거의 사용 안 함)

*ConfigMap: 애플리케이션의 일반 설정값을 저장하고 Pod에 주입하는 Kubernetes 리소스

*Secret: 비밀번호, 토큰 등 민감한 정보를 안전하게 저장하고 Pod에 주입하는 Kubernetes 리소스

---

3. Pod란?

Kubernetes에서 가장 작은 배포 단위이며, 하나 이상의 컨테이너를 담는 논리적인 실행 단위

 

 - 같은 Pod 안에 있는 컨테이너들은 같은 IP 주소, 포트, Volume을 공유

 - 보통은 컨테이너 하나만 들어가지만, 밀접하게 연관된 컨테이너(예: 앱 + 로그 수집기)를 함께 배치할 수도 있음

 - 하나의 Pod 안에 있는 컨테이너는 함께 시작되고 함께 종료

 

✅ Pod의 특징

기능	설명
단일 IP 공간	Pod 안의 컨테이너들은 동일한 IP를 사용하여 통신함
단일 네트워크 단위	Pod는 하나의 네트워크 엔드포인트로 외부와 통신함
공유 스토리지	Pod 내의 컨테이너들은 공유된 Volume에 접근 가능
데이터 휘발성	Pod가 삭제되면 내부 데이터는 사라짐 → Volume 사용 필요
운명 공동체	컨테이너 중 하나라도 문제가 생기면 Pod 전체가 재시작됨

 

 

---

4. Service란?

Kubernetes에서 Pod에 안정적으로 접근하기 위한 고정된 엔드포인트 역할을 한다.

Pod는 죽었다가 다시 생성되면 IP가 바뀐다.
    - 사용자가 Pod에 직접 접근하면 → IP 변경으로 인해 통신 끊김 발생 가능
    - 여러 Pod가 같은 서비스를 제공하는 경우 → 하나하나 접근하기 어려움

→ Pod 앞단에 고정된 네트워크 주소인 Service가 필요하다.

 

✅ Service의 기능

기능	설명
고정 IP 제공	Pod가 재시작되어도, Service IP는 변하지 않음
로드밸런싱	동일한 Label을 가진 여러 Pod로 트래픽 자동 분산 (Round-Robin 방식)
디스커버리	DNS를 통해 my-service.default.svc.cluster.local 형식으로 접근 가능
Pod 선택	Label Selector를 사용해 Service가 연결할 Pod를 선택함

 

---

5. Controller란?

Kubernetes에서 리소스(Pod 등)의 상태를 자동으로 유지, 관리해주는 역할을 한다.
사용자가 정의한 "원하는 상태(Desired State)"를 지속적으로 감시하고, 실제 상태와 다르면 자동으로 조정한다.

쿠버네티스 Controller 역할 ❘ https://inf.run/yW34

✅ 대표적인 Controller 종류

컨트롤러	설명
ReplicaSet	지정된 개수만큼 Pod를 항상 유지함. Pod가 죽으면 자동으로 새로 생성함. 단독으로 사용하기보다는 Deployment 내부에서 동작하는 경우가 많음.
Deployment	애플리케이션의 버전 관리, 롤링 업데이트, 스케일링을 담당. 내부적으로 ReplicaSet을 사용하며, 실무에서 가장 자주 쓰이는 컨트롤러.
StatefulSet	각 Pod에 고유한 이름, 네트워크 주소, Volume을 부여하여 관리. DB, Kafka, Elasticsearch처럼 상태를 가지는 서비스에 사용.
DaemonSet	클러스터의 모든 노드에 1개씩 Pod을 배포. 노드 모니터링, 로그 수집 등 Node 단위로 실행되는 데몬 역할에 사용.
Job / CronJob	일정 작업을 한 번만 실행(Job) 하거나, 주기적으로 실행(CronJob) 함. 예: 백업, 배치 처리, 보고서 생성 작업 등 일회성 또는 반복 작업에 사용.