1P by GN⁺ 5일전 | ★ favorite | 댓글 1개
  • 글 작성자는 개인 서버 운영에서 Kubernetes의 복잡성과 리소스 소모에 좌절하고, 이를 systemd와 Podman 조합으로 대체한 경험을 공유함
  • Kubernetes는 GitOps와 자동화에 매력을 느끼게 하지만, 소규모 환경에서는 과도하게 무거운 시스템임
  • Podman의 자동 업데이트 기능systemd 서비스 생성을 활용하면, 기존 Kubernetes의 핵심 기능을 간단하게 구현 가능함
  • systemctl과 loginctl을 조합한 사용자 레벨 서비스 자동 실행도 설명하며, VPS 자원 소모가 대폭 줄었음을 강조함
  • 단, Podman의 systemd 통합은 곧 "Quadlet"이라는 새로운 방식으로 대체될 예정이라고 언급함

서론: Kubernetes와의 첫 만남

  • 2018년에 Kubernetes를 실험하면서 개인용 NUC에 클러스터 구축을 시도한 경험을 소개함
  • Kubernetes는 복잡하지만 기본적으로는 다음과 같은 반복 루프 구조로 동작함:
    • 현재 상태 파악 → 원하는 상태 계산 → 차이 계산 → 적용
  • cert-manager 등 다양한 컴포넌트를 활용한 자동화 기능이 매우 인상적이었음

Kubernetes의 과한 리소스 요구

  • 개인 서버(NUC)에서 Kubernetes는 지속적인 CPU 사용팬 소음, 발열을 유발함
  • Azure, MicroK8s, K3S 등 다양한 배포판도 상당한 리소스를 소모함
    • MicroK8s: 12% CPU 사용 (2vCPU VPS)
    • K3S: 6% CPU 사용 (2vCPU Ampere A1)

GitOps 자동화의 유혹

  • Flux와 같은 도구로 Git 기반 배포 자동화가 가능해 매우 편리했음
  • GitHub에 컨테이너 이미지만 푸시하면 서버가 자동으로 최신 앱을 배포함
  • 하지만, Kubernetes 없이 이와 같은 자동화 구현은 매우 어려웠음

Podman과 systemd의 등장

  • Podman은 Docker 대체 도구이며, 컨테이너를 systemd 서비스로 변환하는 기능이 있음
  • podman generate systemd를 통해 자동으로 service 파일 생성 가능
  • io.containers.autoupdate 태그를 통해 하루 1회 자동 이미지 업데이트 가능
  • Fedora Magazine에서 이 방법을 참고하여 Kubernetes 대체 환경 구성에 성공함

필요한 세 가지 구성 요소

  1. systemctl --user enable mycontainer.service

    • 로그인 시 컨테이너가 자동 실행되도록 설정
  2. loginctl enable-linger

    • 서버 부팅 시 사용자 세션이 활성화되도록 설정
  3. Podman의 auto-update 기능

  • 이 세 가지로 Kubernetes가 제공하는 기능의 99%를 더 단순하고 가볍게 대체할 수 있었음

마이그레이션 결과

  • 기존 VPS에서 새로운 VPS로 전체 서비스를 마이그레이션함
  • 자원은 절반으로 줄었지만 성능은 오히려 향상, 서비스 밀도 증가, 비용 절감 효과 확인

향후 과제: Quadlet

  • 아쉽게도 Podman의 systemd 통합은 곧 폐기 예정
  • 대신 Quadlet 파일이라는 새로운 정의 방식으로 이동할 예정임
  • 새로운 기술을 익힐 준비가 필요하다는 점을 덧붙이며 마무리함
