EKS에 대한 kro 고려 사항 - Amazon EKS

이 페이지 개선에 도움 주기

이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 GitHub에서 이 페이지 편집 링크를 선택합니다.

EKS에 대한 kro 고려 사항

이 주제에서는 리소스 구성, RBAC 패턴 및 다른 EKS 기능과의 통합을 사용하는 경우를 포함하여 kro의 EKS 기능 사용에 대한 중요한 고려 사항을 다룹니다.

kro를 사용해야 하는 경우

kro는 복잡한 리소스 관리를 단순화하는 재사용 가능한 인프라 패턴과 사용자 지정 API를 생성하도록 설계되었습니다.

다음을 수행해야 하는 경우 kro 사용:

  • 애플리케이션 팀을 위해 단순화된 API를 사용하여 셀프 서비스 플랫폼 생성

  • 여러 팀에서 인프라 패턴 표준화(데이터베이스 + 백업 + 모니터링)

  • 리소스 종속성 관리 및 여러 리소스 사이에서 값 전달

  • 구현 복잡성을 숨기는 사용자 지정 추상화 구축

  • 여러 ACK 리소스를 상위 수준의 구성 요소로 구성

  • 복잡한 인프라 스택에 대한 GitOps 워크플로 활성화

다음 경우에 kro 사용 안 함:

  • 간단한 독립 실행형 리소스 관리(ACK 또는 Kubernetes 리소스 직접 사용)

  • 동적 런타임 로직이 필요함(kro는 선언에 기반하며, 필수가 아님)

  • 리소스에 종속성 또는 공유 구성이 없음

kro는 '포장된 길'이라고도 하는 재사용 가능한 단호한 패턴을 생성하는 데 뛰어난 기능을 제공합니다. 이를 통해 팀은 복잡한 인프라를 올바르고 쉽게 배포할 수 있습니다.

RBAC 패턴

kro를 사용하면 ResourceGraphDefinitions를 생성하는 플랫폼 팀과 인스턴스를 생성하는 애플리케이션 팀 사이에서 문제를 분리할 수 있습니다.

플랫폼 팀의 책임

플랫폼 팀은 사용자 지정 API를 정의하는 ResourceGraphDefinitions(RGD)를 생성하고 유지 관리합니다.

필요한 권한:

  • ResourceGraphDefinitions 생성, 업데이트, 삭제

  • 기본 리소스 유형(배포, 서비스, 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 기능을 사용하여 Git 리포지토리에서 RGD와 인스턴스를 모두 배포합니다.

리포지토리 구성:

  • 플랫폼 리포지토리: 플랫폼 팀에서 관리하는 ResourceGraphDefinitions 포함

  • 애플리케이션 리포지토리: 앱 팀에서 관리하는 사용자 지정 리소스의 인스턴스 포함

  • 공유 리포지토리: 소규모 조직을 위한 RGD 및 인스턴스 모두 포함

고려 사항:

  • 인스턴스 이전에 RGD 배포(Argo CD 동기화 웨이브가 도움이 될 수 있음)

  • 플랫폼 및 애플리케이션 팀에서 별도의 Argo CD 프로젝트 사용

  • 플랫폼 팀은 RGD 리포지토리 액세스를 제어함

  • 애플리케이션 팀은 RGD 정의에 대한 읽기 전용 액세스 권한을 보유함

Argo CD에 대한 자세한 내용은 Argo CD 작업 섹션을 참조하세요.

ResourceGraphDefinitions 구성

용도, 복잡성 및 소유권에 따라 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)

  • 사용 중단: 주석과 함께 이전 RGD 표시, 마이그레이션 타임라인 전달

인스턴스 마이그레이션:

  • 업데이트된 RGD를 사용하여 새 인스턴스 생성

  • 새 인스턴스가 올바르게 작동하는지 검증

  • 오래된 인스턴스 삭제

  • kro가 기본 리소스 업데이트를 자동으로 처리함

모범 사례.

  • 먼저 비프로덕션 환경에서 RGD 변경 사항을 테스트함

  • 주요 변경 사항에 대해 RGD 이름에 시맨틱 버전 관리 사용

  • 호환성에 영향을 미치는 변경 사항 및 마이그레이션 경로 문서화

  • 애플리케이션 팀을 위한 마이그레이션 예제 제공

검증 및 테스트

프로덕션에 배포하기 전에 RGD를 검증합니다.

검증 전략:

  • 스키마 검증: kro는 RGD 구조를 자동으로 검증함

  • 인스턴스 모의 실습: 개발 네임스페이스에서 테스트 인스턴스 생성

  • 통합 테스트: 구성된 리소스가 함께 작동하는지 확인

  • 정책 적용: 승인 컨트롤러를 사용하여 조직 표준 적용

테스트할 일반적인 문제:

  • 리소스 종속성 및 정렬

  • 여러 리소스 사이에서 전달 값(CEL 표현식)

  • 조건부 리소스 포함(includeWhen)

  • 기본 리소스에서 상태 전파

  • 인스턴스 생성을 위한 RBAC 권한

업스트림 설명서

kro 사용에 대한 자세한 내용은 다음을 참조하세요.

다음 단계