Container Harbour에 오신 것을 환영합니다! 🚢 Ep.1

Source: Dev.to

들어보세요. 들어보세요. 여러분의 앱에 대해 이야기해야 합니다. 🎤

뭐가 나를 웃게 하는지 아세요? 누군가가 “Kubernetes가 뭐예요?” 라고 물을 때마다, 대답하는 사람이 조용해지고 눈에 먼 곳을 바라보다가… 이렇게 말합니다:

“음, 이것은 컨테이너 오케스트레이션 플랫폼으로, 클러스터의 노드 전반에 걸쳐 컨테이너화된 애플리케이션의 배포, 스케일링 및 관리를 자동화합니다…”

그리고 질문한 사람은 천천히 고개를 끄덕이며 이해한 척 서 있습니다. 실제로는 소리치고 있습니다. 😱

여기서는 그런 일이 일어나지 않을 겁니다. 절대요.

여기서는 항구로 갈 겁니다. 🚢

장면: 분주한 화물 항구 🌊

이 상황을 상상해 보세요: 새벽 6시입니다. 물 위에 해가 떠오르고 있습니다. 갈매기들은 갈매기답게 (대부분은 문제를 일으키며) 행동하고 있습니다. 그리고 항구는? 항구는 ALIVE(살아 있습니다).

배들은 전 세계 곳곳—로테르담, 상하이, 케이프 타운—에서 들어옵니다. 각 배는 freight containers(화물 컨테이너)로 가득 차 있습니다—화물선에 쌓여 있는 큰 강철 상자를 말합니다. 각 컨테이너는 하나의 임무만을 가지고 있습니다. 바나나 🍌, 전자제품, 가구 등 무엇이든 좋습니다. 중요한 건 하나의 물건을 깔끔하게 포장해 사용 준비가 된 상태라는 점입니다.

그렇다면, 이 모든 것이 완전한 혼돈으로 빠지지 않도록 누가 관리할까요?

항구장 🎩

항구장은 다음을 알고 있습니다:

• 어떤 컨테이너가 언제 도착하는지
• 각 컨테이너가 어느 부두에 배정되는지
• 필요한 포크리프트 운전사 수
• 컨테이너가 물에 빠졌을 때 어떻게 할지 (실제로 일어납니다)
• 거대한 배가 예고 없이 나타났을 때 추가 인력을 언제 부를지

항구장은 무거운 작업을 직접 하지 않습니다. 그것이 그의 역할이 아니죠. 항구장은 orchestrates(조율)합니다—계획하고, 감시하고, 대응하고, 명령합니다.

익숙하게 들리나요? 친구여, 그것이 바로 Kubernetes입니다. 🎯

여러분의 앱은 화물 컨테이너 📦

잠시 뒤로 물러서 봅시다. 항구에 도착하기 전에, 컨테이너 안에 무엇이 들어있는지 이야기해야 합니다.

예전, 2010년 즈음에 앱을 배포하던 방식은 다음과 같았습니다:

1. 애플리케이션 코드를 작성한다.
2. 동료에게 “이거 서버에 배포해줄 수 있어?” 라고 말한다.
3. 그들은 왜 당신 컴퓨터에서는 동작하는데 그들 컴퓨터에서는 안 되는지 삼 일 동안 고민한다.

“But I installed Python 3.8!”
“Yeah, but the server has Python 3.6…”
“But I set the environment variable!”
“Which one?!”

이런, 제발. 🤦

그때 Docker와 컨테이너가 등장했습니다. 컨테이너는 이렇게 말했습니다:

“앱이 필요로 하는 모든 것—코드, 런타임, 라이브러리, 환경 변수—을 하나의 깔끔하고 표준화된 상자에 담으면 어떨까요?”

마치 화물 컨테이너와 같습니다. 로테르담에서 바나나를 포장해 바다를 건너 뉴욕에 도착하면—무엇이 될까요? 여전히 바나나입니다. 놀라움도 없고, “바나나는 내 배에서는 잘 작동했는데…” 같은 일도 없습니다.

이것이 컨테이너의 마법입니다. 🍌➡️🌊➡️🍌

알겠는데, 왜 항구장(Harbourmaster)이 필요할까? 🤔

좋은 질문이에요. 이제 본격적으로 들어갑니다.

항구에 하나의 컨테이너만 있다고 상상해 보세요. 간단하죠! 항구장이 필요 없어요. 그냥 어디에든 두면 끝입니다.

