**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# AWS Controllers for Kubernetes(ACK)를 사용하여 Kubernetes에서 AWS 리소스 배포
AWS Controllers for Kubernetes(ACK)를 사용하면 Kubernetes에서 직접 AWS 서비스 리소스를 정의 및 관리할 수 있습니다. AWS Controllers for Kubernetes(ACK)를 사용하면 친숙한 Kubernetes API 및 도구를 사용하여 애플리케이션 워크로드와 함께 Kubernetes 사용자 지정 리소스를 사용하여 워크로드 리소스 및 클라우드 인프라를 관리할 수 있습니다.
EKS 기능을 사용하면 ACK는 AWS에서 완전하게 관리되므로 클러스터에서 ACK 컨트롤러를 설치, 유지 관리 및 조정할 필요가 없습니다.
## ACK 작동 방식
ACK는 Kubernetes 사용자 지정 리소스 사양을 AWS API 직접 호출로 변환합니다. AWS 서비스 리소스를 나타내는 Kubernetes 사용자 지정 리소스를 생성, 업데이트 또는 삭제하면 ACK는 AWS 리소스를 생성, 업데이트 또는 삭제하는 데 필요한 AWS API 직접 호출을 수행합니다.
ACK에서 지원하는 각 AWS 리소스에는 구성을 지정하기 위한 Kubernetes API 스키마를 정의하는 자체 사용자 지정 리소스 정의(CRD)가 있습니다. 예를 들어 ACK는 버킷, 버킷 정책 및 기타 S3 리소스를 포함하여 S3에 대한 CRD를 제공합니다.
ACK는 AWS 리소스의 상태를 Kubernetes 사용자 지정 리소스에 정의된 원하는 상태로 지속적으로 조정합니다. 리소스가 원하는 상태에서 드리프트되면 ACK는 이를 감지하고 수정 조치를 수행하여 다시 정렬합니다. Kubernetes 리소스에 대한 변경 사항은 AWS 리소스 상태에 즉시 반영되지만, 업스트림 AWS 리소스 변경에 대한 수동 드리프트 감지 및 수정에는 최대 10시간(재동기화 기간)이 걸릴 수 있습니다. 하지만 보통은 훨씬 더 빠릅니다.
**S3 버킷 리소스 매니페스트 예제**
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-ack-bucket
spec:
name: my-unique-bucket-name
```
이 사용자 지정 리소스를 클러스터에 적용하면 ACK는 계정에 Amazon S3 버킷(아직 존재하지 않는 경우)을 생성합니다. 기본이 아닌 스토리지 티어를 지정하거나 정책을 추가하는 등 이 리소스에 대한 후속 변경 사항은 AWS의 S3 리소스에 적용됩니다. 이 리소스가 클러스터에서 삭제되면 AWS의 S3 버킷이 기본적으로 삭제됩니다.
## ACK의 이점
ACK는 Kubernetes 네이티브 AWS 리소스 관리를 제공하므로 애플리케이션에 사용하는 것과 동일한 Kubernetes API 및 도구를 사용하여 AWS 리소스를 관리할 수 있습니다. 이 통합 접근 방식에서는 여러 도구 사이를 전환하거나 별도의 코드형 인프라 시스템을 학습할 필요가 없으므로 인프라 관리 워크플로를 단순화합니다. Kubernetes 매니페스트에서 AWS 리소스를 선언적으로 정의하여 기존 개발 프로세스와 원활하게 통합되는 GitOps 워크플로 및 인프라를 코드 사례로 사용할 수 있습니다.
ACK는 AWS 리소스의 원하는 상태를 실제 상태와 지속적으로 조정하여 드리프트를 수정하고 인프라 전반에서 일관성을 보장합니다. 이러한 지속적 조정은 선언된 구성과 일치하도록 AWS 리소스에 대한 대역 외 필수 변경 사항을 자동으로 되돌려 코드형 인프라의 무결성을 유지 관리합니다. 여러 AWS 계정 및 리전에서 리소스를 관리하도록 ACK를 구성하여 추가 도구 없이도 복잡한 다중 계정 아키텍처를 지원할 수 있습니다.
다른 인프라 관리 도구에서 마이그레이션하는 조직의 경우 ACK는 리소스 채택을 지원하므로 기존 AWS 리소스를 다시 생성하지 않고도 ACK 관리를 이에 적용할 수 있습니다. 또한 ACK는 수정 액세스 없이도 AWS 리소스 관찰을 위한 읽기 전용 리소스 및 Kubernetes AWS 리소스가 클러스터에서 삭제된 경우에도 선택적으로 리소스를 유지하기 위한 주석을 제공합니다.
ACK의 EKS 기능에 대해 자세히 알아보고 시작하려면 [ACK 개념](ack-concepts.md) 및 [EKS에 대한 ACK 고려 사항](ack-considerations.md) 섹션을 참조하세요.
## 지원되는 AWS 서비스
ACK는 다양한 AWS 서비스(다음을 포함하되 이에 국한되지 않음)를 지원합니다.
+ Amazon EC2
+ Amazon S3
+ Amazon RDS
+ Amazon DynamoDB
+ Amazon ElastiCache
+ Amazon EKS
+ Amazon SQS
+ Amazon SNS
+ AWS Lambda
+ AWS IAM
정식 버전인 업스트림으로 나열된 모든 AWS 서비스는 ACK의 EKS 기능에서 지원됩니다. 자세한 내용은 [full list of AWS services supported](https://aws-controllers-k8s.github.io/community/docs/community/services/)를 참조하세요.
## 다른 EKS 관리형 기능과 통합
ACK는 다른 EKS 관리형 기능과 통합됩니다.
+ **Argo CD**: Argo CD를 사용하여 여러 클러스터에서 ACK 리소스 배포를 관리하여 AWS 인프라에 대한 GitOps 워크플로를 지원합니다.
+ ACK는 ArgoCD와 페어링할 때 GitOps의 이점을 확장하지만, ACK는 git과의 통합이 필요하지 않습니다.
+ **Kube Resource Orchestrator(kro)**: kro를 사용하여 ACK 리소스에서 복잡한 리소스를 구성하여 리소스 관리를 단순화하는 상위 수준 추상화를 생성합니다.
+ Kubernetes 리소스와 AWS 리소스를 모두 정의하는 kro를 사용하여 복합 사용자 지정 리소스를 생성할 수 있습니다. 팀원은 이러한 사용자 지정 리소스를 사용하여 복잡한 애플리케이션을 빠르게 배포할 수 있습니다.
## ACK 시작하기
ACK의 EKS 기능을 시작하는 방법:
1. ACK가 사용자를 대신하여 AWS 리소스를 관리하는 데 필요한 권한이 있는 IAM 기능 역할을 생성 및 구성하세요.
1. AWS 콘솔, AWS CLI 또는 기본 코드형 인프라를 통해 EKS 클러스터에서 [ACK 기능 리소스를 생성](create-ack-capability.md)하세요.
1. 클러스터에 Kubernetes 사용자 지정 리소스를 적용하여 Kubernetes에서 AWS 리소스 관리를 시작하세요.
# ACK 기능 생성
이 장에서는 Amazon EKS 클러스터에서 ACK 기능을 생성하는 방법을 설명합니다.
## 사전 조건
ACK 기능을 생성하기 전에 다음이 있는지 확인합니다.
+ Amazon EKS 클러스터
+ ACK가 AWS 리소스를 관리할 권한이 있는 IAM 기능 역할
+ EKS 클러스터에서 기능 리소스를 생성할 수 있는 충분한 IAM 권한
+ 설치 및 구성된 적절한 CLI 도구 또는 EKS 콘솔에 대한 액세스
IAM 기능 역할을 생성하는 방법에 대한 지침은 [Amazon EKS 기능 IAM 역할](capability-role.md) 섹션을 참조하세요.
**중요**
ACK는 AWS 리소스를 생성, 수정 및 삭제할 수 있는 기능을 부여하는 인프라 관리 기능입니다. 이는 신중하게 제어해야 하는 관리자 범위의 기능입니다. 클러스터에서 Kubernetes 리소스를 생성할 권한이 있는 사람은 누구나 IAM 기능 역할 권한에 따라 ACK를 통해 AWS 리소스를 효과적으로 생성할 수 있습니다. 사용자가 제공하는 IAM 기능 역할에 따라 ACK에서 생성하고 관리할 수 있는 AWS 리소스가 결정됩니다. 최소 권한으로 적절한 역할을 생성하는 방법에 대한 지침은 [Amazon EKS 기능 IAM 역할](capability-role.md) 및 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
## 도구 선택
AWS Management Console, AWS CLI 또는 eksctl을 사용하여 ACK 기능을 생성할 수 있습니다.
+ [콘솔을 사용하여 ACK 기능 생성](ack-create-console.md) - 안내 경험을 이용하려면 콘솔 사용
+ [AWS CLI를 사용하여 ACK 기능 생성](ack-create-cli.md) -스크립트 및 자동화를 이용하려면 AWS CLI 사용
+ [eksctl을 사용하여 ACK 기능 생성](ack-create-eksctl.md) - Kubernetes 네이티브 경험을 이용하려면 eksctl 사용
## ACK 기능을 생성할 때 상황
ACK 기능을 생성할 때:
1. EKS는 ACK 기능 서비스를 생성하고 클러스터의 리소스를 모니터링하고 관리하도록 이를 구성함
1. 사용자 지정 리소스 정의(CRD)가 클러스터에 설치됨
1. 기준 Kubernetes 권한을 부여하는 기능별 액세스 항목 정책을 사용하여 IAM 기능 역할에 대한 액세스 항목이 자동으로 생성됨([EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 참조)
1. 이 기능은 사용자가 제공하는 IAM 기능 역할을 수임함
1. ACK에서 클러스터에 있는 사용자 지정 리소스 감시를 시작함
1. 기능 상태가 `CREATING`에서 `ACTIVE`로 변경됨
활성 상태가 되면 클러스터에서 ACK 사용자 지정 리소스를 생성하여 AWS 리소스를 관리할 수 있습니다.
**참고**
자동으로 생성된 액세스 항목에는 AWS 리소스를 관리할 권한을 ACK에 부여하는 `AmazonEKSACKPolicy`가 포함됩니다. Kubernetes 보안 암호를 참조하는 일부 ACK 리소스(예: 암호가 있는 RDS 데이터베이스)에는 추가 액세스 항목 정책이 필요합니다. 액세스 항목 및 추가 권한을 구성하는 방법에 대한 자세한 내용은 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
## 다음 단계
ACK 기능을 생성한 후:
+ [ACK 개념](ack-concepts.md) - ACK 개념 이해 및 AWS 리소스 시작하기
+ [ACK 개념](ack-concepts.md) - 조정, 필드 내보내기 및 리소스 채택 패턴에 대해 알아보기
+ [ACK 권한 구성](ack-permissions.md) - IAM 권한 및 다중 계정 패턴 구성
# 콘솔을 사용하여 ACK 기능 생성
이 주제에서는 AWS Management Console을 사용하여 AWS Controllers for Kubernetes(ACK) 기능을 생성하는 방법을 설명합니다.
## ACK 기능 생성
1. https://console.aws.amazon.com/eks/home\$1/clusters에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하여 클러스터 세부 정보 페이지를 여세요.
1. **기능** 탭을 선택하세요.
1. 왼쪽 탐색에서 **AWS Controllers for Kubernetes(ACK)**를 선택하세요.
1. **AWS Controllers for Kubernetes 기능 생성**을 선택하세요.
1. **IAM 기능 역할**의 경우:
+ IAM 기능 역할이 이미 있는 경우 드롭다운 선택
+ 새 역할을 생성해야 하는 경우 **관리자 역할 생성** 선택
그러면 신뢰 정책 및 `AdministratorAccess` 관리형 정책이 미리 채워진 새 탭에서 IAM 콘솔이 열립니다. 원하는 경우 이 정책의 선택을 취소하고 다른 권한을 추가할 수 있습니다.
역할을 생성한 후 EKS 콘솔로 돌아가면 역할이 자동으로 선택됩니다.
**중요**
제안된 `AdministratorAccess` 정책은 광범위한 권한을 부여하며 시작을 간소화하기 위해 제공됩니다. 프로덕션 사용 시 ACK로 관리하려는 특정 AWS 서비스에 필요한 권한만 부여하는 사용자 지정 정책으로 바꿉니다. 최소 권한 정책 생성에 대한 지침은 [ACK 권한 구성](ack-permissions.md) 및 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
1. **생성(Create)**을 선택합니다.
기능 생성 프로세스가 시작됩니다.
## 기능이 활성 상태인지 확인
1. **기능** 탭에서 ACK 기능 상태를 확인하세요.
1. 상태가 `CREATING`에서 `ACTIVE`로 변경될 때까지 기다리세요.
1. 활성 상태가 되면 기능을 사용할 준비가 된 것입니다.
기능 상태 및 문제 해결에 대한 자세한 내용은 [기능 리소스 작업](working-with-capabilities.md) 섹션을 참조하세요.
## 사용자 지정 리소스를 사용할 수 있는지 확인
기능이 활성 상태가 되면 클러스터에서 ACK 사용자 지정 리소스를 사용할 수 있는지 확인합니다.
**콘솔 사용**
1. Amazon EKS 콘솔에서 클러스터로 이동
1. **리소스** 탭 선택
1. **확장** 선택
1. **CustomResourceDefinitions** 선택
AWS 리소스에 대한 여러 CRD가 나열됩니다.
**kubectl 사용**
```
kubectl api-resources | grep services.k8s.aws
```
AWS 리소스에 대한 여러 API가 나열됩니다.
**참고**
AWS Controllers for Kubernetes의 기능은 다양한 AWS 리소스에 대해 여러 CRD를 설치합니다.
## 다음 단계
+ [ACK 개념](ack-concepts.md) - ACK 개념 이해 및 시작하기
+ [ACK 권한 구성](ack-permissions.md) - 기타 AWS 서비스에 대한 IAM 권한 구성
+ [기능 리소스 작업](working-with-capabilities.md) - ACK 기능 리소스 관리
# AWS CLI를 사용하여 ACK 기능 생성
이 주제에서는 AWS CLI를 사용하여 AWS Controllers for Kubernetes(ACK) 기능을 생성하는 방법을 설명합니다.
## 사전 조건
+ **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 > ack-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 ACKCapabilityRole \
--assume-role-policy-document file://ack-trust-policy.json
```
`AdministratorAccess` 관리형 정책을 역할에 연결합니다.
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
```
**중요**
제안된 `AdministratorAccess` 정책은 광범위한 권한을 부여하며 시작을 간소화하기 위해 제공됩니다. 프로덕션 사용 시 ACK로 관리하려는 특정 AWS 서비스에 필요한 권한만 부여하는 사용자 지정 정책으로 바꿉니다. 최소 권한 정책 생성에 대한 지침은 [ACK 권한 구성](ack-permissions.md) 및 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
## 2단계: ACK 기능 생성
클러스터에서 ACK 기능 리소스를 생성합니다. *region-code*를 클러스터를 생성한 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꿉니다.
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack \
--type ACK \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ACKCapabilityRole \
--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-ack \
--query 'capability.status' \
--output text
```
상태가 `ACTIVE`로 표시되면 기능이 준비된 것입니다. `ACTIVE` 상태가 되면 다음 단계를 계속하지 마세요.
전체 기능 세부 정보를 볼 수도 있습니다.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack
```
## 4단계: 사용자 지정 리소스를 사용할 수 있는지 확인
기능이 활성 상태가 되면 클러스터에서 ACK 사용자 지정 리소스를 사용할 수 있는지 확인합니다.
```
kubectl api-resources | grep services.k8s.aws
```
AWS 리소스에 대한 여러 API가 나열됩니다.
**참고**
AWS Controllers for Kubernetes의 기능은 다양한 AWS 리소스에 대해 여러 CRD를 설치합니다.
## 다음 단계
+ [ACK 개념](ack-concepts.md) - ACK 개념 이해 및 시작하기
+ [ACK 권한 구성](ack-permissions.md) - 기타 AWS 서비스에 대한 IAM 권한 구성
+ [기능 리소스 작업](working-with-capabilities.md) - ACK 기능 리소스 관리
# eksctl을 사용하여 ACK 기능 생성
이 주제에서는 eksctl을 사용하여 AWS Controllers for Kubernetes(ACK) 기능을 생성하는 방법을 설명합니다.
**참고**
다음 단계에서는 eksctl 버전 `0.220.0` 이상이 필요합니다. 버전을 확인하려면 `eksctl version`을 실행합니다.
## 1단계: IAM 기능 역할 생성
신뢰 정책 파일을 생성합니다.
```
cat > ack-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 ACKCapabilityRole \
--assume-role-policy-document file://ack-trust-policy.json
```
`AdministratorAccess` 관리형 정책을 역할에 연결합니다.
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
```
**중요**
제안된 `AdministratorAccess` 정책은 광범위한 권한을 부여하며 시작을 간소화하기 위해 제공됩니다. 프로덕션 사용 시 ACK로 관리하려는 특정 AWS 서비스에 필요한 권한만 부여하는 사용자 지정 정책으로 바꿉니다. 최소 권한 정책 생성에 대한 지침은 [ACK 권한 구성](ack-permissions.md) 및 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
**중요**
이 정책은 모든 S3 버킷에 대한 작업을 허용하는 `"Resource": "*"`를 사용하여 S3 버킷 관리에 대한 권한을 부여합니다.
프로덕션 사용 시: \$1 `Resource` 필드를 특정 버킷 ARN 또는 이름 패턴으로 제한 \$1 IAM 조건 키를 사용하여 리소스 태그 기준으로 액세스 제한 \$1 사용 사례에 필요한 최소 권한만 부여
다른 AWS 서비스의 경우 [ACK 권한 구성](ack-permissions.md) 섹션을 참조하세요.
역할에 정책을 연결합니다.
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):policy/ACKS3Policy
```
## 2단계: ACK 기능 생성
eksctl을 사용하여 ACK 기능을 생성합니다. *region-code*를 클러스터를 생성한 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꿉니다.
```
eksctl create capability \
--cluster [.replaceable]`my-cluster` \
--region [.replaceable]`region-code` \
--name ack \
--type ACK \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ACKCapabilityRole \
--ack-service-controllers s3
```
**참고**
`--ack-service-controllers` 플래그는 옵션입니다. 생략하면 ACK에서 사용 가능한 모든 컨트롤러를 활성화합니다. 성능과 보안을 개선하려면 필요한 컨트롤러만 활성화하는 방법을 고려합니다. 여러 컨트롤러를 지정할 수 있습니다. `--ack-service-controllers s3,rds,dynamodb`
명령은 즉시 반환되지만 기능이 활성 상태가 되려면 다소 시간이 걸립니다.
## 3단계: 기능이 활성 상태인지 확인
기능 상태를 확인합니다.
```
eksctl get capability \
--cluster [.replaceable]`my-cluster` \
--region [.replaceable]`region-code` \
--name ack
```
상태가 `ACTIVE`로 표시되면 기능이 준비된 것입니다.
## 4단계: 사용자 지정 리소스를 사용할 수 있는지 확인
기능이 활성 상태가 되면 클러스터에서 ACK 사용자 지정 리소스를 사용할 수 있는지 확인합니다.
```
kubectl api-resources | grep services.k8s.aws
```
AWS 리소스에 대한 여러 API가 나열됩니다.
**참고**
AWS Controllers for Kubernetes의 기능은 다양한 AWS 리소스에 대해 여러 CRD를 설치합니다.
## 다음 단계
+ [ACK 개념](ack-concepts.md) - ACK 개념 이해 및 시작하기
+ [ACK 권한 구성](ack-permissions.md) - 기타 AWS 서비스에 대한 IAM 권한 구성
+ [기능 리소스 작업](working-with-capabilities.md) - ACK 기능 리소스 관리
# ACK 개념
ACK는 매니페스트의 원하는 상태를 AWS의 실제 상태에 맞게 지속적으로 조정하여 Kubernetes API를 통해 AWS 리소스를 관리합니다. Kubernetes 사용자 지정 리소스를 생성하거나 업데이트할 때 ACK는 해당 AWS 리소스를 생성하거나 수정하는 데 필요한 AWS API 직접 호출을 수행한 다음 드리프트가 있는지 모니터링하고 현재 상태를 반영하도록 Kubernetes 상태를 업데이트합니다. 이 접근 방식을 사용하면 클러스터와 AWS 간의 일관성을 유지하면서 익숙한 Kubernetes 도구 및 워크플로를 사용하여 인프라를 관리할 수 있습니다.
이 주제에서는 ACK가 Kubernetes API를 통해 AWS 리소스를 관리하는 방법의 기본 개념을 설명합니다.
## ACK 시작하기
ACK 기능을 생성한 후([ACK 기능 생성](create-ack-capability.md) 참조) 클러스터에서 Kubernetes 매니페스트를 사용하여 AWS 리소스 관리를 시작할 수 있습니다.
예를 들어 고유한 버킷 이름을 선택하여 `bucket.yaml`에서 이 S3 버킷 매니페스트를 생성합니다.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-test-bucket
namespace: default
spec:
name: my-unique-bucket-name-12345
```
매니페스트를 적용합니다.
```
kubectl apply -f bucket.yaml
```
상태를 확인합니다.
```
kubectl get bucket my-test-bucket
kubectl describe bucket my-test-bucket
```
버킷이 AWS에서 생성되었는지 확인합니다.
```
aws s3 ls | grep my-unique-bucket-name-12345
```
Kubernetes 리소스를 생성합니다.
```
kubectl delete bucket my-test-bucket
```
버킷이 AWS에서 삭제되었는지 확인합니다.
```
aws s3 ls | grep my-unique-bucket-name-12345
```
버킷이 목록에 더 이상 표시되지 않아야 합니다. 이는 ACK가 AWS 리소스의 전체 수명 주기를 관리함을 보여줍니다.
ACK 시작 방법에 대한 자세한 내용은 [Getting Started with ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/getting-started/)를 참조하세요.
## 리소스 수명 주기 및 조정
ACK는 연속 조정 루프를 사용하여 AWS 리소스가 Kubernetes 매니페스트에 정의된 원하는 상태와 일치하는지 확인합니다.
**조정 작동 방식**:
1. Kubernetes 사용자 지정 리소스(예: S3 버킷)를 생성하거나 업데이트함
1. ACK는 변경을 감지하고 원하는 상태를 AWS의 실제 상태와 비교함
1. 차이가 있는 경우 ACK는 AWS API를 직접 호출하여 차이를 조정함
1. ACK는 현재 상태를 반영하도록 Kubernetes의 리소스 상태를 업데이트함
1. 루프는 일반적으로 몇 시간마다 지속적으로 반복됨
새 Kubernetes 리소스를 생성하거나 기존 리소스의 `spec`을 업데이트하거나 ACK가 ACK 외부에서 수행된 수동 변경 사항과의 드리프트를 AWS에서 감지하면 조정이 트리거됩니다. 또한 ACK는 10시간의 재동기화 기간으로 주기적 조정을 수행합니다. Kubernetes 리소스에 대한 변경 사항은 즉각적인 조정을 트리거하는 반면, 업스트림 AWS 리소스 변경 사항에 대한 수동 드리프트 감지는 주기적 재동기화 중에 수행됩니다.
위의 시작하기 예제를 살펴보면 ACK는 다음 단계를 수행합니다.
1. 버킷이 AWS에 존재하는지 확인
1. 그렇지 않은 경우 `s3:CreateBucket` 직접 호출
1. 버킷 ARN 및 상태로 Kubernetes 상태 업데이트
1. 드리프트에 대한 지속적 모니터링
ACK 작동 방식에 대한 자세한 내용은 [ACK Reconciliation](https://aws-controllers-k8s.github.io/community/docs/user-docs/reconciliation/)을 참조하세요.
## 상태 조건
ACK 리소스는 상태 조건을 사용하여 상태를 전달합니다. 이러한 조건을 이해하면 문제를 해결하고 리소스 상태를 이해하는 데 도움이 됩니다.
+ **Ready**: 리소스를 사용할 준비가 되었음을 나타냅니다(표준화된 Kubernetes 조건).
+ **ACK.ResourceSynced**: 리소스 사양이 AWS 리소스 상태와 일치함을 나타냅니다.
+ **ACK.Terminal**: 복구할 수 없는 오류가 발생했음을 나타냅니다.
+ **ACK.Adopted**: 새 리소스를 생성하는 대신 기존 AWS 리소스에서 리소스를 채택했음을 나타냅니다.
+ **ACK.Recoverable**: 사양을 업데이트하지 않고도 해결할 수 있는 복구 가능한 오류를 나타냅니다.
+ **ACK.Advisory**: 리소스에 대한 자문 정보를 제공합니다.
+ **ACK.LateInitialized**: 필드의 늦은 초기화가 완료되었는지를 나타냅니다.
+ **ACK.ReferencesResolved**: 모든 `AWSResourceReference` 필드가 해결되었는지를 나타냅니다.
+ **ACK.IAMRoleSelected**:이 리소스를 관리하기 위해 IAMRoleSelector가 선택되었는지를 나타냅니다.
리소스 상태를 확인합니다.
```
# Check if resource is ready
kubectl get bucket my-bucket -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
# Check for terminal errors
kubectl get bucket my-bucket -o jsonpath='{.status.conditions[?(@.type=="ACK.Terminal")]}'
```
상태 예제:
```
status:
conditions:
- type: Ready
status: "True"
lastTransitionTime: "2024-01-15T10:30:00Z"
- type: ACK.ResourceSynced
status: "True"
lastTransitionTime: "2024-01-15T10:30:00Z"
- type: ACK.Terminal
status: "True"
ackResourceMetadata:
arn: arn:aws:s3:::my-unique-bucket-name
ownerAccountID: "111122223333"
region: us-west-2
```
ACK 상태 및 조건에 대한 자세한 내용은 [ACK Conditions](https://aws-controllers-k8s.github.io/community/docs/user-docs/conditions/)를 참조하세요.
## 삭제 정책
ACK의 삭제 정책은 Kubernetes 리소스를 삭제할 때 AWS 리소스에 어떤 일이 발생하는지 제어합니다.
**삭제(기본값)**
Kubernetes 리소스를 삭제하면 AWS 리소스가 삭제됩니다. 이는 기본 동작입니다.
```
# No annotation needed - this is the default
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: temp-bucket
spec:
name: temporary-bucket
```
이 리소스를 삭제하면 AWS에서 S3 버킷이 삭제됩니다.
**보관**:
Kubernetes 리소스를 삭제할 때 AWS 리소스는 유지됩니다.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: important-bucket
annotations:
services.k8s.aws/deletion-policy: "retain"
spec:
name: production-data-bucket
```
이 리소스를 삭제하면 Kubernetes에서 제거되지만 AWS의 S3 버킷에는 남아 있습니다.
이 `retain` 정책은 Kubernetes 리소스보다 수명이 길어야 하는 프로덕션 데이터베이스, 여러 애플리케이션에서 사용하는 공유 리소스, 실수로 삭제해서는 안 되는 중요한 데이터가 있는 리소스 또는 리소스를 채택하고 구성한 다음 수동 관리로 다시 릴리스하는 임시 ACK 관리에 유용합니다.
ACK 삭제 정책에 대한 자세한 내용은 [ACK Deletion Policy](https://aws-controllers-k8s.github.io/community/docs/user-docs/deletion-policy/)를 참조하세요.
## 리소스 채택
채택을 통해 기존 AWS 리소스를 다시 생성하지 않고도 ACK 관리를 적용할 수 있습니다.
채택을 사용해야 하는 경우:
+ 기존 인프라를 ACK 관리로 마이그레이션
+ Kubernetes에서 실수로 리소스가 삭제된 경우 분리된 AWS 리소스 복구
+ 다른 도구(CloudFormation, Terraform)에서 생성한 리소스 가져오기
채택 작동 방식:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
이 리소스를 생성하는 경우:
1. 해당 이름의 버킷이 AWS에 있는지 ACK에서 확인
1. 찾은 경우 ACK에서 채택(생성할 API 직접 호출 없음)
1. ACK가 AWS에서 현재 구성을 읽음
1. ACK가 실제 상태를 반영하도록 Kubernetes 상태 업데이트
1. 향후 업데이트에서 정상적으로 리소스 조정
리소스가 채택되면 리소스는 다른 ACK 리소스와 마찬가지로 관리되며, `retain` 삭제 정책을 사용하지 않는 한 Kubernetes 리소스를 삭제하면 AWS 리소스가 삭제됩니다.
리소스를 채택할 때 AWS 리소스가 이미 존재해야 하고 ACK가 리소스를 검색하려면 읽기 권한이 필요합니다. 이 `adopt-or-create` 정책은 리소스가 있는 경우 리소스를 채택하고 없는 경우 리소스를 생성합니다. 이는 리소스의 존재 여부에 상관없이 작동하는 선언적 워크플로를 원하는 경우에 유용합니다.
ACK 리소스 채택에 대한 자세한 내용은 [ACK Resource Adoption](https://aws-controllers-k8s.github.io/community/docs/user-docs/adopted-resource/)을 참조하세요.
## 교차 리전 및 교차 계정 액세스
ACK는 단일 클러스터에서 서로 다른 AWS 계정 및 리전의 리소스를 관리할 수 있습니다.
**교차 리전 리소스 주석**
주석을 사용하여 AWS 리소스의 리전을 지정할 수 있습니다.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: eu-bucket
annotations:
services.k8s.aws/region: eu-west-1
spec:
name: my-eu-bucket
```
또한 지정된 네임스페이스에서 생성된 모든 AWS 리소스의 리전을 지정할 수도 있습니다.
**네임스페이스 주석**
네임스페이스의 모든 리소스에 대해 기본 리전을 설정합니다.
```
apiVersion: v1
kind: Namespace
metadata:
name: production
annotations:
services.k8s.aws/default-region: us-west-2
```
리소스 수준 주석으로 재정의되지 않는 한 이 네임스페이스에서 생성된 리소스는 이 리전을 사용합니다.
**교차 계정**
IAM 역할 선택기를 사용하여 특정 IAM 역할을 네임스페이스에 매핑합니다.
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: target-account-config
spec:
arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
namespaceSelector:
names:
- production
```
매핑된 네임스페이스에서 생성된 리소스는 지정된 역할을 자동으로 사용합니다.
IAM 역할 선택기에 대한 자세한 내용은 [ACK Cross-Account Resource Management](https://aws-controllers-k8s.github.io/docs/guides/cross-account)를 참조하세요. 교차 계정 구성 세부 정보는 [ACK 권한 구성](ack-permissions.md) 섹션을 참조하세요.
## 오류 처리 및 재시도 동작
ACK는 일시적인 오류를 자동으로 처리하고 실패한 작업을 재시도합니다.
재시도 전략:
+ 일시적인 오류(속도 제한, 일시적인 서비스 문제, 권한 부족)는 자동 재시도를 트리거함
+ 지수 백오프로 과도한 AWS API를 방지함
+ 최대 재시도 횟수는 오류 유형에 따라 다름
+ 영구 오류(잘못된 파라미터, 리소스 이름 충돌)는 재시도되지 않음
오류에 대한 세부 정보를 보려면 `kubectl describe`를 사용하여 리소스 상태를 확인합니다.
```
kubectl describe bucket my-bucket
```
오류 메시지가 있는 상태 조건, 최근 조정 시도를 보여주는 이벤트, 실패를 설명하는 상태 조건의 `message` 필드를 찾습니다. 일반적인 오류로는 IAM 권한 부족, AWS에서 리소스 이름 충돌, `spec`에서 유효하지 않은 구성 값, 초과된 AWS 서비스 할당량이 있습니다.
일반적인 오류 문제를 해결하려면 [ACK 기능 관련 문제 해결](ack-troubleshooting.md) 섹션을 참조하세요.
## kro를 사용하는 리소스 구성
여러 ACK 리소스를 함께 구성하고 연결하려면 Kube Resource Orchestrator(kro)의 EKS 기능을 사용합니다. kro는 리소스 그룹을 정의하는 선언적 방법을 제공하여 리소스 간에 구성을 전달해 복잡한 인프라 패턴을 간단히 관리합니다.
ACK 리소스를 사용하여 사용자 지정 리소스 구성을 생성하는 자세한 예제는 [kro 개념](kro-concepts.md) 섹션을 참조하세요.
## 다음 단계
+ [EKS에 대한 ACK 고려 사항](ack-considerations.md) - EKS 특정 패턴 및 통합 전략
# ACK 권한 구성
ACK에는 사용자를 대신하여 AWS 리소스를 생성 및 관리할 IAM 권한이 필요합니다. 이 주제에서는 IAM이 ACK와 함께 작동하는 방법을 설명하고 다양한 사용 사례에 대한 권한 구성에 대한 지침을 제공합니다.
## IAM에서 ACK를 사용하는 방식
ACK는 IAM 역할을 사용하여 AWS에서 인증하고 리소스에 대한 작업을 수행합니다. ACK에 권한을 제공하는 다음과 같은 두 가지 방법이 있습니다.
**기능 역할**: ACK 기능을 생성할 때 사용자가 제공하는 IAM 역할. 이 역할은 기본적으로 모든 ACK 작업에 사용됩니다.
**IAM 역할 선택기**: 특정 네임스페이스 또는 리소스에 매핑할 수 있는 추가 IAM 역할. 이러한 역할은 해당 범위의 리소스에 대한 기능 역할을 재정의합니다.
ACK는 리소스를 생성하거나 관리해야 하는 경우 다음과 같이 사용할 IAM 역할을 결정합니다.
1. IAMRoleSelector가 리소스의 네임스페이스와 일치하는지 확인
1. 일치하는 항목이 발견되면 해당 IAM 역할 수임
1. 그렇지 않으면 기능 역할 사용
이 접근 방식을 사용하면 간단한 단일 역할 설정에서 복잡한 다중 계정, 다중 팀 구성에 이르기까지 유연한 권한 관리를 지원할 수 있습니다.
## 시작하기: 간단한 권한 설정
개발, 테스트 또는 간단한 사용 사례의 경우 필요한 모든 서비스 권한을 기능 역할에 직접 추가할 수 있습니다.
이 접근 방식은 다음과 같은 경우에 효과적입니다.
+ ACK를 시작함
+ 모든 리소스가 동일한 AWS 계정에 있음
+ 단일 팀이 모든 ACK 리소스를 관리함
+ 모든 ACK 사용자에게 동일한 권한이 있다고 신뢰함
## 프로덕션 모범 사례: IAM 역할 선택기
프로덕션 환경의 경우 IAM 역할 선택기를 사용하여 최소 권한 액세스 및 네임스페이스 수준 격리를 구현합니다.
IAM 역할 선택기를 사용하는 경우 기능 역할에는 서비스 특정 역할을 수임하기 위해 `sts:AssumeRole` 및 `sts:TagSession` 권한만 있으면 됩니다. 기능 역할 자체에 AWS 서비스 권한(예: S3 또는 RDS)을 추가할 필요가 없습니다. 이러한 권한은 기능 역할이 수임하는 개별 IAM 역할에 부여됩니다.
**권한 모델 중에서 선택**:
다음과 같은 경우 **직접 권한**(기능 역할에 서비스 권한 추가)을 사용합니다.
+ 시작 중이며 가장 간단한 설정을 원하는 경우
+ 모든 리소스가 클러스터와 동일한 계정에 있는 경우
+ 관리, 클러스터 전체 권한 요구 사항이 있는 경우
+ 모든 팀이 동일한 권한을 공유할 수 있는 경우
다음과 같은 경우 **IAM 역할 선택기**를 사용합니다.
+ 여러 AWS 계정에서 리소스 관리
+ 팀 또는 네임스페이스마다 다른 권한이 필요함
+ 네임스페이스당 세분화된 액세스 제어가 필요함
+ 최소 권한 보안 사례를 따르려고 함
직접 권한으로 시작하고, 요구 사항이 증가함에 따라 나중에 IAM 역할 선택기로 마이그레이션할 수 있습니다.
**프로덕션에서 IAM 역할 선택기를 사용하는 이유:**
+ **최소 권한**: 각 네임스페이스는 필요한 권한만 받음
+ **팀 격리**: 팀 A에서 실수로 팀 B의 권한을 사용할 수 없음
+ **더 쉬운 감사**: 어떤 네임스페이스가 어떤 역할을 사용하는지에 대한 명확한 매핑
+ **교차 계정 지원**: 여러 계정에서 리소스를 관리하는 데 필요함
+ **우려 사항 분리**: 서비스 또는 환경마다 다른 역할을 사용함
### 기본 IAM 역할 선택기 설정
**1단계: 서비스 특정 IAM 역할 생성**
특정 AWS 서비스에 대한 권한이 있는 IAM 역할을 생성합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "*"
}
]
}
```
기능 역할이 해당 역할을 수임할 수 있도록 신뢰 정책을 구성합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
```
**2단계: 기능 역할에 권한을 AssumeRole에 부여**
기능 역할에 서비스 특정 역할을 수임할 권한을 추가합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::111122223333:role/ACK-S3-Role"
}
]
}
```
**3단계: IAMRoleSelector 생성**
IAM 역할을 네임스페이스에 매핑합니다.
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: s3-namespace-config
spec:
arn: arn:aws:iam::111122223333:role/ACK-S3-Role
namespaceSelector:
names:
- s3-resources
```
**4단계: 매핑된 네임스페이스에서 리소스 생성**
`s3-resources` 네임스페이스의 리소스는 지정된 역할을 자동으로 사용합니다.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-bucket
namespace: s3-resources
spec:
name: my-production-bucket
```
## 다중 계정 관리
IAM 역할 선택기를 사용하여 여러 AWS 계정에서 리소스를 관리합니다.
**1단계: 교차 계정 IAM 역할 생성**
대상 계정(444455556666)에서 소스 계정의 기능 역할을 신뢰하는 역할을 생성합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
```
이 역할에 서비스 특정 권한을 연결합니다.
**2단계: AssumeRole 권한 부여**
소스 계정(111122223333)에서 기능 역할이 대상 계정 역할을 수임하도록 허용합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::444455556666:role/ACKTargetAccountRole"
}
]
}
```
**3단계: IAMRoleSelector 생성**
네임스페이스에 교차 계정 역할을 매핑합니다.
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: production-account-config
spec:
arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
namespaceSelector:
names:
- production
```
**4단계: 리소스 생성**
`production` 네임스페이스의 리소스는 대상 계정에 생성됩니다.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-bucket
namespace: production
spec:
name: my-cross-account-bucket
```
## 세션 태그
EKS ACK 기능은 모든 AWS API 요청에 대해 세션 태그를 자동으로 설정합니다. 이러한 태그를 사용하면 각 요청의 소스를 식별하여 세분화된 액세스 제어 및 감사를 지원할 수 있습니다.
### 사용 가능한 세션 태그
ACK에서 수행하는 모든 AWS API 직접 호출에는 다음 세션 태그가 포함됩니다.
| 태그 키 | 설명 |
| --- | --- |
| `eks:eks-capability-arn` | 요청을 수행하는 EKS 기능의 ARN |
| `eks:kubernetes-namespace` | 관리하는 리소스의 Kubernetes 네임스페이스 |
| `eks:kubernetes-api-group` | 리소스의 Kubernetes API 그룹(예: `s3.services.k8s.aws`) |
### 액세스 제어를 위해 세션 태그 사용
IAM 정책 조건에서 이러한 세션 태그를 사용하여 ACK가 관리할 수 있는 리소스를 제한할 수 있습니다. 이를 통해 네임스페이스 기반 IAM 역할 선택기 외에도 추가 보안 계층을 제공합니다.
**예제: 네임스페이스로 제한**
요청이 `production` 네임스페이스에서 시작된 경우에만 ACK에서 S3 버킷을 생성하도록 허용합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:CreateBucket",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks:kubernetes-namespace": "production"
}
}
}
]
}
```
**예제: 기능으로 제한**
특정 ACK 기능에서만 작업을 허용합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks:eks-capability-arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack"
}
}
}
]
}
```
**참고**
세션 태그는 기본적으로 이러한 태그를 설정하지 않는 자체 관리형 ACK와는 다릅니다. 이를 통해 관리형 기능을 사용하여 보다 세분화된 액세스 제어를 지원합니다.
## 고급 IAM 역할 선택기 패턴
레이블 선택기, 리소스 특정 역할 매핑 및 추가 예제를 포함한 고급 구성은 [ACK IRSA 설명서](https://aws-controllers-k8s.github.io/community/docs/user-docs/irsa/)를 참조하세요.
## 다음 단계
+ [ACK 개념](ack-concepts.md) - ACK 개념 및 리소스 수명 주기 이해
+ [ACK 개념](ack-concepts.md) - 리소스 채택 및 삭제 정책에 대해 알아보기
+ [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) - 기능에 대한 보안 모범 사례 이해
# EKS에 대한 ACK 고려 사항
이 주제에서는 IAM 구성, 다중 계정 패턴, 다른 EKS 기능과의 통합 등 EKS의·ACK 기능 사용에 대한 중요한 고려 사항을 다룹니다.
## IAM 구성 패턴
ACK 기능은 IAM 기능 역할을 사용하여 AWS로 인증합니다. 요구 사항에 따라 올바른 IAM 패턴을 선택합니다.
### 단순: 단일 기능 역할
개발, 테스트 또는 간단한 사용 사례의 경우 필요한 모든 권한을 기능 역할에 직접 부여합니다.
**사용해야 하는 경우**:
+ ACK 시작하기
+ 단일 계정 배포
+ 한 팀에서 관리하는 모든 리소스
+ 개발 및 테스트 환경
**예제**: 리소스 태그 지정 조건을 사용하여 기능 역할에 S3 및 RDS 권한을 추가합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
}
}
},
{
"Effect": "Allow",
"Action": ["rds:*"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
},
}
}
]
}
```
이 예제에서는 S3 및 RDS 작업을 특정 리전으로 제한하며, RDS 리소스에 `ManagedBy: ACK` 태그가 있어야 합니다.
### 프로덕션: IAM 역할 선택기
프로덕션 환경의 경우 IAM 역할 선택기를 사용하여 최소 권한 액세스 및 네임스페이스 수준 격리를 구현합니다.
**사용해야 하는 경우**:
+ 프로덕션 환경
+ 다중 팀 클러스터
+ 다중 계정 리소스 관리
+ 최소 권한 보안 요구 사항
+ 서비스마다 다른 권한이 필요함
**이점:**
+ 각 네임스페이스는 필요한 권한만 얻음
+ 팀 격리 - 팀 A는 팀 B의 권한을 사용할 수 없음
+ 보다 쉬운 감사 및 규정 준수
+ 교차 계정 리소스 관리에 필요함
자세한 IAM 역할 선택기 구성은 [ACK 권한 구성](ack-permissions.md) 섹션을 참조하세요.
## 다른 EKS 기능과 통합
### Argo CD와 함께 사용하는 GitOps
Argo CD의 EKS 기능을 사용해 Git 리포지토리에서 ACK 리소스를 배포하여 인프라 관리를 위한 GitOps 워크플로를 지원합니다.
**고려 사항:**
+ 포괄적인 GitOps에 대한 애플리케이션 매니페스트와 함께 ACK 리소스 저장
+ 팀 구조를 기반으로 환경, 서비스 또는 리소스 유형별로 구성
+ 지속적인 조정을 위해 Argo CD의 자동화된 동기화 사용
+ 삭제된 리소스를 자동으로 제거하도록 정리 활성화
+ 다중 클러스터 인프라 관리를 위해 허브 및 스포크 패턴 고려
GitOps는 감사 추적, 롤백 기능 및 선언적 인프라 관리를 제공합니다. Argo CD에 대한 자세한 내용은 [Argo CD 작업](working-with-argocd.md) 섹션을 참조하세요.
### kro를 사용하는 리소스 구성
Kube Resource Orchestrator(kro)의 EKS 기능을 사용하여 여러 ACK 리소스를 상위 수준 추상화 및 사용자 지정 API로 구성합니다.
**kro를 ACK와 함께 사용하는 경우**:
+ 공통 인프라 스택에 대해 재사용 가능한 패턴 생성(데이터베이스 \$1 백업 \$1 모니터링)
+ 애플리케이션 팀에서 단순화된 API를 사용하여 셀프 서비스 플랫폼 빌드
+ 리소스 종속성 관리 및 여러 리소스 사이에서(S3 버킷 ARN에서 Lambda 함수로) 값 전달
+ 여러 팀 간 인프라 구성 표준화
+ 사용자 지정 리소스 뒤에 구현 세부 정보를 숨겨 복잡성 감소
**예제 패턴**:
+ 애플리케이션 스택: S3 버킷 \$1 SQS 대기열 \$1 알림 구성
+ 데이터베이스 설정: RDS 인스턴스 \$1 파라미터 그룹 \$1 보안 그룹 \$1 보안 암호
+ 네트워킹: VPC \$1 서브넷 \$1 라우팅 테이블 \$1 보안 그룹
kro는 구성된 리소스에 대한 종속성 정렬, 상태 전파 및 수명 주기 관리를 처리합니다. kro에 대한 자세한 내용은 [kro 개념](kro-concepts.md) 섹션을 참조하세요.
## 리소스 구성
더 나은 관리, 액세스 제어 및 비용 추적을 위해 Kubernetes 네임스페이스와 AWS 리소스 태그를 사용하여 ACK 리소스를 구성합니다.
### 네임스페이스 구성
Kubernetes 네임스페이스를 사용하여 환경(프로덕션, 스테이징, 개발), 팀(플랫폼, 데이터, ml) 또는 애플리케이션을 기준으로 ACK 리소스를 논리적으로 분리합니다.
**이점:**
+ 액세스 제어를 위한 네임스페이스 범위의 RBAC
+ 주석을 사용하여 네임스페이스당 기본 리전 설정
+ 더 쉬운 리소스 관리 및 정리
+ 조직 구조에 맞게 정렬된 논리적 분리
### 리소스에 태깅
EKS ACK 기능은 생성하는 모든 AWS 리소스에 기본 태그를 자동으로 적용합니다. 이러한 태그는 자체 관리형 ACK와 다르며 향상된 추적성을 제공합니다.
**기능에서 적용하는 기본 태그**:
| 태그 키 | 설명 |
| --- | --- |
| `eks:controller-version` | ACK 컨트롤러의 버전 |
| `eks:kubernetes-namespace` | ACK 리소스의 Kubernetes 네임스페이스 |
| `eks:kubernetes-resource-name` | Kubernetes 리소스의 이름 |
| `eks:kubernetes-api-group` | Kubernetes API 그룹(예: `s3.services.k8s.aws`) |
| `eks:eks-capability-arn` | EKS ACK 기능의 ARN |
**참고**
자체 관리형 ACK는 `services.k8s.aws/controller-version` 및 `services.k8s.aws/namespace`와 같은 여러 기본 태그를 사용합니다. 이 기능의 태그는 다른 EKS 기능과 일관성을 위해 `eks:` 접두사를 사용합니다.
**추가 권장 태그**:
비용 할당, 소유권 추적 및 구성 목적을 위해 사용자 지정 태그를 추가합니다.
+ 환경(프로덕션, 스테이징, 개발)
+ 팀 또는 부서 소유권
+ 결제 할당을 위한 비용 센터
+ 애플리케이션 또는 서비스 이름
## 다른 코드형 인프라 도구에서 마이그레이션
많은 조직이 워크로드 오케스트레이션을 넘어 Kubernetes를 표준화하는 데서 가치를 찾습니다. 인프라 및 AWS 리소스 관리를 ACK로 마이그레이션하면 애플리케이션 워크로드와 함께 Kubernetes API를 사용하여 인프라 관리를 표준화할 수 있습니다.
**인프라에 대한 Kubernetes 표준화의 이점**:
+ **신뢰할 수 있는 단일 소스**: Kubernetes에서 애플리케이션과 인프라를 모두 관리하여 포괄적인 GitOps 사례 지원
+ **통합 도구**: 팀은 여러 도구와 프레임워크를 학습하는 대신 Kubernetes 리소스와 도구를 사용함
+ **일관된 조정**: ACK는 워크로드에 대한 Kubernetes의 수행 방식과 같이 AWS 리소스를 지속적으로 조정함으로써 드리프트를 감지하고 필수 도구와 비교하여 이를 수정함
+ **네이티브 구성**: kro와 ACK를 함께 사용하면 애플리케이션 및 리소스 매니페스트에서 AWS 리소스를 직접 참조하고 여러 리소스 사이에서 연결 문자열과 ARN을 전달함
+ **단순화된 작업**: 전체 시스템에 배포, 롤백 및 관찰성을 위한 하나의 컨트롤 플레인
ACK는 다시 작성하지 않고 기존 AWS 리소스 채택을 지원함으로써 CloudFormation, Terraform 또는 클러스터 외부의 리소스에서 제로 가동 중지 시간의 마이그레이션을 활성화합니다.
**기존 리소스 채택**:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
채택되면 리소스는 ACK에서 관리되며, Kubernetes 매니페스트를 통해 업데이트할 수 있습니다. 필요에 따라 리소스를 채택하는 동시에 다른 리소스에 대한 기존 IaC 도구를 유지 관리하면서 점진적으로 마이그레이션할 수 있습니다.
또한 ACK는 읽기 전용 리소스도 지원합니다. 참조하지만 수정하지 않으려는 다른 팀 또는 도구에서 관리하는 리소스의 경우 채택을 `retain` 삭제 정책과 결합하고 읽기 IAM 권한만 부여합니다. 이를 통해 애플리케이션은 수정 위험 없이도 Kubernetes API를 통해 공유 인프라(VPC, IAM 역할, KMS 키)를 검색할 수 있습니다.
리소스 채택에 대한 자세한 내용은 [ACK 개념](ack-concepts.md) 섹션을 참조하세요.
## 삭제 정책
삭제 정책은 해당 Kubernetes 리소스를 삭제할 때 AWS 리소스에 어떤 일이 발생하는지 제어합니다. 리소스 수명 주기와 운영 요구 사항에 따라 올바른 정책을 선택합니다.
### 삭제(기본값)
Kubernetes 리소스를 삭제하면 AWS 리소스가 삭제됩니다. 이를 통해 클러스터와 AWS 사이에서 일관성을 유지 관리하여 리소스가 누적되지 않도록 합니다.
**삭제를 사용하는 경우**:
+ 정리가 중요한 개발 및 테스트 환경
+ 애플리케이션 수명 주기에 연결된 임시 리소스(테스트 데이터베이스, 임시 버킷)
+ 애플리케이션보다 수명이 짧아야 하는 리소스(SQS 대기열, ElastiCache 클러스터)
+ 비용 최적화 - 미사용 리소스 자동 정리
+ Git에서 리소스를 제거하면 인프라가 삭제되는 GitOps로 관리되는 환경
기본 삭제 정책은 Kubernetes의 선언적 모델에 맞게 조정됩니다. 클러스터의 내용은 AWS에 있는 것과 일치합니다.
### 보관
Kubernetes 리소스를 삭제할 때 AWS 리소스는 유지됩니다. 이를 통해 중요한 데이터를 보호하고 리소스 수명이 Kubernetes 표현보다 오래 지속될 수 있습니다.
**유지 기능을 사용하는 경우**:
+ 클러스터 변경 후에도 유지되어야 하는 중요한 데이터가 있는 프로덕션 데이터베이스
+ 규정 준수 또는 감사 요구 사항이 있는 장기 스토리지 버킷
+ 여러 애플리케이션 또는 팀에서 사용하는 공유 리소스
+ 다른 관리 도구로 마이그레이션되는 리소스
+ 인프라를 보존하려는 재해 복구 시나리오
+ 신중하게 폐기해야 하는 복잡한 종속성이 있는 리소스
```
apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
name: production-db
annotations:
services.k8s.aws/deletion-policy: "retain"
spec:
dbInstanceIdentifier: prod-db
# ... configuration
```
**중요**
유지되는 리소스에서는 계속 AWS 비용이 발생하므로 더 이상 필요하지 않으면 AWS에서 수동으로 삭제해야 합니다. 리소스 태그 지정을 사용하여 정리를 위해 유지되는 리소스를 추적합니다.
삭제 정책에 대한 자세한 내용은 [ACK 개념](ack-concepts.md) 섹션을 참조하세요.
## 업스트림 설명서
ACK 사용에 대한 자세한 내용은 다음을 참조하세요.
+ [ACK 사용 설명서](https://aws-controllers-k8s.github.io/community/docs/user-docs/usage/) - 리소스 생성 및 관리
+ [ACK API 참조](https://aws-controllers-k8s.github.io/community/reference/) - 모든 서비스에 대한 전체 API 설명서
+ [ACK 설명서](https://aws-controllers-k8s.github.io/community/docs/) - 포괄적인 사용자 설명서
## 다음 단계
+ [ACK 권한 구성](ack-permissions.md) - IAM 권한 및 다중 계정 패턴 구성
+ [ACK 개념](ack-concepts.md) - ACK 개념 및 리소스 수명 주기 이해
+ [ACK 기능 관련 문제 해결](ack-troubleshooting.md) - ACK 문제 해결
+ [Argo CD 작업](working-with-argocd.md) - GitOps를 사용하여 ACK 리소스 배포
+ [kro 개념](kro-concepts.md) - ACK 리소스를 상위 수준 추상화로 구성
# ACK 기능 관련 문제 해결
이 주제에서는 기능 상태 확인, 리소스 상태 확인 및 IAM 권한 문제를 포함하여 EKS의·ACK 기능에 대한 문제 해결 지침을 제공합니다.
**참고**
EKS 기능은 완전관리형 기능이며, 클러스터 외부에서 실행됩니다. 사용자는 컨트롤러 로그 또는 컨트롤러 네임스페이스에 대한 액세스 권한이 없습니다. 문제 해결은 기능 상태, 리소스 상태 및 IAM 구성에 중점을 둡니다.
## 기능이 ACTIVE이지만 리소스가 생성되지 않음
ACK 기능에 `ACTIVE` 상태가 표시되지만 AWS에서 리소스가 생성되지 않는 경우 기능 상태, 리소스 상태 및 IAM 권한을 확인합니다.
**기능 상태 확인**:
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-ack
# Look for issues in the health section
```
**일반적인 원인:**
+ **IAM 권한 누락**: 기능 역할에 AWS 서비스에 대한 권한이 부족함
+ **잘못된 네임스페이스**: 적절한 IAMRoleSelector 없이 네임스페이스에서 생성된 리소스
+ **유효하지 않은 리소스 사양**: 리소스 상태 조건에 검증 오류가 있는지 확인
+ **API 스로틀링**: AWS API 속도 제한에 도달함
+ **승인 웹후크**: 컨트롤러가 리소스 상태를 패치하지 못하도록 차단하는 승인 웹후크
**리소스 상태 확인**:
```
# Describe the resource to see conditions and events
kubectl describe bucket my-bucket -n default
# Look for status conditions
kubectl get bucket my-bucket -n default -o jsonpath='{.status.conditions}'
# View resource events
kubectl get events --field-selector involvedObject.name=my-bucket -n default
```
**IAM 권한 확인**:
```
# View the Capability Role's policies
aws iam list-attached-role-policies --role-name my-ack-capability-role
aws iam list-role-policies --role-name my-ack-capability-role
# Get specific policy details
aws iam get-role-policy --role-name my-ack-capability-role --policy-name policy-name
```
## AWS에서 생성되었지만 Kubernetes에 표시되지 않는 리소스
ACK는 Kubernetes 매니페스트를 통해 생성한 리소스만 추적합니다. ACK를 사용하여 기존 AWS 리소스를 관리하려면 채택 기능을 사용합니다.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
리소스 채택에 대한 자세한 내용은 [ACK 개념](ack-concepts.md) 섹션을 참조하세요.
## 교차 계정 리소스가 생성되지 않음
IAM 역할 선택기를 사용할 때 대상 AWS 계정에서 리소스가 생성되지 않는 경우 신뢰 관계 및 IAMRoleSelector 구성을 확인합니다.
**신뢰 관계 확인**
```
# Check the trust policy in the target account role
aws iam get-role --role-name cross-account-ack-role --query 'Role.AssumeRolePolicyDocument'
```
신뢰 정책은 소스 계정의 기능 역할에서 이를 수임하도록 허용해야 합니다.
**IAMRoleSelector 구성 확인**.
```
# List IAMRoleSelectors (cluster-scoped)
kubectl get iamroleselector
# Describe specific selector
kubectl describe iamroleselector my-selector
```
**네임스페이스 정렬 확인**:
IAMRoleSelector는 클러스터 범위의 리소스이지만 특정 네임스페이스를 대상으로 합니다. ACK 리소스가 IAMRoleSelector의 네임스페이스 선택기와 일치하는 네임스페이스에 있는지 확인합니다.
```
# Check resource namespace
kubectl get bucket my-cross-account-bucket -n production
# List all IAMRoleSelectors (cluster-scoped)
kubectl get iamroleselector
# Check which namespace the selector targets
kubectl get iamroleselector my-selector -o jsonpath='{.spec.namespaceSelector}'
```
**IAMRoleSelected 조건 확인**:
`ACK.IAMRoleSelected` 조건을 확인하여 IAMRoleSelector가 리소스와 성공적으로 일치하는지 확인합니다.
```
# Check if IAMRoleSelector was matched
kubectl get bucket my-cross-account-bucket -n production -o jsonpath='{.status.conditions[?(@.type=="ACK.IAMRoleSelected")]}'
```
조건이 `False`이거나 누락된 경우 IAMRoleSelector의 네임스페이스 선택기가 리소스의 네임스페이스와 일치하지 않습니다. 선택기의 `namespaceSelector`가 리소스의 네임스페이스 레이블과 일치하는지 확인합니다.
**기능 역할 권한 확인**:
기능 역할에는 대상 계정 역할에 대한 `sts:AssumeRole` 및 `sts:TagSession` 권한이 필요합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::[.replaceable]`444455556666`:role/[.replaceable]`cross-account-ack-role`"
}
]
}
```
자세한 교차 계정 구성은 [ACK 권한 구성](ack-permissions.md) 섹션을 참조하세요.
## 다음 단계
+ [EKS에 대한 ACK 고려 사항](ack-considerations.md) - ACK 고려 사항 및 모범 사례
+ [ACK 권한 구성](ack-permissions.md) - IAM 권한 및 다중 계정 패턴 구성
+ [ACK 개념](ack-concepts.md) - ACK 개념 및 리소스 수명 주기 이해
+ [EKS 기능 문제 해결](capabilities-troubleshooting.md) - 일반 기능 문제 해결 지침
# EKS의 ACK 기능과 자체 관리형 ACK 비교
EKS의 ACK 기능은 자체 관리형 ACK 컨트롤러와 동일한 기능을 제공하지만 상당한 운영 이점을 제공합니다. EKS 기능과 자체 관리형 솔루션의 일반적인 비교는 [EKS 기능 및 고려 사항](capabilities-considerations.md) 섹션을 참조하세요. 이 주제에서는 ACK에 특정한 차이에 중점을 둡니다.
## 업스트림 ACK와의 차이
EKS의 ACK 기능은 업스트림 ACK 컨트롤러에 기반하지만 IAM 통합에서 차이가 납니다.
**IAM 기능 역할**: 이 기능은 서비스 계정에 대한 IAM 역할(IRSA)이 아닌 `capabilities.eks.amazonaws.com` 서비스 위탁자를 허용하는 신뢰 정책이 있는 전용 IAM 역할을 사용합니다. Kubernetes 서비스 계정을 생성하거나 이에 주석을 달거나 OIDC 공급자를 구성할 필요 없이 IAM 정책을 기능 역할에 직접 연결할 수 있습니다. 프로덕션 사용 사례의 모범 사례는 `IAMRoleSelector`를 사용하여 서비스 권한을 구성하는 것입니다. 자세한 내용은 [ACK 권한 구성](ack-permissions.md) 섹션을 참조하세요.
**세션 태그**: 관리형 기능이 모든 AWS API 요청에서 세션 태그를 자동으로 설정하여 세분화된 액세스 제어 및 감사를 지원합니다. 태그에는 `eks:eks-capability-arn`, `eks:kubernetes-namespace` 및 `eks:kubernetes-api-group`이 포함됩니다. 기본적으로 이러한 태그를 설정하지 않는 자체 관리형 ACK와는 다릅니다. IAM 정책에서 세션 태그 사용에 대한 자세한 내용은 [ACK 권한 구성](ack-permissions.md) 섹션을 참조하세요.
**리소스 태그**: 이 기능은 자체 관리형 ACK와는 다른 기본 태그를 AWS 리소스에 적용합니다. 이 기능은 자체 관리형 ACK에서 사용하는 `services.k8s.aws/` 태그 대신 `eks:` 접두사의 태그(예: `eks:kubernetes-namespace`, `eks:eks-capability-arn`)를 사용합니다. 기본 리소스 태그의 전체 목록은 [EKS에 대한 ACK 고려 사항](ack-considerations.md) 섹션을 참조하세요.
**리소스 호환성**: ACK 사용자 지정 리소스는 ACK 리소스 YAML 파일을 변경하지 않고도 업스트림 ACK와 동일하게 작동합니다. 이 기능은 동일한 Kubernetes API 및 CRD를 사용하므로 `kubectl` 같은 도구가 동일한 방식으로 작동합니다. 업스트림 ACK의 모든 GA 컨트롤러 및 리소스가 지원됩니다.
전체 ACK 설명서 및 서비스별 가이드는 [ACK 설명서](https://aws-controllers-k8s.github.io/community/)를 참조하세요.
## 마이그레이션 경로
가동 중지 시간 없이 자체 관리형 ACK에서 관리형 기능으로 마이그레이션할 수 있습니다.
1. 리더 선정 리스에 `kube-system`을 사용하도록 자체 관리형 ACK 컨트롤러를 업데이트합니다. 예를 들어 다음과 같습니다.
```
helm upgrade --install ack-s3-controller \
oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
--namespace ack-system \
--set leaderElection.namespace=kube-system
```
그러면 컨트롤러의 리스가 `kube-system`으로 이전되어 관리형 기능을 이에 맞게 조정할 수 있습니다.
1. 클러스터에서 ACK 기능 생성([ACK 기능 생성](create-ack-capability.md) 참조)
1. 관리형 기능은 기존 ACK 관리형 AWS 리소스를 인식하고 조정을 인계함
1. 자체 관리형 컨트롤러 배포를 점진적으로 스케일 다운하거나 제거합니다.
```
helm uninstall ack-s3-controller --namespace ack-system
```
이 접근 방식을 사용하면 마이그레이션 중에 두 컨트롤러가 모두 안전하게 공존할 수 있습니다. 관리형 기능은 이전에 자체 관리형 컨트롤러o에서 관리하던 리소스를 자동으로 채택하여 충돌 없이 지속적인 조정을 보장합니다.
## 다음 단계
+ [ACK 기능 생성](create-ack-capability.md) - ACK 기능 리소스 생성
+ [ACK 개념](ack-concepts.md) - ACK 개념 및 리소스 수명 주기 이해
+ [ACK 권한 구성](ack-permissions.md) - IAM 및 권한 구성