▲

Canine - Kubernetes를 Heroku처럼 쉽게 만드는 오픈소스 플랫폼

 (github.com/czhu12)
26P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 1인 개발자도 쉽게 Kubernetes를 활용할 수 있도록 만든 오픈소스 플랫폼으로, 기존 Heroku와 비슷한 간편함 제공
    • Docker와 Docker Compose 환경에서 동작하며, 간단한 명령어로 설치 및 실행 가능
  • 기존 스타트업에서 겪은 예상치 못한 IT 비용 증가 문제를 해결하고자 개발됨
  • 복잡한 기능 대신 Ingress, Services, Deployments, Pods, CronJobs 등 핵심 요소만 노출하여 단순함을 추구함
  • Helm을 통해 거의 모든 오픈소스 앱을 배포할 수 있으며, YAML 설정을 내려받아 Canine에서 벗어나는 것도 가능
  • 계정, 배포, 대시보드 등 쿠버네티스에 기본 없는 기능도 보완해 소규모 팀이 쓰기 좋은 개발 플랫폼을 지향

개요

  • Canine은 오픈소스 Kubernetes 배포 플랫폼으로, Heroku처럼 손쉽게 앱을 배포할 수 있도록 설계됨
  • 자체 Kubernetes 클러스터 위에서 동작하며, 필요시 YAML 설정을 내려받아 탈중앙화된 운영도 가능함
  • Ingress, Services, Deployments, Pods, CronJobs 등 핵심 리소스만 노출하여 단순하고 직관적인 사용성을 제공함

문제의식: 복잡한 구조와 폭증하는 비용

  • 기존 스타트업 운영 경험에서 IT 비용이 예상보다 훨씬 빠르게 증가했음
  • 비용은 주로 조직 복잡성과 연동 서비스 증가에 따라 늘어나며, 서버나 컴퓨팅 사용량과는 무관한 경우가 많았음
  • 다음과 같은 서드파티 툴이 누적되어 IT 비용을 급증시킴:
    • Looker, Redshift, Databricks, DBT Cloud, FiveTran 등 데이터 관련 도구
    • Datadog, New Relic, Sentry 등 모니터링 도구
    • Google Maps API, AWS 등 인프라 도구
  • 일부는 오픈소스로 대체 가능했지만, 모니터링·헬스체크·알림 등 운영 인프라 구성의 부담으로 채택을 꺼려했음

쿠버네티스의 가능성과 한계

  • Kubernetes는 단일 노드부터 수천 클러스터까지 확장 가능한 플랫폼이며, 거의 모든 클라우드에서 표준적으로 제공됨
  • 하지만 초보자와 소규모 팀에게는 복잡하고 쉽게 망가질 수 있는 시스템으로 인식됨
  • 특히 CoreDNS 삭제 같은 실수로 인해 전체 클러스터가 작동하지 않을 수 있음
  • 비용과 운영의 복잡성이 누적되면 기존의 추상화된 PaaS가 오히려 발목을 잡게 됨

Canine의 특징

  • Kubernetes의 최소 필요 기능만 노출하여 단순성과 통제 가능성 확보
  • 부족한 부분은 다음과 같은 기능으로 보완:
    • 계정 관리
    • 배포 관리
    • 단순한 one-off 스크립트 실행
    • 메트릭 대시보드
  • 직관적 배포 플랫폼을 통해 초보자도 쉽게 Kubernetes 환경에 애플리케이션 배포 가능함
  • Docker 및 Docker Compose만 준비되어 있으면, 명령어 한 번으로 설치 및 실행이 가능함
  • 쿠버네티스의 복잡한 설정이나 유지보수 부담을 줄여주는 UI 기반 관리 환경 제공함
  • Helm 통합을 통해 Sentry 같은 오픈소스 앱도 쉽게 배포 가능

마이그레이션과 자유도

  • Canine은 기존 쿠버네티스에 얹어서 사용되므로 벗어나기도 쉬움
  • 모든 구성은 YAML로 내려받을 수 있으며, 추후 다른 플랫폼으로 이전도 수월함

