1. 배경
쿠버네티스 배포 및 관리 기능을 구현하기 위하여, 어떤 플랫폼을 이용할지 조사하는 과정에 있습니다. 대표적으로 멀티 클라우드 기반에서 쿠버네티스를 관리하는 툴로는 Rancher, KubeSphere 등이 있지만, Vmware의 Aria automation을 통해 멀티 클라우드에서의 Iaas 리소스 (Virtual Machine, Volue, Network 등) 배포/관리가 가능하기 때문에, 이러한 기능을 바탕으로 쿠버네티스 까지 관리 가능하다면 큰 강점이 있는 플랫폼이라고 생각하였습니다. 이에 따라 Aria에서 쿠버네티스 관리 기능을 살펴보고 리뷰하고자 합니다. 검토를 진행하며 기능 위주의 요구사항 중 필수적인 최소 항목은 다음과 같습니다.
- 쿠버네티스 클러스터 정보(쿠버네티스 버전, Health 상태 등)
- 노드 정보
- 대략적인 모니터링 시스템
- 멀티 클라우드 쿠버네티스 관리 및 배포 지원 여부
2. Aria Kubernetes Integration
공식적으로 Aria에서 쿠버네티스를 Integration하기 위해서 지원하는 플랫폼 다음과 같습니다.
- vSphere with Tanzu Kubernetes Cluster
- TKGI
- OpenShift
2-1. vSphere with Tanzu Kubernetes Cluster
vSphere with Tanzu 서비스의 경우 기본 Tanzu Edition 라이센스를 이용하여 vSphere 계층 위에서 쿠버네티스 워크로드를 실행할 수 있습니다. 기본적인 요구사항은 vSphere 클러스터를 구성이 필요합니다. 이후 클러스터 내부의 EXSi 호스트에서 쿠버네티스 계층이 생성됩니다. 이러한 클러스터를 공식문서에서는 관리자 클러스터 라고 명명합니다.
이러한 관리자 클러스터 내에서 네임스페이스(K8S 네임스페이스와 별개)를 생성하여 리소스 쿼터를 지정하고, 해당 네임스페이스 내에서 쿠버네티스 워크로드를 실행하거나 vSphere Pod라는 리소스를 통해 애플리케이션을 실행할 수 있습니다.
vSphere 클러스터를 구성하기 위해 최소 조건은 ESXi Host 2대, vSAN을 사용할 경우 3개에서 5개의 물리서버를 권장하여 저희 환경에서는 구성할 수 없어 테스트를 진행 할 수 없었습니다.
2-2 TKGI Integration
TKGI(VMWare Tanzu Grid Intgrated Edition)의 경우 VMware IaaS 환경에서 쿠버네티스를 배포하고 관리하도록 도와주는 서비스 입니다. Managed Console을 제공하여 쿠버네티스뿐 아니라 컨테이너의 라이프사이클 관리나, 배포 또한 가능하여 쿠버네티스 워크로드 전체를 관리할 수 있습니다. 또한 네트워크 레이어가 NSX-T가 구성된 환경에서도 Integration이 가능하여, NSX에서 제공하는 다양한 로드밸런서의 타입과, 보안 정책을 사용할 수 있습니다. vSphere 환경뿐 아니라 Ops Manager를 통해 Pulbic Cloud와 Integration까지 지원합니다.(퍼블릭 클라우드의 Managed Cluster를 관리하는 것이 아닌 IaaS에 TKGI를 설치하는 것으로 판단되어 검토가 필요함)
추가로 VMWare에서 관리하는 오픈소스인 Harbor와 백업용 Velero 등 추가로 제공하는 기능이 다양하고, NSX-T 기반의 네트워크 isolate 와 multiple vCenter 호스트 기반의 워크로드를 통해 완벽한 Multi-teanant를 구성할 수 있어 사용에 장점은 많은 것으로 판단되나, 현재 라이센스와 환경이 구성되어있지 않아 직접 테스트를 해보지 못하여 확인이 필요합니다.
위의 상황을 이유로 현재 Aria를 통한 쿠버네티스 배포를 실제로 진행하지는 못하였습니다. 이를 위해 외부에 Vanila 쿠버네티스를 구성한 후 아리아에 조인하는 방식으로 테스트를 진행하였습니다.
3.Aria Automation에서 쿠버네티스 관리
Aria 에서 쿠버네티스 관련 항목은 Assebler → Infrastructure에서 두 가지 Kubernetes Zone과 Kubernetes 탭을 확인할 수 있습니다. Kubernetes Zone의 경우 vSphere with Tanzu에서 배포하기 위해 vCenter 계정과 연결하여, 관리자 클러스터와 관리자 네임스페이스를 불러옵니다. 이를 기반으로 Aria에서 쿠버네티스 클러스터를 배포할 때 클러스터가 생성되는 위치를 지정합니다.
현재 환경에서는 vCenter Account는 존재하지만, 해당 계정에 관리자 클러스터가 생성되지 않아 Kubernetes Zone 생성은 되지만 실제 배포할 수 있는 영역은 없습니다. Account에 관리자 연결된 관리자 클러스터가 있다면, Resource → Compute에서 해당 정보를 볼 수 있습니다.
기존 클러스터를 추가하기 위하여 Kubernetes →Add → Attach External Cluster 에서 클러스터 정보를 입력합니다. Cluster Credential에서 클러스터의 APIServer 주소를 입력하고, 인증 정보를 입력합니다. 인증 타입은 ID/PW, Certificate, Bearer Token 세 가지 타입을 지원합니다(Kubernetes API Authentication 참조). 저는 인증서를 이용하여, Kubernetes CA, apiserver-public- key, apiserver-private-key 를 입력하였습니다.
이후 Validate후 추가하면 다음과 같이 클러스터가 추가된 것을 확인 할 수 있습니다.
클러스터를 추가한 후 확인 했을 때는 생각보다 클러스터에 대한 많은 정보를 알 수 있어 보이지는 않았습니다. 단순히 전체 클러스터의 리소스 총합, 노드, 네임스페이스 정보 정도 확인 할 수 있는데, 이 또한 자세한 정보는 나타나지 않아 기능 구현이 추가로 필요하다고 판단됩니다.
다만 Aria에서는 해당 클러스터에 대한 Kubeconfig 파일을 제공하여 해당 파일을 통해 클러스터에 접근하여 사용하도록 의도한 것으로 판단됩니다. 또한 제공되는 기능 중 하나는 네임스페이스를 생성할 수 있는데, 이를 이용하여 해당 프로젝트에 속한 사용자에게 Kubeconfig 파일을 통해 특정 네임스페이스에 접근 권한을 줄 수 있습니다.
또한 네임스페이스에 Resource/Object Limit을 지정하여 리소스 쿼터를 지정할 수 있습니다. (Custom Resource인 것으로 보아 Tanzu 클러스터에서 지원 가능하는 것으로 보임)
개인적으로 테스트를 진행하며 단순히 Aria를 통해 쿠버네티스 클러스터를 관리하는데의 장점은 Aria의 계정 권한은 이용할 수 있다는 점, 이를 통해 프로젝트 단위의 클러스터를 관리할 수 있는 부분은 있지만 한계도 분명히 존재합니다. 클러스터와 프로젝트가 1대1 매핑이기 때문에 여러 프로젝트에서 동시에 클러스터에 접근할 수 없고, 또한 프로젝트 내의 특정 유저를 지정할 수 없어 쿠버네티스의 세부적인 RBAC 기능을 사용하기에는 한계가 있습니다. 또한 부족한 클러스터/컨테이너 정보, 퍼블릭 클라우드 쿠버네티스와 Integration( 클러스터 추가 시 Cloud account를 통한 추가의 경우 vCententer에 연결된 클러스터만 가능) 이러한 부족한 기능을 Aria Ochestor의 Action을 통해 보완할 수 있을 거라 판단되지만 해당 작업도 공수가 많이 들기 때문에, 다른 모니터링 툴과의 통합이 더 적합할 것으로 생각됩니다.
'Cloud' 카테고리의 다른 글
AWS API Gateway Custom domain 설정 (0) | 2023.12.13 |
---|---|
AWS API Gateway - Lambda 통합 (0) | 2023.12.13 |
Aria Orchestrator Workflow JDBC 추가(Mysql Connector) (2) | 2023.12.03 |