Kro(Kube Resource Orchestrator) vs Helm, Kustomize, Crossplane

클라우드/DevOps

Kro(Kube Resource Orchestrator) vs Helm, Kustomize, Crossplane

dayeonsheep 2025. 3. 8. 21:16

이전 글에서 생긴 나의 궁금증은 아래와 같다

=> 다만 기존의 나온 서비스들을 조합해서 Kro 같은 효과를 낼 순 없는지... kro만을 이용해서 관리를 고도화 한다고 했을 때 발생할 문제점은 어떻게 되는지 궁금

=> Helm 이랑 Kustomize가 이미 잘 구축해 놓은 eco system을 장악할 만한 강력한 편리성을 제공하는지? (는 흠~)

=> crossplane도 같은 기능을 할 수 있을 것 같은데 비교는 어떻게 되는지?

비교해보자!

1. Kro vs Helm

Kro와 Helm은 Kubernetes 리소스 관리에 사용되는 도구이지만, 접근 방식에 차이

Kro의 장점:

구조화된 YAML과 CEL(Common Expression Language)을 사용하여 더 안전하고 예측 가능한 런타임 환경을 제공함
- 이는 실행 환경을 보다 안전하고 예측 가능하게 만들며, 연산 비용도 일정하게 유지할 수 있음(Apiserver도 동일한 방식으로 작동함). 반면 Helm의 튜링 완전한 템플릿 언어로는 이를 보장할 수 없음.
Helm처럼 Go/Jinja 스타일의 템플릿을 사용하는 대신, 구조화된 YAML을 활용하여 사전에 검증하고 검토할 수 있도록 함
DAG(Directed Acyclic Graph, 방향 비순환 그래프) 기반의 자동 종속성 관리로 올바른 배포 순서를 보장함
- Kro는 CEL을 활용하여 리소스 간 종속성을 감지하고 올바른 배포 순서를 보장함.
- 예를 들어, 특정 리소스가 URL을 환경 변수로 필요로 할 경우, Kro는 해당 URL이 상태(Status)에 나타날 때까지 대기한 후 배포를 진행할 수 있음.
CRD(Custom Resource Definition) 업그레이드를 더 효과적으로 처리하여 업데이트 관리가 용이함
- 리소스들 정의를 패키지화(묶어서 작성) 해서 관리하게 되니까
Helm차트의 패키징 배포와 다르게 ResourceGraphDefinition(RGD)을 활용하여 클러스터에 직접 적용되는 방식을 사용함

Helm의 장점:

광범위한 커뮤니티 지원과 풍부한 차트 생태계를 가지고 있음
패키징과 배포를 위한 강력한 CLI 도구를 제공함
튜링 완전한(Turing-complete) 템플릿 언어로 복잡한 로직 구현이 가능함
Go 템플릿 엔진을 사용하여 매니페스트 파일을 동적으로 생성하며, 이를 통해 다양한 환경에 맞게 애플리케이션을 배포할 수 있음

Kro의 단점:

Helm처럼 쉬운 패키징과 배포를 위한 CLI 도구가 부족함
- (이 부분만 극복해도 kro로 migration할 가치는 있다고 생각함)

Helm의 단점:

템플릿 언어의 복잡성으로 인해 유지보수가 어려울 수 있음
튜링 완전한 템플릿 언어로 인해 예측 가능성과 안전성 측면에서 문제가 발생할 수 있음

=> 패키징 방식과 이미 탄탄한 eco system에서 차이가 크다

2. Kro vs Kustomize

Kro와 Kustomize는 리소스 관리 방식에서 차이

Kro의 장점:

자동 종속성 관리 및 커스텀 리소스 및 컨트롤러 생성 기능과 같은 더 고급 기능을 제공함
더 포괄적인 리소스 오케스트레이션 솔루션을 제공함
- <-> Kustomize는 기존 manifest를 사용자 정의하는 데 집중함
CEL을 사용하여 복잡한 로직과 조건부 처리가 가능함
- CEL로 리소스 간의 값 전달과 조건부 로직 구현 가능, '복잡' 이라는 게 어느정도까지인지는 추상적이긴 함

