오픈소스 시각적 쿠버네티스 오케스트레이션 플랫폼을 만들었습니다 — YAML 필요 없음

Source: Dev.to

Kubernetes는 믿을 수 없을 정도로 강력하지만, 제대로 사용하기엔 매우 복잡합니다.
학습 곡선이 가파르고, 피드백 루프가 느리며, 하나의 잘못된 들여쓰기만으로도 모든 것이 깨집니다.

그래서 저는 KubeOrch 를 만들었습니다 — 드래그‑앤‑드롭 인터페이스를 통해 Kubernetes 워크로드를 설계, 연결, 배포할 수 있는 오픈소스 시각적 오케스트레이션 플랫폼입니다. YAML이 필요 없습니다. 추측도 필요 없습니다. 아키텍처를 그린 뒤 Deploy 버튼만 누르면 됩니다.

아래는 제가 만든 것, 내부 작동 방식, 그리고 전체를 오픈소스로 공개한 이유입니다.

The Problem With Kubernetes Today

Kubernetes는 컨테이너 오케스트레이션 전쟁에서 승리했습니다. 사실상의 표준이 되었죠. 하지만 개발자 경험은 그 채택 속도를 따라가지 못하고 있습니다.

간단한 웹 애플리케이션에 PostgreSQL 데이터베이스와 Redis 캐시를 Kubernetes에 배포하려면 어떤 작업이 필요한지 생각해 보세요:

이것은 9개 이상의 YAML 파일, 수백 줄, 그리고 수십 가지의 은밀한 오설정 가능성을 의미합니다. 그리고 이것은 단순한 경우입니다.

기존 도구—Helm, Kustomize, Lens—는 YAML을 추상화하거나(하지만 여전히 직접 작성해야 함) 기존 클러스터를 시각화합니다(하지만 먼저 직접 작성해야 함). 핵심 문제를 다룬 도구는 없습니다:

분산 시스템의 정신 모델은 시각적이지만, 도구는 이를 텍스트로 표현하도록 강요합니다.

Source: …

KubeOrch가 하는 일

KubeOrch는 워크플로우를 뒤집습니다. 매니페스트를 작성하고 올바르게 연결되길 기대하는 대신, 여러분은:

1. 드래그하여 서비스(PostgreSQL, Redis, Kafka, 여러분의 앱 — 150개 이상의 컴포넌트)를 캔버스에 배치합니다.
2. 연결합니다. 포트 사이에 선을 그려 연결합니다.
3. 배포합니다 — KubeOrch가 매니페스트를 생성하고, 의존성을 해결하며, 클러스터에 적용합니다.

플랫폼은 네 가지 주요 구성 요소로 이루어집니다:

1. KubeOrch Core (Go)

작업의 두뇌 역할을 합니다. Gin 기반의 Go API 서버로, 다음을 담당합니다:

• JSON‑to‑YAML 변환 – 시각적 설계는 JSON 그래프로 저장되고, Core는 배포 시 이를 프로덕션 준비가 된 Kubernetes 매니페스트로 변환합니다.
• 자동 연결 해석 – 앱에서 PostgreSQL으로 선을 그리면, Core가 올바른 DATABASE_URL 환경 변수, 서비스 DNS 이름, 적절한 포트를 자동으로 찾아 설정합니다—사용자가 직접 지정할 필요가 없습니다.
• Nixpacks 통합 – Core에 GitHub 레포를 지정하면 Dockerfile 없이 자동으로 컨테이너를 빌드합니다.
• 서비스 메쉬 지원 – Istio, 인그레스 컨트롤러, 로드밸런서를 일류 시민으로 다룹니다.
• 실시간 스트리밍 – 실행 중인 모든 컨테이너의 로그와 메트릭을 WebSocket 기반으로 스트리밍합니다.

// Example: Core's auto‑wiring picks up connection intent and resolves it
type Connection struct {
    SourceService string `json:"source"`
    TargetService string `json:"target"`
    SourcePort    int    `json:"sourcePort"`
    TargetPort    int    `json:"targetPort"`
}
// Core resolves this into env vars, DNS entries, and NetworkPolicies automatically

2. KubeOrch UI (Next.js + TypeScript)

시각적 캔버스로, 다음 기술을 사용해 구축되었습니다:

• React Flow – 드래그‑앤‑드롭 워크플로우 디자이너
• Next.js 15 + TypeScript
• shadcn/ui + Tailwind CSS v4 – 컴포넌트 라이브러리
• Zustand – 상태 관리
• WebSocket – 실시간 로그 스트리밍

UI는 의도적으로 의견이 강합니다. 서비스가 똑똑하게 스냅되도록 설계되었습니다—예를 들어 Node.js 앱을 PostgreSQL에 연결하려 할 때, UI는 이미 그 연결이 의미하는 바를 알고 있어 설정을 미리 채워줍니다.

3. OrchCLI (Go)

로컬 개발 루프를 담당하는 CLI:

# Initialize a KubeOrch project
orchcli init

# Start all services (supports hot reload)
orchcli start

# Fork and contribute to core or UI
orchcli init --fork-core
orchcli init --fork-ui

주요 기능:

• 파일 잠금을 이용한 동시 작업 지원으로 설정 손상 방지.
• 클론한 레포를 기반으로 개발 모드를 자동 감지.
• 모든 서비스에 대한 핫‑리로드 지원.

한 줄 설치

curl -sfL https://raw.githubusercontent.com/KubeOrch/cli/main/install.sh | sh

npm으로 설치

npm install -g @kubeorch/cli

4. Docs (Astro)

아키텍처, 시작 가이드, CLI 레퍼런스, API 레퍼런스를 포괄하는 전체 문서 사이트—Astro를 사용해 빠른 정적 생성으로 구현되었습니다.

내가 가장 자랑스러워하는 아키텍처 결정

KubeOrch를 구축할 때 가장 어려운 문제는 UI나 Kubernetes API 통합이 아니라 자동 서비스 연결이었다.

두 서비스가 시각 캔버스에서 연결될 때, 플랫폼은 다음을 결정해야 한다:

• 연결 문자열을 담을 환경 변수는 무엇인가?
• 종속 서비스가 사용할 DNS 이름은 무엇인가?
• 어떤 포트를 노출해야 하는가?
• 이 연결에 NetworkPolicy가 필요한가?
• Secret이 필요한가, 아니면 연결 문자열을 ConfigMap에 넣어도 안전한가?

사용자에게 직접 물어보는 순진한 해결책은 전체 취지를 무색하게 만든다.

해결책: 타입이 지정된 포트를 갖는 Service‑Template 시스템

라이브러리의 모든 구성 요소(PostgreSQL, Redis, Kafka 등)는 포트에 타입 메타데이터를 주석으로 달아 정의한다:

{
  "name": "postgresql",
  "ports": [
    {
      "port": 5432,
      "type": "postgres",
      "envVarTemplate": "{{TARGET_NAME}}_DATABASE_URL",
      "valueTemplate": "postgresql://{{USER}}:{{PASSWORD}}@{{SERVICE_DNS}}:{{PORT}}/{{DATABASE}}"
    }
  ],
  "templates": {
    "secret": {
      "USER": "postgres",
      "PASSWORD": "{{GENERATE_RANDOM_PASSWORD}}",
      "DATABASE": "appdb"
    }
  }
}

UI에서 my‑app에서 postgresql로 선을 그리면 Core는:

1. 대상 포트 타입(postgres)을 조회한다.
2. envVarTemplate을 적용해 → POSTGRESQL_DATABASE_URL을 만든다.
3. 런타임 값(생성된 시크릿, DNS 이름 등)으로 valueTemplate을 렌더링한다.
4. 적절한 Secret, ConfigMap, Service, 그리고 선택적인 NetworkPolicy 객체를 자동으로 생성한다.

이 접근법 덕분에 개발자는 시각적인 영역에 머무를 수 있고, 시스템이 번거롭고 오류가 발생하기 쉬운 배선을 모두 처리한다.

TL;DR

• KubeOrch는 Kubernetes 워크로드를 시각적으로 설계·연결·배포하게 해준다—YAML이 필요 없다.
• Core는 JSON‑to‑YAML 변환, 자동 연결, Nixpacks 빌드, 실시간 스트리밍을 담당한다.
• UI는 React Flow, Next.js, Tailwind로 만든 직관적인 드래그‑앤‑드롭 캔버스를 제공한다.
• OrchCLI는 부드러운 로컬 개발 경험을 제공하고, Astro 문서는 모든 내용을 쉽게 찾아볼 수 있게 한다.

