[요약] Part 1. 쿠버네티스 도입 전 고려해야 할 핵심 원칙

쿠버네티스 환상과 오버엔지니어링

많은 조직이 유행에 휩쓸려 무작정 기술을 도입하려 하지만, 올바른 판단 기준이 필요합니다.

• 오버엔지니어링의 위험성
• 해결하려는 문제 규모에 비해 너무 복잡한 도구를 사용하는 것을 경고합니다.
• 트래픽이 적거나 1~2대의 서버로 충분한 단순한 서비스에 쿠버네티스를 구축하는 것은 유지보수 비용만 크게 증가시킵니다.
• 올바른 도입 시점
• 다수의 서버(Node)를 수동으로 관리하기 불가능할 때 도입을 고려합니다.
• 수십 개의 복잡한 마이크로서비스(MSA) 간의 네트워킹과 배포를 제어해야 할 때 유용합니다.
• 무중단 배포, 오토스케일링이 매일 빈번하게 일어나는 대규모 환경에 적합합니다.

* 작은 토이 프로젝트: 단일 서버 환경에서 직접 도커 컨테이너를 실행
* 중간 규모의 서비스: AWS ECS, Cloud Run 같은 클라우드 관리형 컨테이너 서비스 활용
* 대규모 마이크로서비스: 쿠버네티스(Kubernetes)를 통한 거대한 오케스트레이션

도커의 한계와 오케스트레이션의 필요성

도커는 혁명적인 도구이지만 서버가 늘어날수록 태생적 한계에 부딪힙니다.

• 도커의 근본적인 한계
• 기본적으로 하나의 서버(컴퓨터) 안에서 컨테이너를 실행하는 데 특화되어 있습니다.
• 서버가 여러 대로 늘어나면 어디에 컨테이너를 띄울지, 장애가 나면 어떻게 살릴지 수동으로 관리해야 합니다.
• 컨테이너 오케스트레이션 (Container Orchestration)
• 수많은 컨테이너를 수십 대의 서버 위에서 자동 배치, 확장, 복구하도록 지휘하는 시스템입니다.
• 스케줄링: 최적의 빈 서버를 찾아 컨테이너를 알맞게 배치합니다.
• 자가 치유 (Self-Healing): 죽어버린 컨테이너를 감지하고 다른 서버에 다시 살려냅니다.
• 오토스케일링 & 로드밸런싱: 트래픽에 맞춰 개수를 늘리고 사용자 요청을 분산시킵니다.

클러스터의 마법: 거대한 하나의 컴퓨터

쿠버네티스는 물리적으로 떨어져 있는 여러 대의 서버를 묶어 줍니다.

• 클러스터 (Cluster)의 개념
• 여러 대의 컴퓨터를 하나의 거대한 자원 풀(Pool)로 만들어 사용자가 개별 서버를 신경 쓰지 않게 합니다.
• 일부 서버가 고장 나더라도 전체 서비스가 멈추지 않는 뛰어난 안정성을 제공합니다.
• 클러스터를 구성하는 두 가지 역할
• 컨트롤 플레인 (마스터 노드): 클러스터의 두뇌이자 지휘자입니다. 목표 상태를 감시하고 일꾼 서버들에게 어디에 컨테이너를 띄울지 명령을 내립니다.
• 워커 노드 (Worker Node): 컨트롤 플레인의 명령을 받아 실제 애플리케이션(컨테이너)을 구동하고 자원을 제공하는 일꾼 서버들입니다.