이제 12척의 서로 다른 배에서 500개의 컨테이너가 도착한다고 상상해 보세요. 어떤 것은 서로 가까이 있어야 하고, 어떤 것은 차가운 상태를 유지해야 하며, 어떤 것은 깨지기 쉬워서, 어떤 것은 거대하고, 그리고 세 개는 Dave가 주의를 기울이지 않아 물에 빠졌습니다. 다시 말해요.

이제 책임자를 필요로 합니다. 지금 바로 항구장이 필요합니다.

그리고 이것이 애플리케이션이 성장할 때 일어나는 일과 정확히 같습니다:

규모가 커지면, 컨테이너를 수동으로 관리하는 것은 갈매기에게 소리치는 식으로 항구를 운영하는 것과 같습니다. 갈매기들은 듣지 않고, 아무 일도 이루어지지 않으며, 결국 당신은 목이 쉬고 슬퍼지게 됩니다. 😢

Dave가 더 이상 감당할 수 없을 때 부르는 것이 Kubernetes입니다. 🚒

항구: 다가오는 것들의 지도 🗺️

제가 전체 투어를 안내해 드리겠습니다. 이번 시리즈에서는 항구를 하나씩 살펴볼 예정입니다. 전체적인 구성을 미리 살펴보면 다음과 같습니다:

🌊 THE HARBOUR (Your Kubernetes Cluster)
│
├── 🏗️  The Quays (Nodes)
│       Physical docking space where containers actually live
│
├── 📦  The Freight Containers (Pods)
│       Your apps, packed and ready to go
│
├── 🏢  The Harbourmaster's Tower (Control Plane)
│       The brain of the operation: API Server, Scheduler, etcd...
│
├── 🚦  The Entry Gates (Services)
│       Controls who gets in and where traffic goes
│
├── 🛃  The Customs Office (Ingress)
│       Smart routing: "Rotterdam cargo goes to Bay 4, Shanghai to Bay 7"
│
├── 🔐  The Sealed Cargo Manifests (ConfigMaps & Secrets)
│       Configuration that travels with the container — some of it classified
│
├── 🏭  The Long‑Term Warehouse (Persistent Volumes)
│       For cargo that needs to stick around even when the ship leaves
│
├── 🪪  The Security Office (RBAC)
│       ID badges, access control, and why Dave can't touch the database anymore
│
├── 🩺  The Health Inspectors (Liveness & Readiness Probes)
│       "Is this container actually doing anything, or just PRETENDING to work?"
│
└── 📈  The Expansion Crew (Autoscaling)
        When a massive unexpected ship arrives, the harbour GROWS

우리는 이 요소들을 하나씩, 에피소드별로 차근차근 살펴볼 것입니다. 서두르지 마세요. 이해되지 않는 전문 용어는 남겨두지 않을 겁니다.

우리는 이 모든 항목을 하나씩, 에피소드마다 방문할 예정입니다. 서두르지 마세요. 설명되지 않은 전문 용어는 없습니다.

쿠버네티스가 답하는 세 가지 질문 🎯

그 핵심에서, 쿠버네티스는 세 가지 질문에 답합니다. 나머지는 세부 사항일 뿐입니다.

질문 1: 이것은 어디서 실행되나요? 🤷

컨테이너와 여러 서버(노드)가 있습니다. 어느 서버에 어떤 컨테이너를 배치할지 수동으로 결정하고 싶지 않죠. 쿠버네티스는 사용 가능한 리소스, 기존 워크로드, 제약 조건을 살펴보며 자동으로 결정합니다.

질문 2: 아직 실행 중인가요? 👀

무언가 실패하면—서버가 다운되고, 네트워크가 끊기고, 메모리 누수가 발생하고, 데이브가 실수로 무언가를 삭제한다—쿠버네티스는 끊임없이 모든 것을 감시하고, 문제가 발생하면 자동으로 해결합니다. 커피를 마시기 전에도 말이죠.

질문 3: 어떻게 확장하나요? 📈

트래픽이 하룻밤 사이에 두 배가 되거나 절반이 되거나, 금요일 오후 5시에 이유 없이 급증합니다. 쿠버네티스는 수요가 증가하면 자동으로 더 많은 컨테이너를 추가하고, 감소하면 제거합니다.

“하지만 Docker Compose만 쓰면 안 될까?” 😬

솔직한 답변: 예. 작은 경우라면 절대적으로 가능합니다.

Docker Compose는 푸드‑트럭 🚐을 운영하는 것과 같습니다 – 빠르고 간단하며 모든 것이 어디에 있는지 정확히 알 수 있습니다.

