쿠버네티스(Kubernetes, k8s)란
컨테이너화된 애플리케이션을 대규모로 운영하기 위한 컨테이너 오케스트레이션 도구이다.
주로 Docker와 같은 컨테이너 기술과 결합하여 컨테이너 관리 플랫폼으로 사용된다.
즉, 컨테이너를 관리하며 대규모 서비스를 운영할 때 유용한 기술이다.
쿠버네티스는 클러스터 기반 구조로 되어 있으며, 클러스터는 컨테이너화된 애플리케이션을 실행하기 위한 컴퓨터(노드)의 집합이다.
주요 구성 요소
클러스터
- 클러스터는 쿠버네티스의 전체 환경으로,
모든 노드(Node), 쿠버네티스 API 서버, 기타 관련 구성 요소를 포함한다. - 위 그림의 한 단위가 하나의 클러스터를 의미한다.
- 쿠버네티스 클러스터는 크게 마스터 노드와 워커 노드로 구성된다.
마스터 노드
클러스터 관리, API 서버 운영, 스케줄링 등의 역할을 담당한다.
| 구성 요소 | 역할 |
|---|---|
| kube-apiserver | 클러스터의 중앙 집중식 관리 시스템으로, 사용자·내부 구성 요소·외부 도구 간 통신의 진입점 역할 수행. 즉, 개발자의 명령은 모두 쿠버네티스 API 서버로 전달된다. |
| kube-scheduler | 새로 생성된 파드를 감지하고, 해당 파드를 실행할 최적의 노드를 선택한다. |
| etcd | 클러스터 상태 저장소로, 모든 클러스터 상태값(ConfigMap 등을 포함)을 key-value 형태로 저장하는 고가용성 분산 데이터베이스. |
| kube-controller-manager | 상태 유지를 위한 자동화를 담당하며, Deployment·ReplicaSet 등의 상태를 감시 및 조정한다. |
참고: 마스터 노드의 안정성과 고가용성은 매우 중요하다.
AWS EKS는 클러스터 생성 시 마스터 노드의 생성 및 관리를 자동으로 지원한다.
워커 노드
워커 노드는 애플리케이션의 실제 실행을 담당한다.
각 워커 노드에는 kubelet이라는 에이전트가 실행되어 마스터 노드와 통신한다.
(AWS 기준으로는 EC2 인스턴스에서 워커 노드가 실행되며, 해당 워커 노드에서 Service Pod가 배포된다.)
| 구성 요소 | 역할 |
|---|---|
| kubelet | API 서버와 통신하며 파드의 시작, 중지, 상태 관리 등의 작업을 수행. 파드의 상태를 주기적으로 API 서버에 보고한다. |
| kube-proxy | 네트워크 프록시 및 로드밸런서로서, 파드 간 통신 및 외부에서 파드로의 접근을 가능하게 한다. 네트워크 규칙을 설정하여 트래픽을 올바르게 포워딩한다. |
쿠버네티스 핵심 요소⭐⭐⭐
| 요소 | 설명 |
|---|---|
| Namespace | 클러스터 내 리소스를 논리적으로 분리하는 단위. (개발, 운영, 테스트 환경 등을 구분 가능) |
| Pod | 쿠버네티스에서 배포 가능한 가장 작은 단위. 일반적으로 하나의 컨테이너를 포함하지만, 여러 컨테이너를 함께 배포할 수도 있다. |
| Service | 클러스터 내 실행 중인 파드에 대한 라우팅 및 로드밸런싱을 제공하는 리소스. 기본적으로 내부 통신용(ClusterIP)으로 동작하지만, LoadBalancer 타입 등을 통해 외부 노출도 가능하다. |
| Ingress | 클러스터 외부에서 내부 서비스로 HTTP/HTTPS 트래픽을 라우팅하는 역할. 도메인(Host) 기반 라우팅 규칙 설정이 가능하다. |
| ReplicaSet | 지정된 수의 파드 복제본이 항상 실행되도록 보장하는 선언적 리소스. |
| Deployment | ReplicaSet을 관리하며, 롤링 업데이트·롤백·오토스케일 등 고급 배포 기능을 제공한다. |
| ConfigMap / Secret | ConfigMap은 일반 설정 데이터를 Key-Value 형태로 저장하며, Secret은 비밀번호·인증서 등 민감 정보를 안전하게 관리한다. |
Deployment 상세 설명
Deployment는 ReplicaSet과 유사하지만, 롤링 업데이트·롤백·오토스케일링 등 고급 배포 기능을 제공한다.
| 기능 | 설명 |
|---|---|
| 롤링 업데이트 | 기존 Pod(As-is)를 유지하면서 새로운 Pod(To-be)를 추가로 생성. Service가 두 Pod로 트래픽을 분산 라우팅하여 무중단 배포를 실현한다. (기존 방식의 문제점을 해결하는 주요 무중단 배포 기법) |
| 롤백 | To-be Pod에 문제가 발생하면 히스토리 기반으로 이전 버전(As-is)으로 복원 가능. (문제 원인 분석 후 이미지 수정이 최종 목표) |
| 오토스케일링 | 최소 2대, 최대 5대 등으로 설정 시, 부하 발생에 따라 자동으로 Pod 수를 증설/축소한다. |
핵심: Deployment는 단순 Pod 유지(ReplicaSet)에서 한발 더 나아가 안전한 배포와 확장성을 보장한다.
주요 특징 및 장점 정리
| 기능 | 설명 |
|---|---|
| 자동 복구(Self-healing) | 컨테이너를 지속적으로 모니터링하며, 종료된 컨테이너를 자동으로 재시작한다. |
| 서비스 디스커버리 및 로드밸런싱 | 내부 파드 간 네트워크 라우팅과 요청 분산을 자동으로 처리한다. |
| 네임스페이스 기반 멀티 환경 지원 | 개발·운영·테스트 환경을 논리적으로 분리할 수 있어 다중 환경 운영이 용이하다. |
| 오토 스케일링 (Auto Scaling) | 파드의 자원 사용량 기준으로 Pod를 자동 증감(HPA)시키고, 노드 자원 부족 시 인스턴스를 자동 확장(Cluster Autoscaler)한다. |
| 자동 롤아웃/롤백 | 무중단 배포 및 문제 발생 시 손쉬운 이전 상태 복원이 가능하다. |
| 자원 제한 설정 | 파드별 CPU, 메모리 등의 자원을 제한하여 안정적인 운영이 가능하다. |
Eazy하게