중요성 및 차별점

  • 일반적인 Kubernetes 도구 대비 초보자 친화적 UI와 쉬운 설치 과정 제공함
  • Heroku와 유사한 사용 경험을 쿠버네티스 생태계에 도입하여, 진입 장벽을 크게 낮춤
  • 오픈소스 기반으로 유연한 확장성 및 커뮤니티 중심 개선이 가능함
  • 소규모 개발팀이나 스타트업에서도 손쉽게 쿠버네티스의 장점을 활용할 수 있는 점에서 큰 효과 기대됨
  • Apache 2.0 License로 자유로운 사용, 배포, 수정 가능
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 저는 “Heroku와 비슷한 경험”을 내 서버에서 구현하려 늘 더 좋은 솔루션을 찾는 편이고, 그래서 정말 반가움 표시
    Canine의 Kubernetes 관련 문서가 매우 접근하기 쉽고, 지금까지 본 중 가장 친절한 수준 느낌
    문서를 보며 궁금증 생김: Canine을 Digital Ocean 같은 곳의 매니지드 K8s 환경에서도 쓸 수 있나 기대감 있었는데, 읽고 나니 직접 K8s 클러스터를 관리해야 한다는 인상임
    몇 가지 궁금점 제시

    1. Hetzner에서 “Cluster”를 만들 때, 실제 여러 대의 머신을 아우르는 진짜 K8s 클러스터인지, 단순히 한 머신의 가상 분할인지 궁금증
    2. 다른 서버에 설치 스크립트를 실행하면 클러스터에 조인돼서 pod를 분산 호스팅하는 진짜 분산 서버 구성이 되는지 궁금증
    3. 이미 존재하는 매니지드 K8s에 Canine을 붙여서 배포 가능한지 궁금증
    • 현재 Canine이 지원하는 구성은 두 가지임
      1. Hetzner VPS 한 대에서 운영
      2. 이미 구축된 Kubernetes 클러스터에서 사용
        일반적으로 1번은 스테이징/개발 앱, 2번은 프로덕션 앱에 이용
        2번의 경우 Digital Ocean 등에서 노드 수 관리해서, 쿠버네티스가 워크로드를 자동으로 재스케줄 및 오토스케일 기능 사용
        질문의 핵심 같은데, Canine이 Hetzner 환경에서 직접 멀티노드 클러스터를 만든다는 기능은 아직 지원 안함
        Hetzner의 terraform으로 K8s 클러스터 만드는 것도 있지만, Canine에선 아직 내장되어 있지 않음
        UI 개선 등 하고 나서 관심은 있음
        지금은 K3s 단일 VPS 설치 가이드로 도와주거나, 이미 클러스터가 준비된 경우 쓸 수 있다는 전제
        참고 링크: terraform-hcloud-kube-hetzner

  • 이런 프로젝트가 꼭 필요하다고 생각하는 사람으로서 응원하는 심정
    오늘이라면 Canine이나 Dokploy를 고민할 것 같음 (Docker Swarm도 과소평가된 기술이라고 생각)
    피드백: “왜 Canine을 쓰지 말아야 하는가” 섹션이 솔직해서 신선할 줄 알았는데, 약간 비꼬는 뉘앙스가 들어 불편
    그냥 솔직하게 서버를 구매하고 관리해야 하고, 다운되면 책임져야 하고, 1인 개발 초기 제품이라는 현실적인 단점만 명확히 써줬으면 좋겠다는 의견

    • Docker Swarm은 지금 유지보수와 지원 현황이 어떤지 궁금증
      몇 년 전 현재 Docker 팀이 개발을 중단한 것 같아 추적을 멈췄던 경험 공유

    • 다른 랜딩 페이지들과 차별화하려다 그렇게 작성한 건데, 실 사용자 피드백 매우 감사하게 생각
      다시 시도해볼 의지 표명

  • 세상에 존재하는 여러 PaaS 플랫폼을 모아서 관리하는 리스트 공유
    awesome-paas

  • OP(작성자)에게 질문
    이런 프로젝트를 만들게 된 배경이 궁금증
    뭔가 복잡한 걸 처음부터 끝까지 만들어보고 싶은 욕심이 있는데, API와 React 통합만 다뤄봤음
    복잡한 아이디어를 현실적인 할 일로 쪼개서 오픈소스 프로젝트 “Heroku 대안”으로까지 성사시킨 과정이 궁금함
    난 Heroku 사용 경험이 거의 없어 “구현할 기능”을 파악할 때 가격 페이지 등을 참고할 것 같은데, 이 방식이 비효율적이진 않을지 우려감

  • Kubernetes 기반 Heroku 대안이라니 흥미롭다는 호기심
    하지만 K8s나 Helm chart 같은 걸 알아야 쓸 수 있다면, 내게는 사실상 Heroku 대안이 아닐 것
    물론 운영자 입장에 따라 echo hello 수준으로 단순할 수도 있다는 건 이해
    난 최대한 빨리 무언가를 올리고 싶을 때 “Kubernetes와 Helm chart”라는 단어조차 떠올리고 싶지 않다는 마음

    • 이게 바로 Canine의 목표였음
      사용자는 Kubernetes의 존재 자체도 몰라도 되고, 다만 그 성숙한 생태계를 누릴 수 있음
      언제든지 더 강력한 기능이 필요할 때는 Kubernetes API와 같은 전문 기능을 직접 열어서 쓰는 것도 가능

  • 작은 부분이지만 지적사항
    Kubernetes는 docker 컨테이너가 아니라 Open Container Initiative(OCI) 규격에 맞는 컨테이너를 돌림
    Docker는 상표명임

    • 또 다른 작은 지적:
      Canine Kubernetes Crash Course에서 “1만 대 서버 지원”이라 설명되어 있는데
      공식적으로는 Kubernetes가 최대 5천 노드까지 지원한다고 명시
      kubernetes 공식 문서 참고
      훨씬 더 큰 클러스터도 가능하지만, 그땐 대폭 커스텀 필요 (API registry 전체 교체 등)
      물론 워크로드도 영향
      Kubernetes는 out-of-the-box로 대형 클러스터 지원까지는 아직 멀었지만, 매 릴리즈마다 발전중임

    • docker 필수라고 하면 싫어함
      요즘은 docker 대신 podman이나 containerd 위주로 운영

  • 이 프로젝트 만드는 게 엄청 재밌었고, 내 인생에서 가장 즐거운 개발임
    모든 “기술 스택”을 한 손에 쥐는 성취감이 최고
    Rails app, Canine infra, Raspberry pi 서버, 내가 쓰는 ISP까지
    스스로 전부 관리하며 앱을 올려본 경험 공유

  • 웹사이트에 라이선스 표기가 2024년 MIT License로 되어 있고
    실제 github에는 apache license로 명시되어 있음
    이렇게 연도가 맞는지 아닌지보다, 라이선스 종류가 중요한 차이로 보임
    실제 적용되는 라이선스가 무엇인지 궁금증 표명

  • Self-hosting에서 docker와 K8s 사이 중간 단계를 원해, 비슷한 걸 직접 알아봤던 경험
    Nomad도 고려했지만 여전히 dead simple docker보다 살짝 복잡했고 에코시스템 미흡
    결국 홈서버는 docker로만 운영, 배포 중 다운타임은 감수
    프로덕션에선 Canine이 K8s의 어느 정도까지 추상화해 주는지 궁금함
    내부까지 들여다볼 일이 생길지, K8s 초보라 그 중간 지점이 정말 가능한 건지 의문

    • 나 역시 Docker와 Kubernetes 중간 위치의 툴을 개발중임
      uncloud
      목표는 Docker적인 CLI와 Docker Compose의 멀티머신/프로덕션 기능을 제공하되, 운영 제어 플레인 없이 단순명료함 유지
      개발중이지만 모든 레이어에서 일어나는 일을 쉽게 파악할 수 있어야 하며, 트러블슈팅도 쉬운 점이 목표

  • 컨셉이 정말 마음에 듦
    K8s는 대단한 기술이나, 그 복잡함이 진입장벽
    공개 자료를 보니 본질을 잘 이해한 것 같음
    특히 PVE, Microcloud, Cockpit 같은 솔루션이 인기 있는 셀프호스팅 영역에서 더욱 유용함 예상
    집에 놀고있는 N100 NUC가 있는데, Microcloud 포기하고 Canine 테스트해볼 의향 생김

    • helm이 때때로 번거로운 점 있음
      values.yaml 수정 후 적용되는 값과 처음부터 셋팅해야 하는 값이 헷갈림
      어떤 helm 설치 본은 서비스가 너무 많아, 무엇을 언제 재시작해도 되는지 헷갈림
      반면 core kubernetes는 stateless job에는 정말 쾌적한 사용감

    • 요즘 K8s의 “복잡도”라는 말이 어디서 나오는지 모르겠음
      예전엔 kubespray로 두 시간 세팅 이런 일도 있었는데
      요즘은 rke 같은 툴 쓰면 yaml 파일 하나랑 ssh 키 하나만으로도 클러스터 생성 가능

답변달기