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

1. 도입부: 왜 쿠버네티스인가?

현대의 백엔드 시스템은 물리 서버(Bare Metal)에 직접 서비스를 올리던 가상화 이전의 시대를 지나, 하이퍼바이저 기반의 가상 머신(VM), 그리고 오늘날의 컨테이너(Container) 중심 아키텍처로 급격하게 이동했다.

컨테이너 기술(Docker 등)의 등장은 가볍고 빠른 배포를 가능하게 만들며 MSA(Microservice Architecture)의 기폭제가 되었다. 하지만 서비스의 규모가 커지고 관리해야 할 컨테이너의 개수가 수십, 수백 개를 넘어 수만 개에 이르면서 새로운 난관에 봉착하게 되었다.

• "서비스 트래픽이 몰려 컨테이너를 늘려야 하는데, 이걸 언제 일일이 수동으로 띄우지?"
• "컨테이너 하나가 알 수 없는 오류로 죽어버렸는데, 자동으로 감지해서 다시 살릴 순 없을까?"
• "수많은 컨테이너에 트래픽을 골고루 분산해주는 로드 밸런싱 처리는 어떻게 하지?"

이러한 컨테이너화된 애플리케이션을 대규모로 운영할 때 발생하는 배치, 스케줄링, 로드 밸런싱, 자동 복구 등의 유기적인 관리 문제를 해결하기 위해 등장한 플랫폼이 바로 쿠버네티스(Kubernetes, k8s)다.

 

 

2. 쿠버네티스(k8s) 정의와 역할

2.1 컨테이너 오케스트레이션(Container Orchestration)이란?

수많은 악기가 모여 하나의 아름다운 교향곡을 연주할 때, 각 악기들의 연주 시점과 템포를 조율하는 지휘자(Orchestrator)가 필수적이다. 컨테이너 오케스트레이션 역시 마찬가지다.

쿠버네티스는 수많은 컨테이너들이 충돌 없이, 물리적 자원을 효율적으로 나눠 쓰며, 유기적으로 동작할 수 있도록 조율하는 인프라 시스템의 지휘자 역할을 담당한다.

 

2.2 Docker와 Kubernetes의 관계

• Docker: 컨테이너를 만들고, 패키징하고, 단일 서버에서 실행하기 위한 컨테이너 기술(엔진)이다. 개별적인 상자(Container)를 만드는 기술에 가깝다.
• Kubernetes: 이렇게 만들어진 수많은 컨테이너 상자들을 여러 대의 서버로 구성된 거대한 물리적 공간(클러스터) 위에 안전하게 배치하고 관리하는 오케스트레이션 플랫폼이다.

🚢 비유하자면: Docker가 수출용 표준 컨테이너 상자 자체를 만드는 기술이라면, 쿠버네티스는 수천 개의 컨테이너 상자를 배에 싣고, 최적의 경로로 이동시키며, 사고가 나면 대처하는 선박 시스템 및 항구 제어 타워 역할을 수행한다.

 

 

3. 쿠버네티스 클러스터 아키텍처 (Cluster Architecture)

쿠버네티스는 클러스터(Cluster) 기반으로 구성된다. 클러스터란 컨테이너화된 애플리케이션을 실행하기 위한 컴퓨터(노드)들의 집합이자 쿠버네티스의 전체 환경을 뜻한다.

쿠버네티스 클러스터는 크게 전체 시스템을 제어하는 마스터 노드(Control Plane)와 실제 애플리케이션이 실행되는 워커 노드(Worker Node)로 나뉜다.

 

3.1 마스터 노드 (Control Plane): 클러스터의 '뇌'

마스터 노드는 클러스터의 상태를 결정하고, 새로운 명령을 내리며, 시스템 전반을 감시하고 제어하는 컨트롤 타워 역할을 담당한다.

① API 서버 (kube-apiserver)

• 역할: 클러스터의 중앙 집중식 관리 진입점이다.
• 특징: 개발자의 명령어(kubectl)나 외부 시스템의 요청, 클러스터 내부 구성 요소의 모든 통신은 이 API 서버를 거친다. 쿠버네티스의 유일한 '공식 창구' 역할을 수행한다.

 

② 스케줄러 (kube-scheduler)

• 역할: 새로 생성된 파드(Pod)를 감지하고, 해당 파드가 어떤 워커 노드에서 실행되는 것이 가장 적합할지 판단하여 배치한다.
• 선택 기준: 노드의 남은 CPU/메모리 자원 상태, 네트워크 구성, 개별 제약 조건(Affinity/Anti-affinity 등)을 복합적으로 고려하여 최적의 위치를 선택한다.

 

