컨테이너와 쿠버네티스 입문 정리
목차
- 컨테이너란?
- 도커란?
- 쿠버네티스란?
- 쿠버네티스 핵심 오브젝트
- 쿠버네티스 단점
- AWS EKS 실습 순서
1. 컨테이너란?
컨테이너(Container)는 애플리케이션과 그 실행에 필요한 모든 것(코드, 라이브러리, 설정 등)을 하나로 묶은 가상화 패키지다.
해상 운송의 컨테이너처럼, 안에 무엇이 들었든 규격화된 박스에 담으면 어디서든 동일하게 동작한다. 개발 환경에서 잘 되던 앱이 서버에 올리면 안 되는 문제를 해결하는 것이 핵심 목적이다.
컨테이너 vs 가상 머신(VM)
| 구분 | 컨테이너 | 가상 머신 |
|---|---|---|
| 구조 | OS 커널 공유 | 독립된 게스트 OS 필요 |
| 무게 | 가벼움 (MB 단위) | 무거움 (GB 단위) |
| 속도 | 초 단위 실행 | 부팅에 수 분 소요 |
| 효율성 | 리소스 효율적 | 리소스 낭비 큼 |
핵심 장점
- 일관성: 어떤 환경으로 옮겨도 동일하게 작동
- 확장성: 동일한 컨테이너를 수십 개로 복제해 빠르게 대응
- 독립성: 각 컨테이너가 격리되어 한 곳에 문제가 생겨도 다른 서비스에 영향 없음
2. 도커란?
도커(Docker)는 컨테이너를 만들고 관리하는 가장 대표적인 플랫폼이다. 현대 소프트웨어 개발의 표준 배송 시스템이라고 볼 수 있다.
Build → Ship → Run
- Build: Dockerfile을 작성해 애플리케이션 실행에 필요한 모든 것을 담은 이미지(Image)를 만든다.
- Ship: 만들어진 이미지를 Docker Hub 같은 레지스트리에 올린다.
- Run: 어느 서버에서든 그 이미지를 내려받아 실행하면 컨테이너가 된다.
Dockerfile 핵심 명령어
| 명령어 | 역할 | 설명 |
|---|---|---|
FROM |
베이스 이미지 | 어떤 환경에서 시작할지 (예: python:3.9) |
COPY |
파일 복사 | 소스 코드를 이미지 내부로 복사 |
RUN |
명령어 실행 | 라이브러리 설치 등 빌드 시 실행할 명령 |
EXPOSE |
포트 설정 | 컨테이너가 사용할 네트워크 포트 명시 |
CMD |
실행 명령 | 컨테이너 시작 시 앱을 실행하는 명령 |
Dockerfile 작성 팁
.dockerignore로 불필요한 파일(node_modules, .git 등)을 제외해 이미지 크기를 줄인다.- 자주 바뀌지 않는 부분(라이브러리 설치)을 위쪽에 배치하면 빌드 속도가 빨라진다.
python:3.9-slim,node:alpine같은 경량 이미지를 사용하면 배포 성능이 좋다.
레지스트리(Registry)
레지스트리는 빌드된 이미지를 저장하고 공유하는 저장소다. Dockerfile이 레시피고 이미지가 완성된 요리라면, 레지스트리는 그것을 보관하는 냉동 창고와 같다.
- 퍼블릭: Docker Hub, Quay.io, GitHub Packages
- 프라이빗(클라우드): AWS ECR, Google GCR, Azure ACR
- 프라이빗(직접 구축): Harbor
3. 쿠버네티스란?
쿠버네티스(Kubernetes, K8s)는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 플랫폼이다. 구글이 15년 이상 내부에서 사용하던 시스템(Borg)을 기반으로 설계되었으며, 현재는 CNCF(Cloud Native Computing Foundation)에서 관리한다.
쿠버네티스가 필요한 이유
- 자동 복구(Self-healing): 컨테이너가 죽으면 자동으로 재시작
- 부하 분산(Load Balancing): 트래픽을 여러 컨테이너로 분산
- 자동 확장(Scaling): CPU/메모리 사용량에 따라 컨테이너 수를 자동 조절
- 롤아웃/롤백: 서비스 중단 없이 새 버전 배포, 문제 발생 시 즉시 이전 버전으로 복구
쿠버네티스 전체 구조
[컨트롤 플레인 (Master Node)]
- API Server: 모든 통신의 중앙 관문
- etcd: 클러스터 상태 정보를 키-값으로 저장하는 DB
- 스케줄러: 파드를 어느 노드에 배치할지 결정
- 컨트롤러 매니저: 현재 상태를 원하는 상태로 지속적으로 유지
[워커 노드 (Worker Node)]
- kubelet: 마스터의 명령을 받아 파드를 생성하고 감시
- kube-proxy: 네트워크 트래픽을 파드로 전달
- 컨테이너 런타임: 실제로 컨테이너를 실행하는 엔진 (Docker, containerd 등)온프레미스 vs 클라우드 매니지드(EKS, GKE 등)
| 구분 | 온프레미스 | 클라우드 매니지드 |
|---|---|---|
| 컨트롤 플레인 | 직접 구축 및 관리 | CSP가 관리 (고가용성 보장) |
| 업데이트 | 수동 (복잡하고 위험) | 자동화 또는 원클릭 지원 |
| 확장성 | 물리적 한계 존재 | 사실상 무한대 |
| 기술 난이도 | 매우 높음 | 상대적으로 낮음 |
4. 쿠버네티스 핵심 오브젝트
파드(Pod)
쿠버네티스의 최소 배포 단위. 하나 이상의 컨테이너를 담는 콩꼬투리 같은 개념이다. 같은 파드 안의 컨테이너들은 IP와 볼륨을 공유하며, 파드는 휘발성이라 죽으면 새로운 IP를 가진 새 파드가 생성된다.
레플리카셋(ReplicaSet)
지정된 개수의 파드를 항상 실행 상태로 유지하는 역할을 한다. 파드가 부족하면 생성하고, 너무 많으면 삭제한다. 직접 사용하기보다 Deployment를 통해 관리하는 것이 일반적이다.
디플로이먼트(Deployment)
애플리케이션의 배포와 업데이트를 총괄 관리하는 컨트롤러다. 레플리카셋을 내부적으로 활용하며 다음 기능을 제공한다.
- 파드 개수 유지 (Self-healing)
- 롤링 업데이트: 서비스 중단 없이 순차적으로 새 버전 교체
- 롤백: 문제 발생 시 이전 버전으로 즉시 복구
- 스케일링: 명령어 하나로 파드 수 조절
서비스(Service)
파드는 재시작될 때마다 IP가 바뀌기 때문에, 서비스는 파드들에게 고정된 진입점을 제공한다. 라벨 셀렉터(Label Selector)로 대상 파드를 자동으로 찾아 트래픽을 분산한다.
| 타입 | 특징 | 용도 |
|---|---|---|
| ClusterIP | 클러스터 내부에서만 접속 가능 (기본값) | 파드 간 통신 |
| NodePort | 모든 노드의 특정 포트를 열어 외부 접속 허용 | 테스트용 외부 노출 |
| LoadBalancer | 클라우드의 로드밸런서와 연결 | 실제 서비스 운영 |
| ExternalName | 외부 도메인 주소에 별칭 부여 | 외부 API 서버 연결 |
네임스페이스(Namespace)
하나의 클러스터를 여러 가상 공간으로 나누는 개념이다. 팀/프로젝트별 분리, 개발/운영 환경 분리, 자원 할당 제한, 접근 권한 분리 등에 활용한다.
기본 제공 네임스페이스는 default, kube-system, kube-public, kube-node-lease가 있다.
오브젝트 관계 정리
컨테이너 : 앱이 실행되는 최소 패키지
파드 : 컨테이너를 감싸는 배포 단위 (IP 할당)
레플리카셋 : 파드를 몇 개 유지할지 감시
디플로이먼트: 파드를 업데이트하고 롤백하는 총괄 관리자
서비스 : 파드에 고정 접근 주소를 제공
네임스페이스: 클러스터를 논리적으로 분리하는 공간
노드 : 파드들이 실제로 돌아가는 서버 컴퓨터5. 쿠버네티스 단점
가파른 학습 곡선: Pod, Service, Deployment 외에도 Ingress, CNI, CSI, RBAC, Helm 등 익혀야 할 개념이 방대하다. 모든 설정을 YAML 파일로 관리하는데 서비스가 복잡해질수록 이 YAML 지옥이 가중된다.
과도한 오버헤드: 단순한 웹 서버 하나를 위해 클러스터를 구축하는 건 배보다 배꼽이 더 큰 상황이 될 수 있다. 소규모 서비스에는 Docker Compose나 PaaS(App Runner, Cloud Run 등)가 훨씬 효율적이다.
운영의 복잡성: 문제 발생 시 원인이 애플리케이션인지, 컨테이너 설정인지, 네트워크인지, 노드 자원 부족인지 파악하기 어렵다. 또한 약 4개월마다 새 버전이 나오기 때문에 버전 업데이트 관리도 부담이다.
보안 설정의 어려움: 기본적으로 클러스터 내 모든 통신이 허용된 상태로 시작하는 경우가 많다. 네트워크 격리(Network Policy), 권한 관리(RBAC), 시크릿 암호화 등을 직접 설정해야 한다.
6. AWS EKS 실습 순서
환경 구성
- AWS 콘솔 로그인 후 서울 리전 선택
- EC2 키 페어 생성 (명령 서버 로그인용)
- IAM 사용자 생성 및 AdministratorAccess 권한 부여
- Access Key / Secret Key 발급 및 저장
- CloudFormation으로 EC2 명령 서버 생성
- EC2 로그인 후
aws configure로 권한 설정
EKS 클러스터 생성
mkdir -p ~/environment/
cd ~/environment/
export AWS_REGION=ap-northeast-2
eksctl create cluster -f eks-demo-cluster.yaml
# 약 15분 소요웹 서버 배포 및 모니터링
# nginx 웹 서버 배포
kubectl create deployment websrv --image=nginx --port=80 --replicas=2
kubectl expose deployment websrv --port=80 --type=LoadBalancer
# 상태 모니터링
watch -d kubectl get no,svc,pod,deploy,rs장애 테스트
- Pod 삭제 테스트: 파드 하나를 삭제하면 ReplicaSet이 자동으로 새 파드를 생성한다.
- Node 삭제 테스트: EC2 콘솔에서 노드를 삭제하면 오토스케일링 그룹이 자동으로 노드를 복구한다.
kubectl delete node명령은 실제 서버를 종료하지 않고 쿠버네티스 설정에서만 노드를 제거하므로 운영 환경에서는 사용을 지양한다.
리소스 삭제
eksctl delete cluster --name eks-demo
# 이후 CloudFormation, 로드밸런서, VPC 순으로 삭제