인턴 1주차 - Kubernetes 기본 개념 정리

인턴 활동 정리

4학년 2학기를 앞두고 있던 여름 방학부터 스타트업에서 백엔드 개발자 인턴을 시작하게 되었다.

앞으로 그때 노션에 정리해 놓았던 글을 정리해서 블로그로 옮겨 보려고 한다.

입사하고 첫 주에는 Kubernetes와 NestJS를 학습하고, 간단한 실습 과제를 해결해 보는 시간을 가졌다.

아래는 쿠버네티스를 처음 접하는 입장에서 구조와 개념을 간단하게 정리한 기록이다.

---

컨테이너

컨테이너는 애플리케이션이 실행되는 데 필요한 코드, 설정, 라이브러리 등을 하나로 묶은 실행 환경이다.
운영체제 전체를 가상화하는 가상 머신과 달리 컨테이너는 필요한 부분만 가볍게 격리해서 빠르게 실행할 수 있다.

환경이 달라도 항상 똑같이 실행되고, 배포나 확장도 간편하다는 점 때문에 인프라 구성에서 기본 단위로 많이 사용된다.

---

Pod

Pod는 쿠버네티스에서 가장 작은 배포 단위다.
하나 이상의 컨테이너를 포함하며 컨테이너 간에는 네트워크(IP 주소 및 포트)와 스토리지(볼륨)를 공유할 수 있다.

• 컨테이너 그룹화: 밀접하게 관련된 컨테이너를 하나의 파드로 묶어 함께 배치한다.
• 공유 리소스: 파드 내 컨테이너는 같은 네트워크 네임스페이스를 사용하며 동일한 볼륨을 참조할 수 있다.
• 자동 복구: 파드가 종료되거나 실패할 경우 쿠버네티스가 자동으로 재생성한다.

---

Node

Node는 파드를 실제로 실행하는 물리적 또는 가상 머신이다.
각 노드는 Control Plane에 의해 관리되며 다음과 같은 구성 요소를 포함한다.

• kubelet: 파드 상태를 감시하고 보고하는 역할을 한다.
• kube-proxy: 네트워크 통신 및 포워딩을 담당하는 프록시 컴포넌트
• 컨테이너 런타임: Docker, containerd 등 실제 컨테이너 실행을 담당하는 소프트웨어

Node는 역할에 따라 아래와 같이 나뉜다.

• 마스터 노드: 클러스터 전체의 제어 및 관리를 담당
• 워커 노드: 실제로 파드가 배포되어 동작하는 노드

---

Cluster

클러스터는 여러 노드(Node)로 구성된 논리적인 단위다.
클러스터에는 전체 상태를 제어하는 Control Plane이 존재하고, 이 구성 요소들은 보통 마스터 노드에 설치되어 실행된다.

Control Plane을 구성하는 주요 컴포넌트는 다음과 같다.

• kube-apiserver: 클러스터의 모든 요청을 처리하는 API 서버.
• etcd: 클러스터의 상태 데이터를 저장하는 분산 키-값 저장소.
• scheduler: 새로 생성된 파드를 적절한 노드에 배치한다.
• controller-manager: 다양한 컨트롤러를 실행하여 클러스터 상태를 관리.
• cloud-controller-manager: 클라우드 환경(AWS, GCP 등)과의 연동을 담당.

---

쿠버네티스 내부 통신과 라우팅

쿠버네티스에서 파드는 고유한 IP 주소를 받아 네트워크 통신이 가능하다.
하지만 파드는 삭제되었다가 다시 생성되면 IP가 바뀔 수 있기 때문에, 파드에 직접 접근하는 방식은 안정적이지 않다.

이 문제를 해결하기 위해 쿠버네티스는 Service라는 추상화 계층을 제공한다.
Service는 파드 앞단에서 고정된 네트워크 접근 지점 역할을 하며, 트래픽을 해당 파드들로 안정적으로 전달해준다.

Service의 주요 유형

• ClusterIP: 클러스터 내부에서만 접근 가능
• NodePort: 외부에서 특정 포트를 통해 접근 가능
• LoadBalancer: 클라우드 환경에서 외부 로드밸런서를 생성
• ExternalName: 외부 도메인을 내부 서비스처럼 연결

---

Ingress – 외부 트래픽의 진입점

Ingress는 외부에서 들어오는 HTTP/HTTPS 요청을 클러스터 내부의 적절한 서비스로 라우팅해준다.
하나의 진입점(예: Load Balancer)을 통해 다양한 경로나 도메인 기반의 요청을 분기시킬 수 있다.

Ingress가 지원하는 주요 기능:

• 경로 기반 라우팅:
  예) /api는 API 서비스로, /admin은 관리 서비스로 연결
• 호스트 기반 라우팅:
  예) api.example.com → API 서비스, web.example.com → 웹 서비스
• TLS 종료(SSL 처리):
  Ingress에서 HTTPS 요청을 종료하고, 내부 통신은 HTTP로 처리
• 리버스 프록시 역할:
  여러 백엔드를 하나의 도메인 아래에서 통합

Ingress는 단독으로 작동하지 않는다. 반드시 함께 동작할 Ingress Controller가 필요하다.
대표적인 컨트롤러로는 NGINX Ingress Controller, Traefik, AWS ALB Ingress Controller 등이 있다.

---

kube-proxy – 서비스 트래픽 전달자

kube-proxy는 각 노드에서 실행되는 네트워크 컴포넌트로,
Service로 들어온 요청을 실제 파드로 전달하는 역할을 한다.

• 서비스의 ClusterIP로 요청이 오면, kube-proxy가 연결된 파드 중 하나로 트래픽을 전달한다.
• 내부적으로는 iptables 또는 IPVS 같은 리눅스 커널 기능을 활용해 로드밸런싱 처리를 수행한다.
• 여러 파드가 같은 서비스에 연결돼 있다면, 요청을 자동으로 분산 처리해준다.

kube-proxy는 클러스터 안에서 서비스 이름 → 파드 IP로 연결을 맵핑해주는 브릿지 역할을 한다.

---

스케줄링 개요

파드가 생성되면, 쿠버네티스는 이를 어느 노드에 배치할지 자동으로 결정한다. 이 과정을 스케줄링이라고 한다.

스케줄링 시 고려되는 주요 기준은 다음과 같다.

• 파드가 요구하는 CPU, 메모리 등 리소스
• 노드의 현재 상태와 리소스 여유
• Affinity / Anti-affinity: 특정 노드에 배치하거나 피하도록 설정된 규칙
• Taints / Tolerations: 특정 노드가 특정 파드를 받지 않도록 설정된 제약
• 네트워크 조건이나 데이터 지역성 등 기타 제약 조건

스케줄링 이후에도 쿠버네티스는 파드 상태를 지속적으로 모니터링하고,
필요 시 자동으로 재스케줄링을 수행해 안정성을 유지한다.

---

오토스케일링 (Auto Scaling)

애플리케이션 부하에 따라 파드 수나 리소스를 자동으로 조절하는 기능이다.

• Horizontal Pod Autoscaler (HPA)
  CPU, 메모리 등의 메트릭 기반으로 파드 수를 자동으로 조절한다.
• Vertical Pod Autoscaler (VPA)
  각 파드에 할당된 리소스(CPU/메모리)를 자동으로 조정한다. 주로 상태 비저장(stateless) 파드에 적용된다.

이 기능들을 통해 시스템 자원을 효율적으로 사용할 수 있고, 예상치 못한 트래픽 증가에도 안정적으로 대응할 수 있다.