③ etcd (엣시디)

• 역할: 클러스터의 모든 상태 정보를 저장하는 가고용성 분산 key-value 데이터베이스다.
• 중요성: ConfigMap, Secret, 노드 상태 정보 등 클러스터의 현재 '진실 정의서'가 이곳에 저장된다. 무상태(Stateless) 아키텍처를 지향하는 쿠버네티스에서 유일하게 상태(State)를 보존하는 곳이므로, 백업과 안정성이 매우 중요하게 다뤄진다. 보안상 오직 API 서버만 etcd와 직접 통신할 수 있다.

 

④ 컨트롤러 매니저 (kube-controller-manager)

• 역할: 클러스터의 '현재 상태'가 설계서에 명시된 '바람직한 상태(Desired State)'와 일치하도록 지속적으로 조정 작업을 수행하는 무한 루프 감시기다.
• 예시: "파드가 항상 3개 켜져 있어야 한다"는 설정이 있으면, 파드가 2개로 줄어드는 순간 이를 감지하여 추가 파드를 생성하도록 명령을 내리는 역할을 전담한다. (Deployment, ReplicaSet 제어)

💡 클라우드 실무 팁 (EKS): 마스터 노드의 가용성과 안정성은 시스템 전체의 생존과 직결된다. AWS의 관리형 쿠버네티스 서비스인 EKS(Elastic Kubernetes Service)를 사용하면, AWS에서 마스터 노드의 생성, 고가용성 멀티 AZ 구성, 버전 업그레이드 및 패치 작업을 자동으로 지원해주기 때문에 인프라 운영 부담이 비약적으로 줄어든다.

 

3.2 워커 노드 (Worker Node): 애플리케이션 실행을 담당하는 '몸통'

워커 노드는 마스터 노드의 통제를 받으며 실제 서비스 인스턴스(컨테이너)들을 실행하고 외부 트래픽을 처리하는 하드웨어 장비(AWS 기준 EC2 인스턴스)다.

① Kubelet (큐블릿)

• 역할: 워커 노드마다 탑재되는 핵심 에이전트(Agent)다.
• 통신 흐름: API 서버와 긴밀히 소통하며 "내 노드에 파드를 실행하라"는 명령을 전달받으면 컨테이너 런타임을 구동해 파드를 가동하고, 파드가 성공적으로 시작했는지 주기적으로 상태 정보를 확인해 API 서버에 보고한다.

 

② Kube-proxy (큐브 프록시)

• 역할: 노드 수준에서 동작하는 네트워크 프록시이자 간이 로드 밸런서다.
• 기능: 쿠버네티스의 가상 IP 시스템을 실제 가용 IP 네트워크 규칙(IPtables 또는 IPVS)으로 변환하여, 파드 상호 간의 통신과 외부 트래픽이 각 파드로 무리 없이 포워딩될 수 있도록 네트워크 경로를 설정한다.

 

 

4. 쿠버네티스 핵심 오브젝트 (Core Objects)

쿠버네티스는 모든 설정을 선언적(Declarative)으로 관리한다. "어떻게 해라"는 절차적 명령 대신, YAML 파일에 "이러한 형태의 리소스를 유지하라"고 상태를 작성하여 제출하면 쿠버네티스가 이를 시스템에 구현해낸다. 이때 사용되는 기본 단위를 오브젝트(Object)라고 부른다.

4.1 네임스페이스 (Namespace)

• 개념: 물리적인 단일 클러스터를 논리적인 여러 영역으로 분리하여 사용할 수 있게 만들어주는 가상 파티션이다.
• 활용: 하나의 클러스터를 개발(Dev), 테스트(Staging), 운영(Prod) 환경으로 나누어 운영할 때 유용하다. 각 네임스페이스 내에서 생성된 리소스는 고유한 이름을 보장받으며 다른 네임스페이스와 격리된다.

 

4.2 파드 (Pod)

• 개념: 쿠버네티스에서 생성하고 배포할 수 있는 가장 작은 컴퓨팅 단위다.
• 구조: 파드는 하나 이상의 컨테이너 그룹으로 구성된다. 일반적으로는 1 파드 = 1 컨테이너 구조로 설계하지만, 메인 컨테이너의 기능을 보조하는 로깅 엔진이나 프록시 등을 동일 파드 내의 서브 컨테이너(Sidecar 패턴)로 함께 묶어 배포할 수 있다.
• 특징: 동일한 파드 내의 컨테이너들은 IP 주소와 포트 공간, 볼륨(저장소)을 긴밀히 공유한다. 파드는 영구적이지 않고 언제든 죽고 다시 살아날 수 있는 '일회성(Ephemeral)' 자원이다.

 

