쿠버네티스 클러스터 구축 가이드 — The Hard Way부터 kubeadm, k3s, 관리형 서비스까지

컨테이너 기술이 소프트웨어 배포의 표준으로 자리 잡으면서, 여러 대의 서버에 걸쳐 수많은 컨테이너를 자동으로 배치하고 장애를 복구해 주는 오케스트레이션 도구로 쿠버네티스(Kubernetes, K8s) 는 이제 엔지니어링의 필수 인프라가 되었습니다.

하지만 쿠버네티스를 직접 구축하려고 하면 시작부터 난관에 부딪힙니다. minikube, kind, k3s, kubeadm, Kubespray, EKS, GKE, Rancher 등 설치 도구만 수십 가지에 달하기 때문입니다.

도커(Docker)는 단일 패키지 설치 한 줄로 끝나는데, 왜 쿠버네티스는 이토록 구축 방법이 다양하고 복잡할까요?

1. 쿠버네티스 설치가 이토록 다양하고 복잡한 이유

쿠버네티스 설치가 복잡한 근본적인 이유는, 쿠버네티스가 단일 프로그램이 아니라 여러 독립적인 서비스들이 네트워크로 유기적으로 통신하는 분산 시스템(Distributed System) 이기 때문입니다.

쿠버네티스 클러스터가 정상 동작하려면 최소한 다음 컴포넌트들이 각자의 자리에서 완벽하게 맞물려 돌아가야 합니다:

• 클러스터의 뇌 역할을 하는 컨트롤 플레인 (Control Plane):

  • etcd: 클러스터의 모든 설정값과 현재 상태를 영구 보관하는 고가용성 분산 저장소입니다.
  • kube-apiserver: 모든 컴포넌트와 관리자가 대화하는 유일한 중앙 관문입니다.
  • kube-scheduler: 새로 실행할 컨테이너(파드)를 어느 서버(노드)에 배치할지 자원 상황을 보고 결정합니다.
  • kube-controller-manager: 컨테이너가 죽으면 다시 살려내고 복제본 개수를 유지하는 자가 치유 루프를 실행합니다.

• 실제 컨테이너가 돌아가는 워커 노드 (Worker Node):

  • kubelet: 각 서버에 상주하며 API 서버의 지시를 받아 실제 컨테이너를 띄우고 상태를 보고하는 현장 관리자입니다.
  • kube-proxy: 파드 간 네트워크 통신과 서비스 부하 분산을 위해 호스트의 네트워크 라우팅 규칙을 제어합니다.
  • 컨테이너 런타임 (containerd 등): 이미지를 내려받고 실제 프로세스로 구동하는 엔진입니다.
  • CNI (Container Network Interface): 서로 다른 물리 서버에 뜬 컨테이너들끼리 단일 사설망처럼 통신할 수 있게 IP를 할당하는 가상 네트워크 플러그인입니다.

여기에 더해 엔지니어가 클러스터를 올리려는 인프라 환경도 천차만별입니다. 개발자 개인의 노트북 1대부터, 수십 대의 물리 서버가 꽂힌 프라이빗 데이터센터(IDC), Proxmox 같은 사내 가상화 하이퍼바이저, 그리고 AWS나 GCP 같은 퍼블릭 클라우드까지 요구되는 가용성과 네트워크 제약이 완전히 다릅니다.

따라서 쿠버네티스 생태계는 각 환경의 제약과 운영 목적에 맞춰 서로 다른 구축 도구들을 발전시켜 왔습니다.

2. 완전 수동 설치: Kubernetes The Hard Way

구글의 클라우드 네이티브 엔지니어 켈시 하이타워(Kelsey Hightower)가 만든 깃허브 튜토리얼로 유명해진 방식입니다.

어떠한 설치 자동화 도구도 쓰지 않고, 순수하게 리눅스 운영체제 위에서 원시 도구만으로 모든 과정을 직접 조립합니다:

• cfssl이나 openssl을 사용해 클러스터 루트 CA(인증 기관)를 만들고, 컴포넌트 간 mTLS(상호 TLS) 암호화 통신에 필요한 수십 개의 인증서와 개인키를 일일이 생성하고 서명합니다.
• etcd 바이너리를 다운로드하여 3대의 마스터 노드에서 분산 Raft 클러스터를 구성합니다.
• kube-apiserver, kube-controller-manager, kube-scheduler의 systemd 서비스 유닛 파일을 직접 작성하여 운영체제 백그라운드 데몬으로 등록합니다.
• 워커 노드에 containerd, crictl, kubelet, kube-proxy 바이너리를 배치하고 네트워크 설정을 잡습니다.

실제 상용 서비스 환경에서 The Hard Way로 클러스터를 운영하는 기업은 거의 없습니다. 설치에만 반나절 이상이 걸리고, 설정 오타 하나로 통신이 끊기며, 향후 버전 업그레이드와 노드 확장의 관리 비용이 지나치게 크기 때문입니다.

