Support configuration for seamless K8s cluster provisioning

[sykim-etri]

Seamless K8s Cluster Provisioning 지원을 위한 설정 파일에 관해 논의합니다.

[sykim-etri]

@seokho-son
쿠버네티스 클러스터 프로비저닝을 위한 설정 파일 예시를 대략 다음과 같이 설계해 보았습니다. (작성된 값은 단순 참고용)
차후 추가되거나 변경될 항목들이 더 있을 수 있습니다만 cloudinfo.yaml과는 스타일이 조금 달라서 검토를 요청 드립니다.

아래 각 항목들의 대략적인 내용은 구글시트를 참고하시면 됩니다.

clusterInfo:
  nhncloud:
    nodegroupsWithCluster: true
    nodeImage:
      - region: [kr1,kr2,kr3]
        configurable: true
        available:
          - default
          - aliyun_3_9_x64_20G_alibase_20231219.vhd
      - region: [jp1]
        configurable: false
   rootDisk:
      type:
        configurable: true
        available:
          - default
          - CLOUD_BASIC
      size:
        configurable: true
        min: 10
        max: 40

[seokho-son]

@sykim-etri 감사합니다!

cloudinfo.yaml과 스타일이 조금 차이나는 것은 이슈가 없을 것 같습니다. 최대한 목적에 맞게 효율적으로 구성하는 것이 좋겠습니다. (어떤 항목이 상위 항목이 되는가에 따라, 작성해야 하는 내용이 엄청 늘어나거나 줄어들거나 하니 말이죠^^)

세부적으로는 하기와 같이 질문 드립니다.

• configurable: true 는 꼭 필요한 항목인지요? 관련 내용이나 값이 없는 것을 false로 가정할 수는 없을까요? (작성 항목을 줄이기 위해)
• rootDisk는 type 별로 허용 size가 다르진 않나요? 혹시 다르다면, disk type 별로 지정이 필요할지도 모르겠습니다.

++ 이와 별개로, cluster 라는 명칭을 향후에는 변경해야 할 것으로 보고 있습니다. (현재는 개발 단계이므로 크게 신경쓰고 있지는 않습니다.) 아시다시피, cluster 는 일반적인 용어라서 혼동이 있을 수 있을 것 같습니다. (vm 클러스터, 컴퓨팅 클러스터, 컨테이너 클러스터, 쿠버네티스 (기반 컨테이너) 클러스터 등), CB-TB 내부에 여러가지 자원들이 함께 관리되는 상황이니, 향후에는 용어 변경이 제안되면 좋을 것 같습니다.

[sykim-etri]

• configurable: true 는 꼭 필요한 항목인지요? 관련 내용이나 값이 없는 것을 false로 가정할 수는 없을까요? (작성 항목을 줄이기 위해)

해당 항목 없이 진행하는 것도 고려하긴 했습니다만 (viper를 활용해보지 않은 상황이라) 명시적으로 CSP API상 설정할 수 없음을 체크하기 위해 추가하였습니다. 일단 해당 항목 없이 진행해보고 이슈가 생기면 논의드리겠습니다.

• rootDisk는 type 별로 허용 size가 다르진 않나요? 혹시 다르다면, disk type 별로 지정이 필요할지도 모르겠습니다.

type별로 허용 size 범위에 대해서는 아직 확인하진 않았습니다. 다만 type별로 허용 size 범위를 모두 기재하는 것이 필요할지 의문은 있습니다. (지원하지 않는 범위라면 실제 생성 단계에서 에러를 리턴할 테니) 현재는 단순 오류 방지를 위한 특정 범위를 벗어나는지를 확인하는 용도 정도로 생각하긴 했습니다.
당장은 큰틀에서 진행해보고 추후 개선하는 방향이 어떨까 싶습니다. (Disk Type별로 허용 단위가 정해져 있거나 추가적인 제약등을 세세하게 기술해야 하면 작성 항목이 훨씬 늘어날 수 있을 것 같습니다.)

++ 이와 별개로, cluster 라는 명칭을 향후에는 변경해야 할 것으로 보고 있습니다. (현재는 개발 단계이므로 크게 신경쓰고 있지는 않습니다.) 아시다시피, cluster 는 일반적인 용어라서 혼동이 있을 수 있을 것 같습니다. (vm 클러스터, 컴퓨팅 클러스터, 컨테이너 클러스터, 쿠버네티스 (기반 컨테이너) 클러스터 등), CB-TB 내부에 여러가지 자원들이 함께 관리되는 상황이니, 향후에는 용어 변경이 제안되면 좋을 것 같습니다.

명칭의 중복 이슈가 있으니 API명을 포함하여 적당한 명칭을 변경이 필요하겠네요.
대략 떠오르는 명칭은 Kubernetes, KubernetesCluster, K8sCluster, ManagedKubernetes 등입니다.

[seokho-son]

해당 항목 없이 진행하는 것도 고려하긴 했습니다만 (viper를 활용해보지 않은 상황이라) 명시적으로 CSP API상 설정할 수 없음을 체크하기 위해 추가하였습니다. 일단 해당 항목 없이 진행해보고 이슈가 생기면 논의드리겠습니다.