4.3 서비스 (Service)

• 개념: 파드가 생성되고 소멸될 때마다 IP 주소가 지속적으로 바뀌는 동적 한계를 극복하기 위해 등장한 고정 진입점(Service Discovery & Load Balancing) 자원이다.
• 주요 타입:
  • ClusterIP (기본형): 클러스터 내부 통신용 고정 가상 IP를 할당한다. 외부에서는 접근이 불가능하며 내부 파드끼리 통신할 때 사용된다.
  • NodePort: 모든 워커 노드의 특정 포트(예: 30000~32767)를 열어 해당 포트로 들어오는 트래픽을 파드로 넘겨준다.
  • LoadBalancer: AWS 등 클라우드 공급자의 인프라와 연동하여 외부 리얼 로드 밸런서(Classic, NLB/ALB 등)를 자동으로 프로비저닝하고 외부 트래픽 수신 통로를 만든다.

 

4.4 인그레스 (Ingress)

• 개념: 클러스터 외부에서 들어오는 트래픽을 도메인 명칭(Host)이나 URL 경로를 기준으로 내부의 적절한 서비스(Service)로 라우팅해주는 L7 규칙 지시서다.
• 핵심 역할:
  • 호스트(Host) 기반 라우팅: api.mysite.com은 백엔드 서비스로, www.mysite.com은 프론트엔드 서비스로 전달하는 포트 가상화 제어.
  • SSL/TLS 터미네이션: 인증서 관리를 인그레스 단에서 일괄 처리하여 백엔드 파드가 암호화 처리 비용을 절약하게 해준다.

 

4.5 레플리카셋 (ReplicaSet)

• 개념: 파드가 항상 지정된 복제본(Replica) 수만큼 정상 실행되도록 보장하는 선언적 자원이다.
• 원리: 리소스 선언문에 replicas: 3을 지정해두면, 누군가 고의로 파드를 지우거나 장애로 인해 파드가 2개로 꺼지는 순간 즉시 새로운 파드를 추가 발 가동하여 항상 3개의 머릿수를 유지한다.

 

4.6 디플로이먼트 (Deployment)

• 개념: 레플리카셋을 상위에서 감싸 안고, 애플리케이션의 버전 배포, 롤링 업데이트, 롤백, 히스토리 관리 등의 실제 배포 수명 주기를 제어하는 핵심 오브젝트다.
• 실무 활용: 실제 실무에서 파드를 단독으로 선언하거나 레플리카셋만 따로 선언하는 경우는 거의 없다. 보통 Deployment를 선언하면 내부적으로 적절한 ReplicaSet이 자동 생성되고 버전에 맞는 파드 제어가 이루어진다.

 

4.7 컨피그맵 (ConfigMap) & 시크릿 (Secret)

컨테이너 이미지 내부 코드에 민감 정보나 환경 변수 설정을 하드코딩하는 안티 패턴을 피하기 위한 핵심 설정 분리 자원이다.

• ConfigMap: 일반 설정 파일, Key-Value 프로퍼티 등 민감하지 않은 환경 정보를 분리 보관하여 컨테이너 부팅 시 주입한다.
• Secret: 데이터베이스 암호, API 토큰, SSL 인증서 등 보안이 필요한 민감한 정보를 저장한다. 쿠버네티스 내부적으로 최소한 Base64 인코딩을 거쳐 메모리에 올라가며 보안 권한(RBAC) 관리가 더 엄격하게 적용된다.

 

 

5. 쿠버네티스의 주요 특징 및 인프라적 장점

쿠버네티스가 글로벌 컨테이너 플랫폼 표준으로 우뚝 서게 된 이유는 단순한 컨테이너 배치를 넘어 실무 인프라 운영 전반을 자가 자동화(Self-Automating)해주기 때문이다.

5.1 자동 복구 (Self-Healing / Auto-healing)

