쿠버네티스(K8S) 기본 개념 정리 (1)

Seung Hyeon ·2026년 7월 14일

개발 스터디

목록 보기

28/29

도커와 쿠버네티스의 차이

쿠버네티스는 여러 대의 컨테이너가 여러 대의 물리적 서버에 걸쳐 실행된다

도커(Docker)는 한 대의 서버 안에서 컨테이너를 다룬다. 서비스 규모가 작을 때는 이걸로 충분하지만, 트래픽이 늘어 여러 대의 서버에 컨테이너를 나눠 띄워야 하는 순간부터는 한계점이 생긴다. 어떤 서버에 무엇을 몇 개 올릴지, 컨테이너 하나가 죽으면 어느 서버에 다시 살릴지를 사람이 일일이 챙겨야 하기 때문이다.

쿠버네티스(Kubernetes)는 여러 대의 서버에 걸쳐 컨테이너를 다룰 수 있다. 도커 컴포즈 파일과 비슷한 정의 파일(매니페스트)에 "이런 컨테이너를 이만큼 띄운다"고 선언해두기만 하면 쿠버네티스가 그 정의에 맞춰 여러 대의 서버에 컨테이너를 배치하고 상태를 유지한다.

클러스터 구성 — 마스터 노드와 워커 노드

쿠버네티스 클러스터는 역할이 다른 두 종류의 노드로 구성된다.

워커 노드는 컨테이너가 실제로 동작하는 서버이다. 컨테이너가 동작해야 하므로 컨테이너 엔진이 필요하다.
마스터 노드(컨트롤 플레인 노드)는 워커 노드에서 실행되는 컨테이너를 관리한다. 이 둘을 묶어 클러스터라 부른다.

➡️ 이 둘을 묶어 클러스터라 부른다

※ 클러스터의 특징은 사람이 개입하지 않아도 굴러간다는 점이다. 컨트롤 플레인(마스터)에 설정된 내용에 따라 워커 노드가 자동으로 관리되어서, 보통 초기 구성 이후에는 가끔씩만 조정한다.

노드마다 설치되는 소프트웨어가 다르다

쿠버네티스 본체와 CNI(컨테이너 간 통신을 담당하는 네트워크 플러그인)는 마스터·워커 양쪽 노드에 설치된다.
반면 etcd는 마스터 노드에만, 컨테이너 엔진은 워커 노드에만 설치된다.

※ ETCD

컨테이너 상태와 클러스터 정보를 관리하는 키-값 데이터베이스
마스터 노드에만 설치
쿠버네티스가 정의 파일(매니페스트)을 읽으면 그 내용이 etcd에 저장된다.

etcd는 클러스터의 모든 리소스 상태(컨테이너 상태, 클러스터 정보 등)를 저장하는 키-값 저장소다. 매니페스트 파일을 클러스터에 등록하면 그 내용이 etcd에 "바람직한 상태"로 저장되고, 쿠버네티스는 이 상태를 기준으로 클러스터를 관리한다.

컨트롤 플레인의 5가지 구성 요소

마스터 노드(컨트롤 플레인 노드)가 워커 노드를 관리한다고 했는데, 실제로 그 일을 하는 것은 컨트롤 플레인을 구성하는 다섯 개의 컴포넌트다.

kube-apiserver: kubectl로부터 명령을 전달받아 실행한다. 외부와의 통신 창구이자 모든 컴포넌트가 거쳐 가는 유일한 통로다.
kube-controller-manager: 여러 컨트롤러를 통합 관리 및 실행한다.
kube-scheduler: 새로 생성된 파드를 어느 워커노드에 배치할지 결정한다
cloud-controller-manager: 클라우드 서비스(AWS 등)와 연동해 로드밸런서 등의 리소르를 생성한다
etcd: 클러스터의 모든 상태가 저장되는 키-값 저장소 (앞 절 참고)

워커 노드의 구성