Kustomize의 장점:

기존 매니페스트를 간단하게 사용자 정의할 수 있음
- 매니페스트 오버레이: 기존의 Kubernetes 매니페스트를 오버레이 방식으로 수정하여, 환경별로 다른 설정을 적용할 수 있음
kubectl에 내장되어 있어 추가 설치 없이 사용 가능함

Kro의 단점:

상대적으로 복잡한 설정이 필요할 수 있음
- 다만 실 사용자들은 Simple-schema 시스템의 편의성을 강조하며 긍정적인 평가를 보이긴 함

Kustomize의 단점:

복잡한 로직이나 조건부 처리에 한계가 있음
- 사용해 보지 않아서 이 한계가 얼마나! 불편한지는 아직 잘 모르겠음
자동 종속성 관리 기능이 부족함, 리소스 간의 종속성을 수동으로 관리해야 함

=> 둘의 가장 큰 차이는 자동 종속성 관리 기능 차이인 듯, 기존의 매니페스트 파일을 기반으로 환경별 설정을 적용하고자 하는 경우는 kustomize가 편리할 듯. 간단하게 매니페스트 관리하고, 따로 설치도 안 해도 되고.

3. Kro vs Crossplane

Kro와 Crossplane은 모두 Kubernetes 확장을 위한 도구이지만, 주요 목적에 차이

Kro의 장점:

Kubernetes 네이티브 리소스 관리에 초점을 맞추고 있음
설정이 상대적으로 단순하여 접근성이 뛰어남
CRD 관리를 자동화하여 실수를 방지함

Crossplane의 장점:

멀티클라우드 인프라 관리에 강점을 가지고 있음 (근데 실제로 multi cloud 관리할 땐 빡세다고 함...)
- Kubernetes API를 통해 다양한 클라우드 인프라 리소스를 선언적으로 관리할 수 있음
IaC: 인프라와 애플리케이션 리소스를 일관된 방식으로 관리 가능함
- Kubernetes 리소스와 클라우드 인프라를 동일한 방식으로 관리해서

~~정리하고 보니 장점이 거의 하나인 것처럼 보이지만...~~

Kro의 단점:

현재는 Kubernetes 네이티브 리소스만 관리하며, 클라우드 리소스 관리는 제한적임
멀티클라우드 환경에서의 활용이 제한적일 수 있음

Crossplane의 단점:

설정이 복잡하여 진입 장벽이 높을 수 있음
- (사용해 보았는데 인정하는 바, 러닝 커브가 완만한 편은 아닌 것 같음)
CRD를 과도하게 사용할 경우 API 서버에 부담을 줄 수 있음

=> 멀티 클라우드 관리 차이도 있지만... 제일 큰 건 러닝 커브 차이인 듯. kro가 확실히 간편해 보임

pulumi도 생각 나는데 k8s 리소스랑 여러 클라우드 리소스 관리할 수 있는 IaC긴 하지만

CRD를 활용한 관리 방식이랑도 다르고, helm이랑 통합하려 할 때나... yaml 대신 여러 프로그래밍 언어로 인프라 관리할 때 정도 사용을 고려해 볼법하지 k8s 리소스 관리에서는 helm, kustomize가 더 익숙하기도 해서... kro랑 굳이 비교하진 않아도 될 것 같다.

그냥 terraform, pulumi, crossplane, ansible 등등 IaC 툴 사용을 고려할 때 비교함이 적합

4. 결론

- 개선이 필요한 점 및 우려 사항

