해당 포스트는 인프런 강의를 수강한 뒤 개인적으로 요약·정리한 블로그 글입니다.
관련 용어 발음 정리
| 영어 약어/단어 | 정의 | 발음 예시 |
|---|---|---|
| master | 클러스터 전체를 관리하는 제어 노드(Control Plane) | 마스터 |
| node | 애플리케이션이 실제로 돌아가는 워커 머신 | 노드 |
| k8s | Kubernetes의 축약 표현 (k + 8글자 + s) | 쿠버네티스 |
| kubectl | Kubernetes를 제어하기 위한 CLI(Command Line Interface) | 큐브 컨트롤, 큐브 시티엘 |
| etcd | Kubernetes의 분산 키-값 저장소(데이터베이스) | 엣지디, 이티시디 |
| Pod | Kubernetes에서 가장 작은 배포 단위(컨테이너 묶음) | 파드, 팟 |
| Service | Pod들의 네트워크 접근점을 추상화한 리소스 | 서비스 |
| Ingress | 클러스터 외부에서 들어오는 HTTP/HTTPS 트래픽을 라우팅 | 인그레스 |
| Namespace | 클러스터를 가상으로 분리하는 논리적 공간 | 네임스페이스 |
| ConfigMap | 설정(환경변수·명령줄 인자 등)을 저장하는 리소스 | 컨피그맵 |
| Secret | 암호·토큰·인증서 같은 민감 정보를 저장하는 리소스 | 시크릿 |
| PV / PVC | PersistentVolume / PersistentVolumeClaim (영구 스토리지) | 피브이 / 피브이시 |
| Helm | Kubernetes 패키지 매니저 (Charts 사용) | 헬름 |
| Istio | 서비스 메시(Service Mesh) 구현체 | 이스티오 |
| Knative | Kubernetes 위에서 서버리스(Function) 실행을 돕는 플랫폼 | 케이 네이티브 |
1. 쿠버네티스란 무엇인가?
-
왜 필요한가?
- 전통적 서버 운영: VM 혹은 물리 서버에 애플리케이션 직접 배포 → 수동 스케일링·업데이트
- 문제점: 사람 손이 많이 가고, 설정이 복잡, 장애 대응이 느림
-
쿠버네티스의 해결책
- 자동화: 컨테이너화된 애플리케이션 배포·스케일·롤백을 자동 처리
- 추상화: Pod·Service 같은 논리 단위로 묶어 인프라 세부사항 숨김
- 확장성: 자동 오토스케일(AutoScaling) 지원
- 고가용성: 노드 장애 시 자동 복구
-
핵심 컴포넌트 구조
graph TD A[Control Plane] -->|API 요청| B[kube-apiserver] B --> C[kube-scheduler] B --> D[kube-controller-manager] B --> E[etcd] F[Worker Node] -->|Pod 관리| G[kubelet] F -->|네트워크| H[kube-proxy] G --> Pod[Pod]-
Control Plane
kube-apiserver: API 요청 처리etcd: 클러스터 상태 저장kube-scheduler: Pod 배치 결정kube-controller-manager: 레플리카 관리 등 컨트롤러 실행
-
Worker Node
kubelet: Control Plane과 통신하며 Pod 실행kube-proxy: 네트워크 룰 설정- 컨테이너 런타임(Docker, containerd)
-
-
왜 Kubernetes인가?
- Google Borg/Omega 경험 기반 설계
- CNCF 졸업 프로젝트로 활발한 커뮤니티·생태계
- AWS·GCP·Azure·온프레미스 모두 동일한 운용 경험 제공
2. Cloud Native란?
-
정의
클라우드 장점을 최대한 활용하는 애플리케이션 설계·구축 패러다임- 컨테이너화, 마이크로서비스, 선언적 인프라(IaC), CI/CD 등 포함
-
과거 vs 현재
- 과거: 모놀리식→수동 프로비전→장애 시 수동 복구
- 현재: 수십~수백 개 컨테이너 동적 운용→자동 스케일·롤백→일관된 환경
-
구성 요소
- 컨테이너: 애플리케이션 + 의존성 경량 패키지
- 마이크로서비스: 기능별 독립 서비스
- 서비스 메시: Istio 등으로 트래픽·보안·모니터링
- DevOps: CI/CD로 배포 자동화
- IaC: Terraform·Helm·GitOps
3. 주요 리소스 관계
Deployment→ReplicaSet→PodService→ Pod 그룹에 IP·DNS 제공Ingress→ Service에 외부 트래픽 라우팅ConfigMap/Secret→ Pod에 설정·민감정보 주입PVC→ Pod에 영구 볼륨 마운트
4. 쿠버네티스 배포(Deployment) 개념 및 아키텍처
4.1 Deployment란?
- Deployment: 원하는 Pod 사양·개수(desired state)를 선언 → ReplicaSet 생성·관리
- 지원 기능: 롤링 업데이트, 롤백, 자동 스케일링
4.2 주요 구성 요소
- ReplicaSet: Pod 복제본(desired number) 유지
- Rolling Update: 순차적 교체로 무중단 배포
- Rollback: 문제 발생 시 이전 Revision으로 복귀
4.3 배포 흐름 단계별 설명
- 명세 제출:
kubectl apply -f deployment.yaml - API Server 저장: Deployment 오브젝트(etcd)에 기록
- 컨트롤러 동작: Deployment 컨트롤러가 ReplicaSet 생성/업데이트
- 스케줄링 & 실행: kube-scheduler→kubelet→컨테이너 기동
- 상태 조정: Controller Manager가 desired vs actual 비교 후 조정
4.4 배포 전략 비교
| 전략 | 설명 | 사용 사례 |
|---|---|---|
| Rolling Update | 순차 교체로 무중단 업그레이드 | 서비스 다운타임 최소화 필요 시 |
| Recreate | 기존 파드 전부 삭제 후 일괄 생성 | 짧은 다운타임 허용 가능 시 |
| Blue/Green | Blue/Green 환경 동시 유지 후 트래픽 전환 | 안전한 롤백·검증 환경 분리 시 |
| Canary Release | 일부 사용자에만 새 버전 배포 후 확대 | 리스크 최소화, 기능 실험 단계에서 |
✨ 이 글에서 쿠버네티스의 핵심 개념과 아키텍처, 배포 전략까지 한눈에 살펴보았습니다.
다음 포스트에서는 실제 deployment.yaml 예제를 작성하고, Helm Chart를 이용해 배포를 자동화하는 과정을 단계별로 다뤄볼게요. 🚀
Frontend Developer