EKS용 kro 고려 사항

EKS용 kro 고려 사항

EKS 관리형 kro 캐퍼빌리티를 사용할 때 고려해야 할 중요한 사항을 설명합니다. 리소스 구성을 사용할 때, RBAC 패턴, 다른 EKS 캐퍼빌리티와의 통합을 다룹니다.

출처: 문서

본문

kro를 사용할 때

kro는 복잡한 리소스 관리를 간소화하는 재사용 가능한 인프라 패턴과 커스텀 API를 만들기 위해 설계되었습니다.

다음이 필요할 때 kro를 사용하세요.

  • 애플리케이션 팀을 위한 간소화된 API가 있는 셀프 서비스 플랫폼 생성
  • 팀 전반의 인프라 패턴 표준화(데이터베이스 + 백업 + 모니터링)
  • 리소스 간 의존성 관리와 값 전달
  • 구현 복잡성을 숨기는 커스텀 추상화 구축
  • 여러 ACK 리소스를 더 높은 수준의 빌딩 블록으로 구성
  • 복잡한 인프라 스택을 위한 GitOps 워크플로 활성화

다음 경우 kro를 사용하지 마세요.

  • 간단하고 독립적인 리소스 관리(ACK 또는 Kubernetes 리소스를 직접 사용)
  • 동적 런타임 로직 필요(kro는 명령형이 아니라 선언적임)
  • 리소스에 의존성이나 공유 구성이 없을 때

kro는 팀이 복잡한 인프라를 올바르게 배포하기 쉽게 만드는, 의견이 담긴 재사용 가능한 패턴인 "paved paths"(포장된 길)를 만드는 데 탁월합니다.

RBAC 패턴

kro는 ResourceGraphDefinition을 만드는 플랫폼 팀과 인스턴스를 만드는 애플리케이션 팀 사이의 관심사 분리를 가능하게 합니다.

플랫폼 팀 책임

플랫폼 팀은 커스텀 API를 정의하는 ResourceGraphDefinition(RGD)을 만들고 유지 관리합니다.

  • 필요한 권한:
    • ResourceGraphDefinition 생성, 업데이트, 삭제
    • 기본 리소스 유형 관리(Deployments, Services, ACK 리소스)
    • RGD가 사용될 모든 네임스페이스에 대한 접근
  • 플랫폼 팀용 ClusterRole 예시:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: platform-kro-admin
rules:
- apiGroups: ["kro.run"]
  resources: ["resourcegraphdefinitions"]
  verbs: ["*"]
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

자세한 RBAC 구성은 kro 권한 구성을 참고하세요.

애플리케이션 팀 책임

애플리케이션 팀은 기본 복잡성을 이해할 필요 없이 RGD가 정의한 커스텀 리소스의 인스턴스를 만듭니다.

  • 필요한 권한:
    • 커스텀 리소스 인스턴스 생성, 업데이트, 삭제
    • 자신의 네임스페이스에 대한 읽기 접근
    • 기본 리소스나 RGD에 대한 접근 불가
  • 이점:
    • 팀이 간단한 고수준 API 사용
    • 플랫폼 팀이 구현 세부 사항 제어
    • 잘못된 구성의 위험 감소
    • 새 팀 구성원의 더 빠른 온보딩

다른 EKS 캐퍼빌리티와의 통합

ACK 리소스 구성

kro는 ACK와 결합해 인프라 패턴을 만들 때 특히 강력합니다.

  • 일반적인 패턴:
    • 스토리지가 있는 애플리케이션: S3 버킷 + SQS 큐 + 알림 구성
    • 데이터베이스 스택: RDS 인스턴스 + 파라미터 그룹 + 보안 그룹 + Secrets Manager 시크릿
    • 네트워킹: VPC + 서브넷 + 라우팅 테이블 + 보안 그룹 + NAT 게이트웨이
    • 스토리지가 있는 컴퓨팅: EC2 인스턴스 + EBS 볼륨 + IAM 인스턴스 프로파일

kro가 의존성 순서를 처리하고, 값(ARN, 연결 문자열 같은)을 리소스 간에 전달하며, 전체 수명 주기를 단일 단위로 관리합니다. ACK 리소스 구성 예시는 ACK 개념을 참고하세요.

Argo CD로 GitOps

