[EKS] 쿠버네티스 핵심 컴포넌(Pod, Service, Deployment) 동작 원리 파악

1. 도입부 (Introduction)

현대의 서비스 아키텍처는 거대한 단일 애플리케이션을 쪼개어 독립적인 서비스 단위로 배포하는 마이크로서비스 아키텍처(MSA)가 주류를 이루고 있다. 이를 가능하게 만든 핵심 기술이 바로 컨테이너(Container)다. 하지만 컨테이너의 개수가 수십, 수백 개로 늘어나면 이들의 배포, 네트워킹, 롤백, 스케일 아웃을 개발자가 일일이 수동으로 제어하는 것은 불가능에 가깝다.

이러한 컨테이너 오케스트레이션(Container Orchestration) 문제를 해결하기 위해 탄생한 표준 솔루션이 바로 쿠버네티스(Kubernetes, K8s)다.

[EKS] 쿠버네티스(k8s) 핵심 개념 및 아키텍처 이해

쿠버네티스는 분산 클러스터 환경에서 가용성을 극대화하고 자원 관리를 효율화하는 강력한 도구다. 하지만 개념과 구성 요소 간의 유기적 관계를 제대로 파악하지 못하고 사용하면, 네트워크 유실이나 배포 실패 등의 난관에 봉착하기 쉽다. 본 가이드에서는 쿠버네티스의 뼈대인 핵심 요소들을 이론과 실무 실습 스크립트를 넘나들며 완벽히 해부해 보겠다.

 

 

2. 쿠버네티스 핵심 아키텍처와 AWS EKS의 관계

쿠버네티스는 기본적으로 컴퓨팅 리소스들의 집합인 클러스터(Cluster) 단위로 운영된다. 이 클러스터는 제어를 담당하는 컨트롤 플레인(Control Plane / 마스터 노드)과 실제 컨테이너 애플리케이션이 구동되는 데이터 플레인(Data Plane / 워커 노드)으로 나뉜다.

컨트롤 플레인 (Control Plane)의 주요 구성 요소

• kube-apiserver: 쿠버네티스 클러스터의 관문이다. 모든 명령어와 내부 통신은 이 API 서버를 거친다.
• etcd: 클러스터의 모든 상태 정보(설정값, 인스턴스 정보 등)를 보관하는 초고가용성 분산 Key-Value 저장소다.
• kube-scheduler: 생성되었으나 노드가 할당되지 않은 파드(Pod)를 감지하고, 노드의 여유 자원 상태를 파악하여 최적의 워커 노드에 배치한다.
• kube-controller-manager: 클러스터의 실제 상태를 선언된 '원하는 상태(Desired State)'와 일치시키기 위해 끊임없이 상태를 감시하고 조율하는 루프를 실행한다.

 

AWS EKS (Elastic Kubernetes Service)가 주는 가치

온프레미스(On-Premise) 환경에서 위 컨트롤 플레인(마스터 노드)을 직접 구축하고 백업하며 24시간 가용성을 유지하는 것은 대단히 어렵고 비용이 많이 드는 작업이다.

AWS EKS는 이 번거로운 컨트롤 플레인 영역을 AWS에서 관리형 서비스로 완전 제어해 준다. 다중 가용 영역(Multi-AZ)에 걸쳐 복제본을 자동 구성하고 모니터링해 주므로, 개발자와 엔지니어는 컨트롤 플레인의 장애 걱정 없이 워커 노드와 실질적인 서비스 비즈니스 배포에만 집중할 수 있다.

 

 

3. 네임스페이스(Namespace): 논리적 작업 공간의 분리

쿠버네티스 클러스터라는 하나의 물리적 공간 위에서 여러 팀이 작업하거나, 개발(Dev)·스테이징(Stage)·운영(Prod) 환경을 격리해 사용해야 할 때가 있다. 이때 사용하는 논리적인 분리 단위를 네임스페이스(Namespace)라고 한다.

물리적으로는 동일한 CPU와 메모리(워커 노드)를 공유하지만, 쿠버네티스 API 내부적으로 벽을 세워 서로 다른 가상 클러스터처럼 동작하게 만드는 지능형 그룹화 전략이다.