• 컨테이너의 헬스체크(Liveness Probe)를 통해 컨테이너 상태를 실시간 모니터링한다.
• 오류가 나거나 먹통이 된 컨테이너를 발견하면 쿠버네티스가 즉시 해당 컨테이너를 강제 재시작하고, 특정 노드 물리 장비에 장애가 발생하면 해당 노드 위에 돌고 있던 모든 파드를 건강한 다른 워커 노드로 안전하게 대피(Evacuation)시켜 가동한다.

 

5.2 편리한 서비스 발견 및 내장 로드 밸런싱

• 파드가 새로 생성되거나 사라지는 동적인 상황 속에서도, 쿠버네티스에 내장된 DNS 서버와 서비스(Service) 컴포넌트를 통해 IP 주소가 계속 변하는 인프라 파드 그룹의 단일 대표 경로를 깔끔하게 발견하고 부하 분산 처리를 완료해 준다.

 

5.3 논리적 멀티 테넌시 분리 (Multi-tenant Environment)

• 네임스페이스(Namespace) 개념을 통해 개발팀(Dev), 테스트 환경(QA), 그리고 실제 고객 서비스가 이루어지는 프로덕션 환경(Prod)을 하드웨어 장비 증설 없이 논리적인 바운더리로 격리하여 하나의 클러스터에서 경제적으로 공유해 사용할 수 있게 만든다.

 

5.4 2단계 오토스케일링 (Auto-scaling)

수많은 엔지니어들이 가장 극찬하는 기능으로, 트래픽 유동성에 따라 시스템 규모를 자동으로 조절해준다.

• HPA (Horizontal Pod Autoscaler): CPU나 메모리 자원 사용량이 임계치(예: 80%)를 돌파하면, 자동으로 동작하는 파드의 개수(Replicas)를 유연하게 가로로 늘리고 줄여준다.
• Cluster Autoscaler (CA): 늘어난 파드들 때문에 워커 노드(EC2)들의 자원이 부족해지면, 자동으로 인프라 백엔드 장비(EC2 인스턴스) 자체의 개수를 늘리거나 반대로 트래픽이 축소되면 노드를 반납하여 비용 낭비를 절감하게 해준다.

 

5.5 무중단 배포 및 자동화된 롤아웃 (Automated Rollouts & Rollbacks)

• 새로운 버전의 애플리케이션을 배포할 때, 전체 컨테이너를 한 번에 교체하면 일시적인 서비스 장애가 발생한다. 쿠버네티스 디플로이먼트(Deployment)는 기존 버전의 파드를 하나씩 순차적으로 내리면서 새로운 버전의 파드를 한 대씩 점진적으로 올려나가는 롤링 업데이트(Rolling Update) 배포를 무중단으로 자동 수행한다.
• 만약 신버전 소스 코드에 심각한 메모리 릭이나 버그가 감지되어 구동 에러가 발생하면, 쿠버네티스는 신버전 배포를 즉각 중단하고 이전 버전의 건강한 상태로 즉각 롤백(Rollback)을 단행하여 전체 서비스 정지 사태를 사전에 예방한다.

 

5.6 파드 단위 자원 보장 및 제한 (Resource Requests & Limits)

• Requests (최소 보장선): "이 파드는 가동을 위해 최소 CPU 0.5코어, 메모리 512MB는 필요하다"는 정보를 기입하여, 해당 여유분이 확실히 보장된 노드에만 파드를 선별적으로 배치한다.
• Limits (최대 상한선): "이 파드는 아무리 트래픽이 늘어나도 CPU 2코어, 메모리 2GB를 넘게 점유해선 안 된다"는 상한 제약 필드를 설정하여, 특정 파드가 이상 루프로 인프라 전체 자원을 잡아먹어 다른 서비스까지 마비시키는 불상사를 영구 차단한다.

 

 

6. 결론: 쿠버네티스로 완성하는 클라우드 네이티브

쿠버네티스는 단순히 도커를 관리하는 컨테이너 오케스트레이터를 넘어, 현대 IT 서비스의 확장성과 자율 운영 안정성을 획기적으로 견인하는 표준 인프라 플랫폼이다.

처음 접할 때는 수많은 리소스 명칭과 복잡한 분산 아키텍처에 의해 진입 장벽이 다소 느껴질 수 있다. 하지만 클러스터 제어 타워인 마스터 노드가 동작하는 원리와 이를 뒷받침하며 서비스를 수행해내는 워커 노드의 조화, 그리고 파드와 서비스, 인그레스가 이루어내는 네트워크 통신 흐름만 명확히 기억한다면 쿠버네티스를 활용한 아키텍처 구축은 훨씬 수월해질 것이다.