쿠버네티스(Kubernetes) 입문 가이드 – 개념부터 VM 방식 비교, k3s 설치·사용법까지
서버를 VM 몇 대에 나눠 올리던 방식에서 벗어나 "컨테이너를 자동으로 배포·복구·확장해주는" 쿠버네티스로 옮겨가는 팀이 많아졌습니다. 이 글에서는 쿠버네티스가 정확히 무엇인지, 실무에서 어떤 상황에 쓰이는지, 기존 VM 방식과 비교했을 때 장단점이 무엇인지 살펴본 뒤 초보자도 그대로 따라 할 수 있도록 경량 배포판 k3s를 리눅스에 설치하고 실제로 애플리케이션 하나를 배포해보는 것까지 명령어 단위로 정리했습니다.
1. 쿠버네티스란 무엇인가
한 줄 정의
쿠버네티스(Kubernetes, 줄여서 K8s)는 여러 대의 서버(노드)를 하나의 클러스터로 묶어, 그 위에서 컨테이너 애플리케이션을 자동으로 배치하고, 장애가 나면 스스로 복구하고, 트래픽에 따라 늘리고 줄여주는 "컨테이너 오케스트레이션" 플랫폼입니다. 원래 구글 내부 시스템(Borg)의 노하우를 바탕으로 만들어져 현재는 CNCF(Cloud Native Computing Foundation)가 관리하는 오픈소스 표준입니다.
꼭 알아야 할 핵심 개념 6가지
- Node(노드) – 클러스터를 구성하는 서버 한 대. 실제 컨테이너가 돌아가는 Worker Node와, 클러스터를 지휘하는 Control Plane(Master) Node로 나뉩니다.
- Pod(파드) – 쿠버네티스가 배포하는 가장 작은 단위. 보통 컨테이너 1개를 감싸며, 같은 IP/스토리지를 공유하는 컨테이너 묶음을 담을 수도 있습니다.
- Deployment(디플로이먼트) – "이 이미지를 이 개수만큼 항상 떠 있게 유지해줘"라고 선언하는 리소스. Pod가 죽으면 Deployment가 자동으로 새 Pod를 다시 띄웁니다(Self-healing).
- Service(서비스) – Pod는 재생성될 때마다 IP가 바뀌므로, 고정된 접속 주소(가상 IP/DNS)를 제공해 여러 Pod에 트래픽을 분산하는 역할을 합니다.
- Namespace(네임스페이스) – 하나의 클러스터 안에서 팀/서비스별로 리소스를 논리적으로 나누는 경계입니다.
- ConfigMap / Secret – 설정값이나 비밀번호 같은 값을 컨테이너 이미지와 분리해서 주입하는 방법입니다.
2. 요즘 실무/개인 프로젝트에서 쿠버네티스를 쓰는 대표 사례
어떤 상황에 많이 쓰일까
- 마이크로서비스(MSA) 운영 – 서비스를 기능 단위로 잘게 쪼갠 뒤 각각을 독립적으로 배포·확장할 때, 수십~수백 개의 서비스를 사람이 일일이 관리하기 어려워 쿠버네티스가 표준처럼 쓰입니다.
- 무중단 배포(CI/CD) – 새 버전을 배포할 때 기존 Pod를 순차적으로 교체(Rolling Update)하거나, 문제가 생기면 즉시 이전 버전으로 롤백(Rollback)하는 파이프라인을 표준 기능으로 제공합니다.
- 오토스케일링 – 트래픽이 몰리는 시간대에 자동으로 Pod 개수를 늘리고(HPA), 새벽처럼 한산할 때는 다시 줄여 비용을 절감합니다.
- 멀티 클라우드 / 하이브리드 클라우드 – AWS·GCP·온프레미스 어디서든 동일한 YAML로 배포되므로, 특정 클라우드 벤더에 종속되지 않고 워크로드를 이식할 수 있습니다.
- 배치/스케줄 작업 – Job, CronJob 리소스로 정기 배치나 데이터 파이프라인을 클러스터 자원 위에서 관리합니다.
- 홈랩/개인 서버 통합 운영 – 최근에는 개인 홈서버 한 대에 k3s를 깔아 블로그, Git 서버, DB, 각종 사이드 프로젝트를 네임스페이스로 나눠 함께 운영하는 "홈랩" 용도로도 널리 쓰입니다. VM을 여러 대 쪼개는 대신 컨테이너로 자원을 훨씬 촘촘하게 나눠 쓸 수 있기 때문입니다.
3. 기존 VM 방식과 쿠버네티스(컨테이너) 방식 비교
서버를 VM으로 올리던 방식과 무엇이 다른가
- 배포 속도 – VM: OS 부팅부터 필요해 수 분 단위 / 쿠버네티스: 이미지를 받아 컨테이너만 띄우면 되므로 수 초~수십 초
- 자원 효율 – VM: 게스트 OS마다 커널·메모리를 통째로 점유해 낭비가 큼 / 쿠버네티스: 호스트 커널을 공유하는 컨테이너라 훨씬 촘촘하게 자원 활용
- 확장(스케일) – VM: 새 VM 생성·설정에 수동 작업이 많음 / 쿠버네티스: replicas 숫자만 바꾸면 즉시 확장, 오토스케일링도 표준 지원
- 장애 대응 – VM: 죽으면 알람 받고 사람이 재기동하는 경우가 많음 / 쿠버네티스: Pod가 죽으면 Deployment가 즉시 자동으로 재생성
- 격리 수준 – VM: 하이퍼바이저 레벨의 강한 격리로 보안·호환성이 높음 / 쿠버네티스: 커널 공유 기반이라 VM보다 격리가 약해, 강한 격리가 필요하면 별도 보안 정책이 필요
- 학습 난이도·운영 복잡도 – VM: 기존 서버 운영 지식으로 충분 / 쿠버네티스: YAML, 네트워킹(CNI), 스토리지(CSI) 등 배워야 할 개념이 많고 클러스터 자체의 운영 부담이 있음
- 적합한 규모 – VM: 서버 몇 대 수준의 단순 구성, 레거시 애플리케이션 / 쿠버네티스: 컨테이너 수가 많고 배포가 잦은 환경, 다만 아주 작은 개인 프로젝트라면 오버엔지니어링이 될 수도 있어 이런 경우를 위해 나온 것이 바로 아래 소개할 k3s입니다.
4. 가볍게 시작하는 k3s란?
왜 정식 쿠버네티스 대신 k3s인가
정식 쿠버네티스(kubeadm 등으로 구성)는 etcd, 여러 컨트롤 플레인 컴포넌트가 각각 무겁게 떠 있어 학습·개인용으로는 부담이 큽니다. Rancher(현 SUSE)에서 만든 k3s는 바이너리 하나(약 100MB 이하)에 필요한 컴포넌트를 모두 압축해 담고, 기본 데이터스토어도 etcd 대신 가벼운 SQLite를 사용해 라즈베리파이 같은 저사양 장비에서도 돌아갈 만큼 가볍습니다. 그러면서도 API는 표준 쿠버네티스와 100% 호환되어 실무 학습용으로도 손색없습니다.
5. 리눅스에 k3s 설치하기 (초보자 실습 가이드)
사전 준비
- Ubuntu 20.04+ / Debian / CentOS / Rocky Linux 등 리눅스 서버 1대 (최소 사양: 1 vCPU, 512MB~1GB RAM 이상 권장)
- root 또는 sudo 권한
- 인터넷 연결 (설치 스크립트와 컨테이너 이미지를 내려받아야 함)
1단계. k3s 설치 (마스터 노드, 단 한 줄이면 끝)
curl -sfL https://get.k3s.io | sh -
설치 스크립트가 kubelet, containerd, kube-apiserver 등 필요한 구성요소를 모두 자동으로 설치하고 systemd 서비스(k3s)로 등록해 바로 실행까지 해줍니다.
2단계. 정상 설치 확인
# 서비스 상태 확인
sudo systemctl status k3s
# 노드가 Ready 상태인지 확인 (기본 제공되는 k3s용 kubectl 사용)
sudo k3s kubectl get nodes
# 예상 출력
# NAME STATUS ROLES AGE VERSION
# myhost Ready control-plane,master 30s v1.30.x+k3s1
3단계. 일반 kubectl 명령어를 매번 sudo k3s 없이 쓰기
# kubeconfig 권한 조정 (본인 계정에서 읽을 수 있게)
sudo chmod 644 /etc/rancher/k3s/k3s.yaml
# kubectl이 이 설정을 보도록 환경변수 등록 (bash 기준)
echo 'export KUBECONFIG=/etc/rancher/k3s/k3s.yaml' >> ~/.bashrc
source ~/.bashrc
# k3s에 내장된 kubectl을 그냥 kubectl 명령으로도 쓰고 싶다면
echo "alias kubectl='k3s kubectl'" >> ~/.bashrc
source ~/.bashrc
kubectl get nodes
4단계. (선택) 워커 노드 추가로 멀티 노드 클러스터 구성
# 마스터 노드에서 조인 토큰 확인
sudo cat /var/lib/rancher/k3s/server/node-token
# 워커로 편입시킬 다른 서버에서 실행 (IP/토큰은 실제 값으로 교체)
curl -sfL https://get.k3s.io | K3S_URL=https://<마스터_IP>:6443 K3S_TOKEN=<위에서_확인한_토큰> sh -
# 다시 마스터에서 노드 목록 확인 – 워커가 추가로 보이면 성공
kubectl get nodes
삭제(재설치)가 필요할 때
# 마스터 노드 제거
sudo /usr/local/bin/k3s-uninstall.sh
# 워커 노드 제거
sudo /usr/local/bin/k3s-agent-uninstall.sh
6. 설치 후 기본 사용법 – 예제로 배포해보기
자주 쓰는 kubectl 명령어
kubectl get nodes– 클러스터에 속한 노드 목록 확인kubectl get pods -A– 전체 네임스페이스의 Pod 목록 확인kubectl apply -f 파일.yaml– YAML 파일에 정의된 리소스를 생성/수정 적용kubectl describe pod 파드이름– 특정 Pod의 상세 상태·이벤트 확인 (문제 발생 시 가장 먼저 볼 명령어)kubectl logs 파드이름– 컨테이너 로그 확인kubectl exec -it 파드이름 -- sh– 실행 중인 컨테이너 내부로 접속kubectl delete -f 파일.yaml– YAML에 정의된 리소스 삭제
실습 예제 – nginx 웹서버를 클러스터에 배포하기
아래 내용을 nginx-demo.yaml 파일로 저장합니다. Deployment(2개 복제본)와 이를 외부에 노출하는 NodePort Service를 함께 정의합니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-demo
spec:
replicas: 2
selector:
matchLabels:
app: nginx-demo
template:
metadata:
labels:
app: nginx-demo
spec:
containers:
- name: nginx
image: nginx:stable
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-demo-svc
spec:
type: NodePort
selector:
app: nginx-demo
ports:
- port: 80
targetPort: 80
nodePort: 30080
# 배포
kubectl apply -f nginx-demo.yaml
# Pod, Service가 떴는지 확인
kubectl get pods -l app=nginx-demo -o wide
kubectl get svc nginx-demo-svc
# 접속 테스트 (서버 자신의 IP로)
curl http://localhost:30080
자가 치유(Self-healing) 직접 확인해보기
# 떠 있는 Pod 이름 확인 후 강제로 하나 삭제
kubectl get pods -l app=nginx-demo
kubectl delete pod <방금_확인한_파드이름>
# 바로 다시 조회 – replicas=2를 맞추기 위해 새 Pod가 자동으로 하나 더 생성됨
kubectl get pods -l app=nginx-demo -w
스케일 조정
# 복제본 수를 4개로 즉시 확장
kubectl scale deployment nginx-demo --replicas=4
kubectl get pods -l app=nginx-demo
실습이 끝나면 정리
kubectl delete -f nginx-demo.yaml
7. 운영 팁 & 주의사항
실무에 적용하기 전에 챙길 것들
- 리소스 requests/limits를 반드시 지정 – 지정하지 않으면 Pod 하나가 노드 자원을 다 써버려 다른 서비스에 장애를 일으킬 수 있습니다.
- 데이터 백업 – k3s는 SQLite(또는 embedded etcd)에 클러스터 상태를 저장합니다.
k3s etcd-snapshot또는 정기적인/var/lib/rancher/k3s백업을 습관화하세요. - 영상화 대시보드 활용 – 명령줄이 익숙하지 않다면 k9s(터미널 UI)나 Headlamp 같은 웹 대시보드를 함께 설치하면 클러스터 상태를 훨씬 직관적으로 볼 수 있습니다.
- 버전 업그레이드는 신중하게 – 운영 중인 클러스터는 마이너 버전을 한 단계씩 올리고, 업그레이드 전에는 반드시 스냅샷/백업을 먼저 받아두세요.
마무리
쿠버네티스는 "컨테이너를 자동으로 관리해주는 플랫폼"이라는 개념만 잡으면 생각보다 진입장벽이 높지 않습니다. 특히 k3s는 명령어 한 줄로 설치되고 표준 쿠버네티스 API를 그대로 쓰기 때문에, 개인 서버나 소규모 프로젝트에서 실습하며 감을 익히기에 가장 좋은 선택지입니다. 이 글의 순서대로 설치 → nginx 배포 → 삭제 테스트까지 한 번 직접 해보면, 이후 실무의 정식 쿠버네티스 클러스터를 만나도 개념이 크게 다르지 않다는 것을 느끼실 수 있을 것입니다.
댓글 0
로그인 후 댓글을 작성할 수 있습니다.