kubelet: 워커노드에서 파드를 실제로 실행하는 에이전트
1. kube-scheduler가 파드를 배치할 노드를 결정해 kube-apiserver에 기록
2. kubelet은 apiserver를 확인해보면서 자기 노드로 결정된 파드를 발견하면, 실행
3. 실행 중인 파드의 상태도 apiserver에 상태 보고하고 스케줄러는 이 정보를 보고 다음 배치를 결정한다.
kube-proxy: 노드의 네트워크 규칙을 관리한다. 서비스로 들어온 요청이 파드까지 도달하도록 라우팅을 담당한다.

쿠버네티스의 동작 구조

관리자가 kubectl 명령어를 실행하면 명령이 컨트롤 플레인의 kube-apiserver에 전달된다.
마스터 노드(컨트롤 플레인)가 명령을 처리한다. 내용은 etcd에 저장되고 스케줄러가 파드를 배치할 워커 노드를 결정한다.
워커 노드의 kubelet이 자기 노드에 배정된 파드를 감지해 컨테이너를 실행하고, kube-proxy가 통신 경로를 연결한다.

바람직한 상태 유지

"쿠버네티스는 항상 바람직한 상태를 유지한다"
= 항상 yaml 파일 설정 값을 유지한다

yaml(매니페스트)에 파드 4개로 정의된 상태에서,

파드 하나가 망가지면 → 자동으로 1개 생성
파드를 3개로 수정하면 → 자동으로 1개 삭제

➡️ 쿠버네티스의 기능은 이렇게 "자동으로 상태를 유지하는 것" 이다.

따라서 파드를 삭제하고 싶다면 삭제 명령어가 아니라(사람이 개입X) 매니페스트 파일을 수정해야 한다. 도커 명령어로 파드를 직접 삭제하면, 좀비처럼 자동으로 1개를 보충한다.

파드(Pod)

쿠버네티스에서 하나의 프로그램을 실행시키는 단위

워커 노드는 컨테이너가 실제 동작하는 "서버"이고, 쿠버네티스에서 컨테이너는 낱개가 아니라 파드 단위로 관리된다.
파드 = 컨테이너 + 볼륨. 볼륨은 컨테이너와 정보를 공유하기 위해 사용한다. (단, 볼륨이 없는 파드도 있음)

컨테이너 엔진

워커 노드는 컨테이너가 동작해야 하는 "컨테이너 엔진"이 필요하다

컨테이너 엔진은 파드 안의 컨테이너를 실제로 실행하는 소프트웨어다.

위 그림에서, 컨테이너 엔진은 모든 것을 떠받치는 것처럼 바닥에 깔려있다.

"쿠버네티스 자체는 컨테이너를 직접 실행하지 않는다"
단지 "이 노드에 이런 파드를 띄워라"라고 지시할 뿐이고, 그 지시를 받아 이미지를 내려받고 컨테이너 프로세스를 실제로 띄우는 것은 컨테이너 엔진의 몫이다.

동작 순서
1. kubelet이 "파드를 실행하라"는 지시를 받으면
2. CRI(Container Runtime Interface)라는 표준 규격으로 컨테이너 엔진에 요청하고
3. 컨테이너 엔진이 이미지를 받아 컨테이너를 띄운다

서비스(Service)

여러 파드를 이끄는 반장

서비스의 역할

같은 종류의 파드를 하나의 서비스가 관리한다

여러 워커 노드에 걸쳐 실행되더라도 동일한 구성의 파드는 하나의 서비스가 관리한다

요청(외부에서 들어오는 트래픽)을 배분하는 로드밸런서 역할을 한다

각 서비스는 고정된 IP 주소 Cluster IP를 부여받는다
내부적으로 여러 파드가 있어도 밖에서는 하나의 IP만 보인다
Cluster IP로 접근하면 서비스가 뒤의 파드들로 요청을 적절히 분배한다

레플리카세트(ReplicaSet)

파드의 수를 관리하는 반장

정의 파일에 선언된 파드 수를 기준으로, 파드를 보충하거나 감소시킨다

