개념 이해 on Advanced Beginner

아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 단지 운영 본부#

Kubernetes 아키텍처를 아파트 단지 운영 본부에 비유하면 이해하기 쉽습니다:

아파트 단지 비유	Kubernetes	역할
관리사무소	Control Plane	단지 전체 운영 결정 및 지휘
관리소장	API Server	모든 요청의 창구, 인증/인가 담당
입주민 대장	etcd	모든 세대 정보 기록 및 보관
입주 배정 담당자	Scheduler	새 입주자를 어느 동에 배치할지 결정
시설 관리팀	Controller Manager	세대 수 유지, 시설 상태 점검
각 동 건물	Worker Node	실제 세대가 있는 공간
동 관리인	Kubelet	해당 동의 세대 관리, 상태 보고
동 안내 데스크	Kube-proxy	방문자를 올바른 세대로 안내
이삿짐 업체	Container Runtime	실제 이사(컨테이너 실행) 담당

이처럼 Control Plane은 “관리사무소에서 단지 전체를 운영"하고, Worker Node는 “각 동에서 실제 입주민을 수용"합니다.

Pod

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 한 세대#

Pod를 아파트 한 세대에 비유하면 이해하기 쉽습니다:

아파트 세대 비유	Kubernetes Pod	역할
아파트 한 세대	Pod	최소 거주/배포 단위
세대 내 거주자들	Containers	함께 살며 자원 공유
세대 현관문	Pod IP	외부에서 접근하는 주소
거실/주방 공유	Network 공유	같은 Pod 내 localhost 통신
공용 창고	Volume	거주자들이 함께 사용하는 저장 공간
각자 방	Container 격리	개별 파일시스템, 프로세스
이사 시 함께 이동	공동 생명주기	Pod 삭제 시 모든 컨테이너 종료
원룸 vs 투룸	단일/멀티 컨테이너	대부분 원룸(1 컨테이너) 권장

이처럼 Pod는 “한 세대에 여러 사람이 함께 살면서 주방과 거실을 공유"하는 것과 같습니다.

Deployment

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 입주민 관리 시스템#

Deployment를 아파트 입주민 관리 시스템에 비유하면 이해하기 쉽습니다:

아파트 관리 비유	Kubernetes Deployment	역할
입주민 관리 시스템	Deployment	세대(Pod) 배치와 업데이트 총괄
“항상 3세대 유지” 규칙	replicas: 3	원하는 세대 수 선언
세대 목록 관리대장	ReplicaSet	실제 세대 수 유지 담당
순차적 이사	Rolling Update	한 세대씩 새 버전으로 교체
이전 주소로 복귀	Rollback	문제 시 이전 상태로 되돌리기
공실 발생 시 자동 입주	자동 복구	Pod 장애 시 자동 재생성
입주 규격 템플릿	Pod Template	생성할 세대의 표준 사양
과거 입주 기록 보관	revisionHistory	롤백용 이전 버전 유지

이처럼 Deployment는 “관리사무소가 항상 일정 수의 세대를 유지하고, 리모델링 시 순차적으로 진행"하는 것과 같습니다.

Service

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 인터폰/안내 시스템#

Service를 아파트 인터폰 시스템에 비유하면 이해하기 쉽습니다:

아파트 인터폰 비유	Kubernetes Service	역할
동 현관 인터폰	Service	고정된 접근점으로 세대 연결
인터폰 번호 (101동)	ClusterIP	변하지 않는 내부 주소
세대 호수 변경되어도 인터폰 동일	Pod IP 변경 무관	Service IP는 고정
같은 세대 여러 명에게 연결	Load Balancing	여러 Pod에 트래픽 분산
내부 인터폰	ClusterIP	단지 내부에서만 통화 가능
외부 전화 연결	NodePort	외부에서 특정 포트로 연결
대표 전화번호	LoadBalancer	외부 고정 IP로 연결
입주민 명부	Endpoints	Service가 관리하는 Pod IP 목록
“101동 김철수네”	DNS	이름으로 Service 접근

이처럼 Service는 “세대 번호가 바뀌어도 인터폰 번호는 그대로여서 항상 연결 가능"한 것과 같습니다.

ConfigMap과 Secret

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 게시판과 우편함#

ConfigMap과 Secret을 아파트 게시판과 우편함에 비유하면 이해하기 쉽습니다:

아파트 비유	Kubernetes	역할
로비 게시판	ConfigMap	모든 입주민이 볼 수 있는 공지사항
개인 우편함 (비밀번호)	Secret	민감한 정보 보관
게시판 내용	data (평문)	일반 설정 값
우편함 내용	data (Base64)	인코딩된 민감 정보
게시판 읽고 메모	환경 변수 주입	설정을 Pod에 전달
게시판 사진 찍어가기	볼륨 마운트	파일로 설정 전달
게시판 내용 변경	ConfigMap 업데이트	설정 변경 (재시작 필요할 수도)
DB 접속 정보	Secret	비밀번호, API 키 등
Wi-Fi 비밀번호 공유	ConfigMap	공개해도 되는 설정