그 푸드‑트럭이 15개국에 200개 지점을 가진 레스토랑 체인이 되면, Docker Compose는 슬픈 Docker‑고래 눈으로 당신을 바라보며 말합니다:

“I… I can’t do this.” 🐳

Kubernetes는 레스토랑 체인을 위해 설계되었습니다. 보트가 아니라 항구를 위해 만들어졌습니다.

그렇다고 해서 항상 정답인 것은 아닙니다. 개인 블로그를 운영한다면 Kubernetes는 과도합니다 – 마치 한 판의 피자를 배달하기 위해 화물선을 사용하는 것과 같습니다. 🍕🚢

규모가 중요하고, 신뢰성이 중요하며, *“그냥 작동하면 돼”*가 중요할 때 – Kubernetes가 답입니다.

따라하기 위해 필요한 것 🛠️

걱정 마세요 — 1일 차에 바로 깊은 바다에 뛰어들게 하지는 않아요. 시리즈를 위해 필요한 것이 여기 있습니다:

• kubectl – Kubernetes와 대화하기 위한 커맨드라인 도구입니다. 항구장군에게 무전하는 라디오라고 생각하세요. 📻
• 로컬 클러스터 – kind (Kubernetes IN Docker) 또는 minikube 를 권장합니다. 노트북에 있는 작은 연습용 항구입니다. 🖥️
• Docker – 컨테이너를 실행할 무언가가 필요하기 때문이죠. 🐳
• 호기심과 유머 감각 – 필수입니다. 협상 불가. 항구장군이 강력히 요구합니다. 🎩

설치하면 Episode 2를 준비한 것입니다 — 여기서는 화물 컨테이너 내부 깊숙이 들어가 Pod를 만나게 됩니다.

항구장의 일지 — Entry 1 📋

항구의 첫째 날. 아침 안개가 걷히고 있다. 지평선에 12척의 배가 보이며, 각각은 마이크로‑서비스가 가득 담긴 컨테이너를 싣고 있다. 포크리프트 운전사들은 준비가 끝났다. 게이트는 열려 있다. 커피는 진하다.

누군가가 나에게 묻는다: “쿠버네티스가 실제로 뭔가요?”

나는 항구를 바라본다 – 완벽하게 조율된 혼돈, 정밀하게 움직이는 컨테이너들, 정확히 트래픽을 라우팅하는 게이트, 순찰하는 건강 검사관들, 장기 화물을 안전하게 보관하는 창고.

“그건 항구입니다,” 라고 나는 말한다. “그리고 우리는 이제 시작일 뿐이죠.” ⚓

다음 회 “Welcome to Container Harbour” 🎬

Episode 2에서는 화물 컨테이너를 열어보고 Pod — Kubernetes의 가장 기본적인 단위와 만나게 됩니다.

• 안에 무엇이 들어갈까?
• 왜 일부 컨테이너는 같은 트럭을 공유할까?
• 화요일 새벽 2시 에 하나가 물에 빠지면 실제로 무슨 일이 일어날까?

스포일러: Kubernetes는 이에 대해 매우 침착합니다. 당신보다 더 침착하죠. 😅

그때까지 — 항구에 오신 것을 환영합니다. 승강대가 내려왔습니다. 탑승하세요. 🚢⚓

P.S. — 로테르담의 실제 항만관리자는 연간 약 30,000 척의 선박을 관리합니다. 주요 기업에서 Kubernetes는 하루에 수백만 개의 컨테이너 시작을 관리합니다. 두 경우 모두 여러분에게 알리고 싶습니다: 그들은 충분히 인정받지 못하고 있습니다. 🎩

주요 요점

• Containers = 애플리케이션을 위한 표준화된 화물 상자 — 어디서나 동일하고, 놀라움이 없습니다.
• Kubernetes = 항구장(하버마스터) — 조정하고, 감시하고, 수정하고, 확장합니다.
• Cluster = 전체 항구 — 노드는 컨테이너가 사는 부두입니다.
• Why Kubernetes? — 500개의 컨테이너를 수동으로 관리하면 당신이 망하게 되기 때문입니다.
• 3 core questions: 어디서 실행되나요? 아직 실행 중인가요? 어떻게 확장하나요?
• Docker Compose = 푸드트럭 🚐 Kubernetes = 글로벌 레스토랑 체인 🏢
• Local practice options: kind 또는 minikube — 당신만의 개인 훈련 항구.
• 갈매기는 아키텍처의 일부가 아닙니다. 갈매기는 무시하세요. 🐦