**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# Kube Resource Orchestrator(kro)를 사용하는 리소스 구성
**Kube Resource Orchestrator(kro)**는 직관적이고 단순한 구성을 사용하여 사용자 지정 Kubernetes API를 정의할 수 있는 오픈 소스 Kubernetes 네이티브 프로젝트입니다. kro를 사용하면 Kubernetes 객체 그룹과 이들 사이의 논리적 작업을 생성하는 새 사용자 지정 API를 쉽게 구성할 수 있습니다.
EKS 기능을 사용하면 kro는 AWS에서 완전하게 관리되므로 클러스터에서 kro 컨트롤러를 설치, 유지 관리 및 조정할 필요가 없습니다.
## kro 작동 방식
kro는 사용자 지정 Kubernetes API의 직관적이고 간단한 생성을 지원하는 `ResourceGraphDefinition`(RGD)이라고 하는 사용자 지정 리소스 정의(CRD)를 도입합니다. `ResourceGraphDefinition`을 생성할 때 kro는 기본 Kubernetes 확장을 사용하여 클러스터에서 새 API를 생성 및 관리합니다. 이 단일 리소스 사양에서 kro는 사양을 기반으로 새 CRD를 생성 및 등록하고 새로 정의된 사용자 지정 리소스를 관리하도록 조정합니다.
RGD에는 여러 리소스가 포함될 수 있으며, kro는 상호 종속성과 리소스 정렬을 결정하므로 사용자가 수행하지 않아도 됩니다. 간단한 구문을 사용하여 한 리소스에서 다른 리소스로 구성을 주입할 수 있으므로 구성을 대폭 단순화하고 클러스터에서 'glue' 연산자가 필요하지 않습니다. kro를 사용하면 사용자 지정 리소스에 기본 Kubernetes 리소스와 클러스터에 설치된 사용자 지정 리소스 정의(CRD)가 포함될 수 있습니다.
kro는 단일 기본 리소스 유형을 지원합니다.
+ **ResourceGraphDefinition(RGD)**: 하나 이상의 기본 네이티브 또는 사용자 지정 Kubernetes 리소스를 캡슐화하여 Kubernetes 사용자 지정 리소스를 정의함
이 리소스 외에도 kro는 여기에서 생성된 사용자 지정 리소스의 수명 주기와 모든 구성 해당 리소스를 생성 및 관리합니다.
kro는 AWS Controllers for Kubernetes(ACK)와 원활하게 통합되어 워크로드 리소스를 AWS 리소스와 함께 구성하여 상위 수준의 추상화를 생성할 수 있습니다. 이를 통해 자체 클라우드 구성 요소를 생성하여 리소스 관리를 단순화하고 조직 표준을 기반으로 기본 및 변경 불가능한 구성 설정을 사용해 재사용 가능한 패턴을 활성화할 수 있습니다.
## kro의 이점
kro를 사용하면 플랫폼 팀이 여러 리소스를 상위 수준 추상화로 구성하는 사용자 지정 Kubernetes API를 생성할 수 있습니다. 그러면 개발자가 표준화되고 버전이 지정된 간단한 사용자 지정 리소스를 사용하여 복잡한 애플리케이션을 배포할 수 있으므로 리소스 관리가 단순화됩니다. 일반적인 리소스 조합에 재사용 가능한 패턴을 정의하여 조직 전체에서 일관된 리소스 생성을 지원합니다.
kro는 여러 리소스 사이에서 값을 전달하고 조건부 로직을 통합하기 위해 [Kubernetes의 공통 표현식 언어(CEL)](https://kubernetes.io/docs/reference/using-api/cel/)를 사용하여 리소스 구성의 유연성을 제공합니다. Kubernetes 리소스와 ACK에서 관리하는 AWS 리소스를 모두 통합된 사용자 지정 API로 구성하여 완전한 애플리케이션 및 인프라 정의를 지원할 수 있습니다.
kro는 Kubernetes 매니페스트를 통해 선언적 구성을 지원하여 GitOps 워크플로 및 인프라를 기존 개발 프로세스와 원활하게 통합하는 코드 사례로 사용할 수 있습니다. EKS 관리형 기능의 일부로 kro는 AWS에서 완전하게 관리되므로 클러스터에 kro 컨트롤러를 설치, 구성 및 유지 관리할 필요가 없습니다.
**예제: ResourceGraphDefinition 생성**
다음 예제에서는 배포 및 서비스를 사용하여 웹 애플리케이션을 생성하는 간단한 `ResourceGraphDefinition`을 보여줍니다.
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: web-application
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
spec:
name: string
replicas: integer | default=3
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ${schema.spec.name}
spec:
replicas: ${schema.spec.replicas}
- id: service
template:
apiVersion: v1
kind: Service
metadata:
name: ${schema.spec.name}
```
사용자가 `WebApplication` 사용자 지정 리소스의 인스턴스를 생성하면 kro는 해당 배포 및 서비스 리소스를 자동으로 생성하여 사용자 지정 리소스와 함께 해당 수명 주기를 관리합니다.
## 다른 EKS 관리형 기능과 통합
kro는 다른 EKS 관리형 기능과 통합됩니다.
+ **AWS Controllers for Kubernetes(ACK)**: kro를 통해 ACK 리소스를 상위 수준의 추상화로 구성하여 AWS 리소스 관리를 단순화합니다.
+ **Argo CD**: Argo CD를 사용하여 여러 클러스터에서 kro 사용자 지정 리소스 배포를 관리하여 플랫폼 구성 요소 및 애플리케이션 스택에 대한 GitOps 워크플로를 지원합니다.
## kro 시작하기
kro의 EKS 기능을 시작하는 방법:
1. AWS 콘솔, AWS CLI 또는 기본 코드형 인프라를 통해 EKS 클러스터에서 [kro 기능 리소스를 생성](create-kro-capability.md)하세요.
1. 사용자 지정 API 및 리소스 구성을 정의하는 ResourceGraphDefinitions(RGDs)를 생성하세요.
1. 사용자 지정 리소스의 인스턴스를 적용하여 기본 Kubernetes 및 AWS 리소스를 프로비저닝 및 관리하세요.
# kro 기능 생성
이 주제에서는 Amazon EKS 클러스터에서 kro 기능을 생성하는 방법을 설명합니다.
## 사전 조건
kro 기능을 생성하기 전에 다음이 있는지 확인합니다.
+ 지원되는 Kubernetes 버전(표준 및 확장 지원의 모든 버전이 지원됨)을 실행하는 기존 Amazon EKS 클러스터
+ EKS 클러스터에서 기능 리소스를 생성할 수 있는 충분한 IAM 권한
+ (CLI/eksctl의 경우) 설치 및 구성된 적절한 CLI 도구
**참고**
ACK 및 Argo CD와 달리 kro에는 신뢰 정책 이외의 추가 IAM 권한이 필요하지 않습니다. kro는 전적으로 클러스터 내에서 작동하며 AWS API 직접 호출을 수행하지 않습니다. 하지만 여전히 IAM 기능 역할에 적절한 신뢰 정책을 제공해야 합니다. kro의 Kubernetes RBAC 권한 구성에 대한 자세한 내용은 [kro 권한 구성](kro-permissions.md) 섹션을 참조하세요.
## 도구 선택
AWS Management Console, AWS CLI 또는 eksctl을 사용하여 kro 기능을 생성할 수 있습니다.
+ [콘솔을 사용하여 kro 기능 생성](kro-create-console.md) - 안내 경험을 이용하려면 콘솔 사용
+ [AWS CLI를 사용하여 kro 기능 생성](kro-create-cli.md) -스크립트 및 자동화를 이용하려면 AWS CLI 사용
+ [eksctl을 사용하여 kro 기능 생성](kro-create-eksctl.md) - Kubernetes 네이티브 경험을 이용하려면 eksctl 사용
## kro 기능을 생성할 때 상황
kro 기능을 생성하는 경우:
1. EKS는 kro 기능 서비스를 생성하고 클러스터의 리소스를 모니터링하고 관리하도록 이를 구성함
1. 사용자 지정 리소스 정의(CRD)가 클러스터에 설치됨
1. ResourceGraphDefinitions 및 해당 인스턴스를 관리할 권한을 부여하는 `AmazonEKSKROPolicy`를 사용하여 IAM 기능 역할에 대한 액세스 항목이 자동으로 생성됨([EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 참조)
1. 기능에서 사용자가 제공하는 IAM 기능 역할(신뢰 관계에만 사용됨)을 수임함
1. kro에서 `ResourceGraphDefinition` 리소스 및 인스턴스 감시를 시작함
1. 기능 상태가 `CREATING`에서 `ACTIVE`로 변경됨
활성 상태가 되면 ResourceGraphDefinitions를 생성하여 사용자 지정 API를 정의하고 해당 API의 인스턴스를 생성할 수 있습니다.
**참고**
자동으로 생성된 액세스 항목에는 ResourceGraphDefinitions 및 해당 인스턴스를 관리할 권한을 kro에 부여하는 `AmazonEKSKROPolicy`가 포함됩니다. kro에서 ResourceGraphDefinitions에 정의된 기본 Kubernetes 리소스(예: 배포, 서비스 또는 ACK 리소스)를 생성하고 관리하려면 추가 액세스 항목 정책을 구성해야 합니다. 액세스 항목 및 추가 권한을 구성하는 방법에 대한 자세한 내용은 [kro 권한 구성](kro-permissions.md) 및 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
## 다음 단계
kro 기능을 생성한 후:
+ [kro 개념](kro-concepts.md) - kro 개념 및 리소스 구성 이해
+ [kro 개념](kro-concepts.md) - SimpleSchema, CEL 표현식 및 리소스 구성 패턴에 대해 알아보기
# 콘솔을 사용하여 kro 기능 생성
이 주제에서는 AWS Management Console을 사용하여 Kube Resource Orchestrator(kro) 기능을 생성하는 방법을 설명합니다.
## kro 기능 생성
1. https://console.aws.amazon.com/eks/home\$1/clusters에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하여 클러스터 세부 정보 페이지를 여세요.
1. **기능** 탭을 선택하세요.
1. 왼쪽 탐색에서 **Kube Resource Orchestrator(kro)**를 선택하세요.
1. **kro 기능 생성**을 선택하세요.
1. **IAM 기능 역할**의 경우:
+ IAM 기능 역할이 이미 있는 경우 드롭다운 선택
+ 역할을 생성해야 하는 경우 **kro 역할 생성** 선택
그러면 신뢰 정책이 미리 채워진 새 탭에서 IAM 콘솔이 열립니다. kro는 클러스터 내에서 완전히 작동하므로 역할에는 추가 IAM 권한이 필요하지 않습니다.
역할을 생성한 후 EKS 콘솔로 돌아가면 역할이 자동으로 선택됩니다.
**참고**
ACK 및 Argo CD와 달리 kro에는 신뢰 정책 이외의 추가 IAM 권한이 필요하지 않습니다. kro는 전적으로 클러스터 내에서 작동하며 AWS API 직접 호출을 수행하지 않습니다.
1. **생성(Create)**을 선택합니다.
기능 생성 프로세스가 시작됩니다.
## 기능이 활성 상태인지 확인
1. **기능** 탭에서 kro 기능 상태를 확인하세요.
1. 상태가 `CREATING`에서 `ACTIVE`로 변경될 때까지 기다리세요.
1. 활성 상태가 되면 기능을 사용할 준비가 된 것입니다.
기능 상태 및 문제 해결에 대한 자세한 내용은 [기능 리소스 작업](working-with-capabilities.md) 섹션을 참조하세요.
## Kubernetes 리소스를 관리할 권한 부여
kro 기능을 생성하는 경우 `AmazonEKSKROPolicy`를 사용하여 EKS 액세스 항목이 자동으로 생성되며, 이를 통해 kro에서 ResourceGraphDefinitions 및 해당 인스턴스를 관리할 수 있습니다. 그러나 ResourceGraphDefinitions에 정의된 기본 Kubernetes 리소스(예: 배포, 서비스, ConfigMaps 등)를 생성하기 위한 권한은 기본적으로 부여되지 않습니다.
이 의도적인 설계는 최소 권한 원칙을 따르며, ResourceGraphDefinitions마다 필요한 권한이 다릅니다. ResourceGraphDefinitions에서 관리할 리소스에 따라 kro에 필요한 권한을 명시적으로 구성해야 합니다.
빠르게 시작하는 경우와 테스트 또는 개발 환경에서는 `AmazonEKSClusterAdminPolicy`를 사용합니다.
1. EKS 콘솔에서 클러스터의 **액세스** 탭으로 이동하세요.
1. **액세스 항목**에서 kro 기능 역할에 대한 항목(이전에 생성한 역할 ARN이 있음)을 찾으세요.
1. 액세스 항목을 선택하여 세부 정보를 여세요.
1. **액세스 정책** 섹션에서 **액세스 정책 연결**을 선택하세요.
1. 정책 목록에서 `AmazonEKSClusterAdminPolicy`를 선택하세요.
1. **액세스 범위**에서 **클러스터**를 선택하세요.
1. **** 연결을 선택합니다.
**중요**
`AmazonEKSClusterAdminPolicy`는 모든 네임스페이스에서 모든 리소스 유형을 생성하는 기능을 포함하여 모든 Kubernetes 리소스를 생성 및 관리하는 광범위한 권한을 부여합니다. 이는 개발 및 POC에 편리하지만 프로덕션에서 사용해서는 안 됩니다. 프로덕션의 경우 ResourceGraphDefinitions에서 관리할 특정 리소스에 필요한 권한만 부여하는 사용자 지정 RBAC 정책을 생성합니다. 최소 권한 구성에 대한 지침은 [kro 권한 구성](kro-permissions.md) 및 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
## 사용자 지정 리소스를 사용할 수 있는지 확인
기능이 활성 상태가 되면 클러스터에서 kro 사용자 지정 리소스를 사용할 수 있는지 확인합니다.
**콘솔 사용**
1. Amazon EKS 콘솔에서 클러스터로 이동
1. **리소스** 탭 선택
1. **확장** 선택
1. **CustomResourceDefinitions** 선택
`ResourceGraphDefinition` 리소스 유형이 나열됩니다.
**kubectl 사용**
```
kubectl api-resources | grep kro.run
```
`ResourceGraphDefinition` 리소스 유형이 나열됩니다.
## 다음 단계
+ [kro 개념](kro-concepts.md) - kro 개념 및 리소스 구성 이해
+ [kro 개념](kro-concepts.md) - SimpleSchema, CEL 표현식 및 구성 패턴에 대해 알아보기
+ [기능 리소스 작업](working-with-capabilities.md) - kro 기능 리소스 관리
# AWS CLI를 사용하여 kro 기능 생성
이 주제에서는 AWS CLI를 사용하여 Kube Resource Orchestrator(kro) 기능을 생성하는 방법을 설명합니다.
## 사전 조건
+ **AWS CLI** – 버전 `2.12.3` 이상. 버전을 확인하려면 `aws --version`을 실행합니다. 자세한 내용은 AWS 명령줄 인터페이스 사용 설명서에서 [설치하기](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)를 참조하세요.
+ **`kubectl`** - Kubernetes 클러스터 작업을 위한 명령줄 도구. 자세한 내용은 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 섹션을 참조하세요.
## 1단계: IAM 기능 역할 생성
신뢰 정책 파일을 생성합니다.
```
cat > kro-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
IAM 역할을 생성합니다.
```
aws iam create-role \
--role-name KROCapabilityRole \
--assume-role-policy-document file://kro-trust-policy.json
```
**참고**
ACK 및 Argo CD와 달리 kro에는 추가 IAM 권한이 필요하지 않습니다. kro는 전적으로 클러스터 내에서 작동하며 AWS API 직접 호출을 수행하지 않습니다. 역할은 EKS 기능 서비스와 신뢰 관계를 설정하는 데만 필요합니다.
## 2단계: kro 기능 생성
클러스터에서 kro 기능 리소스를 생성합니다. *region-code*를 클러스터가 있는 AWS 리전(예: `us-west-2`)으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꿉니다.
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--type KRO \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/KROCapabilityRole \
--delete-propagation-policy RETAIN
```
명령은 즉시 반환되지만, EKS가 필요한 기능 인프라 및 구성 요소를 생성하므로 기능이 활성 상태가 되려면 다소 시간이 걸립니다. EKS는 생성될 때 클러스터에서 이 기능과 관련된 Kubernetes 사용자 지정 리소스 정의를 설치합니다.
**참고**
클러스터가 존재하지 않는다는 오류가 발생하거나 권한이 없는 경우 다음을 확인합니다.
클러스터 이름이 올바른지
AWS CLI가 올바른 리전에 구성되었는지
필요한 IAM 권한이 있음
## 3단계: 기능이 활성 상태인지 확인
기능이 활성 상태가 될 때까지 기다립니다. *region-code*를 클러스터를 생성한 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꿉니다.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--query 'capability.status' \
--output text
```
상태가 `ACTIVE`로 표시되면 기능이 준비된 것입니다.
전체 기능 세부 정보를 볼 수도 있습니다.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro
```
## 4단계: Kubernetes 리소스를 관리할 권한 부여
kro 기능을 생성하는 경우 `AmazonEKSKROPolicy`를 사용하여 EKS 액세스 항목이 자동으로 생성되며, 이를 통해 kro에서 ResourceGraphDefinitions 및 해당 인스턴스를 관리할 수 있습니다. 그러나 ResourceGraphDefinitions에 정의된 기본 Kubernetes 리소스(예: 배포, 서비스, ConfigMaps 등)를 생성하기 위한 권한은 기본적으로 부여되지 않습니다.
이 의도적인 설계는 최소 권한 원칙을 따르며, ResourceGraphDefinitions마다 필요한 권한이 다릅니다. 예: \$1 ConfigMaps 및 Secrets만 생성하는 ResourceGraphDefinition에는 배포 및 서비스를 생성하는 권한과 다른 권한이 필요함 \$1 ACK 리소스를 생성하는 ResourceGraphDefinition에는 해당 특정 사용자 지정 리소스에 대한 권한이 필요함 \$1 일부 ResourceGraphDefinitions는 새 리소스를 생성하지 않고 기존 리소스만 읽을 수 있음
ResourceGraphDefinitions에서 관리할 리소스에 따라 kro에 필요한 권한을 명시적으로 구성해야 합니다.
### 빠른 설정
빠르게 시작하는 경우와 테스트 또는 개발 환경에서는 `AmazonEKSClusterAdminPolicy`를 사용합니다.
기능 역할 ARN을 가져옵니다.
```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--query 'capability.roleArn' \
--output text)
```
클러스터 관리 정책을 연결합니다.
```
aws eks associate-access-policy \
--region region-code \
--cluster-name my-cluster \
--principal-arn $CAPABILITY_ROLE_ARN \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
--access-scope type=cluster
```
**중요**
`AmazonEKSClusterAdminPolicy`는 모든 네임스페이스에서 모든 리소스 유형을 생성하는 기능을 포함하여 모든 Kubernetes 리소스를 생성 및 관리하는 광범위한 권한을 부여합니다. 이는 개발 및 POC에 편리하지만 프로덕션에서 사용해서는 안 됩니다. 프로덕션의 경우 ResourceGraphDefinitions에서 관리할 특정 리소스에 필요한 권한만 부여하는 사용자 지정 RBAC 정책을 생성합니다. 최소 권한 구성에 대한 지침은 [kro 권한 구성](kro-permissions.md) 및 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
## 5단계: 사용자 지정 리소스를 사용할 수 있는지 확인
기능이 활성 상태가 되면 클러스터에서 kro 사용자 지정 리소스를 사용할 수 있는지 확인합니다.
```
kubectl api-resources | grep kro.run
```
`ResourceGraphDefinition` 리소스 유형이 나열됩니다.
## 다음 단계
+ [kro 개념](kro-concepts.md) - kro 개념 및 리소스 구성 이해
+ [kro 개념](kro-concepts.md) - SimpleSchema, CEL 표현식 및 구성 패턴에 대해 알아보기
+ [기능 리소스 작업](working-with-capabilities.md) - kro 기능 리소스 관리
# eksctl을 사용하여 kro 기능 생성
이 주제에서는 eksctl을 사용하여 Kube Resource Orchestrator(kro) 기능을 생성하는 방법을 설명합니다.
**참고**
다음 단계에서는 eksctl 버전 `0.220.0` 이상이 필요합니다. 버전을 확인하려면 `eksctl version`을 실행합니다.
## 1단계: IAM 기능 역할 생성
신뢰 정책 파일을 생성합니다.
```
cat > kro-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
IAM 역할을 생성합니다.
```
aws iam create-role \
--role-name KROCapabilityRole \
--assume-role-policy-document file://kro-trust-policy.json
```
**참고**
ACK 및 Argo CD와 달리 kro에는 신뢰 정책 이외의 추가 IAM 권한이 필요하지 않습니다. kro는 전적으로 클러스터 내에서 작동하며 AWS API 직접 호출을 수행하지 않습니다.
## 2단계: kro 기능 생성
eksctl을 사용하여 kro 기능을 생성합니다. *region-code*를 클러스터를 생성한 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꿉니다.
```
eksctl create capability \
--region region-code \
--cluster my-cluster \
--name my-kro \
--type KRO \
--role-arn arn:aws:iam::[.replaceable]111122223333:role/KROCapabilityRole
```
명령은 즉시 반환되지만 기능이 활성 상태가 되려면 다소 시간이 걸립니다.
## 3단계: 기능이 활성 상태인지 확인
기능 상태를 확인합니다. *region-code*를 클러스터를 생성한 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꿉니다.
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-kro
```
상태가 `ACTIVE`로 표시되면 기능이 준비된 것입니다.
## 4단계: Kubernetes 리소스를 관리할 권한 부여
기본적으로 kro는 ResourceGraphDefinitions 및 해당 인스턴스만 생성하고 관리할 수 있습니다. kro가 ResourceGraphDefinitions에 정의된 기본 Kubernetes 리소스를 생성하고 관리할 수 있도록 하려면 `AmazonEKSClusterAdminPolicy` 액세스 정책을 기능의 액세스 항목에 연결합니다.
기능 역할 ARN을 가져옵니다.
```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
--region region-code \
--cluster my-cluster \
--name my-kro \
--query 'capability.roleArn' \
--output text)
```
클러스터 관리 정책을 연결합니다.
```
aws eks associate-access-policy \
--region region-code \
--cluster my-cluster \
--principal-arn $CAPABILITY_ROLE_ARN \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
--access-scope type=cluster
```
**중요**
`AmazonEKSClusterAdminPolicy`는 모든 Kubernetes 리소스를 생성하고 관리할 수 있는 광범위한 권한을 부여하며 시작을 간소화하기 위해 제공됩니다. 프로덕션 사용 시 ResourceGraphDefinitions에서 관리할 특정 리소스에 필요한 권한만 부여하는 보다 제한적인 RBAC 정책을 생성합니다. 최소 권한 구성에 대한 지침은 [kro 권한 구성](kro-permissions.md) 및 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
## 5단계: 사용자 지정 리소스를 사용할 수 있는지 확인
기능이 활성 상태가 되면 클러스터에서 kro 사용자 지정 리소스를 사용할 수 있는지 확인합니다.
```
kubectl api-resources | grep kro.run
```
`ResourceGraphDefinition` 리소스 유형이 나열됩니다.
## 다음 단계
+ [kro 개념](kro-concepts.md) - kro 개념 및 리소스 구성 이해
+ [kro 개념](kro-concepts.md) - SimpleSchema, CEL 표현식 및 구성 패턴에 대해 알아보기
+ [기능 리소스 작업](working-with-capabilities.md) - kro 기능 리소스 관리
# kro 개념
kro를 사용하면 플랫폼 팀이 여러 리소스를 상위 수준 추상화로 구성하는 사용자 지정 Kubernetes API를 생성할 수 있습니다. 이 주제에서는 실제 예제를 살펴본 다음 kro의 EKS 기능을 사용할 때 알아야 하는 핵심 개념을 설명합니다.
## kro 시작하기
kro 기능을 생성한 후([kro 기능 생성](create-kro-capability.md) 참조) 클러스터에서 ResourceGraphDefinitions를 사용하여 사용자 지정 API 생성을 시작할 수 있습니다.
다음은 간단한 웹 애플리케이션 추상화를 생성하는 전체 예제입니다.
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: webapplication
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
group: kro.run
spec:
name: string | required=true
image: string | default="nginx:latest"
replicas: integer | default=3
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: app
image: ${schema.spec.image}
ports:
- containerPort: 80
- id: service
template:
apiVersion: v1
kind: Service
metadata:
name: ${schema.spec.name}
spec:
selector:
app: ${schema.spec.name}
ports:
- protocol: TCP
port: 80
targetPort: 80
```
이 ResourceGraphDefinition을 적용한 후 애플리케이션 팀은 단순화된 API를 사용하여 웹 애플리케이션을 생성할 수 있습니다.
```
apiVersion: kro.run/v1alpha1
kind: WebApplication
metadata:
name: my-app
spec:
name: my-app
replicas: 5
```
kro는 적절한 구성으로 배포 및 서비스를 자동으로 생성합니다. `image`는 지정되지 않았으므로 스키마의 기본값 `nginx:latest`를 사용합니다.
## 핵심 개념
**중요**
kro는 런타임이 아닌 생성 시 ResourceGraphDefinitions를 검증합니다. RGD를 생성할 때 kro는 CEL 구문을 검증하고 실제 Kubernetes 스키마를 기준으로 표현식의 유형을 확인하며 필드 존재를 확인하고 순환 종속성을 감지합니다. 즉, 인스턴스를 배포하기 전에 RGD를 생성할 때 오류가 즉시 발견됩니다.
### ResourceGraphDefinition
ResourceGraphDefinition(RGD)은 다음을 지정하여 사용자 지정 Kubernetes API를 정의합니다.
+ **스키마** - SimpleSchema 형식(필드 이름, 유형, 기본값, 검증)을 사용하는 API 구조
+ **리소스** - 생성할 기본 Kubernetes 또는 AWS 리소스의 템플릿
+ **종속성** - 리소스가 서로 연관되는 방식(필드 참조에서 자동으로 감지됨)
RGD를 적용하면 kro가 클러스터에서 새 사용자 지정 리소스 정의(CRD)를 등록합니다. 그런 다음 애플리케이션 팀은 사용자 지정 API의 인스턴스를 생성할 수 있으며, kro는 모든 기본 리소스의 생성 및 관리를 처리합니다.
자세한 내용은 kro 설명서의 [ResourceGraphDefinition Overview](https://kro.run/docs/concepts/rgd/overview/)를 참조하세요.
### SimpleSchema 형식
SimpleSchema는 OpenAPI 지식 없이도 API 스키마를 정의하는 단순화된 방법을 제공합니다.
```
schema:
apiVersion: v1alpha1
kind: Database
spec:
name: string | required=true description="Database name"
size: string | default="small" enum=small,medium,large
replicas: integer | default=1 minimum=1 maximum=5
```
SimpleSchema는 `string`, `integer`, `boolean`, `number` 유형(`required`, `default`, `minimum`/`maximum`, `enum`, `pattern`과 같은 제약 조건이 적용됨)을 지원합니다.
자세한 내용은 kro 설명서의 [SimpleSchema](https://kro.run/docs/concepts/rgd/schema/)를 참조하세요.
### CEL 표현식
kro는 공통 표현식 언어(CEL)를 사용하여 값을 동적으로 참조하고 조건부 로직을 추가합니다. CEL 표현식은 `${` 및 `}`로 래핑되며, 다음과 같은 두 가지 방법으로 사용할 수 있습니다.
**독립 실행형 표현식** - 전체 필드 값은 단일 표현식입니다.
```
spec:
replicas: ${schema.spec.replicaCount} # Expression returns integer
labels: ${schema.spec.labelMap} # Expression returns object
```
표현식 결과는 전체 필드 값을 대체하며 필드의 예상 유형과 일치해야 합니다.
**문자열 템플릿** - 문자열에 포함된 하나 이상의 표현식입니다.
```
metadata:
name: "${schema.spec.prefix}-${schema.spec.name}" # Multiple expressions
annotation: "Created by ${schema.spec.owner}" # Single expression in string
```
문자열 템플릿의 모든 표현식은 문자열을 반환해야 합니다. `string()`을 사용하여 다른 유형(`"replicas-${string(schema.spec.count)}"`)으로 변환합니다.
**필드 참조** - `schema.spec`을 사용하여 인스턴스 사양 값에 액세스합니다.
```
template:
metadata:
name: ${schema.spec.name}-deployment
namespace: ${schema.metadata.namespace} # Can also reference metadata
spec:
replicas: ${schema.spec.replicas}
```
**선택적 필드 액세스** - 존재하지 않을 수 있는 필드에 `?`를 사용합니다.
```
# For ConfigMaps or Secrets with unknown structure
value: ${configmap.data.?DATABASE_URL}
# For optional status fields
ready: ${deployment.status.?readyReplicas > 0}
```
필드가 없는 경우 표현식은 실패 대신 `null`을 반환합니다.
**조건부 리소스** - 조건이 충족되는 경우에만 리소스를 포함합니다.
```
resources:
- id: ingress
includeWhen:
- ${schema.spec.enableIngress == true}
template:
# ... ingress configuration
```
`includeWhen` 필드는 부울 표현식 목록을 허용합니다. 리소스를 생성하려면 모든 조건이 true여야 합니다. 현재 `includeWhen`에서는 `schema.spec` 필드만 참조할 수 있습니다.
**변환** - 삼항 연산자 및 함수를 사용하여 값을 변환합니다.
```
template:
spec:
resources:
requests:
memory: ${schema.spec.size == "small" ? "512Mi" : "2Gi"}
# String concatenation
image: ${schema.spec.registry + "/" + schema.spec.imageName}
# Type conversion
port: ${string(schema.spec.portNumber)}
```
**교차 리소스 참조** - 다른 리소스의 값을 참조합니다.
```
resources:
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-data
- id: configmap
template:
apiVersion: v1
kind: ConfigMap
data:
BUCKET_NAME: ${bucket.spec.name}
BUCKET_ARN: ${bucket.status.ackResourceMetadata.arn}
```
CEL 표현식에서 다른 리소스를 참조하면 종속성이 자동으로 생성됩니다. kro는 참조된 리소스가 먼저 생성되도록 보장합니다.
자세한 내용은 kro 설명서의 [CEL Expressions](https://kro.run/docs/concepts/rgd/cel-expressions/)를 참조하세요.
### 리소스 종속성
kro는 CEL 표현식에서 종속성을 자동으로 유추하므로, 사용자는 순서를 지정하지 않고 관계를 설명하면 됩니다. 한 리소스가 CEL 표현식을 사용하여 다른 리소스를 참조하면 kro는 종속성을 생성하고 올바른 생성 순서를 결정합니다.
```
resources:
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-data
- id: notification
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: BucketNotification
spec:
bucket: ${bucket.spec.name} # Creates dependency: notification depends on bucket
```
`${bucket.spec.name}` 표현식은 종속성을 생성합니다. kro는 모든 리소스와 해당 종속성에 대한 방향성 비순환 그래프(DAG)를 빌드한 다음, 생성 시 토폴로지 순서를 계산합니다.
**생성 순서**: 리소스는 토폴로지 순서(종속성 먼저)로 생성됩니다.
**병렬 생성**: 종속성이 없는 리소스는 동시에 생성됩니다.
**삭제 순서**: 리소스는 토폴로지의 반대 순서(종속 항목 먼저)로 삭제됩니다.
**순환 종속성**: 허용되지 않습니다. kro는 검증 중에 순환 종속성이 있는 ResourceGraphDefinitions를 거부합니다.
계산된 생성 순서를 볼 수 있습니다.
```
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}'
```
자세한 내용은 kro 설명서의 [Graph inference](https://kro.run/docs/concepts/rgd/dependencies-ordering/)를 참조하세요.
## ACK를 사용하여 구성
kro는 ACK의 EKS 기능과 원활하게 작업하여 Kubernetes 리소스로 AWS 리소스를 구성합니다.
```
resources:
# Create {aws} S3 bucket with ACK
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-files
# Inject bucket details into Kubernetes ConfigMap
- id: config
template:
apiVersion: v1
kind: ConfigMap
data:
BUCKET_NAME: ${bucket.spec.name}
BUCKET_ARN: ${bucket.status.ackResourceMetadata.arn}
# Use ConfigMap in application deployment
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: app
envFrom:
- configMapRef:
name: ${config.metadata.name}
```
이 패턴을 사용하면 AWS 리소스를 생성하고 세부 정보(ARN, URL, 엔드포인트)를 추출한 후 애플리케이션 구성에 주입할 수 있습니다. 이때 모두 단일 단위로 관리됩니다.
자세한 구성 패턴 및 고급 예제는 [EKS에 대한 kro 고려 사항](kro-considerations.md) 섹션을 참조하세요.
## 다음 단계
+ [EKS에 대한 kro 고려 사항](kro-considerations.md) - EKS 특정 패턴, RBAC, ACK 및 Argo CD와의 통합에 대해 알아보기
+ [kro 설명서](https://kro.run/docs/overview) - 고급 CEL 표현식, 검증 패턴 및 문제 해결을 포함한 포괄적인 kro 설명서
# kro 권한 구성
ACK 및 Argo CD와 달리 kro에는 IAM 권한이 필요하지 않습니다. kro는 전적으로 Kubernetes 클러스터 내에서 작동하며 AWS API 직접 호출을 수행하지 않습니다. 표준 Kubernetes RBAC를 사용하여 kro 리소스에 대한 액세스를 제어합니다.
## kro에서 권한이 작동하는 방법
kro는 범위가 서로 다른 두 가지 유형의 Kubernetes 리소스를 사용합니다.
**ResourceGraphDefinitions**: 사용자 지정 API를 정의하는 클러스터 범위의 리소스. 일반적으로 조직 표준을 설계하고 유지하는 플랫폼 팀에서 관리합니다.
**인스턴스**: ResourceGraphDefinitions에서 생성된 네임스페이스 범위의 사용자 지정 리소스. 적절한 RBAC 권한이 있는 애플리케이션 팀에서 생성할 수 있습니다.
기본적으로 kro 기능에는 `AmazonEKSKROPolicy` 액세스 항목 정책을 통해 ResourceGraphDefinitions 및 해당 인스턴스를 관리할 권한이 있습니다. 그러나 ResourceGraphDefinitions에 정의된 기본 Kubernetes 리소스(예: 배포, 서비스 또는 ACK 리소스)를 생성하고 관리하려면 kro에 추가 권한이 필요합니다. 액세스 항목 정책 또는 Kubernetes RBAC를 통해 이러한 권한을 부여해야 합니다. 이러한 권한 부여에 대한 자세한 내용은 [kro 임의의 리소스 권한](capabilities-security.md#kro-resource-permissions)을 참조하세요.
## 플랫폼 팀 권한
플랫폼 팀은 ResourceGraphDefinitions를 생성하고 관리할 권한이 필요합니다.
**플랫폼 팀을 위한 ClusterRole 예제**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-platform-admin
rules:
- apiGroups: ["kro.run"]
resources: ["resourcegraphdefinitions"]
verbs: ["*"]
```
**플랫폼 팀원에게 바인딩**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: platform-team-kro-admin
subjects:
- kind: Group
name: platform-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-platform-admin
apiGroup: rbac.authorization.k8s.io
```
## 애플리케이션 팀 권한
애플리케이션 팀은 네임스페이스에서 사용자 지정 리소스의 인스턴스를 생성할 권한이 필요합니다.
**애플리케이션 팀의 역할 예제**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: kro-app-developer
namespace: my-app
rules:
- apiGroups: ["kro.run"]
resources: ["webapps", "databases"]
verbs: ["create", "get", "list", "update", "delete", "patch"]
```
**애플리케이션 팀원에게 바인딩**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-kro-developer
namespace: my-app
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: kro-app-developer
apiGroup: rbac.authorization.k8s.io
```
**참고**
역할(이 예제에서는 `kro.run`)의 API 그룹이 ResourceGraphDefinition 스키마에 정의된 `apiVersion`과 일치해야 합니다.
## 읽기 전용 액세스
수정 권한 없이 ResourceGraphDefinitions 및 인스턴스를 확인할 읽기 전용 액세스 권한을 부여합니다.
**읽기 전용 ClusterRole**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-viewer
rules:
- apiGroups: ["kro.run"]
resources: ["resourcegraphdefinitions"]
verbs: ["get", "list", "watch"]
```
**인스턴스의 읽기 전용 역할**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: kro-instance-viewer
namespace: my-app
rules:
- apiGroups: ["kro.run"]
resources: ["webapps", "databases"]
verbs: ["get", "list", "watch"]
```
## 다중 네임스페이스 액세스
애플리케이션 팀에 RoleBindings와 함께 ClusterRoles를 사용하여 여러 네임스페이스에 대한 액세스 권한을 부여합니다.
**다중 네임스페이스 액세스를 위한 ClusterRole**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-multi-namespace-developer
rules:
- apiGroups: ["kro.run"]
resources: ["webapps"]
verbs: ["create", "get", "list", "update", "delete"]
```
**특정 네임스페이스에 바인딩**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-dev-access
namespace: development
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-multi-namespace-developer
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-staging-access
namespace: staging
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-multi-namespace-developer
apiGroup: rbac.authorization.k8s.io
```
## 모범 사례
**최소 권한 원칙**: 각 팀의 책임에 필요한 최소 권한만 부여합니다.
**개별 사용자 대신 그룹 사용**: 쉽게 관리할 수 있도록 개별 사용자가 아닌 그룹에 역할을 바인딩합니다.
**별도의 플랫폼 및 애플리케이션 사안**: 플랫폼 팀은 ResourceGraphDefinitions를 관리하고 애플리케이션 팀은 인스턴스를 관리합니다.
**네임스페이스 격리**: 네임스페이스를 사용하여 서로 다른 팀이나 환경을 격리하고 RBAC로 각 네임스페이스에 대한 액세스를 제어합니다.
**감사를 위한 읽기 전용 액세스**: 감사 목적으로 보안 및 규정 준수 팀에 읽기 전용 액세스를 제공합니다.
## 다음 단계
+ [kro 개념](kro-concepts.md) - kro 개념 및 리소스 구성 이해
+ [kro 개념](kro-concepts.md) - SimpleSchema, CEL 표현식 및 구성 패턴 이해
+ [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) - 기능에 대한 보안 모범 사례 검토
# EKS에 대한 kro 고려 사항
이 주제에서는 리소스 구성, RBAC 패턴 및 다른 EKS 기능과의 통합을 사용하는 경우를 포함하여 kro의 EKS 기능 사용에 대한 중요한 고려 사항을 다룹니다.
## kro를 사용해야 하는 경우
kro는 복잡한 리소스 관리를 단순화하는 재사용 가능한 인프라 패턴과 사용자 지정 API를 생성하도록 설계되었습니다.
**다음을 수행해야 하는 경우 kro 사용**:
+ 애플리케이션 팀을 위해 단순화된 API를 사용하여 셀프 서비스 플랫폼 생성
+ 여러 팀에서 인프라 패턴 표준화(데이터베이스 \$1 백업 \$1 모니터링)
+ 리소스 종속성 관리 및 여러 리소스 사이에서 값 전달
+ 구현 복잡성을 숨기는 사용자 지정 추상화 구축
+ 여러 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 권한 구성](kro-permissions.md) 섹션을 참조하세요.
### 애플리케이션 팀의 책임
애플리케이션 팀은 기본 복잡성을 이해하지 않고도 RGD에서 정의한 사용자 지정 리소스의 인스턴스를 생성합니다.
**필요한 권한**:
+ 사용자 지정 리소스의 인스턴스 생성, 업데이트, 삭제
+ 해당 네임스페이스에 대한 읽기 액세스
+ 기본 리소스 또는 RGD에 대한 액세스 없음
**이점**:
+ 팀에서 단순한 상위 수준 API를 사용함
+ 플랫폼 팀은 구현 세부 정보를 제어함
+ 잘못된 구성의 위험이 감소함
+ 새로운 팀원을 위한 더 빠른 온보딩
## 다른 EKS 기능과 통합
### ACK 리소스 구성
kro는 인프라 패턴을 생성하기 위해 ACK와 결합할 때 특히 강력합니다.
**일반적인 패턴**:
+ **스토리지를 사용하는 애플리케이션**: S3 버킷 \$1 SQS 대기열 \$1 알림 구성
+ **데이터베이스 스택**: RDS 인스턴스 \$1 파라미터 그룹 \$1 보안 그룹 \$1 Secrets Manager 보안 암호
+ **네트워킹**: VPC \$1 서브넷 \$1 라우팅 테이블 \$1 보안 그룹 \$1 NAT 게이트웨이
+ **스토리지를 사용하는 컴퓨팅**: EC2 인스턴스 \$1 EBS 볼륨 \$1 IAM 인스턴스 프로파일
kro는 종속성 정렬을 처리하고 리소스(예: ARN 및 연결 문자열) 사이에서 값을 전달하며 전체 수명 주기를 단일 단위로 관리합니다.
ACK 리소스 구성 예제는 [ACK 개념](ack-concepts.md) 섹션을 참조하세요.
### Argo CD와 함께 사용하는 GitOps
Argo CD의 EKS 기능을 사용하여 Git 리포지토리에서 RGD와 인스턴스를 모두 배포합니다.
**리포지토리 구성**:
+ **플랫폼 리포지토리**: 플랫폼 팀에서 관리하는 ResourceGraphDefinitions 포함
+ **애플리케이션 리포지토리**: 앱 팀에서 관리하는 사용자 지정 리소스의 인스턴스 포함
+ **공유 리포지토리**: 소규모 조직을 위한 RGD 및 인스턴스 모두 포함
**고려 사항**:
+ 인스턴스 이전에 RGD 배포(Argo CD 동기화 웨이브가 도움이 될 수 있음)
+ 플랫폼 및 애플리케이션 팀에서 별도의 Argo CD 프로젝트 사용
+ 플랫폼 팀은 RGD 리포지토리 액세스를 제어함
+ 애플리케이션 팀은 RGD 정의에 대한 읽기 전용 액세스 권한을 보유함
Argo CD에 대한 자세한 내용은 [Argo CD 작업](working-with-argocd.md) 섹션을 참조하세요.
## ResourceGraphDefinitions 구성
용도, 복잡성 및 소유권에 따라 RGD를 구성합니다.
**용도 기준:**
+ **인프라**: 데이터베이스 스택, 네트워킹, 스토리지
+ **애플리케이션**: 웹 앱, API, 배치 작업
+ **플랫폼**: 공유 서비스, 모니터링, 로깅
**복잡성 기준**:
+ **단순**: 종속성이 최소 수준인 2\$13개의 리소스
+ **보통**: 종속성이 보통 수준인 5\$110개의 리소스
+ **복합**: 종속성이 복잡한 수준인 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 사용에 대한 자세한 내용은 다음을 참조하세요.
+ [Getting Started with kro](https://kro.run/docs/guides/getting-started) - ResourceGraphDefinitions 생성
+ [CEL Expressions](https://kro.run/docs/concepts/cel) - CEL 표현식 작성
+ [kro 가이드](https://kro.run/docs/guides/) - 고급 구성 패턴
+ [문제 해결](https://kro.run/docs/troubleshooting) - 문제 해결 및 디버깅
## 다음 단계
+ [kro 권한 구성](kro-permissions.md) - 플랫폼 및 애플리케이션 팀에 대해 RBAC 구성
+ [kro 개념](kro-concepts.md) - kro 개념 및 리소스 수명 주기 이해
+ [kro 기능 관련 문제 해결](kro-troubleshooting.md) - kro 문제 해결
+ [ACK 개념](ack-concepts.md) - 구성을 위한 ACK 리소스에 대해 알아보기
+ [Argo CD 작업](working-with-argocd.md) - GitOps에서 RGD 및 인스턴스 배포
# kro 기능 관련 문제 해결
이 주제에서는 기능 상태 확인, RBAC 권한, CEL 표현식 오류 및 리소스 구성 문제를 포함하여 kro의 EKS 기능에 대한 문제 해결 지침을 제공합니다.
**참고**
EKS 기능은 완전관리형 기능이며, 클러스터 외부에서 실행됩니다. 컨트롤러 로그 또는 `kro-system` 네임스페이스에 대한 액세스 권한이 없습니다. 문제 해결에서는 기능 상태, RBAC 구성 및 리소스 상태에 중점을 둡니다.
## 기능이 ACTIVE이지만 ResourceGraphDefinitions가 작동하지 않음
kro 기능에 `ACTIVE` 상태가 표시되지만 ResourceGraphDefinitions에서 기본 리소스를 생성하지 않는 경우 기능 상태, RBAC 권한 및 리소스 상태를 확인합니다.
**기능 상태 확인**:
EKS 콘솔 또는 AWS CLI를 사용하여 기능 상태 및 상태 문제를 볼 수 있습니다.
**콘솔**:
1. https://console.aws.amazon.com/eks/home\$1/clusters에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하세요.
1. **관찰성** 탭을 선택합니다.
1. **클러스터 모니터링**을 선택합니다.
1. **기능** 탭을 선택하여 모든 기능의 상태를 보세요.
**AWS CLI**:
```
# View capability status and health
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro
# Look for issues in the health section
```
**일반적인 원인:**
+ **RBAC 권한 누락**: kro에 기본 Kubernetes 리소스를 생성할 권한이 없음
+ **유효하지 않은 CEL 표현식**: ResourceGraphDefinition의 구문 오류
+ **리소스 종속성**: 종속된 리소스가 준비되지 않음
+ **스키마 검증**: 인스턴스가 RGD 스키마 요구 사항과 일치하지 않음
**RBAC 권한 확인**:
```
# Check if capability has cluster admin policy
kubectl get accessentry -A | grep kro
```
기능에 필요한 권한이 없는 경우 `AmazonEKSClusterAdminPolicy`를 kro 기능의 액세스 항목에 연결하거나 프로덕션에서 사용하기 위한 제한적인 RBAC 정책을 생성합니다. 세부 정보는 [kro 권한 구성](kro-permissions.md) 섹션을 참조하세요.
**ResourceGraphDefinition 상태 확인**:
```
# List all RGDs
kubectl get resourcegraphdefinition
# Describe specific RGD
kubectl describe resourcegraphdefinition my-rgd
# Check for validation errors
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions}'
```
ResourceGraphDefinitions에는 다음과 같은 세 가지 주요 상태 조건이 있습니다.
+ `ResourceGraphAccepted` - RGD에서 검증 통과 여부(CEL 구문, 유형 확인, 필드 존재)
+ `KindReady` - 사용자 지정 API에 대한 CRD의 생성 및 등록 여부
+ `ControllerReady` - kro에서 사용자 지정 API의 인스턴스에 대한 적극적인 감시 여부
`ResourceGraphAccepted`가 `False`인 경우 조건 메시지에서 알 수 없는 필드, 유형 불일치 또는 순환 종속성과 같은 검증 오류를 확인합니다.
## 인스턴스가 생성되었지만 기본 리소스가 표시되지 않음
사용자 지정 리소스 인스턴스가 있지만 기본 Kubernetes 리소스(배포, 서비스, ConfigMaps)가 생성되지 않은 경우 kro에 권한이 있는지 확인하고 구성 오류를 확인합니다.
**인스턴스 상태 확인**:
```
# Describe the instance (replace with your custom resource kind and name)
kubectl describe custom-kind
my-instance
# View instance events
kubectl get events --field-selector involvedObject.name=my-instance
# Check instance status conditions
kubectl get custom-kind
my-instance -o jsonpath='{.status.conditions}'
# Check instance state
kubectl get custom-kind
my-instance -o jsonpath='{.status.state}'
```
인스턴스에는 상위 수준 상태를 보여주는 `state` 필드가 있습니다.
+ `ACTIVE` - 인스턴스가 성공적으로 실행 중임
+ `IN_PROGRESS` - 인스턴스가 처리 또는 조정 중임
+ `FAILED` - 인스턴스를 조정하지 못함
+ `DELETING` - 인스턴스가 삭제 중임
+ `ERROR` - 처리 중에 오류가 발생함
인스턴스에는 다음과 같은 네 가지 상태 조건도 있습니다.
+ `InstanceManaged` - 최종 사용자 및 레이블이 올바르게 설정됨
+ `GraphResolved` - 런타임 그래프가 생성되고 리소스가 해결됨
+ `ResourcesReady` - 모든 리소스가 생성되고 준비됨
+ `Ready` - 전체 인스턴스 상태(모든 하위 조건이 `True`인 경우에만 `True`가 됨)
`Ready` 조건에 초점을 맞춰 인스턴스 상태를 확인합니다. `Ready`가 `False`인 경우 하위 조건을 확인하여 실패한 단계를 식별합니다.
**RBAC 권한 확인**:
kro 기능에는 ResourceGraphDefinitions에 정의된 기본 Kubernetes 리소스를 생성할 권한이 필요합니다.
```
# Check if the capability has the AmazonEKSClusterAdminPolicy
kubectl get accessentry -A | grep kro
```
권한이 누락된 경우 `AmazonEKSClusterAdminPolicy`를 kro 기능의 액세스 항목에 연결하거나 프로덕션에서 사용하기 위한 보다 제한적인 RBAC 정책을 생성합니다. 세부 정보는 [kro 권한 구성](kro-permissions.md) 섹션을 참조하세요.
## CEL 표현식 오류
CEL 표현식 오류는 인스턴스가 생성되는 시점이 아니라 ResourceGraphDefinition 생성 시간에 발생합니다. kro는 모든 CEL 구문을 검증하고 Kubernetes 스키마를 기준으로 표현식의 유형을 확인하며 RGD를 생성할 때 필드 존재를 확인합니다.
**일반적인 CEL 검증 오류**:
+ **정의되지 않은 필드 참조**: 스키마 또는 리소스에 없는 필드 참조
+ **유형 불일치**: 표현식에서 잘못된 유형(예: 정수가 예상되는 경우 문자열)을 반환함
+ **유효하지 않은 구문**: CEL 표현식에서 대괄호, 따옴표 또는 연산자 누락
+ **알 수 없는 리소스 유형**: 클러스터에 없는 CRD 참조
**RGD 검증 상태 확인**:
```
# Check if RGD was accepted
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions[?(@.type=="ResourceGraphAccepted")]}'
# View detailed validation errors
kubectl describe resourcegraphdefinition my-rgd
```
`ResourceGraphAccepted`가 `False`인 경우 조건 메시지에 검증 오류가 있습니다.
**유효한 CEL 표현식 예제**:
```
# Reference schema field
${schema.spec.appName}
# Conditional expression
${schema.spec.replicas > 1}
# String template (expressions must return strings)
name: "${schema.spec.appName}-service"
# Standalone expression (can be any type)
replicas: ${schema.spec.replicaCount}
# Resource reference
${deployment.status.availableReplicas}
# Optional field access (returns null if field doesn't exist)
${configmap.data.?DATABASE_URL}
```
## 리소스 종속성이 해결되지 않음
kro는 CEL 표현식에서 종속성을 자동으로 추론하고 올바른 순서로 리소스를 생성합니다. 리소스가 예상대로 생성되지 않는 경우 종속성 순서 및 리소스 준비 상태를 확인합니다.
**계산된 생성 순서 보기**:
```
# See the order kro will create resources
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}'
```
여기에서는 리소스 간 CEL 표현식 참조를 기반으로 계산된 순서를 보여줍니다.
**리소스 준비 상태 확인**:
```
# View instance status to see which resources are ready
kubectl get custom-kind
my-instance -o jsonpath='{.status}'
# Check specific resource status
kubectl get deployment my-deployment -o jsonpath='{.status.conditions}'
```
**readyWhen 조건(사용된 경우) 확인:**
`readyWhen` 필드는 선택 사항입니다. 지정되지 않으면 생성 직후 리소스가 준비된 것으로 간주됩니다. `readyWhen` 조건을 정의한 경우 리소스 준비 상태를 올바르게 점검하는지 확인합니다.
```
resources:
- id: deployment
readyWhen:
- ${deployment.status.availableReplicas == deployment.spec.replicas}
```
**리소스 이벤트 확인**:
```
# View events for the underlying resources
kubectl get events -n namespace --sort-by='.lastTimestamp'
```
## 스키마 검증 실패
스키마 검증 오류로 인해 인스턴스가 생성되지 않는 경우 인스턴스가 RGD 스키마 요구 사항과 일치하는지 확인합니다.
**검증 오류 확인**:
```
# Attempt to create instance and view error
kubectl apply -f instance.yaml
# View existing instance validation status
kubectl describe custom-kind
my-instance | grep -A 5 "Validation"
```
**일반적인 검증 문제**:
+ **필수 필드 누락**: 인스턴스가 필요한 모든 스키마 필드를 제공하지 않음
+ **유형 불일치**: 정수가 예상되는 경우 문자열 제공
+ **유효하지 않은 열거 값**: 허용된 목록에 없는 값 사용
+ **패턴 불일치**: 문자열이 정규식 패턴과 일치하지 않음
**RGD 스키마 검토**:
```
# View the schema definition
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.spec.schema}'
```
인스턴스가 필요한 모든 필드에 올바른 유형을 제공하는지 확인합니다.
## 다음 단계
+ [EKS에 대한 kro 고려 사항](kro-considerations.md) - kro 고려 사항 및 모범 사례
+ [kro 권한 구성](kro-permissions.md) - 플랫폼 및 애플리케이션 팀에 대해 RBAC 구성
+ [kro 개념](kro-concepts.md) - kro 개념 및 리소스 수명 주기 이해
+ [EKS 기능 문제 해결](capabilities-troubleshooting.md) - 일반 기능 문제 해결 지침
# kro의 EKS 기능 및 자체 관리형 kro 비교
kro의 EKS 기능은 자체 관리형 kro와 동일한 기능을 제공하지만 상당한 운영 이점을 제공합니다. EKS 기능과 자체 관리형 솔루션의 일반적인 비교는 [EKS 기능 및 고려 사항](capabilities-considerations.md) 섹션을 참조하세요.
kro의 EKS 기능은 동일한 업스트림 kro 컨트롤러를 사용하며, 업스트림 kro와 완벽하게 호환됩니다. ResourceGraphDefinitions, CEL 표현식 및 리소스 구성은 동일하게 작동합니다. 전체 kro 설명서 및 예제는 [kro 설명서](https://kro.run/docs/overview)를 참조하세요.
## 마이그레이션 경로
가동 중지 시간 없이 자체 관리형 kro에서 관리형 기능으로 마이그레이션할 수 있습니다.
**중요**
마이그레이션하기 전에 자체 관리형 kro 컨트롤러가 kro의 EKS 기능과 동일한 버전을 실행 중인지 확인합니다. EKS 콘솔에서 또는 `aws eks describe-capability`를 사용하여 기능 버전을 확인한 다음, 일치하도록 자체 관리형 설치를 업그레이드합니다. 그러면 마이그레이션 중에 호환성 문제가 방지됩니다.
1. 리더 선정 리스에 `kube-system`을 사용하도록 자체 관리형 kro 컨트롤러를 업데이트합니다.
```
helm upgrade --install kro \
oci://ghcr.io/awslabs/kro/kro-chart \
--namespace kro \
--set leaderElection.namespace=kube-system
```
그러면 컨트롤러의 리스가 `kube-system`으로 이전되어 관리형 기능을 이에 맞게 조정할 수 있습니다.
1. 클러스터에서 kro 기능 생성([kro 기능 생성](create-kro-capability.md) 참조)
1. 관리형 기능은 기존 ResourceGraphDefinitions 및 인스턴스를 인식하여 조정을 인계함
1. 자체 관리형 kro 배포를 점진적으로 스케일 다운하거나 제거합니다.
```
helm uninstall kro --namespace kro
```
이 접근 방식을 사용하면 마이그레이션 중에 두 컨트롤러가 모두 안전하게 공존할 수 있습니다. 관리형 기능은 이전에 자체 관리형 kro에서 관리하던 ResourceGraphDefinitions 및 인스턴스를 자동으로 채택하여 충돌 없이 지속적인 조정을 보장합니다.
## 다음 단계
+ [kro 기능 생성](create-kro-capability.md) - kro 기능 리소스 생성
+ [kro 개념](kro-concepts.md) - kro 개념 및 리소스 구성 이해