이처럼 ConfigMap은 “게시판에 붙여 모두가 보는 공지"이고, Secret은 “개인 우편함에 넣어 본인만 확인하는 정보"입니다.

Volume과 스토리지

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 수납공간과 창고#

Volume과 스토리지를 아파트 수납공간에 비유하면 이해하기 쉽습니다:

아파트 수납 비유	Kubernetes	역할
세대 내 붙박이장	emptyDir	Pod와 함께 생성/삭제되는 임시 공간
단지 공용 창고	PersistentVolume (PV)	이사해도 유지되는 외부 저장소
창고 사용 신청서	PersistentVolumeClaim (PVC)	필요한 용량과 조건 요청
창고 자동 배정 시스템	StorageClass	요청 시 자동으로 창고 할당
세대 간 물건 공유	Volume Mount	컨테이너 간 데이터 공유
개인만 사용	ReadWriteOnce (RWO)	단일 노드에서만 읽기/쓰기
여러 세대가 읽기만	ReadOnlyMany (ROX)	여러 노드에서 읽기 전용
여러 세대가 함께 사용	ReadWriteMany (RWX)	여러 노드에서 읽기/쓰기
퇴거 시 창고 처리	Reclaim Policy	Retain(유지), Delete(삭제)

이처럼 emptyDir은 “이사하면 사라지는 붙박이장"이고, PV/PVC는 “이사해도 물건이 남아있는 별도 창고"입니다.

네트워킹

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 단지 출입 시스템#

Kubernetes 네트워킹을 아파트 단지 출입 시스템에 비유하면 이해하기 쉽습니다:

아파트 출입 비유	Kubernetes	역할
세대 간 방문	Pod-to-Pod 통신	같은 단지 내 자유로운 왕래
각 세대 고유 호수	Pod IP	고유한 네트워크 주소
동 현관 인터폰	Service	안정적인 접근점 제공
단지 정문/경비실	Ingress	외부 방문자 안내 및 통제
방문자 명부	Ingress Rules	도메인/경로별 라우팅 규칙
외부 전화 연결	NodePort	외부에서 특정 포트로 접근
대표 전화번호	LoadBalancer	외부 고정 IP 제공
출입 통제 규칙	NetworkPolicy	특정 세대 간 왕래 제한
VIP 전용 출입구	TLS Termination	HTTPS 암호화 처리

이처럼 Ingress는 “단지 정문에서 방문자를 확인하고 올바른 동/호수로 안내"하는 것과 같습니다.

리소스 관리

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 전기/수도 배정#

리소스 관리를 아파트 전기/수도 배정에 비유하면 이해하기 쉽습니다:

아파트 공과금 비유	Kubernetes	역할
기본 전기 용량	requests	최소 보장 리소스
최대 전기 용량	limits	사용 가능한 최대치
전기 초과 시 차단기	CPU 스로틀링	한계 초과 시 성능 저하
수도 초과 시 단수	OOMKilled	메모리 초과 시 강제 종료
프리미엄 세대	Guaranteed QoS	가장 마지막에 퇴거 요청
일반 세대	Burstable QoS	중간 우선순위
관리비 미납 세대	BestEffort QoS	가장 먼저 퇴거 요청
단지 전체 전기 한도	ResourceQuota	네임스페이스 총량 제한
세대별 기본 배정량	LimitRange	기본 리소스 설정

이처럼 requests는 “항상 보장받는 기본 전기량"이고, limits는 “절대 넘을 수 없는 최대 사용량"입니다.

스케일링

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 세대 수 조절#

스케일링을 아파트 세대 수 조절에 비유하면 이해하기 쉽습니다:

아파트 관리 비유	Kubernetes	역할
입주 수요에 따라 세대 수 조절	스케일링	트래픽에 따른 Pod 수 조정
세대 수 늘리기	Horizontal Scaling (HPA)	Pod 개수 증가
세대 크기 늘리기	Vertical Scaling (VPA)	Pod 리소스 증가
입주율 50% 초과 시 증축	averageUtilization	스케일링 기준 메트릭
최소 3세대 유지	minReplicas	최소 Pod 수
최대 10세대까지	maxReplicas	최대 Pod 수
증축은 빠르게, 감축은 천천히	scaleUp/scaleDown 정책	급격한 변화 방지
전기 사용량 측정기	Metrics Server	리소스 사용량 모니터링
성수기 자동 증축	자동 스케일링	부하에 따른 자동 조절

이처럼 HPA는 “입주 수요가 늘면 세대 수를 늘리고, 줄면 다시 줄이는” 자동 관리 시스템입니다.

헬스 체크

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 안전 점검#

헬스 체크를 아파트 안전 점검에 비유하면 이해하기 쉽습니다:

아파트 점검 비유	Kubernetes	역할
정기 안전 점검	Health Check	애플리케이션 상태 확인
“살아 계신가요?” 확인	Liveness Probe	컨테이너 생존 확인
“손님 받을 준비 됐나요?”	Readiness Probe	트래픽 수신 준비 확인
“이사 완료됐나요?”	Startup Probe	시작 완료 여부 확인
응답 없으면 119 호출	Liveness 실패 → 재시작	컨테이너 재시작
바쁘면 손님 안 받음	Readiness 실패 → 트래픽 제외	Service에서 제외
이사 중이면 기다림	Startup 진행 중	다른 Probe 비활성화
초인종 눌러서 확인	HTTP Probe	HTTP 엔드포인트 체크
전화해서 확인	TCP Probe	포트 연결 체크
가스 점검 (직접 확인)	Exec Probe	명령어 실행 체크