네임스페이스의 가치와 역할

1. 리소스 관리 격리: 특정 네임스페이스 안의 리소스(Pod, Service 등)는 기본적으로 다른 네임스페이스의 리소스에 가려져 있어 관리가 매우 직관적이다.
2. 보안 및 접근 제어(RBAC): "팀원 A는 dev-namespace만 접근할 수 있고, prod-namespace에는 접근할 수 없다"와 같은 정밀한 권한 관리가 가능하다.
3. 자원 할당 제한(Resource Quota): 각 네임스페이스가 사용할 수 있는 최대 CPU나 메모리 한계를 정하여, 특정 개발팀의 무한 루프 코드가 운영 서버의 컴퓨팅 파워를 침범하는 사태를 예방할 수 있다.

 

실습 명령어 및 가이드

네임스페이스를 생성하고, 조회하고, 격리된 공간의 리소스를 추적하는 핵심 명령어들이다.

# 1. 'my-namespace'라는 이름의 새로운 네임스페이스 생성
kubectl create namespace my-namespace

# 2. 클러스터 내 전체 네임스페이스 목록 조회
kubectl get namespaces

# 3. 특정 네임스페이스 내에 구동 중인 Pod 목록 조회 (-n 또는 --namespace 옵션 필수)
kubectl get pods -n my-namespace

# 4. 특정 네임스페이스 내의 서비스 자원 조회
kubectl get services -n my-namespace

💡 Tip: 네임스페이스 지정을 생략하면 기본값인 default 네임스페이스를 기준으로 명령어가 실행된다. 실무에서 네임스페이스 지정을 깜빡하여 엉뚱한 공간에 파드가 생성되는 실수가 잦으니 항상 대상 공간을 명시적으로 선언하는 습관을 들여야 한다.

 

 

4. 파드(Pod): 쿠버네티스 배포의 최소 유닛

파드(Pod)는 쿠버네티스에서 생성하고 관리할 수 있는 배포 프로세스의 가장 작은 물리적 단위다. 파드는 하나 이상의 컨테이너(Docker 등)로 구성된 공유 그룹이다.

Pod의 핵심 네트워크 특징

쿠버네티스에서 하나의 Pod는 네트워크적으로 고유한 단일 IP 주소를 부여받는다. 즉, 하나의 파드 내에 배치된 여러 개의 컨테이너들은 네트워크 가상 네임스페이스를 완전히 공유한다. 따라서 이 컨테이너들은 포트가 겹치지 않는 한, 외부 IP를 통하지 않고 로컬호스트(127.0.0.1 또는 localhost) 기준으로 매우 빠르게 통신할 수 있다. 또한 로컬 디스크 볼륨(Volume)도 공유하여 파일을 쉽게 주고받을 수 있다.

 

왜 단일 Pod 내에 여러 컨테이너를 배치할까? (Sidecar Pattern)

일반적으로는 하나의 파드당 하나의 컨테이너만 탑재하는 것이 권장된다. 하지만 서로 고도로 결합하여 실시간 데이터 교류가 필요한 '협력 프로세스'인 경우 다중 컨테이너 구성을 도입한다.

• 메인 애플리케이션 컨테이너: 실제 서비스(예: Spring Boot web app, Nginx 웹 서버)를 구동한다.
• 보조(Sidecar / Adapter) 컨테이너: 메인 컨테이너가 뱉는 로그파일을 실시간 수집하여 중앙 로그 서버로 전송하는 수집기(Log Forwarder), 주기적인 헬스 체크(Health Checker), 로컬 캐시 데몬(Redis) 등을 배치하여 메인 비즈니스 로직과 비즈니스 외부 인프라 요구사항의 책임을 철저히 분리한다.

 

[실습 1] 스크립트를 통한 Pod 생성 및 관리 (멀티 컨테이너 예시)

아래는 웹서버 Nginx와 주기적으로 Nginx에 요청을 보내 헬스를 점검하는 비지박스(http-pinger) 컨테이너를 하나의 Pod에 담은 선언 파일이다.