한 번 사용해 보고, 시각 모델이 Kubernetes의 강력함과 최종적으로 일치하도록 해 보세요!

{
  "services": [
    {
      "name": "my‑service",
      "image": "my‑image:latest",
      "env": [
        {
          "name": "DB_URL",
          "value": "postgres://user:password@db:5432/2/{{DB_NAME}}"
        }
      ]
    }
  ]
}

연결을 그리면 Core가 포트 타입을 매칭하고, 템플릿을 해결된 값으로 렌더링한 뒤, 결과를 종속 서비스의 환경 변수로 주입한다—민감한 정보는 Secret으로 처리한다.

150+ services가 이 방식으로 정의되어 있으며, 데이터베이스, 큐, ML 플랫폼, 모니터링 스택 등 다양한 영역을 포괄한다.

왜 오픈 소스인가?

저는 이것을 SaaS로 만들 수도 있었습니다. 생각도 해봤죠.

하지만 쿠버네티스 툴링은 커뮤니티 신뢰에 의해 살아남고 사라집니다. 운영자는 클러스터 자격 증명이 제3자 API를 통해 전달되는 것을 원하지 않습니다. 그들은 직접 컨트롤 플레인을 실행하고, 코드를 감사하며, 수정 사항을 기여하고 싶어합니다.

더 중요한 것은 — KubeOrch가 해결하는 문제는 보편적이라는 점입니다. YAML과 씨름하는 모든 팀은 같은 싸움을 하고 있습니다. 이 문제를 잘 해결하는 오픈소스 프로젝트는 전체 생태계의 인프라가 됩니다.

KubeOrch는 Apache 2.0 licensed이며, CNCF‑지향 프로젝트로서 완전한 거버넌스 문서를 갖추고 있습니다:

• 기여자 단계(기여자 → 멤버 → 유지관리자)
• 거버넌스 정책
• API 안정성 정책
• 커뮤니티 레포에서의 RFC/제안 프로세스

궁극적인 목표는 이 프로젝트를 CNCF 샌드박스에 기부하는 것입니다. 기본 작업은 이미 마련되어 있습니다.

시작하기

로컬에서 시도하기

# Install the CLI
curl -sfL https://raw.githubusercontent.com/KubeOrch/cli/main/install.sh | sh

# Initialize a new project
orchcli init

# Start everything
orchcli start

시각적 캔버스를 보려면 를 엽니다.

Core를 직접 실행하기

git clone https://github.com/KubeOrch/core.git
cd core
go mod tidy
go run main.go

Core는 에서 시작합니다.

레포지토리 탐색

• KubeOrch/core — Go 백엔드, 오케스트레이션 엔진
• KubeOrch/ui — Next.js 시각적 캔버스
• KubeOrch/cli — OrchCLI 개발자 도구
• KubeOrch/community — 거버넌스, 로드맵, RFC
• KubeOrch/docs — 전체 문서

---

다음 단계

로드맵에는 단기적인 세 가지 우선 순위가 있습니다:

1. GitOps integration — 시각 디자인을 Git 저장소와 동기화하고 푸시 시 배포를 트리거합니다
2. Multi‑cluster support — 하나의 캔버스에서 여러 클러스터에 걸친 워크로드를 관리합니다
3. Plugin SDK — 커뮤니티가 맞춤형 컴포넌트를 구축하고 마켓플레이스에 게시할 수 있게 합니다

이 중 어떤 문제에 관심이 있다면, 기여자 가이드는 커뮤니티 저장소에 있으며 이슈가 열려 있습니다.

---

마무리 생각

Kubernetes는 사라지지 않을 것입니다. 하지만 개발자 경험은 기본 플랫폼의 강력함에 맞추기까지 아직 갈 길이 멉니다.

KubeOrch는 그 격차를 메우기 위한 시도입니다 — 분산 시스템의 시각적 정신 모델을 기본 인터페이스로 만들고, YAML 위에 얹힌 2차 시각화 레이어가 아니라.

Kubernetes 설정의 어려움을 겪어봤다면 한번 시도해 보세요. 그리고 함께 만들고 싶다면 언제든 환영합니다.

GitHub:
Follow me on X/Twitter for more.