앞서 본 "바람직한 상태 유지"가 바로 이 컴포넌트의 일이다.
ex) 파드 4개가 선언된 상태에서 하나가 죽으면 레플리카세트가 감지해 1개를 새로 만들고, 3개로 수정하면 1개를 지운다.

➡️ 결국, 파드는 두 명의 반장이 관리하는 셈이다 — 서비스(요청 배분) + 레플리카세트(개수 유지)

레플리카(Replica)

레플리카세트가 관리하는 "동일한 구성"의 파드

디플로이먼트(Deployment)

파드의 "배포"를 관리하며, 파드의 정보를 갖고 있다. 파드를 묶음으로 쉽게 관리한다

레플리카세트는 단독으로 쓰이는 경우가 드물다. 실무에서는 디플로이먼트만 만들고, 레플리카세트와 파드는 디플로이먼트가 알아서 생성한다.

※ 일반적으로 파드 생성은 디플로이먼트로 여러 개를 자동 배포
※ 디플로이먼트가 레플리카세트를 관리하고, 레플리카세트가 여러 파드를 관리한다

디플로이먼트의 장점

파드의 수를 지정하는 대로 여러 개의 파드를 쉽게 생성할 수 있다
ex) 파드를 100개를 생성하라고 시키면 디플로이먼트가 알아서 파드를 100개 생성해준다.
파드가 비정상적으로 종료되면 알아서 새 파드를 생성해 파드 개수를 유지한다.
동일한 구성의 여러 파드를 일괄적으로 중지, 삭제, 업데이트를 하기가 쉽다.
ex) 디플로이먼트를 활용하면 '100개의 파드로 띄워져있는 결제 서버'를 한 번에 일시 중지/삭제/업데이트하는 게 굉장히 쉽다

총정리

Pod : 컨테이너 + 볼륨
Service : 파드에 요청을 배분
Deployment : 파드의 배포를 관리
ReplicaSet : 파드의 수를 관리
Job : 파드를 한 번 실행

매니페스트 파일

파드, 서비스에 대한 설정

매니페스트 파일은 파드, 서비스 같은 리소스에 대한 설정이다. YAML 또는 JSON으로 작성하며, 쿠버네티스에 업로드하면 그 내용이 etcd에 "바람직한 상태"로 등록된다.

매니페스트는 리소스 단위로 작성한다.

리소스: 파드, 서비스, 디플로이먼트, 레플리카세트 등
파드에는 '설정된 개수를 자동으로 유지하는' 기능이 없고, 개수 유지는 디플로이먼트와 레플리카세트에서 담당한다.
다만 디플로이먼트 매니페스트 안에서 레플리카세트와 파드까지 함께 설정할 수 있기 때문에 실무에서는 디플로이먼트 하나만 작성하는 경우가 대부분이다.

파일 관리 — 분할 vs 통합

리소스 단위로 분할: deployment.yml + service.yml처럼 따로 작성
하나의 파일로 통합: deser.yml처럼 한 파일에 작성하고, 리소스 사이를 ---로 구분

※ ---는 YAML 표준의 문서 구분자(document separator). 한 파일 안에 여러 YAML 문서를 담는 YAML 자체의 기능

매니페스트 작성 내용 — 4개의 최상위 필드

apiVersion: API 그룹 및 버전
kind: 리소스 유형
metadata: 메타데이터 — 이름, 레이블 등
spec: 리소스 내용(스펙) — "어떤 리소스를 만들 것인가"

레이블(Label) & 셀렉터(Selector)

레이블은 키-값 쌍의 형태
레이블을 부여하면 셀렉터 기능을 사용해 특정 레이블이 부여된 파드만을 배포할 수 있음 (특정 리소스 선택 가능)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend-app    # 셀렉터: "이 레이블이 붙은 파드가 내 관리 대상"
  template:
    metadata:
      labels:
        app: backend-app  # 레이블: 이 템플릿으로 생성되는 파드에 붙는 이름표
    spec:
      containers:
        - name: backend
          image: backend:1.0