[BYOK] TKS BYOK

[ktkfree]

BYOK ( Bring Your Own Kubernetes ) 기능을 정식 feature 로 설계/개발한다.

ASIS

import는 공식 feature 가 아니고, admin cluster 에 "LMA 를 설치"하기 위해 임시로 개발한 기능이에요.
즉, LMA 설치가 목적이지 imported cluster 의 TKS 클러스터화에 대한 고려는 되지 않았습니다.
import는 kubeconfig 를 입력받아 secret만 넣어주고, DB 에 기본값으로 클러스터를 생성하는 최소한의 행위입니다.
따라서 create-user-cluster 워크플로우에서 하는 모든 행위들을 skip 한 상태이기 때문에 관련된 모든 곳에서의 동작을 보장할 수 없습니다.
생각나는 부분은
 . decapod 로 관리되지 않기에 cluster의 상태를 보여줄 수 없다던가 ( 예를들어 노드개수등 )
 . addon 을 설치하지 않기에 해당 cluster에 argo rollout 이 없어 앱서빙이 안된다던가
 . rbac-setting 을 하지 않아 tks 기능 실행/설치시 권한 관련 오류가 발생할 수 있다던가
 . keycloak 관련 OIDC 인증이 오류가 발생할 수 있다던가
 . policy 적용을 할 수 없다던가
등등
클러스터 생성 타입(aws[managed,unmanaged], byoh) 에 imported(혹은 external) 류의 타입을 추가하고 ,
외부 import 된 클러스터에 대한 전체 기획/시나리오를 점검하고 UI,Backend 개발을 해야겠습니다.

요건
. TKS UI 를 통하여 BYOK 가 가능해야 한다.
. BYOK 클러스터를 TKS 내에서 논리적으로 타입화하여 관리한다. ( BYOK 에서 가능한 기능, 불가능한 기능들을 산정하고 그에 맞추어 UI,backend 를 설계/개발한다.)
. Admin cluster 에 모니터링 방안을 결정한다. ( 현재는 admin cluater 에 LMA 를 설치하는 것이 정식 feature 가 아니며, 이 결정에 따라 Admin cluster 를 ui 에서 어떻게 보여줄지, import 기능을 사용할지가 결정된다. )
. 개발 방법에 대한 세부 사항이긴 하나 조금 더 고도화한다면, 기존의 create-user-cluster 를 cluster 를 생성하는 부분, 생성된 cluster 에 postjob 을 실행하는 부분으로 스텝을 구분하여 byok 후 postjob 을 수행하도록 재구성한다.