[리눅스 기초 #57] 컨테이너 함대의 제독이 되다: 쿠버네티스(Kubernetes) 핵심 개념과 첫 클러스터 구축

 

리눅스 기초 시리즈의 57번째 시간입니다! 지난 시간에는 우리가 발을 딛고 있는 토양인 클라우드 인프라를 코드로 설계하는 테라폼(Terraform)을 다뤘습니다. 이제 우리는 명령 한 줄로 서버 수십 대를 순식간에 창조할 수 있는 능력을 갖췄습니다.

그런데 서버가 늘어나고 그 안에서 돌아가는 Docker 컨테이너가 수백 개가 된다면 어떨까요? 어떤 컨테이너가 죽었는지, 트래픽이 몰릴 때 어느 서버의 컨테이너를 늘려야 할지 사람이 일일이 관리하는 것은 불가능에 가깝습니다. 오늘은 이 컨테이너 함대를 지휘하는 거대한 지능형 운영체제, 쿠버네티스(Kubernetes)의 기초를 저의 경험담과 함께 정리해 보겠습니다.

---

1. 나의 경험담: "새벽의 호출기, 쿠버네티스가 대신 받다"

 

제가 처음 대규모 서비스를 운영했을 때, 가장 두려웠던 것은 '새벽의 서버 다운'이었습니다. 특정 컨테이너가 알 수 없는 이유로 죽으면, 저는 자다가 일어나 SSH로 접속해 docker restart를 쳐야 했죠. 하지만 쿠버네티스를 도입한 후, 제 삶의 질은 180도 바뀌었습니다.

쿠버네티스는 제가 명령하지 않아도 컨테이너의 상태를 1초 단위로 감시합니다. 만약 컨테이너가 죽으면? 쿠버네티스가 즉시 새로운 컨테이너를 살려냅니다. 사용자가 몰려 서버가 힘들어하면? 알아서 옆 서버에 컨테이너 복제본을 늘려버리죠. 저는 그저 '내가 원하는 최종 상태'만 선언해두면 됩니다. 마치 숙련된 조타수들이 알아서 움직이는 거대한 항공모함의 제독이 된 기분이었습니다.

---

2. Before: 수동 조타의 한계, Docker Compose의 그림자

쿠버네티스 이전에는 Docker Compose에 의존했습니다. 한 대의 서버 안에서는 훌륭했지만, 서버가 2대, 3대로 늘어나는 순간 관리가 불가능해졌습니다. "A 서버가 죽으면 B 서버로 트래픽을 어떻게 옮기지?"라는 질문에 답하기 위해 복잡한 네트워크 설정을 수동으로 만져야 했죠.

기존의 한계 (Docker Compose):

Bash Shell

 

# 서버 한 대가 물리적으로 죽으면,

그 안의 컨테이너들도 함께 영영 사라집니다.
관리자가 직접 새 서버를 띄우고 다시 실행해야 하죠.
docker-compose up -d # (수동 복구의 시작...)

(▲ Before: 서버 장애가 발생하면 관리자의 '손'이 반드시 필요했던 수동적인 시대였습니다.)

---

3. Action: 쿠버네티스 선언문(Manifest) 작성하기

 

이제 우리는 리눅스 터미널에서 쿠버네티스에게 "내 웹 서비스를 3개의 복제본으로 유지해줘"라고 명령하는 YAML 설정 파일을 작성해 보겠습니다.

실전 Deployment 코드 (nginx-deploy.yaml):

YAML Manifest

 

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-web-server
spec:
replicas: 3 # 언제나 3개의 컨테이너를 띄우라고 명시!
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80

(▲ Action: kubectl apply -f nginx-deploy.yaml 명령어를 실행하면, 쿠버네티스가 클러스터 전체 노드 상황을 파악해 가장 여유로운 곳에 3개의 Nginx 컨테이너를 골고루 배치합니다.)

---

4. After: 무너지지 않는 불사신 서버 환경

쿠버네티스를 구축하고 나면, 리눅스 관리의 관점이 '서버 한 대'에서 '서비스 전체'로 확장됩니다.

달라진 점들:

• 자가 치유(Self-Healing): 컨테이너가 응답하지 않으면 자동으로 죽이고 새로 살려냅니다.
• 무중단 배포: 새로운 버전의 코드를 올릴 때, 컨테이너를 하나씩 교체하며 서비스 중단 없이 업데이트합니다.
• 추상화된 인프라: 이제 개발자는 실제 서버가 어디에 있는지 몰라도 됩니다. 쿠버네티스라는 거대한 리소스 풀(Pool)만 바라보면 되니까요.

---

5. 핵심 용어 요약

용어	역할	비유
Node	리눅스 서버 본체	화물을 싣는 배 한 척
Pod	컨테이너의 최소 실행 단위	표준화된 화물 컨테이너 박스
Deployment	애플리케이션 배포 및 관리	운항 계획서
Service	네트워크 노출 및 로드밸런싱	항구의 안내 데스크

---

6. 마치며: 항해의 정점에 도달할 준비가 되었나요?

리눅스 기초 57단계를 통해 우리는 이제 한 대의 엔진(서버)을 고치는 기술자를 넘어, 수만 개의 컨테이너가 유기적으로 움직이는 생태계를 설계하는 아키텍트의 문턱에 섰습니다. 쿠버네티스는 어렵지만, 그만큼 여러분의 가치를 높여줄 가장 강력한 무기입니다.

오늘의 인사이트: "쿠버네티스는 단순한 도구가 아니라, 장애를 상수로 받아들이고 극복하는 인프라의 철학이다."

---

57번째 이야기를 마칩니다. 이제 우리만의 '컨테이너 제국'이 건설되었습니다. 다음 시간에는 이 복잡한 쿠버네티스 자원들을 마치 윈도우 앱 깔듯 클릭 한 번으로 설치하게 해주는 '쿠버네티스의 패키지 매니저, 헬름(Helm) 완벽 활용법'에 대해 다뤄보겠습니다.

이 글이 여러분의 쿠버네티스 공포증을 해소하는 데 도움이 되었나요? 혹시 로컬 환경에서 가볍게 연습해볼 수 있는 'Minikube'나 'k3s' 설치 방법이 궁금하신가요?

초보자를 위해 내 컴퓨터에 5분 만에 쿠버네티스 연습장을 차리는 법을 다음 포스팅 부록으로 준비해 드릴까요?