CharmingGroot

운영계 세팅 회고 ep2 - k3s를 고른 이유

인프라5분English

English version: Production Server Setup Notes, Ep. 2 - Why We Chose k3s

요구사항

고객사 서버 한 대에 우리 서비스를 올려야 했다.
서비스는 MSA로 나뉘어 있고, 이것들이 모두 한 서버에 올라간다.

  • 화면(프론트엔드)
  • API 서버
  • 서비스 워커
  • PostgreSQL(pgBackRest로 백업)과 Redis
  • DB 백업 같은 정기 작업(CronJob)
  • 관측 도구: 로그(Loki), 트레이스(Tempo), 메트릭·대시보드(Prometheus·Grafana), 수집기(OpenTelemetry Collector)

지금은 서버 한 대지만 추후 이중화 가능성을 염두에 둬야 하는 상황이었다.
그래서 여러 서비스를 오케스트레이션할 수 있고, 서버 한 대에서 시작해 스케일아웃(scale-out)할 수 있는 기반이 필요했다.

k3s를 선택한 이유

MSA로 나누면 서비스마다 따로 배포하고, 죽으면 다시 띄우고, 서비스끼리 서로를 호출할 주소도 관리해야 한다.
쿠버네티스는 원하는 상태(desired state)를 선언해 두면, 컨트롤러가 실제 상태를 계속 그 상태로 맞춘다(reconciliation).

  • Self-healing: 실패한 컨테이너를 재시작하고, 헬스 체크(liveness probe)에 응답하지 않는 컨테이너는 교체한다. 준비(readiness)가 끝나기 전에는 트래픽을 보내지 않는다.
  • Automated rollouts와 rollbacks: rolling update로 무중단 배포를 하고, 문제가 생기면 이전 버전으로 롤백한다.
  • Service discovery와 load balancing: 다른 서비스는 Service Name으로 호출한다. 파드가 바뀌어도 Service Name은 그대로이고, 트래픽은 파드들에 분산된다.
  • Secret과 configuration management: 설정과 시크릿을 이미지와 분리해 ConfigMap·Secret으로 관리한다.
  • Batch execution: DB 백업 같은 정기 작업을 CronJob으로 돌린다.
  • Horizontal scaling: 레플리카 수를 늘려 스케일아웃한다.

Docker Compose도 여러 컨테이너를 함께 띄울 수 있다.
다만 단일 호스트용 도구라, 서버를 늘리려면 결국 쿠버네티스나 Docker Swarm 같은 멀티 호스트 오케스트레이터로 옮겨야 한다.
확장을 생각하면 처음부터 쿠버네티스에 올리는 게 맞았다.

kubeadm 대신 k3s

쿠버네티스를 kubeadm으로 설치하면 control plane만 깔린다.
컨테이너 런타임, Pod 네트워크, DNS, Ingress controller, 로드밸런서, 볼륨 프로비저너는 따로 골라서 깔아야 한다.
서버 한 대에 이걸 하나하나 깔고 관리하는 건 부담이었다.

kubeadm control plane만 설치, 나머지는 따로 골라 설치·운영 컨테이너 런타임 Pod 네트워크(CNI) 클러스터 DNS Ingress controller 로드밸런서 볼륨 프로비저너 k3s 실행 파일 하나에 기본으로 들어 있음 containerd Flannel CoreDNS Traefik ServiceLB local-path SQLite
kubeadm은 control plane 바깥을 직접 골라 붙인다. k3s는 같은 역할을 하는 구성 요소를 실행 파일 하나에 담아 둔다.

k3s는 이걸 실행 파일 하나에 넣어 뒀다.
데이터스토어도 기본이 SQLite라서 etcd를 따로 관리하지 않아도 된다.

최소 사양만 보면 둘은 비슷하다. kubeadm 문서는 머신당 메모리 2GB·control plane CPU 2개, k3s 문서는 서버 노드 CPU 2개·메모리 2GB를 든다. 차이는 따로 깔고 지켜봐야 할 구성 요소의 수다.

이중화와 확장

서버를 늘릴 때도 k3s를 그대로 쓸 수 있다.
k3s는 SQLite로 돌던 서버를 --cluster-init으로 다시 시작하면 내장 etcd로 바뀐다.
여기에 서버 노드를 두 대 더 붙여 3대로 묶으면 control plane이 이중화된다. etcd가 과반을 유지해야 해서 서버는 홀수로 둔다.
일을 더 나눠 맡길 노드가 필요하면 agent 노드를 붙인다.

단일 노드 server 노드 control plane + 워크로드 server 노드 추가 이중화 구성 server 노드 1 control plane server 노드 2 control plane server 노드 3 control plane server 노드는 홀수(3개 이상)로 묶는다 agent 노드 1 워크로드 agent 노드 2 워크로드
서버 노드를 셋 이상 홀수로 묶어 control plane을 이중화하고, 워크로드를 더 나눠 맡길 노드가 필요하면 agent를 붙인다.

k3s도 표준 쿠버네티스라서, 언젠가 다른 배포판으로 옮겨야 하면 매니페스트와 Helm 차트를 그대로 가져가면 된다.

영업 관점

영업할 때 잘 먹히기도 하니, 다른 대안에 대해서 크게 고민 없이 고른 측면도 없지 않아 있다.

참고