Docker 기반 Orchestration Tool 조사 (k8s, k3s 비교 및 Docker Swarm 분

2024. 12. 4. 15:38ㆍDocker

 

항목 k3s k8s
설치 크기

 작음 (약 40MB)
  • 공식 문서에는 100MB 미만이라고 안내하고 있음
 큼 (500MB 이상)
아키텍처 여러 컴포넌트가 단일 바이너리로 통합되어 있음 (때문에 설치가 간편) 각 컴포넌트가 별도로 실행
필요 자원



 적은 메모리 및 CPU 요구사항
  • 최소 512MB RAM
  • 최소 1 CPU
 높은 메모리 및 CPU 요구사항
  • 최소 2GB RAM
  • 최소 2 CPU
노드 제한 최대 500개 노드까지 무료 5000개 이상 노드 지원
특징



 경량화 버전으로 IoT, 엣지 컴퓨팅 등에 적합
단일 바이너리 배포
자동화된 TLS 관리		 대규모 엔터프라이즈 및 클러스터에 적합
복잡한 배포 구조
수동 TLS 구성 필요
배포 방식 서버 및 에이전트 모드 사용 마스터, 워커, API 서버 등 다중 구성 요소로 배포됨
보안

 k8s와 비슷하지만 일부 보안 기능 제한됨
기본 보안 정책 내장		 보안 기능 제공
상세한 보안 정책 구성 필요
기본 저장소















 기본 스토리지 메커니즘은 SQLite3
  • 다른 데이터스토어 구성이 없고, 디스크에 임베디드 etcd 데이터베이스 파일이 없는 경우 사용됨
  • 여러 서버가 있는 클러스터에서는 사용할 수 없음 (SQLite3)
임베디드 etcd
  • High Availability Embedded etcd 지원
  • 새 etcd 클러스터를 초기화하거나, 기존 etcd 클러스터에 가입 가능
외부 데이터베이스
  • etcd3, MySQL, MariaDB, PostgreSQL 지원
  • k3s가 연결 방법을 알 수 있도록 datastore-endpoint 파라미터를 설정해야 함 (참고: https://docs.k3s.io/kr/datastore)
 etcd
로드밸런서



 Service LoadBalancer 컨트롤러 내장
  • 기본적으로 활성화되어 있음
  • cloud-provider 사용 시 --disable servicelb 플래그로 비활성화 가능
 외부 로드밸런서 필요
  • 클라우드 제공자 로드밸런서 사용
  • 별도의 인그레스 컨트롤러 설정 필요
CNI

 기본 Flannel CNI 내장
  • 다른 CNI로 쉽게 교체 가능
 CNI 플러그인 별도 설치 필요
  • 다양한 CNI 플러그인 선택 가능
자동화 도구 제한적 지원 광범위한 도구 지원
모니터링 기본 최소화된 모니터링 다양한 모니터링 도구 통합 가능
업그레이드 단순한 업그레이드 프로세스 복잡한 업그레이드 절차
커뮤니티 성장 중인 커뮤니티 매우 큰 커뮤니티와 광범위한 지원
라이센스
Apache2.0 license
NOTICE 파일을 별도로 만들어 Apache License 2.0 소스코드의 저작권 및 Attribution을 고지해야 함.
또한, Apache License 2.0 전문(영문)을 프로그램내에 포함해야 함.
하이브리드 클라우드

 

 

공통 컴포넌트 및 주요 차이점

k3s 구성 요소

 

k8s 구성 요소

공통 컴포넌트

  1. API Server
    • 쿠버네티스 API를 제공하는 중앙 관리 컴포넌트
    • 모든 통신의 중심점으로 작동
    • 리소스의 유효성을 검사하고 구성 데이터를 저장
  2. Controller Manager
    • 클러스터의 상태를 관리하고 제어하는 컨트롤러들의 모음
    • Node Controller, Replication Controller 등을 포함
    • 클러스터의 desired state를 유지
  3. Scheduler
    • Pod를 적절한 노드에 할당하는 역할
    • 리소스 요구사항, 하드웨어/소프트웨어 제약 조건 등을 고려
  4. Kubelet
    • 각 노드에서 실행되는 에이전트
    • 컨테이너의 생명주기 관리
    • 노드의 상태를 API 서버에 보고
  5. Kube-proxy
    • 네트워크 규칙을 관리하고 연결을 포워딩
    • 서비스의 네트워크 통신을 처리

 

주요 차이점

  1. 데이터 스토어
    • K8s: etcd를 사용 (분산 키-값 저장소)
    • K3s: SQLite(기본값)를 사용하며 더 가벼움. 선택적으로 etcd 사용 가능
  2. 아키텍처 통합
    • K8s: 각 컴포넌트가 별도로 실행
    • K3s: 여러 컴포넌트가 단일 바이너리로 통합되어 있음
  3. Container Runtime
    • K8s: containerd, CRI-O 등 선택 가능
    • K3s: containerd가 기본 내장
  4. 로드밸런서
    • K8s: 외부 로드밸런서 필요
    • K3s: ServiceLB가 내장되어 있음
  5. 리소스 요구사항
    • K8s: 더 많은 메모리와 CPU 자원 필요
    • K3s: 최소한의 자원으로 운영 가능 (라즈베리 파이에서 실행 가능)

 

Docker swarm VS k3s

결론

Docker Swarm은 설치와 사용이 간단하여 소규모 프로젝트나 개발 환경에 적합한 반면, k3s는 쿠버네티스 기반의 더 풍부한 기능(자동 스케일링, 고급 모니터링, 세밀한 리소스 관리 등)을 제공하여 중대규모 프로덕션이나 엣지 컴퓨팅 환경에 더 적합한 컨테이너 오케스트레이션 도구입니다.

항목 docker swarm k3s
오토 스케일링 수동 스케일링만 가능 HPA (Horizontal Pod Autoscaling) 지원
  • 쿠버네티스에서 자동으로 워크로드를 수평 확장하는 기능
상태 체크 및 자동 복구 기본적인 health check 만 지원
  • 단순한 pass/fail 만 체크 가능
  • fail 시 단순 재시작만 가능
  • 상태에 따른 세밀한 제어 불가
 Liveness Probe (생존 확인)
  • 애플리케이션이 살아있는지 확인
  • 실패시 Pod를 재시작
  • 교착 상태나 무한 루프 감지에 유용


Readiness Probe (준비 상태 확인)
  • 애플리케이션이 트래픽을 처리할 준비가 됐는지 확인
  • 실패시 트래픽 차단 (서비스에서 제외)
  • 데이터베이스 연결, 의존성 준비 상태 확인에 유용


Startup Probe (시작 확인)
  • 애플리케이션의 첫 구동 완료를 확인
  • 실패시 다른 Probe는 비활성화
  • 느리게 시작하는 애플리케이션에 유용


다양한 재시작 정책 (설정 단순함)
  • Always: 항상 재시작
  • OnFailure: 실패시에만 재시작
  • Never: 재시작하지 않음
배포 전략 롤링 업데이트만 지원 다양한 배포 전략 수립 가능
  • 롤링 업데이트
    • 구버전 파드 하나씩 줄여나가고 신버전 파드를 하나씩 생성하여 전환하는 방법으로 쿠베 기본 배포 전략
  • Blue/Green 배포
    • 새 버전 완전히 준비 후 전환
    • 빠른 롤백 가능
  • Canary 배포
    • 일부 트래픽만 새 버전으로 전환
    • 점진적인 트래픽 이동
  • 세부 제어도 가능
    • 상세한 헬스 체크
    • 자동 롤백 조건 설정
    • 트래픽 세부 제어
볼륨 관리 로컬 볼륨 중심 Persistent Volume
Storage Class
다양한 스토리지 백엔드 지원
동적 볼륨 프로비저닝
네트워크 정책 기본적인 네트워크 격리
  • Overlay 네트워크
  • 네트워크 간 기본 격리
  • 내부/외부 네트워크 구분
  • 기본적인 네트워크 암호화
 세부적인 규칙 설정 가능
  • Pod 레벨 격리
  • 네임스페이스 기반 격리
  • 포트/프로토콜 지정
  • IP CIDR 기반 규칙


양방향 제어
  • Ingress 트래픽 제어
  • Egress 트래픽 제어
  • 상세한 허용/거부 규칙


정책 결합 가능
  • 여러 정책 동시 적용
  • 네임스페이스 별 정책
리소스 관리 컨테이너 단위의 기본적인 리소스 제한 방식 사용
  • 세부적인 우선순위 체계 없음
  • 컨테이너 자동 재시작 정책만 설정 가능
  • 단순히 OOM(Out of Memory) Killer에 의존
  • 동적 리소스 조정 불가


 다양한 리소스 관리 옵션 보유
  • 클러스터 레벨 관리
    • Pod Topology Spread Constraints
      • Pod의 지역적 분산 관리
      • 가용성 향상을 위한 분산 배치
      • 영역/노드 간 균형 조정
  • 노드 레벨 관리
    • Node Affinity/Anti-Affinity
      • 특정 노드에 Pod 할당/제외
      • 하드웨어 특성 기반 스케줄링
      • 워크로드 분산 관리
  • 네임스페이스 레벨 관리
    • 리소스 쿼터
      • 네임스페이스별 리소스 총량 제한
    • 기본 제한 (LimitRange)
      • 네임스페이스의 기본 리소스 제한 설정
      • 컨테이너별 최소/최대 리소스 제한
      • 리소스 요청/제한 기본값 설정
  • Pod 레벨 관리
    • QoS 클래스
      • Pod의 우선순위와 리소스 보장 수준을 정의
      • Guaranteed, Burstable, BestEffort 클래스 구분
      • 우선순위 기반 스케줄링
서비스 디스커버리
(네트워크상의 서비스들이 서로를 자동으로 찾고 통신할 수 있게 하는 메커니즘)		 제한적인 서비스 디스커버리
  • 내장 DNS 기반의 단순한 서비스 디스커버리
  • 서비스 이름으로 자동 접근
  • 오버레이 네트워크 사용
 CoreDNS 기반의 고급 서비스 디스커버리
  • 다양한 서비스 타입 지원
    • ClusterIP: 클러스터 내부 통신용, 고정 내부 IP 제공
    • NodePort: 외부 접근용 포트 할당
    • LoadBalancer: 클라우드 로드밸런서 통합
    • ExternalName: 외부 서비스와의 연동
  • 추가 기능
    • 서비스 헬스 체크
    • 자동 로드밸런싱
    • 서비스 메시 지원
    • 외부 서비스 연동
    • DNS 기반 서비스 검색
모니터링 제한적 (수동으로 구현해야하는 것들 다수)
  • 매트릭 수집 수동 설정 필요
  • 대시보드 사용하려면 써드파티 도구 필요
  • 로그 중앙화 필요하면 수동 구성 필요
 포괄적 (기본 지원)
  • Prometheus 통합
  • Grafana 대시보드
  • 상세한 메트릭 수집
  • 중앙화된 로깅

티스토리툴바