Kro (Kube Resource Orchestrator) 란?

 

AWS, Google, Microsoft가 공동 개발한 새로운 Kubernetes 오픈 소스 프로젝트, Kro

: 3사가 공동개발 ㄷㄷ 인데 어떻게 단순화하기 위해 이 오픈소스를 만들게 된 건지 궁금해서 찾아봤다

메인으로 참고한 글 ↓

Kubernetes Gets a New Resource Orchestrator in the Form of Kro

 

Kube Resource Orchestrator(Kro)는?

- Kubernetes에서 워크로드 배포 및 관리를 단순화하는 오픈 소스 프로젝트

- Kubernetes의 점점 증가하는 복잡성을 해결하려는 최신 시도

- 지금까지도 Kubernetes의 복잡성을 줄이려는 다양한 접근법이 있었지만, Kro는 간결성과 사용 편의성을 강조한다는 점에서 차별화

 

 

윗 article을 기반으로 Kro의 동기, 아키텍처, 사용 예시에 대해 간단히 요약해 보려고 한다

---

 

Kubernetes의 복잡성 문제

복잡성 해결을 위해 시도했던 것들은,

• Helm은 패키지 관리자 역할
• Cloud Native Application Bundles(CNAB)은 분산 애플리케이션을 위한 표준 패키징 형식으로 개발
• Microsoft와 Alibaba는 Open Application Model(OAM)을 만들었고, 이는 KubeVela라는 형태로 발전

그러나 여전히 애플리케이션 개발자는 Kubernetes의 다양한 리소스를 개별적으로 다뤄야 함. 여전히 복잡함.

예를 들어, WordPress를 배포한다고 가정

• ConfigMap: WordPress 설정 파일 저장
• Secret: MySQL의 자격 증명 저장
• PersistentVolume 및 PVC 저장소 설정
• StatefulSet: MySQL을 고가용성(HA)으로 실행
• Service: MySQL과 WordPress를 네트워크에서 노출
• Ingress: 외부에서 접근 가능한 엔드포인트 제공

-> 워드프레스 하나만 배포하더라도 운영자는 여러 리소스를 고려해야 함

Helm 차트가 일부 문제를 해결할 수 있지만, Helm은 디자인 타임(설계 단계) 패키징 형식일 뿐이며,

실제로 배포 후에는 DevOps 팀이 개별 리소스를 계속 관리해야 함 ㅇㅇ

---

 

그래서 Kro란 무엇인가?

• Kro는 Kubernetes 네이티브 프레임워크로, 복잡한 Kubernetes 리소스 구성을 단순화
• 개별 리소스를 정의하고 관리하는 대신, 연관된 리소스를 하나의 재사용 가능한 단위로 묶어 효율적인 배포 및 관리를 가능하게 힘

Kro는 ResourceGraphDefinition(RGD)라는 개념을 도입!

• RGD는 Kubernetes Custom Resource Definition(CRD)로, 관련된 Kubernetes 리소스들과 그 관계를 선언적으로 정의
• 애플리케이션을 하나의 논리적 단위로 관리할 수 있도록 설계되었으며, 의존성을 이해하고 올바른 배포 순서를 결정할 수 있는 DAG(유향 비순환 그래프) 구조를 가짐 (ㅇㅎ...)

Kro의 주요 특징

✅ Custom Expression Language(CEL) 활용:
Kubernetes webhook에서 사용하는 CEL을 사용하여 객체 간 값을 쉽게 전달하고, 논리 연산을 수행할 수 있음

✅ 리소스 자동 정렬:
CEL을 활용하여 리소스 간의 관계를 정의하면, Kro가 자동으로 올바른 생성 순서를 결정함 (신기하다)

✅ CRD 기반 관리:
RGD를 정의하면, Kubernetes는 이를 CRD로 인식하여 여러 애플리케이션 인스턴스를 쉽게 배포할 수 있음

---

Kro로 리소스 관리 예시

기존 Kubernetes 배포 예시

Apache 웹 서버를 배포하기 위한 Kubernetes 리소스(Deployment & Service)를 정의한 예시 

• Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: apache
  template:
    metadata:
      labels:
        app: apache
    spec:
      containers:
        - name: apache
          image: httpd:latest
          ports:
            - containerPort: 80

• Service

apiVersion: v1
kind: Service
metadata:
  name: apache-service
spec:
  type: NodePort
  selector:
    app: apache
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30080 

 

 

 

Kro의 RGD로 변환해보자~

위의 Deployment와 Service를 하나의 ResourceGraphDefinition(RGD)로 변환하면 다음과 같다

apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
  name: web-app
spec:
  schema:
    apiVersion: v1alpha1
    kind: Application
    spec:
      name: string
      image: string | default="httpd:latest"
      replicas: integer | default=1
      svcType: string | default="ClusterIP"
    status:
      deploymentConditions: ${deployment.status.conditions}
      availableReplicas: ${deployment.status.availableReplicas}

  resources:
    - id: deployment
      template:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: ${schema.spec.name}
        spec:
          replicas: ${schema.spec.replicas}
          selector:
            matchLabels:
              app: ${schema.spec.name}
          template:
            metadata:
              labels:
                app: ${schema.spec.name}
            spec:
              containers:
                - name: ${schema.spec.name}
                  image: ${schema.spec.image}
                  ports:
                    - containerPort: 80

    - id: service
      template:
        apiVersion: v1
        kind: Service
        metadata:
          name: ${schema.spec.name}-service
        spec:
          type: ${schema.spec.svcType}
          selector: ${deployment.spec.selector.matchLabels}
          ports:
            - protocol: TCP
              port: 80
              targetPort: 80

✅ 위 RGD는 애플리케이션의 이름, 이미지, 서비스 타입을 동적으로 설정할 수 있도록 구성
✅ schema.spec.name을 활용하여 Deployment와 Service의 이름을 자동으로 지정

---

Kro로 애플리케이션 배포하기

- Apache 웹 애플리케이션 배포

apiVersion: kro.run/v1alpha1
kind: Application
metadata:
  name: web-app-1
spec:
  name: web-app-1
  image: "httpd:2.4"
  replicas: 3
  svcType: "NodePort"

 

- Nginx 웹 애플리케이션 배포

apiVersion: kro.run/v1alpha1
kind: Application
metadata:
  name: web-app-2
spec:
  name: web-app-2
  image: "nginx"

✅ 같은 RGD를 활용해 Apache와 Nginx 애플리케이션을 각각 배포할 수 있음~

 

Kro는 Kubernetes 리소스를 애플리케이션 수준에서 관리할 수 있는 도구

• 기업의 중앙 IT 팀은 RGD를 정의하여 거버넌스, 정책, 보안 조치를 적용할 수 있다.
• 개별 DevOps 팀은 애플리케이션에 필요한 부분만 수정하여 Kubernetes의 복잡성을 줄일 수 있다.

Kro는 Kubernetes의 원시 리소스를 직접 다루지 않고, 애플리케이션 중심의 관리 방식을 제공함으로써 플랫폼 엔지니어링을 한 단계 발전시킬 것이라는 전망이다...

---

우선 어떤 서비스인지 개요는 알게 되었는데

=> 일단 한 번 RGD를 구성해 놓으면 추후 관리에 간단해 지는 것으로 보임. syntax도 간편해 보임.

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

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

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

 my personal opinion is that KRO streamlines kubernetes native management for developers whereas Crossplane extends that model to external system and enables managing any infrastructure 
출처 밑 링크드인 링크

 

Kubernetes Abstraction: The Key to Faster, More Efficient Development

 

생긴 질문들을 추후 추가로 이어 작성해 보겠다