하지만 이 과정은 독보적인 학습 효과를 줍니다. “API 서버와 etcd는 어떤 인증서로 대화하는가?”, “kubelet이 apiserver에 등록될 때 인증 토큰은 어떻게 검증되는가?” 같은 쿠버네티스의 심장부 배관(Plumbing)을 완벽하게 이해할 수 있습니다. CKA(공인 쿠버네티스 관리자) 시험을 준비하거나 내부 수준의 장애 트러블슈팅 역량을 기르고 싶다면 최고의 수련 코스입니다.

3. 공식 표준 CLI: kubeadm (온프레미스의 정석)

쿠버네티스 공식 프로젝트(SIG-Cluster-Lifecycle)가 제공하는 베스트 프랙티스 부트스트랩 도구입니다.

수동 설치의 복잡한 인증서 발급과 설정 파일 매핑을 단 몇 줄의 직관적인 명령어로 해결합니다:

# 1. Initialize cluster on control plane node
sudo kubeadm init --pod-network-cidr=192.168.0.0/16

# 2. Join worker node to control plane
sudo kubeadm join 192.168.1.10:6443 --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:1234..5678

kubeadm의 가장 뛰어난 설계적 특징은 컨트롤 플레인 컴포넌트들을 호스트 OS의 systemd 데몬으로 돌리지 않고, 스태틱 파드(Static Pod) 형태로 격리하여 기동한다는 점입니다:

• kubeadm init을 실행하면 apiserver, etcd, controller-manager, scheduler의 YAML 매니페스트가 /etc/kubernetes/manifests/ 디렉터리에 자동 생성됩니다.
• 호스트에서 유일하게 systemd 데몬으로 돌고 있는 kubelet이 이 디렉터리를 감시하다가, 정의된 매니페스트를 읽고 로컬 containerd 런타임을 통해 마스터 컴포넌트들을 컨테이너로 띄웁니다.
• 마스터 컴포넌트마저 컨테이너로 격리함으로써 호스트 환경 오염을 방지하고 상태 추적을 일원화한 것입니다.

한 가지 주의할 점은 kubeadm이 의도적으로 CNI(네트워크 플러그인)를 기본 설치하지 않는다 는 점입니다. 클러스터를 초기화한 직후 노드 상태를 조회하면 NotReady로 표시되며, Calico, Cilium, Flannel 같은 CNI 매니페스트를 kubectl apply -f로 별도 배포해야 파드 간 IP 통신이 활성화되면서 노드가 정상적인 Ready 상태로 전환됩니다.

물리 베어메탈 서버나 IDC 환경에서 클러스터를 직접 소유하고 제어하려 할 때 가장 널리 쓰이는 표준적인 기초 토대입니다.

4. 대규모 베어메탈 자동화: Kubespray & RKE

kubeadm은 훌륭한 도구이지만, 서버가 수십–수백 대에 달하면 한계가 드러납니다. 각 서버에 일일이 SSH로 들어가서 스왑(Swap) 메모리를 끄고, 리눅스 커널 모듈(overlay, br_netfilter)을 올리고, sysctl 네트워크 파라미터를 맞추는 사전 작업은 여전히 사람의 손을 타기 때문입니다.

이 지점을 코드로 전자동화(IaC)해 주는 도구들이 등장했습니다:

• Kubespray (Ansible 기반):
  • 오픈소스 커뮤니티에서 가장 성숙한 대규모 클러스터 배포 도구입니다.
  • 인벤토리 파일(서버 IP와 역할 목록)만 작성해 두고 Ansible 플레이북을 실행하면, OS 기본 설정부터 방화벽 오픈, containerd 설치, kubeadm 실행, 마스터 노드 고가용성(HA)을 위한 HAProxy/Keepalived 구성, CNI 설치까지 모든 과정을 무인으로 끝내줍니다.
• Rancher RKE / RKE2:
  • 렌처(Rancher)가 개발한 엔터프라이즈급 쿠버네티스 배포 엔진입니다.
  • 특히 RKE2는 미국 정부의 FIPS 보안 규정을 만족하도록 설계된 보안 강화 배포판으로, 단일 YAML 설정 파일만으로 클러스터의 생성, 백업, 무중단 롤링 업그레이드를 제어합니다.

수십 대 이상의 물리 서버를 직접 운영해야 하는 프라이빗 데이터센터나 온프레미스 엔터프라이즈 환경에서 가장 신뢰받는 선택지입니다.

5. 초경량 및 로컬 개발용: k3s, kind, minikube

실제 대규모 상용 서비스가 아니라 개발자 개인의 로컬 테스트, CI/CD 자동화 파이프라인, 혹은 자원이 제한된 환경(라즈베리파이, IoT 엣지 디바이스)에서는 풀스펙 쿠버네티스를 띄우는 것이 심각한 자원 낭비입니다.