넵 감사합니다. 해보시고 이리저리 수정해보시는 작업이 필요하실거예요.
viper로 파일을 읽어서 언마셜하면, go struct 에 입력되므로, 이후에는 struct를 기준으로 생각하시면 됩니다. :)

type별로 허용 size 범위에 대해서는 아직 확인하진 않았습니다. 다만 type별로 허용 size 범위를 모두 기재하는 것이 필요할지 의문은 있습니다. (지원하지 않는 범위라면 실제 생성 단계에서 에러를 리턴할 테니) 현재는 단순 오류 방지를 위한 특정 범위를 벗어나는지를 확인하는 용도 정도로 생각하긴 했습니다.
당장은 큰틀에서 진행해보고 추후 개선하는 방향이 어떨까 싶습니다. (Disk Type별로 허용 단위가 정해져 있거나 추가적인 제약등을 세세하게 기술해야 하면 작성 항목이 훨씬 늘어날 수 있을 것 같습니다.)

넵. 우선 먼저 진행해보고 상황을 봐도 좋을 것 같습니다. 말씀하신대로 우선은 모든 type별 일반적인 비허용 size 범위 정도를 작성해두는 것도 방법이겠네요.

명칭의 중복 이슈가 있으니 API명을 포함하여 적당한 명칭을 변경이 필요하겠네요.
대략 떠오르는 명칭은 Kubernetes, KubernetesCluster, K8sCluster, ManagedKubernetes 등입니다.

저도 K8sCluster 정도가 적합할 것 같습니다.

[seokho-son]

@sykim-etri configuration 관련 처리 현황 문의 드립니다.

cloud_conf.yaml 를 대체하는 코드를 작업 중이신지
아니면, k8s 만을 위한 전용 config를 별도로 작업 중이신 것인지도 문의 드립니다.

[sykim-etri]

@seokho-son
k8s를 위한 전용 config를 별도로 생성(k8sclusterinfo.yaml)하여 진행하고 있는 상황입니다.

[seokho-son]

@sykim-etri 공유 감사합니다. 확인하였습니다. 기존 cloud_conf.yaml 의 개선 작업은 제가 처리하겠습니다.

[sykim-etri]

@seokho-son
클러스터 관련 기능 중 conf/cloud_conf.yaml 내용을 참조하는 부분은 클러스터 생성 가능 여부를 판단하는 용도로 사용 중이며,
k8sclusterinfo.yaml은 asset/ 내에서 관리하는 것을 고려하고 있습니다.

[seokho-son]

@sykim-etri 넵 해당 항목인 인지하고 있습니다.

asset/k8sclusterinfo.yaml 을 구성하시고 나면,
conf/cloud_conf.yaml cluster: enable: "y" 도 k8sclusterinfo 에서 처리하실 예정이신지요?
아니면, 기존 config 쪽을 유지하여, assets 과 명확하게 구분하실 계획이신가요?

현재 k8scluster에 대한 설정값들이, 입력값 제약을 가하기 위해서 어쩔 수 없이 활용하는 측면이 있어서,
assets에 포함된다고 보기가 다소 까다로운 것 같습니다. (참고로 현재 assets/cloudinfo.yaml은 시스템 자체와 무관한 퍼블릭 정보 입니다.)

[sykim-etri]

@seokho-son

현재 k8scluster에 대한 설정값들이, 입력값 제약을 가하기 위해서 어쩔 수 없이 활용하는 측면이 있어서, assets에 포함된다고 보기가 다소 까다로운 것 같습니다. (참고로 현재 assets/cloudinfo.yaml은 시스템 자체와 무관한 퍼블릭 정보 입니다.)

k8sclusterinfo.yaml의 내용이 드라이버의 특성을 포함하고 있긴 합니다만 퍼블릭 정보를 기반으로 하니 asset으로 관리되면서 입력값 제약으로 활용되어도 괜찮지 않을까요?

asset/k8sclusterinfo.yaml 을 구성하시고 나면, conf/cloud_conf.yaml cluster: enable: "y" 도 k8sclusterinfo 에서 처리하실 예정이신지요? 아니면, 기존 config 쪽을 유지하여, assets 과 명확하게 구분하실 계획이신가요?

conf/cloud_conf.yaml의 cluster: enable: y는 관리자(?)의 설정으로 조정할 수 있는 부분이니 asset과 구분하는 것이 덜 혼란스러울 것으로 보입니다.

[seokho-son]

넵, 명확하게 두 가지 형태로 구분하고자 하시는 것이라면 문제 없을 것 같습니다.

사실 기존에 conf/cloud_conf.yaml 에도 유사하게 모호한 사항들이 있어서, 조정 예정이었습니다. 여기에 k8scluster 관련 사항들이 포함되어 있어서, 전에 전체 수정하며 k8scluster 관련 사항들도 함께 구현하실 수 있는지 문의 드렸던 것이고요.

일단, 설정 관련 파일의 위치와 내용은 향후에도 무리없이 변경 가능하니,
conf/cloud_conf.yaml 는 신경쓰지 마시고, k8scluster 기능 구현을 위해서 생각하신 바대로 우선 추진하면 될 것 같습니다.