TIL - 20251110

juni·2025년 11월 10일

목록 보기

174/316

1110 Kubernetes와 AWS EKS: 컨테이너 오케스트레이션의 시작

문제점: Docker만으로는 수십, 수백 개의 컨테이너를 운영 환경에서 안정적으로 관리하기 어렵습니다.
- 컨테이너 하나가 죽으면 누가 다시 살릴 것인가? (장애 복구)
- 트래픽이 몰리면 어떻게 컨테이너 수를 늘릴 것인가? (스케일링)
- 서비스 중단 없이 애플리케이션을 어떻게 업데이트할 것인가? (배포)
쿠버네티스: 이러한 복잡한 문제들을 해결하기 위한 컨테이너 오케스트레이션(Container Orchestration) 플랫폼입니다. 컨테이너화된 애플리케이션을 대규모로 자동으로 배포, 스케일링, 관리하는 역할을 합니다.

쿠버네티스는 "원하는 상태(Desired State)"를 YAML 파일에 선언적으로 정의하면, 현재 상태를 지속적으로 모니터링하여 원하는 상태를 유지하려고 노력합니다. 이 상태를 정의하는 기본 단위가 바로 오브젝트입니다.

Pod(파드)는 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위입니다.
핵심 개념:
- 컨테이너를 감싸는 캡슐: Pod는 하나 이상의 컨테이너를 포함합니다. (보통 1 Pod = 1 Container)
- 네트워크/스토리지 공유: Pod 내의 컨테이너들은 동일한 네트워크 공간(IP 주소)과 스토리지 볼륨을 공유합니다.
- 일회성(Ephemeral): Pod는 언제든지 죽고 새로 생성될 수 있으며, 이때마다 새로운 IP를 할당받습니다. 따라서 Pod의 IP로 직접 통신하는 것은 지양해야 합니다.

Deployment(디플로이먼트)는 Pod와 그것의 복제본인 ReplicaSet의 상태를 관리하고, 애플리케이션의 배포와 업데이트를 자동화하는 핵심 컨트롤러입니다.
주요 역할:
- 자동 복구 (Self-healing): Pod 하나가 죽으면, Deployment는 이를 감지하고 원하는 개수를 맞추기 위해 자동으로 새로운 Pod를 생성합니다.
- 스케일링 (Scaling): "컨테이너를 3개에서 5개로 늘려줘"라고 Deployment의 replicas 수를 변경하면, 알아서 Pod를 2개 더 생성합니다.
- 무중단 업데이트 (Rolling Update): 새 버전 배포 시, 기존 Pod를 한 번에 다 죽이는 대신, 새로운 버전의 Pod를 점진적으로 생성하고 기존 버전의 Pod를 제거하는 방식으로 서비스 중단 없이 업데이트를 수행합니다.

문제점: Pod는 일회성이며 IP가 계속 바뀌므로, Pod의 IP로 직접 통신하는 것은 불가능합니다.
Service(서비스)는 여러 개의 동일한 Pod 그룹에 대한 고정적인 단일 진입점(Single Point of Entry)과 네트워크 연결을 제공하는 리소스입니다.
주요 역할:
- 고정 IP와 DNS 제공: Service는 생성될 때 변하지 않는 고유한 IP 주소(Cluster IP)와 DNS 이름을 할당받습니다.
- 로드 밸런싱 (Load Balancing): Service는 자신에게 들어온 요청을, 자신이 관리하는 여러 Pod들에게 자동으로 분산시켜 줍니다.
- Service 타입:
  - ClusterIP: 클러스터 내부에서만 통신할 때 사용. (기본값)
  - NodePort: 개발/테스트 목적으로 외부에서 간단히 접근할 때 사용.
  - LoadBalancer: 클라우드 환경(AWS, GCP 등)에서 외부 로드 밸런서를 자동으로 생성하여, 애플리케이션을 외부 인터넷에 정식으로 노출시킬 때 사용.

애플리케이션의 설정(DB 주소 등)이나 민감한 정보(비밀번호, API 키)를 Docker 이미지에 직접 포함시키는 것은 매우 나쁜 관행입니다.
ConfigMap: 일반 설정 정보를 Key-Value 형태의 평문으로 저장합니다.
Secret: 민감한 정보를 Base64로 인코딩하여 저장합니다.
사용법: ConfigMap이나 Secret의 데이터를 Pod의 환경 변수나 볼륨 파일로 주입하여, 코드나 이미지의 변경 없이 설정만 독립적으로 관리할 수 있습니다.

EKS는 AWS에서 제공하는 완전 관리형 쿠버네티스 서비스입니다.
EKS의 역할: 쿠버네티스 클러스터의 "두뇌" 역할을 하는 컨트롤 플레인(Control Plane)의 설치, 관리, 고가용성, 업그레이드를 AWS가 대신 처리해줍니다.
- 컨트롤 플레인: 클러스터의 전체 상태를 관리하고 결정을 내리는 핵심 구성 요소.
- 워커 노드: 실제 컨테이너(Pod)가 실행되는 EC2 인스턴스. (이 부분은 사용자가 관리)
EKS 배포 흐름:
1. 사전 준비: EKS 클러스터가 사용할 IAM 역할, VPC 등을 준비합니다.
2. 클러스터 생성 (eksctl): eksctl이라는 명령줄 도구를 사용하면, 클러스터 생성에 필요한 복잡한 AWS 리소스들을 자동으로 프로비저닝할 수 있습니다.
3. 애플리케이션 배포 (kubectl): 로컬 컴퓨터에서 kubectl을 사용하여, 작성해 둔 Deployment, Service YAML 파일을 EKS 클러스터에 적용(apply)합니다.
4. 외부 노출: Service의 타입을 LoadBalancer로 지정하면, EKS는 AWS의 실제 로드 밸런서(ELB/NLB)를 자동으로 생성하고 Service에 연결하여 애플리케이션을 외부에 안정적으로 노출시킵니다.

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 스케일링, 운영을 자동화하는 컨테이너 오케스트레이션 플랫폼입니다.
Deployment는 Pod의 개수와 상태를 관리하며 자동 복구와 무중단 업데이트를 지원하는 "Pod 관리자"입니다.
Service는 변하기 쉬운 Pod들에게 고정된 IP와 로드 밸런싱을 제공하는 "네트워크 추상화" 계층입니다.
ConfigMap/Secret을 통해 설정을 코드와 분리하여 유연성을 높입니다.
AWS EKS는 복잡한 쿠버네티스 컨트롤 플레인을 AWS가 대신 관리해주는 관리형 서비스로, 개발자가 쿠버네티스를 더 쉽게 운영 환경에 도입할 수 있도록 돕습니다.