• k3s (Rancher 개발):
  • 쿠버네티스 공식 인증(CNCF Certified)을 받은 대표적인 초경량 배포판입니다.
  • 구형 인트리(In-tree) 클라우드 프로바이더 코드와 불필요한 알파 기능들을 과감히 덜어내고, 모든 컴포넌트를 단 100MB 크기의 단일 실행 바이너리 로 압축했습니다.
  • 무거운 etcd 대신 가벼운 SQLite 를 기본 데이터베이스로 사용할 수 있어, 512MB RAM을 가진 라즈베리파이나 Proxmox의 경량 VM/LXC 컨테이너에서도 가볍게 돌아갑니다.
• kind (Kubernetes in Docker):
  • 도커 컨테이너 자체를 쿠버네티스의 노드로 에뮬레이션하는 기발한 도구입니다.
  • 로컬 머신에 도커만 깔려 있다면, 단 30초 만에 1마스터 2워커 구조의 멀티노드 클러스터를 즉시 띄울 수 있습니다.
  • 테스트가 끝나면 kind delete cluster 한 줄로 흔적 없이 지워버릴 수 있어, GitHub Actions 같은 클라우드 CI/CD 환경에서 통합 테스트를 돌리는 사실상의 글로벌 표준으로 자리 잡았습니다.
• minikube:
  • 로컬 VM이나 도커 기반으로 단일 노드 클러스터를 띄워주는 원조 입문용 도구입니다. 대시보드나 인그레스 같은 애드온을 명령어 하나로 켤 수 있어 초심자 실습용으로 무난합니다.

6. 퍼블릭 클라우드 관리형: Managed K8s (EKS, GKE, AKS, NKS)

오늘날 전 세계 기업의 80% 이상이 실제 상용 서비스 운영을 위해 선택하는 방식입니다.

• AWS: Amazon EKS (Elastic Kubernetes Service)
• GCP: Google Kubernetes Engine (GKE)
• Azure: Azure Kubernetes Service (AKS)
• 네이버클라우드: Ncloud Kubernetes Service (NKS)

관리형 쿠버네티스의 핵심은 “골치 아픈 컨트롤 플레인의 운영 책임을 클라우드 제공자(CSP)에게 완전히 위임한다” 는 점입니다:

• etcd의 멀티 AZ(가용 영역) 분산 복제, 스냅샷 백업, 마스터 노드의 장애 복구, apiserver의 무중단 보안 패치를 클라우드 사업자가 99.95% 이상의 SLA를 걸고 책임집니다.
• 엔지니어는 콘솔 화면에서 클릭 몇 번을 하거나 테라폼(Terraform) 코드로 클러스터를 즉시 프로비저닝하고, 실제 컨테이너가 실행되는 워커 노드 풀(Node Pool)과 비즈니스 애플리케이션 배포에만 집중하면 됩니다.
• 클라우드의 전용 L4/L7 로드밸런서(NLB/ALB), 영구 블록 스토리지(EBS, Persistent Volume), 통합 IAM 권한 체계와 네이티브하게 결합되므로 운영 생산성이 극대화됩니다.

단점은 마스터 노드 운영에 따른 시간당 고정 비용이 발생한다는 점과, 클라우드 인프라에 종속되어 온프레미스 베어메탈처럼 커널 파라미터나 etcd 설정을 극단적으로 커스터마이징하기 어렵다는 점입니다.

7. 한눈에 보는 목적별 선택 가이드

수많은 도구 중에서 지금 어떤 것을 선택해야 할까요? 목적과 인프라 환경에 따라 다음과 같이 명확하게 정리할 수 있습니다.

8. 정리: 도구는 목적을 위한 수단일 뿐이다

처음 쿠버네티스를 마주하면 수많은 설치 도구의 이름에 압도되기 쉽습니다. 하지만 도구의 껍데기를 벗겨내고 나면, 그 안에서 돌아가는 본질은 결국 똑같습니다.

The Hard Way로 올린 바이너리든, kubeadm이 띄운 스태틱 파드든, k3s 안에 압축된 프로세스든, EKS 뒤에 숨겨진 마스터 노드든 모두 동일한 apiserver, etcd, scheduler, kubelet이 모여 선언적 복구 루프(Reconcile Loop)를 돌리고 있는 것 입니다.

중요한 것은 도구의 복잡한 명령어 암기가 아니라, 내가 구축하려는 환경의 제약 조건(비용, 인프라 제어권, 운영 리소스)을 명확히 파악하고 가장 경제적인 도구를 선택하는 엔지니어링 안목 입니다.

로컬 개발 환경이라면 주저 없이 kind나 k3s로 가볍게 시작하고, 온프레미스 인프라를 직접 통제해야 한다면 kubeadm이나 Kubespray를 다루며, 대규모 상용 서비스를 지탱해야 한다면 관리형 서비스를 지렛대 삼아 비즈니스 로직에 집중하는 것이 가장 현명한 접근법입니다.