콘텐츠로 이동

Kubernetes (오케스트레이션)

컨테이너 한두 개는 직접 관리해도 되지만, 서비스가 몇십 개로 늘고 스케일을 바꿔야 하고 한 대가 죽어도 다시 살려야 한다면 얘기가 달라져요. Kubernetes(K8s)는 그런 컨테이너 여러 개를 배포·확장·복구하는 오케스트레이터입니다. 우리의 모든 서비스가 바로 이 위에서 돌아가요.

요청이 늘면 컨테이너를 늘리고, 노드가 죽으면 다른 노드에 다시 띄우고, 새 버전을 끊김 없이 교체하는 일을 쿠버네티스가 자동으로 처리합니다.

처음에는 다소 낯설 수 있지만, 핵심은 단순해요. "이런 상태로 유지해줘"라고 선언하면, 쿠버네티스가 그 상태를 지켜가도록 계속 일합니다. 그래서 아래 개념들만 차근차근 이해하면 전체 그림이 잡혀요.

한 가지 주의할 점은, 쿠버네티스는 "어떻게 배포할지"보다 "최종적으로 어떤 상태가 되어야 하는지"를 다룬다는 거예요. 배포 절차 자체는 뒤의 GitOps 도구가 맡죠.

핵심 개념

클러스터 구조. 쿠버네티스는 컨트롤 플레인(관리하는 뇌)과 워커 노드(실제로 컨테이너가 도는 머신들)로 나뉘어요. 컨트롤 플레인이 원하는 상태를 계속 비교하고, 노드가 그 상태를 맞추죠. 우리는 이를 Self-hosted(직접 운영)로 구성해 두었어요.

파드(Pod). 쿠버네티스의 기본 배포 단위예요. 하나 이상의 컨테이너를 묶어 같이 띄우고, 같은 네트워크·저장소를 공유해요. 대개 애플리케이션 컨테이너 하나에 파드 하나를 둡니다.

디플로이먼트(Deployment). "이 이미지로 N개를 유지해줘"라고 선언하는 리소스예요. 롤링 업데이트로 새 버전을 조금씩 교체하고, 문제가 생기면 이전 리비전으로 롤백해요.

서비스(Service)와 로드 밸런서. 파드는 언제든 새로 뜨고 사라져서 IP가 고정되지 않아요. 서비스가 파드들 앞에서 안정적인 접근 주소를 제공하고, 로드 밸런서가 트래픽을 고르게 나눠요.

네임스페이스(Namespace). 한 클러스터를 논리적으로 나누는 공간이에요. 마케팅 사이트, 위키, 백엔드를 각각 다른 네임스페이스에 두면 서로 섞이지 않아요. 네임스페이스는 리소스 한도나 접근 제어를 공간 단위로 적용하는 기준이 되기도 해요.

헬름(Helm). 매니페스트 여러 개를 묶어 하나의 차트로 배포하는 패키징 도구예요. 반복되는 배포 정의를 줄여줍니다.

사용 사례 / 실제 적용

하나의 클러스터에 성격이 다른 서비스가 함께 돌아가요. 마케팅 Astro, 기술 위키 MkDocs, 백엔드 API가 각각의 네임스페이스로 분리되어 있고요. 부하가 늘면 디플로이먼트가 파드를 늘리고(Auto Scaling), 로드 밸런서가 요청을 분산합니다.

배포는 사람이 직접 하지 않아요. 앞뒤 문서에서 이어지지만, 이미지가 준비되면 ArgoCD가 원하는 상태를 클러스터에 반영하고, 쿠버네티스가 그 상태를 실제로 맞추는 구조입니다. 노드가 죽어도 시스템이 스스로 복구되기 때문에, 운영자가 매번 손댈 일이 줄어들죠.

하위 챕터

더 알아보기