Argo CD용 EKS 캐퍼빌리티를 사용해 RGD와 인스턴스 모두를 Git 리포지토리에서 배포합니다.

  • 리포지토리 구성:
    • 플랫폼 리포지토리 - 플랫폼 팀이 관리하는 ResourceGraphDefinition 포함
    • 애플리케이션 리포지토리 - 앱 팀이 관리하는 커스텀 리소스 인스턴스 포함
    • 공유 리포지토리 - 소규모 조직을 위해 RGD와 인스턴스 모두 포함
  • 고려 사항:
    • 인스턴스보다 먼저 RGD를 배포(Argo CD 동기화 웨이브가 도움이 될 수 있음)
    • 플랫폼과 애플리케이션 팀에 별도 Argo CD 프로젝트 사용
    • 플랫폼 팀이 RGD 리포지토리 접근 제어
    • 애플리케이션 팀은 RGD 정의에 대한 읽기 전용 접근 보유

Argo CD에 대한 자세한 내용은 Argo CD 사용하기를 참고하세요.

ResourceGraphDefinition 구성하기

RGD를 용도, 복잡성, 소유권별로 조직합니다.

용도별:

  • 인프라: 데이터베이스 스택, 네트워킹, 스토리지
  • 애플리케이션: 웹 앱, API, 배치 작업
  • 플랫폼: 공유 서비스, 모니터링, 로깅

복잡성별:

  • 단순: 최소 의존성을 가진 2-3개 리소스
  • 중간: 일부 의존성이 있는 5-10개 리소스
  • 복잡: 복잡한 의존성이 있는 10개 이상 리소스

명명 규칙:

  • 설명적인 이름 사용: webapp-with-database, s3-notification-queue
  • 파괴적 변경에는 이름에 버전 포함: webapp-v2
  • 관련 RGD에 일관된 접두사 사용: platform-, app-

네임스페이스 전략:

  • RGD는 클러스터 범위(네임스페이스가 아님)
  • 인스턴스는 네임스페이스 범위
  • RGD에서 네임스페이스 셀렉터를 사용해 인스턴스를 만들 수 있는 위치 제어

버전 관리와 업데이트

RGD 진화와 인스턴스 마이그레이션을 계획하세요.

RGD 업데이트:

  • 파괴적이지 않은 변경: RGD를 제자리에서 업데이트(선택적 필드 추가, includeWhen가 있는 새 리소스)
  • 파괴적 변경: 다른 이름으로 새 RGD 생성(webapp-v2)
  • 폐기(Deprecation): 어노테이션으로 이전 RGD 표시, 마이그레이션 일정 전달

인스턴스 마이그레이션:

  1. 업데이트된 RGD로 새 인스턴스 생성
  2. 새 인스턴스가 올바르게 작동하는지 검증
  3. 이전 인스턴스 삭제
  4. kro가 기본 리소스 업데이트를 자동으로 처리

모범 사례:

  • 프로덕션 이외 환경에서 먼저 RGD 변경 테스트
  • 주요 변경에는 RGD 이름에 시맨틱 버전 사용
  • 파괴적 변경과 마이그레이션 경로 문서화
  • 애플리케이션 팀에 마이그레이션 예시 제공

검증과 테스트

프로덕션에 배포하기 전에 RGD를 검증하세요.

검증 전략:

  • 스키마 검증 - kro가 RGD 구조를 자동으로 검증
  • 드라이 런(dry-run) 인스턴스 - 개발 네임스페이스에서 테스트 인스턴스 생성
  • 통합 테스트 - 구성된 리소스가 함께 작동하는지 확인
  • 정책 강제 - 조직 표준을 강제하기 위해 어드미션 컨트롤러 사용

테스트할 일반적인 문제:

  • 리소스 의존성과 순서
  • 리소스 간 값 전달(CEL 표현식)
  • 조건부 리소스 포함(includeWhen)
  • 기본 리소스에서의 상태 전파
  • 인스턴스 생성용 RBAC 권한

업스트림 문서

kro 사용에 대한 자세한 정보:

  • Getting Started with kro - ResourceGraphDefinition 생성
  • CEL Expressions - CEL 표현식 작성
  • kro Guides - 고급 구성 패턴
  • Troubleshooting - 문제 해결과 디버깅

다음 단계

  • kro 권한 구성 - 플랫폼과 애플리케이션 팀용 RBAC 구성
  • kro 개념 - kro 개념과 리소스 수명 주기 이해하기
  • kro 캐퍼빌리티 문제 해결 - kro 문제 해결
  • ACK 개념 - 구성용 ACK 리소스 알아보기
  • Argo CD 사용하기 - GitOps로 RGD와 인스턴스 배포

더 알아보기 (Learn more)