이처럼 Probe는 “관리인이 주기적으로 세대를 방문하여 상태를 확인"하는 것과 같습니다.

Namespace

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

전체 비유: 아파트 단지의 동 구분#

Namespace를 아파트 단지의 동 구분에 비유하면 이해하기 쉽습니다:

아파트 단지 비유	Kubernetes Namespace	역할
101동, 102동 구분	Namespace	리소스를 논리적으로 분리
동별 관리비 예산	ResourceQuota	네임스페이스별 리소스 총량 제한
세대당 전기/수도 한도	LimitRange	개별 Pod/컨테이너 리소스 기본값
관리사무소 전용 구역	kube-system	시스템 구성요소 전용 공간
공용 게시판 구역	kube-public	모든 사용자 접근 가능 공간
동별 출입 카드	RBAC + Namespace	접근 권한 분리

이처럼 Namespace는 “하나의 아파트 단지에서 동별로 관리 영역을 나누는 것"과 같습니다.

StatefulSet

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

전체 비유: 지정석이 있는 식당#

StatefulSet을 지정석이 있는 식당에 비유하면 이해하기 쉽습니다:

식당 비유	Kubernetes StatefulSet	역할
지정석 번호 (1번, 2번, 3번)	Pod 이름 (app-0, app-1, app-2)	안정적이고 고유한 식별자
손님 전용 사물함	PersistentVolumeClaim	Pod마다 전용 영구 스토리지
순서대로 착석/퇴석	순차적 생성/삭제	0번부터 생성, 역순으로 삭제
예약 명패	안정적 네트워크 ID	Pod 재시작 후에도 같은 호스트명 유지
자유석 식당	Deployment	아무 자리나 앉고, 바뀔 수 있음

이처럼 StatefulSet은 “지정석과 전용 사물함이 있어서 항상 같은 자리, 같은 물건을 사용하는 것"과 같습니다.

RBAC

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

전체 비유: 건물 출입 카드 시스템#

RBAC을 건물 출입 카드 시스템에 비유하면 이해하기 쉽습니다:

건물 출입 비유	Kubernetes RBAC	역할
출입 권한 세트 (3층 서버실 접근 가능)	Role	특정 Namespace 내 허용 작업 정의
전 건물 마스터 권한	ClusterRole	클러스터 전체 허용 작업 정의
사원증에 권한 부여	RoleBinding	사용자에게 Role 할당
전 지점 출입 권한 부여	ClusterRoleBinding	사용자에게 ClusterRole 할당
사원증	ServiceAccount	Pod가 사용하는 인증 주체
“꼭 필요한 구역만 출입” 원칙	최소 권한 원칙	필요한 권한만 부여

이처럼 RBAC은 “누가 어디에서 무엇을 할 수 있는지"를 체계적으로 관리하는 것과 같습니다.

Job과 CronJob

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

전체 비유: 아르바이트와 정기 청소#

Job과 CronJob을 아르바이트와 정기 청소에 비유하면 이해하기 쉽습니다:

비유	Kubernetes	역할
일회성 아르바이트	Job	한 번 실행하고 끝나는 작업
정기 청소 스케줄	CronJob	주기적으로 반복 실행되는 작업
아르바이트생 3명 고용	completions: 3	성공 완료해야 할 횟수
동시에 2명 투입	parallelism: 2	동시에 실행할 Pod 수
최대 재시도 횟수	backoffLimit	실패 시 재시도 상한
작업 마감 시한	activeDeadlineSeconds	전체 작업 제한 시간

이처럼 Job은 “정해진 일을 완료하면 끝나는 작업"이고, CronJob은 “정해진 시간에 반복 실행되는 예약 작업"입니다.

NetworkPolicy

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

전체 비유: 아파트 단지 방화벽#

NetworkPolicy를 아파트 단지의 출입 통제 시스템에 비유하면 이해하기 쉽습니다:

아파트 단지 비유	Kubernetes NetworkPolicy	역할
동별 출입 통제 규칙	NetworkPolicy	Pod 간 트래픽 허용/차단 정의
“101동 주민만 출입 허용”	podSelector	정책 적용 대상 Pod 선택
“배달원은 로비까지만”	Ingress 규칙	들어오는 트래픽 제어
“택배 발송은 경비실 경유”	Egress 규칙	나가는 트래픽 제어
경비 시스템 (CCTV, 카드키)	CNI 플러그인	정책을 실제로 적용하는 네트워크 엔진
규칙 없으면 자유 출입	기본 Allow All	NetworkPolicy 미설정 시 모든 트래픽 허용

이처럼 NetworkPolicy는 “어떤 Pod가 어떤 Pod와 통신할 수 있는지"를 제어하는 방화벽 규칙과 같습니다.