# test_pod2.yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pinger-pod
  namespace: my-namespace  # 격리된 논리적 작업 공간 지정
  labels:
    app: nginx-pinger      # 서비스나 레플리카셋이 식별하기 위한 라벨 지정
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80    # Nginx 컨테이너 포트

  - name: http-pinger
    image: busybox
    # 5초마다 동일 Pod 내 localhost:80(Nginx)에 웹 요청을 보내는 루프 실행
    command: ['sh', '-c', 'while true; do wget -qO- http://localhost:80; sleep 5; done']

배포 및 검증 방법

# yml 스크립트 파일 반영
kubectl apply -f test_pod2.yml

# 생성된 Pod 내의 실시간 컨테이너 로그 모니터링 (멀티 컨테이너의 경우 첫 번째 컨테이너 로그가 기본 출력됨)
kubectl logs -f nginx-pinger-pod -n my-namespace

 

[실습 2] kubectl 명령어를 통한 즉시 Pod 제어법

간단한 테스트 용도로 야믈(YAML) 파일 없이 단일 명령어로 즉시 파드를 생성하고 제거하는 방법이다.

# 1. nginx 컨테이너를 구동하는 파드를 'my-nginx'라는 이름으로 즉시 런칭
kubectl run my-nginx --image=nginx --port=80

# 2. 파드 목록과 상세 위치(IP, 구동 워커 노드명)를 확장하여 상세 조회
kubectl get pods -o wide

# 3. 클러스터 전체 네임스페이스를 망라하여 구동 중인 모든 파드 상태 확인
kubectl get pods -A

# 4. 파드 내 컨테이너 쉘에 직접 연결하여 점검 및 curl 테스트 수행
kubectl exec -it nginx-pod -n my-namespace -- /bin/sh
# (쉘 진입 후 내부에서 로컬 루프백 호출) curl http://localhost

# 5. 테스트를 마친 단일 파드 수동 삭제
kubectl delete pod my-nginx

 

 

5. 서비스(Service): 가변적인 Pod를 지탱하는 네트워크 이정표

쿠버네티스의 파드(Pod)는 기본적으로 휘발성(Ephemeral) 리소스다. 시스템 장애가 발생하여 파드가 죽거나 노드가 교체되면, 파드는 완전히 새로운 IP를 부여받고 다시 태어난다.

만약 프론트엔드 애플리케이션이 백엔드 파드의 고정 IP를 직접 참조하여 통신한다면, 백엔드가 재배포되거나 자가 치유(Self-healing)될 때마다 통신 경로가 완전히 단절될 것이다. 이 고질적인 동적 네트워킹 문제를 완벽히 해결하는 자원이 바로 서비스(Service)다.

서비스의 핵심 역할