Hacker News 의견
  • Kubernetes를 단순히 컨테이너 이미지를 실행하고 업데이트하는 용도로만 본다면 과도한 사용일 수 있음

    • Kubernetes는 컨테이너가 상태를 공유하고, 서로 연결하며, 설정이나 비밀에 접근할 수 있도록 필요한 자원을 제공함
    • CPU와 메모리 비용은 컨테이너 관리와 필요한 자원을 제공하는 데서 발생함
    • 분산 시스템에서는 모든 시스템이 원하는 방식으로 작동하지 않기 때문에 관리자가 지속적으로 원하는 상태를 달성하려고 노력함
  • Docker를 사용하여 몇 개의 작은 웹사이트를 운영하려 했으나 이미지 업데이트와 테스트가 어려웠음

    • Debian에서 systemd 유닛을 생성하는 스크립트로 모든 것을 대체하고 서비스 변경 시 재시작함
    • 테스트 VM을 사용하여 변경 사항을 배포 호스트에 rsync하고 배포 스크립트를 실행함
    • 전체 시스템은 2GB VPS에서 실행되며, Wordpress가 SQLite를 공식 지원하면 1GB로 줄일 수 있음
    • Mariadb를 사용하여 지원 요구 사항을 최소화함
  • Kubernetes 클러스터를 관리하는 데는 문제가 없지만, 취미 프로젝트에서는 리소스 요구 사항 때문에 사용이 어려움

    • Kubernetes는 $10/월 VPS에서 실행하기에는 리소스 집약적임
    • 수동으로 docker compose 명령어를 사용하고, Ingress 대신 Traefik의 컨테이너 발견 기능을 사용함
    • CronJobs 대신 작은 스크립트를 작성하여 crontab을 관리함
    • Kubernetes가 이미 해결한 문제를 덜 효율적으로 해결하려고 노력함
    • 저렴한 VPS 인스턴스에서 잘 작동하는 Kubernetes 호환 API를 제공하는 경량 대안을 원함
  • Systemd는 많은 문제를 해결하며, 무시해서는 안 됨

    • machinectl, nspawn, vmspawn, importctl 등 다양한 기능을 제공함
    • homed/homectl은 사용자 관리 확장, mounts는 드라이브 자동 마운트, boot는 서비스 시작/중지 제어, timers는 cron 대체
    • 서비스 유닛은 작업을 제어하고, systemctl edit로 구성 파일을 편집할 수 있음
  • Podman-systemd를 사용하여 homelab을 운영하며, 새로운 Kubernetes 변형을 조사할 때마다 추가적인 번거로움이 없음

    • Ansible 플레이북을 사용하여 이미지를 미리 가져오고 유닛 파일을 적절한 위치에 배치함
    • Voron 3D 프린터 스택을 podman-systemd로 운영하며, mkosi와 systemd-sysupdate로 전환을 고려 중임
    • Docker-compose 파일을 systemd 유닛으로 변환해야 하는 번거로움이 있음
    • Podman은 사용자/권한 설정의 복잡성을 줄여줌
  • Quadlet을 사용하여 systemd 내에서 컨테이너를 관리하는 것이 다음 단계임

    • 자세한 내용은 Red Hat 블로그에서 확인 가능함
  • Skate를 만들어 멀티호스트와 Kubernetes 매니페스트를 지원하는 시스템을 구축함

    • 내부적으로는 podman과 systemd를 사용함
  • Docker compose 명령어와 Caddy를 사용하여 인증서를 자동으로 얻는 것이 가능함

    • docker compose up -d --pull always 명령어로 간단하게 설정 가능함
    • CI 설정은 scp와 ssh를 사용하여 구성됨
    • 간단하고 개발 머신에서도 작동함
  • Systemd는 이제 불변 워크플로우를 위한 공식 지원 OS 배포판인 ParticleOS를 제공함

  • 단일 서버에 배포하는 것이 복잡하지 않아야 한다고 생각하며, Harbormaster라는 도구를 작성함

    • YAML 파일을 사용하여 리포지토리를 발견하고, Docker Compose 파일을 실행함
    • 모든 상태를 단일 디렉토리에 보관하여 백업이 용이함
    • 단일 서버에 필요한 가장 쉬운 컨테이너 오케스트레이션 도구임