💡 핵심 인사이트
컨테이너(Docker) 1~2개를 노트북에서 띄우는 건 쉽지만, 수천만 명이 접속하는 넷플릭스처럼 **컨테이너 '1만 개'를 클라우드에 띄우고, 죽으면 다시 살려내고, 트래픽이 몰리면 10만 개로 늘려주는 등 수많은 컨테이너를 지휘하는 '마에스트로(지휘자)' 역할의 시스템이 바로 '컨테이너 오케스트레이션(Kubernetes)'**입니다.

Ⅰ. 도커(Docker)의 한계와 오케스트레이션의 필요성

개발자가 앱을 네모난 철제 상자(컨테이너)에 예쁘게 포장하는 것까지는 **도커(Docker)**가 해줬습니다. 그런데 이 상자를 AWS 클라우드라는 거대한 바다에 띄웠을 때 참사가 벌어집니다.

  • 새벽 3시에 1번 컨테이너 서버가 램(RAM) 부족으로 펑 터져서 죽었습니다.
  • 블랙프라이데이 세일이 시작되어 접속자가 100배 늘어 컨테이너 1개로는 도저히 트래픽을 막을 수 없습니다.

사람(엔지니어)이 자다 깨서 마우스 클릭으로 죽은 컨테이너를 다시 살리고, 서버를 10개로 늘리는 짓(노가다)은 불가능합니다. **수백 대의 서버(Node)에 깔린 수천 개의 컨테이너 박스를 자동으로 감시하고 배치하고 껐다 켰다 해줄 '인공지능 관제탑'**이 절실해졌습니다.

Ⅱ. 1대장 쿠버네티스(Kubernetes, K8s)의 마법

구글이 15년간 자사 서비스를 돌리던 노하우(Borg)를 오픈소스로 푼 것이 쿠버네티스이며, 현재 오케스트레이션 시장을 99% 천하 통일했습니다.

쿠버네티스의 3대 핵심 기능

  1. 오토 힐링 (Auto-Healing, 자가 치유)
    • K8s 관제탑은 "결제 컨테이너는 항상 3개가 떠 있어야 해(Desired State)"라는 선언문을 들고 감시합니다.
    • 1개가 뻑나서 죽으면, 인간에게 묻지도 않고 자기가 알아서 빈 서버를 찾아내어 1초 만에 죽은 컨테이너와 똑같은 쌍둥이를 새로 띄워내 무조건 3개를 유지시킵니다. (절대 죽지 않는 좀비 서버의 탄생).
  2. 오토 스케일링 (Auto-Scaling, 무한 복제)
    • 갑자기 이벤트 트래픽이 몰려 CPU가 80%를 넘기면, K8s는 즉시 컨테이너를 3개에서 100개로 쫙 복제하여 늘려(Scale-out) 트래픽을 방어합니다. 이벤트가 끝나면 다시 3개로 줄여 돈(클라우드 비용)을 아껴줍니다.
  3. 무중단 롤링 배포 (Rolling Update)
    • 개발팀이 신버전 V2 코드를 가져오면, K8s는 V1 컨테이너 100개를 한 번에 끄지 않습니다. 1개 끄고 V2 켜고, 1개 끄고 V2 켜는 식으로 물 흐르듯 배포하여 사용자 접속이 단 1초도 끊기지 않게 합니다.

Ⅲ. CI/CD 파이프라인과의 완벽한 연계 (GitOps)

현대의 데브옵스 파이프라인은 이 K8s를 만나 비로소 완성됩니다.

  • 젠킨스나 깃허브 액션(CI)이 코드를 빌드해서 **도커 이미지(상자)**를 만듭니다.
  • 그 이미지를 **쿠버네티스(CD)**에게 던져주며 "이거 라이브 서버에 10개 띄워줘!"라고 명령합니다.
  • (최근엔 앞서 배운 [119. GitOps] 도구인 ArgoCD가 깃허브의 코드를 감시하다가, K8s에 직접 코드를 꽂아 넣어버리는 방식이 대세입니다.)

📢 섹션 요약 비유: 컨테이너(Docker)가 각자 악기를 부는 개별 **'연주자'**라면, 오케스트레이션(Kubernetes)은 수천 명의 연주자를 조율하는 **'카리스마 지휘자(마에스트로)'**입니다. 바이올린 연주자 한 명이 기절하면 1초 만에 대기석의 다른 바이올린 연주자를 강제로 끌고 와 빈자리를 채우고(오토 힐링), 곡이 절정에 달하면 트럼펫 연주자 50명을 순식간에 복제해 소리를 키우며(오토 스케일링) 웅장한 음악(서비스)이 절대 멈추지 않게 통제합니다.