TIL - 20251015

juni·2025년 10월 15일

목록 보기

154/316

1015 Kubernetes : Pod, Deployment, Service

쿠버네티스는 컨테이너화된 애플리케이션을 대규모로 자동으로 배포, 스케일링, 관리하기 위한 오픈소스 컨테이너 오케스트레이션(Container Orchestration) 플랫폼입니다.
문제점: 도커만으로는 수십, 수백 개의 컨테이너를 관리하기 어렵습니다. 컨테이너 하나가 죽으면 누가 다시 살릴 것인가? 트래픽이 몰리면 어떻게 컨테이너 수를 늘릴 것인가? 여러 서버에 컨테이너를 어떻게 효율적으로 배치할 것인가?
쿠버네티스의 역할: 이러한 복잡한 문제들을 자동화하여, 개발자가 컨테이너의 저수준 관리에서 벗어나 애플리케이션 자체에 집중할 수 있도록 돕는 "컨테이너를 위한 운영체제(OS)"와 같습니다.

ECR (Elastic Container Registry)는 AWS에서 제공하는 완전 관리형 프라이빗(Private) Docker 이미지 레지스트리입니다.
Docker Hub와의 차이점:
- 공개 범위: Docker Hub는 기본적으로 공개(Public) 저장소이지만, ECR은 기본적으로 비공개(Private)입니다.
- 보안 및 통합: ECR은 IAM 역할(Role) 및 정책과 완벽하게 통합되어, AWS 환경 내에서 매우 안전하고 효율적인 이미지 접근 제어를 제공합니다. EC2, ECS, EKS와 같은 다른 AWS 서비스에서 이미지를 가져올 때 별도의 로그인 절차 없이 IAM 역할을 통해 원활하게 인증할 수 있습니다.
사용 흐름:
1. ECR에 리포지토리(Repository)를 생성합니다.
2. 로컬 환경이나 CI/CD 파이프라인에서 AWS CLI를 통해 ECR에 로그인합니다.
3. 빌드한 Docker 이미지를 ECR 리포지토리 주소 형식에 맞게 태그(tag)합니다.
4. 이미지를 ECR로 푸시(push)합니다.
5. 쿠버네티스 클러스터는 이 ECR에 저장된 이미지를 풀(pull)하여 컨테이너를 실행합니다.

Pod(파드)는 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위입니다.
핵심 개념:
1. 컨테이너를 감싸는 캡슐: Pod는 하나 이상의 컨테이너를 포함하는 논리적인 호스트입니다. 대부분의 경우, 하나의 Pod에는 하나의 컨테이너만 실행하는 것이 일반적입니다.
2. 네트워크와 스토리지 공유: Pod 내의 컨테이너들은 동일한 네트워크 공간(IP 주소, 포트)과 스토리지 볼륨을 공유합니다. localhost를 통해 서로 통신할 수 있습니다.
3. 생명주기: Pod는 일회성(Ephemeral)입니다. Pod가 죽으면(삭제되거나 노드 장애 발생 시), 그 안의 컨테이너와 함께 영원히 사라집니다. 따라서 사용자가 직접 Pod를 생성하고 관리하는 경우는 거의 없습니다.

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

문제점: Pod는 일회성이며, 생성될 때마다 새로운 IP 주소를 할당받습니다. 따라서 Pod의 IP 주소로 직접 통신하는 것은 거의 불가능합니다.
Service(서비스)는 여러 개의 동일한 Pod 그룹에 대한 고정적인 단일 진입점(Single Point of Entry)과 네트워크 연결을 제공하는 리소스입니다.
Service의 역할:
1. 고정 IP와 DNS 제공: Service는 생성될 때 고유하고 변하지 않는 IP 주소(Cluster IP)와 DNS 이름을 할당받습니다.
2. 로드 밸런싱 (Load Balancing): Service는 자신에게 들어온 요청을, 자신이 관리하는 여러 Pod들에게 자동으로 분산시켜 줍니다.
3. 느슨한 결합 (Loose Coupling): 다른 Pod 그룹은 Service의 고정된 DNS 이름을 통해 통신하므로, 대상 Pod들이 죽고 새로 생성되어 IP가 바뀌더라도 전혀 영향을 받지 않습니다.

타입	설명	사용 사례
ClusterIP	(기본값) 클러스터 내부에서만 접근 가능한 IP를 할당.	마이크로서비스 간의 내부 통신 (e.g., 웹 서버 ↔ DB)
NodePort	모든 노드(서버)의 특정 포트를 열고, 해당 포트로 들어온 요청을 Service로 전달.	개발/테스트 목적으로 외부에서 간단히 접근할 때.
LoadBalancer	AWS, GCP 등 클라우드 공급업체의 외부 로드 밸런서를 자동으로 생성하고 Service에 연결.	애플리케이션을 외부 인터넷에 정식으로 노출할 때.

ECR은 AWS 환경에서 사용할 프라이빗 Docker 이미지 저장소입니다.
Pod는 컨테이너를 감싸는 가장 작은 배포 단위이지만, 일회성이므로 직접 관리하지 않습니다.
Deployment는 Pod의 개수와 버전을 관리하며, 자동 복구, 스케일링, 무중단 업데이트를 책임지는 "Pod 관리자"입니다.
Service는 변하기 쉬운 Pod들에게 고정된 IP와 DNS 이름을 부여하고, 요청을 분산시키는 "로드 밸런서"이자 "네트워크 추상화" 계층입니다.
흐름: 사용자 → Service (LoadBalancer) → Deployment가 관리하는 Pod 중 하나 → 컨테이너