Helm 대비 부족한 기능
- Helm처럼 패키징/배포를 CLI로 쉽게 할 수 있도록 추가 기능 필요.
- Loop(for 루프) 기능 부재는 활용성 저하 요인 (논의 중이나 CEL의 실행 예측성 원칙과 충돌할 가능성 있음).
YAML 대신 코드 기반 인터페이스 필요성
- YAML보다 코드로 직접 작성하는 방식을 원하는 사용자도 많음.
- 결국 Shell이나 Python 래퍼를 만들어야 하는 상황이 발생할 가능성이 큼.
- WASM* 을 활용하여 프로그래밍 언어를 직접 사용할 수 있도록 개선 가능성 논의됨.
  - WASM(WebAssembly): 브라우저뿐만 아니라 다양한 환경에서 고성능 애플리케이션을 실행할 수 있도록 설계된 이식 가능한 바이너리 포맷 및 실행 환경(C, C++, Rust 등으로 작성된 코드를 컴파일 해서 다양한 환경에서 실행 가능하도록 함)
  - Kubernetes 같은 클라우드 네이티브 환경에서도 WASM을 활용하면, 특정 프로그래밍 언어에 의존하지 않고 다양한 언어를 사용할 수 있도록 개선할 가능성이 있음.
CRD 과사용 및 API 서버 부담 문제
- 새로운 CRD를 추가하는 방식이 Kubernetes API 서버의 부하를 증가시킬 가능성이 있음.
- Crossplane 등과 마찬가지로 CRD가 과도하게 사용될 경우 유지보수와 성능 저하 문제가 발생할 수 있음.
- Trivy*의 SBOM 저장 방식* 처럼, Kubernetes API 서버를 데이터 저장소처럼 사용하는 것은 비효율적일 수 있음.
  - Trivy: Aqua Security에서 개발한 오픈소스 컨테이너 이미지 및 애플리케이션 보안 스캐너
    - 컨테이너 이미지, 코드 저장소(Git), 라이브러리, 운영체제(OS) 등에서 취약점을 검색하는 도구임.
  - SBOM(소프트웨어 구성 요소 명세서) 저장 방식: 특정 애플리케이션이 사용하는 모든 소프트웨어 패키지, 라이브러리 및 종속성(dependencies)을 기록한 목록
  - Trivy는 SBOM을 Kubernetes API 서버에 저장하는 기능을 제공하지만, 이 방식은 효율적이지 않을 수 있음, 왜?
    - Kubernetes API 서버는 주로 클러스터 상태를 관리하는 역할을 하므로, 대량의 데이터를 저장하는 용도로 사용하면 부담이 커질 수 있음
    - 예를 들어, 많은 컨테이너 이미지의 SBOM 데이터를 Kubernetes API 서버에 저장하면 성능 저하 및 관리 오버헤드가 발생할 가능성이 있음
    - 따라서, 별도의 db나 object storage(S3, PostgreSQL 등) 같은 적절한 저장소를 활용하는 것이 더 나을 수도 있음
- Helm의 단순한 패키징 방식과 비교하면 Kubernetes 리소스 관리가 복잡해질 위험 존재.
멀티 클라우드 환경에서의 한계
- Crossplane이 멀티 클라우드 지원을 하지만 설정이 복잡하여 많은 사용자들이 Kro로 전환을 고려.
- 그러나 Kro가 EKS 같은 외부 리소스를 어떻게 관리할지 명확하지 않음.
- 현재는 Kubernetes 네이티브 리소스만 관리하며, AWS/GCP/Azure 리소스 관리는 ACK/KCC/ASO 같은 기존 컨트롤러에 의존.

결론

Kro는 Helm과 Operator의 장점을 결합한 혁신적인 접근을 제공하지만, 여전히 Helm의 완전한 대체제로 자리 잡기 위해서는 CLI 패키징, 루프 지원 등 프로그래밍 기능 확장, 프로그래밍 가능한 인터페이스, 멀티클라우드 리소스 관리 기능 개선 등의 개선이 필요함
CRD 기반 접근 방식이 Kubernetes API 서버에 과부하를 유발할 수 있다는 점은 장기적인 유지보수 관점에서 우려
Helm의 한계를 보완하면서도 Kubernetes 관리의 복잡성을 줄일 수 있을지가 Kro의 성공 여부를 결정할 핵심 요소가 될 것

꽤나 긍정적인 의견이 많다.

완전 대체까지는 얼마나 걸릴지, 가능할지 불확실하지만 꽤나 강점을 둔 툴로 자리잡을 수 있을 것 같음

참고

저작자표시 비영리 변경금지