Crossplane, Terraform을 대체할 수 있을까. 개념과 비교해보기

Crossplane은 쿠버네티스 익스텐션 오픈소스다. K8S API를 통해서 쿠버네티스를 포함한 모든 리소스를 매니징할 수 있게 해준다.

Cloud Native Compute Foundation(CNCF)의 프로젝트로, 현재 AWS, Azure와 같은 클라우드 리소스 매니징에 많이 사용된다.

Crossplane?

• 쿠버네티스 클러스터로부터 외부, non-쿠버네티스 리소스와 연결하고 이 리소스를 활용하는데 사용됨
• Kubernetes CRD로 만들어져 쿠버네티스 오브젝트의 external 리소스다.
• external resource의 state를 감시하고, state를 적용하는 쿠버네티스 컨트롤러 역할을 한다.

Crossplane Components

Crossplane의 강점은 Composition에 있다. 다른 유형의 리소스를 결합해서 새로운 유형의 리소스 구축이 가능하다. 예를 들면 kubernetes cluster와 nodepool를 만들거나, DB 인스턴스와 스키마, 유저를 만들 때 등등 효율적인 매니징이 가능하다.

https://prune998.medium.com/playing-with-crossplane-for-real-f591e66065ae

내가 만약 Postresql 인스턴스를 claim 하면, Composite Resource를 참조하고 CloudSQLInstance와 Firewall Rule을 생성하게된다.

위 과정을 좀 더 세부적으로 접근하면, 다음과 같다.

1. CRD(Custom Resource Definition) 생성: 프로바이더는 각 클라우드 리소스를 관리하기 위해 CRD를 생성. (노란 박스의 CRD)
2. XRD(CompositeResourceDefinition) 생성: 인프라 팀은 XRD를 생성하여 지정된 매개변수를 조정 인터페이스를 생성.
3. Crossplane에 의한 CRD 생성 및 관리: Crossplane은 XRD를 기반으로 두 가지 새로운 CRD를 생성하고 maintain함. (하나는 Claim, 다른 하나는 CompositeResource(XR, 초록박스)임) Crossplane은 이 CRD를 기반으로 CR(CustomResource)를 관찰하고 조정함
4. Composition 생성: 인프라 팀은 Composition을 생성함. 이 Composition은 원본 XRD와 CRD 목록을 참조하여 리소스를 생성. 이 과정은 XRD 인터페이스에서 값을 가져와 리소스를 템플릿화하는 것과 유사함.
5. 리소스 클레임: 개발 팀은 리소스(다이어그램의 보라색 박스)를 Claim하게됨. Claim은 Crossplane이 유지 관리하는 특정 유형의 CustomResource.
6. CompositeResource(XR) 생성: Crossplane은 Claim을 기반으로 XR을 생성.
7. CustomResource(CR) 생성: Crossplane은 CompositeResource(XR)의 내용에 기반하여 제공자의 리소스 인스턴스인 CR을 생성
8. 리소스 조정: 제공자는 관리하는 리소스를 조정하고, GCP(Google Cloud Platform) API를 호출하여 CR에 선언된 리소스를 생성.   
   
   더 쉬운 이해를 위해 비유를 하자면,

• Provider: 레스토랑에서 요리를 만들기 위해 재료를 공급하는 공급업체
• CRD(Custom Resource Definition): 레스토랑에서 사용하는 재료의 레시피로, 주방장이 이 CRD를 보고 요리를 할 수있음
• XRD(Composite Resource Definition): 여러 레시피를 하나의 메뉴로 만드는 것임. 하나의 메뉴라고 보면됨.
• Claim과 XR(Composite Resource): Claim은 손님이 주문으로 원하는 요리를 요청하는 것. XR은 주방에서 실제로 요리를 준비하는 과정임.
• CR(Custom Resource): 요리가 완성되면 개별 접시에 담아 제공됨. 하나의 메뉴에 여러 접시에 담긴 요리가 있음. 이 개별 접시 요리가 CR이며, 클라우드 리소스 단위임.

Terraform vs Crossplane

테라폼은 크로스플레인의 주요 비교대상이다. 

공통적으로 둘다 엔지니어가 인프라를 선언적으로 구성할 수 있으며, Provider Plugin을 지원하기 때문에 다양한 인프라 관리가 가능하다. 특히 적극적인 커뮤니티가 있다. 물론 Crossplane이 좀 더 작다.

차이점은 Crossplane이 Control plane이라면 Terraform은 Control plane에 대한 Interface가 CLI 라는 것이다.

Collaboration

협업에 있어 Terraform은 작업 중에 state 파일에 의존하며, 전체 인프라 구성을 적용하는 동안에 다른 변경이 불가능함. Crossplane은 XRM으로 리소스의 느슨한 결합으로 결과 일관성을 가지기 때문에 협업 확장에 도움이됨.

Self Servie

Terraform은 모듈로 자체 서비스 모델을 지원하기에 협업 제약에 종속됨. Crossplane은 API 엔드포인트로 노출되는 Composite Resource를 통해 더 높은 수준의 접근 제어 추상화가 제공됨.

Integration and Automation

Terraform은 자체 API 제공이 안되며 주로 CI/CD 파이프라인을 통해서 자동화됨. Crssplane은 지속적으로 인프라를 감시하고 변경이 있으면 자동으로 조정됨. 특히 API 제공하기 때문에 자동화에 유리함

Terraform는 관리할 리소스의 사이즈가 커질 수록 복잡해지며, tfstate 관리가 쉽지않다. 특히, Terraform으로 생성한 리소스가 콘솔 상에서 수정이 일어나면 곤란한 상황도 발생한다.

이런 부분에선 확실히 Crossplane이 우위를 가지고 있다. 둘은 공식 문서에서도 나와있듯이 대체재보단, 보완재로 활용되어도 좋을 것같다.

---

직접 테스트해본 결과, 쿠버네티스 기반의 Gitops + ArgoCD로 CD 파이프라인을 활용한다면, crossplane은 아주 유용할 것같다.

https://marketplace.upbound.io/providers

Crossplane은 어플리케이션의 클라우드 리소스와 쿠버네티스 리소를 패키징 + 상태 유지할 수 있다. 심지어 unbound marketplace에 가면, 기본적으로 aws, gcp, azure는 모두 지원하며 종류가 생각보다 많으며 문서도 잘 정리되어 있어 쉽게 적용할 수 있다.

실무에 조금씩 활용해보면서, 시간나면 후기를 정리해보려 한다.