1. 영구 엔드포인트 제공: 백엔드 파드들이 죽고 살아나면서 IP가 아무리 바뀌어도 서비스 자체는 고정된 내부 가상 IP(ClusterIP)를 유지한다.
2. 서비스 디스커버리(Service Discovery): 클러스터 내부의 DNS 시스템과 연동되어 서비스 이름(e.g., http://my-service)만으로 대상 목적지를 감지할 수 있다. 다른 네임스페이스에서 해당 서비스에 접근하고자 할 때는 정규화된 도메인 네임(FQDN) 형식인 my-service.<namespace-name>.svc.cluster.local 형태로 라우팅이 완료된다.
3. 자동 로드 밸런싱(Load Balancing): 서비스의 selector 조건에 부합하는 여러 개의 파드 목록을 감시 및 그룹화하고, 서비스 엔드포인트로 인입되는 대량의 요청을 산하 파드들로 라운드 로빈(Round-Robin) 방식으로 균등하게 분산 전달해 준다.

 

서비스 라우팅의 3대 핵심 포트 속성

서비스를 정의할 때 가장 헷갈리기 쉬운 개념인 3개의 포트 관계에 대한 정확한 개념 정립이다.

• port: 서비스 자체가 클러스터 내부에서 클라이언트를 향해 열어두고 리슨(Listen)하는 포트다. 클러스터 안에서 서비스에 접근할 때 이 포트를 목적지로 삼는다.
• targetPort: 서비스가 수신한 트래픽을 실제로 요청을 처리하는 최종 대상 Pod 컨테이너 내부의 어떤 포트로 던져줄지 결정하는 타겟 포트다. 파드 yml의 containerPort와 반드시 정밀하게 부합해야 한다.
• nodePort (NodePort 타입 서비스에 해당): 외부 트래픽을 워커 노드 자체의 물리적인 외부 IP와 바인딩하기 위해 노드 전역에서 개방하는 포트 범위를 의미한다 (보통 30000-32767 사이에서 할당).

 

[실습 3] 서비스 연동 yml 파일 및 테스트

# my-service.yml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: dlwldn30
spec:
  # type을 명시적으로 선언하지 않을 경우 기본값은 ClusterIP가 된다.
  # ClusterIP: 클러스터 내부 통신 전용 가상 IP 생성
  # NodePort: 노드 물리 포트를 연결해 외부 노출
  # LoadBalancer: 퍼블릭 클라우드(AWS) 인프라의 로드 밸런서를 자동 프로비저닝하여 연결
  ports:
  - port: 80         # 서비스가 내부에서 여는 포트
    targetPort: 80   # 파드 컨테이너의 nginx 포트와 일치시킴
  selector:
    app: my-nginx    # app=my-nginx 라벨을 가진 모든 파드로 로드밸런싱 유도

서비스 정상 기동 및 연결성 호출 검증

# 1. 특정 Pod 내부 가상 쉘에 직접 실행자로 진입
kubectl exec -it my-nginx -n dlwldn30 -- /bin/sh

# 2. 동일 Namespace 안의 영구 서비스 엔드포인트 이름으로 다이렉트 통신 시도
curl http://my-service:80

 

 

6. 레플리카셋(ReplicaSet)과 디플로이먼트(Deployment)의 가치

가용성이 극도로 중요한 실무 운영 환경에서 단일 파드로 서비스를 런칭하는 것은 매우 위험하다. 컨테이너 엔진이나 물리 하드웨어가 깨졌을 때 수동 복구를 기다려야 하기 때문이다.

쿠버네티스는 시스템 안정성을 위해 지정된 개수(Replicas)의 복제 파드가 항상 동작하도록 감시 및 제어하는 이중 안전망 리소스를 제공한다.

 

레플리카셋(ReplicaSet)

레플리카셋은 설정한 복제 개수($N$)만큼 파드가 항시 동작하도록 상태를 끊임없이 모니터링한다. 예를 들어 사용자가 인위적으로 어떤 파드를 삭제하면(kubectl delete pod), 레플리카셋의 루프가 개수 결손을 실시간 탐지하고 template 스펙을 바탕으로 완전히 똑같은 파드를 즉시 재생성해 채워 넣는다.

• selector.matchLabels: 레플리카셋이 추적하고 감시해야 할 대상 파드의 고유 라벨들을 선언한다.
• template.metadata.labels: 레플리카셋에 의해 새롭게 생성되는 파드들에 자동으로 박히게 될 고유 라벨이다. 이 라벨은 위의 matchLabels와 한 자의 오차도 없이 반드시 일치해야 오류가 나지 않는다.

 

디플로이먼트(Deployment): 진정한 애플리케이션 생명 주기 관리자

실무에서 레플리카셋 단독으로 자원을 선언하는 경우는 거의 없다. 실무자들은 항상 그 상위 컨트롤러 레이어인 디플로이먼트(Deployment)를 사용하여 애플리케이션의 릴리즈 라이프사이클을 통제한다.

디플로이먼트는 변경 사항(컨테이너 이미지 버전 등)이 발생했을 때 배후에서 점진적으로 파드를 롤링 업데이트(Rolling Update)하는 무중단 배포를 관장한다.

디플로이먼트에 이미지 변경을 적용하면 디플로이먼트는 '새로운 버전의 레플리카셋(Revision 2)'을 생성하고, 신규 버전의 파드를 하나씩 띄우는 것과 동시에 기존 버전의 레플리카셋(Revision 1)에 소속된 구버전 파드를 순차적으로 감소시킨다. 만약 새로 배포한 버전에 결함이 발견되면, 단 한 줄의 롤백 명령으로 이전 안정적인 레벨로 즉각 복원할 수 있는 버전 롤백 메커니즘도 완벽히 지원한다.

 

[실습 4] Deployment 적용 및 롤링 배포 실무 연동 스크립트

# nginx-deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: dlwldn30
spec:
  replicas: 2               # 항시 유지되어야 할 복제 파드 본 수
  selector:
    matchLabels:
      app: my-nginx         # 이 디플로이먼트가 관리할 파드 식별 조건
  template:
    metadata:
      labels:
        app: my-nginx       # 생성할 파드에 부여할 라벨 정의
    spec:
      containers:
      - name: nginx 
        image: nginx:1.22.1 # 이미지 버전 명시
        ports:
        - containerPort: 80 

무중단 관리 및 롤백 검증 명령어

# 1. 파일 기반 Deployment 적용
kubectl apply -f nginx-deployment.yml

# 2. 실전 테스트 - 배포한 버전에 문제가 발생하여 이전 리비전(Revision)으로 급격히 복원(Rollback)하고자 할 때
kubectl rollout undo deployment nginx-deployment -n dlwldn30

# 3. 코드나 야믈 구조 변경 없이, 인위적으로 최신 빌드 이미지 풀링 및 파드 롤링 재시작을 강제 실행할 때
# (latest 태그를 유지하면서 내부 물리 바이너리가 갱신된 상황에서 새로운 revision 생성을 트리거하는 가장 유용한 팁이다)
kubectl rollout restart deployment nginx-deployment -n dlwldn30

 

 

7. 인그레스(Ingress)와 인그레스 컨트롤러(Ingress Controller)

쿠버네티스 서비스(Service)가 클러스터 내부 네트워킹을 공고히 다져놓았다면, 외부에 거주하는 실제 사용자들의 인터넷 브라우저 트래픽을 도메인과 서브패스 기반으로 가장 앞단에서 맞이하여 내부 서비스로 깔끔하게 안내해 주는 클러스터 현관문 역할을 담당하는 것이 바로 인그레스(Ingress)다.

Ingress와 Ingress Controller의 명확한 개념 분리

이론적으로 공부할 때 가장 혼동을 유발하기 쉬운 부분이다. 이 둘은 철저히 역할과 행동이 다르다.

1. 인그레스(Ingress)는 "규칙 정의서"다: "특정 도메인(server.store)의 /dlwldn30/ 경로로 들어오는 트래픽은 my-service라는 이름의 서비스 80 포트로 연결해 달라"는 맵핑 메타데이터와 정보만을 기술하여 쿠버네티스 API 서버에 저장해 두는 '정적 규칙 파일'이다. 스스로 네트워크를 핸들링하는 주체가 아니다.
2. 인그레스 컨트롤러(Ingress Controller)는 "실제 라우팅 엔진"이다: 위의 인그레스 야믈 규칙을 실시간 감시 및 분석하여 실제로 외부 L4/L7 로드 밸런서 하드웨어 설정을 연동하거나 내부 Reverse Proxy(Nginx, Envoy 등)의 라우팅 매핑 테이블로 컴파일하여 실질적인 '트래픽 스위칭 및 포워딩'을 직접 수행하는 구동 엔진이다.

 

AWS 환경(EKS)에서 동작하는 실무적 원리

AWS EKS 상에 인그레스 컨트롤러(예: Ingress-Nginx Controller)를 설치하기 위해 명시적으로 시스템 컴포넌트를 apply하는 순간, 컨트롤러는 AWS 클라우드 공급자 API와 유기적으로 통신하여 인프라 레벨의 AWS Network Load Balancer(NLB) 혹은 Application Load Balancer(ALB)를 자동으로 EKS 외부 리소스로 생성 및 프로비저닝한다.

사용자가 도메인(Route53 등)을 통해 이 AWS 로드 밸런서 주소로 트래픽을 던지면, 트래픽은 EKS 내부에서 항시 구동 중인 Ingress-Nginx Controller Pod로 유입된다. 컨트롤러는 수신한 웹 요청의 HTTP 호스트 헤더와 서브 패스를 뜯어보고 개발자가 명시한 Ingress 규칙에 적합한 백엔드 Service 엔드포인트로 패킷을 고속 스위칭 및 중계해 준다.

 

[실습 5] 도메인 및 경로 기반 Ingress 라우팅 선언

# nginx-ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: dlwldn30
  annotations:
    # 이 인그레스 규칙서가 NGINX 기반 인그레스 컨트롤러 엔진에 의해 동적 컴파일되도록 클래스 매핑
    kubernetes.io/ingress.class: nginx
    # rewrite-target: 인입 경로의 특정 패스를 실제 대상 컨테이너로 넘길 때 파싱 변환 규칙 지정
    nginx.ingress.kubernetes.io/rewrite-target: /$1 
spec:
  rules:
  - host: server.dlwldn318.store          # 사용자가 브라우저 주소창에 입력하는 도메인 정의
    http:
      paths:
      - path: /dlwldn30/(.*)             # 정규식 패턴을 이용하여 /dlwldn30/ 이하 모든 패스를 캡처
        pathType: Prefix
        backend:
          service:
            name: my-service             # 라우팅할 대상 k8s 서비스 지정
            port:
              number: 80                 # 전달할 타겟 서비스 포트 지정

인그레스 설치 명령어 가이드라인

# EKS 클러스터 위에 AWS 연동형 인그레스-nginx 컨트롤러 인프라 구성 요소를 설치하는 공식 배포 커맨드
kubectl apply -f [https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/aws/deploy.yaml](https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/aws/deploy.yaml)

 

 

8. 실무 중심 팁 및 자주 쓰는 kubectl 명령어 핵심 정리

쿠버네티스를 운영하며 문제를 분석하고 빠르게 대처하기 위해 매일 사용하는 고수준 트러블 슈팅 명령어 모음집이다.

# ⚠️ [쿠버네티스 트러블슈팅의 핵심] describe 명령을 습관화하자!
# 파드가 어떤 상태로 누워있는지, 최근에 노드 할당 에러나 이미지 풀링 실패가 왜 일어났는지 상세 정보 및 k8s 이벤트를 한 화면에 출력해 준다.
kubectl describe pod nginx-pinger-pod -n my-namespace

# 야믈 설정 파일 변경점을 실시간으로 인프라에 안전하게 선언적(Declarative)으로 반영
kubectl apply -f my-deployment.yaml

# 적용되었던 자원들을 클러스터에서 한 번에 완전히 안전하게 회수 및 삭제
kubectl delete -f my-deployment.yaml

# 클러스터 상의 특정 파드를 대상으로 포트 포워딩을 일시적으로 수립하여 내 로컬 컴퓨터 브라우저에서 직접 디버깅할 때 사용
kubectl port-forward pod/nginx-pinger-pod 8080:80 -n my-namespace

 

 

9. 결론 (Conclusion)

쿠버네티스는 컨테이너 애플리케이션의 라이프사이클을 안전하고 고가용성으로 운영해 주는 아주 매력적인 클라우드 플랫폼이다.

• 네임스페이스(Namespace)라는 논리적인 울타리에서 팀과 환경을 완벽하게 격리하고,
• 가장 작은 배포 단위인 파드(Pod)가 지닌 일시적인 성격을 보완하기 위해 고정 엔드포인트와 로드밸런싱을 보장하는 서비스(Service)를 앞에 세우며,
• 이 파드 복제본의 실시간 건강 상태와 버전 교체 전략을 선언적으로 주도하는 디플로이먼트(Deployment)를 연동하며,
• 클러스터 진입로에서 전 세계 도메인 인입 패킷을 분류하는 인그레스(Ingress)를 체계적으로 맞물림으로써 견고하고 자가 치유가 가능한 분산 시스템 구축이 완성된다.

여기에 AWS EKS라는 거인의 어깨 위에서 마스터 노드의 무거운 운영 짐을 내려놓고 가치 있는 개발에 집중하는 것이 바로 현대 클라우드 네이티브 아키텍처의 핵심이자 정수라 할 수 있다. 오늘 정리한 쿠버네티스의 필수 개념과 매커니즘, 그리고 명령어 및 실무 가이드라인을 바탕으로 직접 클러스터를 생성하고 직접 apply를 실행해 나만의 아키텍처를 확장해 보기를 바란다.