Documentation / Kite

Kite 사용 가이드

계정 권한, VM 할당과 접속, 플랫폼의 동작 구조를 안내합니다. 처음 사용하는 이용자와 서버를 관리하는 운영자를 위한 문서입니다.

콘솔 열기

01 / Access control

계정마다 알맞은 권한.

Kite는 숫자가 높을수록 더 넓은 작업을 허용하되 Level 2와 Level 3의 권한 범위를 분리합니다.

Level 0배정형 사용자

No VM Create

관리자가 배정한 VM을 사용하고 전원과 삭제를 제어할 수 있습니다.

VM 직접 생성과 사양 변경은 허용하지 않습니다.
자기 VM에 접속하고 시작·중지·삭제할 수 있습니다. 다른 사용자의 VM에는 접근할 수 없습니다.

Level 1일반 사용자

Fixed Self-service

내 작업 공간에서 고정 스펙 VM만 생성하고 관리할 수 있습니다.

CPU 2, Memory 4Gi, Disk 25Gi로 고정합니다.
Frontend와 API는 직접 생성하는 VM을 최대 2개로 제한합니다.

Level 2팀 운영자

Power User

자기 VM은 자유 스펙으로 만들 수 있고 관리자 화면에서는 Level 0/1 권한만 조정합니다.

다른 사용자의 VM 조회, 전원 변경, 삭제는 할 수 없습니다.
사용자 권한은 0과 1 사이에서만 바꿀 수 있고 Level 2/3 대상은 건드릴 수 없습니다.

Level 3전체 관리자

Full Admin

Kite의 모든 관리 작업을 수행할 수 있습니다.

전체 VM 제어, 사용자 삭제, 시스템 설정을 허용합니다.
사용자에게 VM Offer를 만들어 스펙을 미리 배정할 수 있습니다.

02 / Resource policy

만들기 전에 확인하세요.

Level 1 · 고정 스펙과 생성 한도

일반 사용자는 직접 VM을 만들 수 있지만 스펙과 생성 한도가 고정됩니다. Frontend와 API가 모두 2대 초과 생성을 막습니다.

CPU: 2
Memory: 4Gi
Disk: 25Gi
Quota: 2 VMs

Level 2 · 자기 VM은 자유 스펙으로

자기 VM을 자유 스펙으로 만들 수 있지만 admin API에서는 사용자 권한 0과 1만 조정합니다. 전체 VM 제어, settings, 사용자 삭제, offer 생성은 Level 3 관리자 작업입니다.

Level 0 · 배정된 VM 사용

관리자가 배정한 VM을 받아 접속하고, 시작·중지·삭제할 수 있습니다. VM 직접 생성과 사양 변경에는 별도 권한이 필요합니다.

03 / VM offers

VM 사전 할당

관리자가 사용자에게 VM 사양을 미리 배정할 수 있습니다. 사용자는 대시보드에서 배정 내용을 확인하고 이름과 접속 정보를 입력해 VM을 만듭니다. 직접 생성 한도보다 큰 VM이 필요할 때도 관리자에게 사전 할당을 요청할 수 있습니다.

관리자가 사양을 배정하고 사용자가 수락하면 가상머신이 생성되는 흐름 — 관리자 배정 → 사용자 수락 → VM 생성 · 개념도

04 / Architecture

요청에서 실제 가상머신까지.

Kite는 Frontend가 KubeVirt를 직접 제어하지 않도록 역할을 나눕니다. API는 권한과 입력을 확인하고 controller는 CRD spec을 기준으로 클러스터 안의 실제 리소스를 조정합니다.

브라우저 요청을 Ingress가 Next.js 프런트엔드와 Go API 컨테이너로 나눠 전달합니다. Go API가 Kubernetes에 CRD spec을 기록하면 Controller 컨테이너가 이를 감시해 KubeVirt 리소스를 조정하고 관찰한 상태를 status에 기록합니다. — 컨테이너 기반의 웹 요청·VM 관리 구조 · /api 요청은 Go API로 직접 전달됩니다. 이미지를 누르면 크게 볼 수 있습니다.

01
사용자가 화면에서 요청
사용자는 Dashboard에서 로그인, VM 생성, 전원 변경 같은 작업을 요청합니다. 화면은 API 응답과 VM 상태를 보여줍니다.
02
API가 권한과 입력 확인
`kite-api`는 세션과 access level을 확인하고 허용된 요청만 Kubernetes API 서버에 기록합니다.
03
CRD가 원하는 상태 보관
`KiteUser`, `KiteVirtualMachine`, `KiteVirtualMachineOffer` CRD의 spec에는 Kite가 추상화한 원하는 상태가 저장됩니다.
04
Controller가 실제 리소스 조정
`kite-controller`는 CRD spec을 읽고 KubeVirt VM, DataVolume, 서비스 같은 실제 Kubernetes 리소스를 맞춥니다.
05
상태가 다시 화면으로 반영
controller는 관측한 상태와 실패 이유를 CRD status에 기록하고 Frontend는 그 값을 사용자에게 보여줍니다.

05 / SSH gateway

하나의 SSH 주소로 VM에 접속하세요.

도입한 이유

VM마다 외부 SSH 포트를 따로 열지 않기 위해 Kite Gateway가 하나의 SSH 진입점을 받습니다. Gateway는 SSH username을 spec.sshId와 매칭해 대상 VM을 찾습니다.

SSH 클라이언트가 라우터와 LoadBalancer Service를 거쳐 Kite SSH Gateway에 연결합니다. Gateway는 SSH ID와 초기 비밀번호를 확인하고 관리 SSH 키로 클러스터 내부 VM의 22번 포트에 연결합니다. 사용자 비밀번호는 VM에 전달하지 않습니다. — SSH Gateway 연결 구조 · 외부 22번 → Service 12311번은 포트 전달 예시입니다. 이미지를 누르면 크게 볼 수 있습니다.

로그인 프록시 방식

사용자는 VM 생성 시 입력한 초기 비밀번호로 Gateway에 로그인합니다. Gateway는 이 비밀번호를 VM에 전달하지 않습니다. 인증 후 Kite 관리 SSH key로 VM sshd에 접속하고 세션만 중계합니다.

현재 지원 범위

외부 사용자 public key 인증은 아직 지원하지 않습니다.

host SSH 포트

설치 스크립트는 host sshd 포트를 변경하지 않습니다. Level 3 관리자는 Admin Settings에서 Gateway Service 포트와 사용자 안내 포트를 따로 저장할 수 있습니다.

예를 들어 외부 라우터가 22번을 Service 12311번으로 넘기면 UI는 사용자에게 22번 접속 명령을 보여줍니다.

Kite 시작하기 맨 위로