FIX: [k8scluster] update k8scluster infor from CB-SP for ListK8sCluster()

[sykim-etri]

본 PR은 ListK8sCluster() API 호출시 최신 정보 확인을 위해 CB-SP에 직접 관련 정보를 요청합니다.

fixes #1933

[seokho-son]

@sykim-etri

• List를 확인할 때 마다 CSP API를 호출하는 것은 다소 소모적일 수 있고, 금방 성능 이슈에 직면할 수도 있을 것 같습니다. 가급적 저장된 데이터를 활용하고 CSP 호출은 줄이면 좋을 것 같긴 합니다.
• CB-TB가 생성 요청 후 결과를 받아 DB에 저장한 결과 값 대비, 이후 CSP가 자체적으로 동적&지속적으로 변경하는 정보는 어떤 것이 있는지요?

[sykim-etri]

@seokho-son
클러스터 생성 API 호출이 동기식으로 호출되지 않기 때문에 이슈들이 존재하는 상황입니다. 간단하게는 주요 정보인 Status 값을 제때 확인할 수가 없으며, 이외 노드그룹 추가나 삭제시에도 해당 노드그룹에 대한 정보들도 제때 확인하기가 어려운 실정입니다.

과도한 CSP API 호출로 인한 성능 이슈는 현재 CB-TB의 캐시 시스템이면 커버가 가능하진 않을까요?
(클러스터 관련 API에 반영 여부는 명확하게 파악되진 않았습니다만..)

[seokho-son]

@sykim-etri 현황 공유 감사합니다.

CSP API 호출은 최소화 하는 형태이면 좋을 것 같긴합니다. ^^ (MCI도 마찬가지). 클러스터 형상을 미리 정의해두고, 라이프사이클을 관리하는 형태로 기능을 제공해줄 수도 있을 것 같습니다.

• 다만, 현재는 개발 과정 중에 있으므로, PR은 승인 가능해보이며, 성능 관련된 이슈는 향후에 성능 이슈가 발생하면 대응해도 될 것 같습니다.
• 향후에는 클러스터의 형상이 완전히 갖춰지는 것을 확인 후, 클러스터의 형태를 오브젝트로 잘 완성하고, 구축된 오브젝트 정보를 기반으로 리스트를 리턴해도 좋을 것 같습니다. (선언형 관리 형태)

과도한 CSP API 호출로 인한 성능 이슈는 현재 CB-TB의 캐시 시스템이면 커버가 가능하진 않을까요?
(클러스터 관련 API에 반영 여부는 명확하게 파악되진 않았습니다만..)

• GET인 경우에는 모두 API 캐시가 동작하도록 되어 있으니, 말씀해주신 바와 같이 k8s 관련 api 호출시에도 적용은 될 것입니다. (단 캐시 기한은 코드상 API 호출 func 파라미터에 지정되어 있는 기한을 따릅니다.)

[seokho-son]

/approve