**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# EKS 기능
**작은 정보**
시작하기: [ACK 기능 생성](create-ack-capability.md) \$1 [Argo CD 기능 생성](create-argocd-capability.md) \$1 [kro 기능 생성](create-kro-capability.md)
Amazon EKS 기능은 개발자의 속도를 가속화하고 Kubernetes 플랫폼 빌드의 복잡성을 완화하는 데 도움이 되는 계층화된 완전관리형 클러스터 기능 세트입니다. EKS 기능은 선언적 연속 배포, AWS 리소스 관리, Kubernetes 리소스 작성 및 오케스트레이션을 위한 Kubernetes 네이티브 기능으로, 모두 AWS의 완전관리형 기능입니다. EKS 기능을 사용하면 워크로드 빌드 및 확장에 더 집중할 수 있으므로 이러한 기본 플랫폼 서비스의 운영 부담을 AWS로 오프로드할 수 있습니다. 이러한 기능은 클러스터가 아닌 EKS 내에서 실행되므로 워커 노드에 중요한 플랫폼 구성 요소를 설치 및 유지 관리하고 규모를 조정할 필요가 없습니다.
시작하기 위해 신규 또는 기존 EKS 클러스터에서 하나 이상의 EKS 기능을 생성할 수 있습니다. 이를 위해 AWS CLI, AWS Management Console, EKS API, eksctl 또는 선호하는 코드형 인프라 도구를 사용할 수 있습니다. EKS 기능은 함께 작동하도록 설계되었지만, 사용 사례 및 요구 사항에 따라 선택할 수 있는 독립된 클라우드 리소스입니다.
EKS에서 지원하는 모든 Kubernetes 버전은 EKS 기능에 대해 지원됩니다.
**참고**
Amazon EKS를 사용할 수 있는 모든 AWS 상용 리전에서 EKS 기능을 사용할 수 있습니다. 지원되는 리전 목록은 AWS 일반 참조의 [Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)를 참조하세요.
## 사용 가능한 기능
### AWS Controllers for Kubernetes(ACK)
ACK를 사용하면 Kubernetes API를 사용하여 AWS 리소스를 관리할 수 있으므로, 이를 통해 Kubernetes 사용자 지정 AWS 리소스를 사용하여 S3 버킷, RDS 데이터베이스, IAM 역할 및 기타 리소스를 생성하고 관리할 수 있습니다. ACK는 원하는 상태를 AWS의 실제 상태에 맞게 지속적으로 조정하여 시간 경과에 따른 드리프트를 수정함으로써 시스템을 정상으로 유지하고 리소스를 지정된 대로 구성합니다. S3, RDS, DynamoDB, Lambda 등 50개가 넘는 AWS 서비스를 지원하여 동일한 도구 및 워크플로를 사용해 Kubernetes 워크로드와 함께 AWS 리소스를 관리할 수 있습니다. ACK는 교차 계정 및 교차 리전 리소스 관리를 지원하여 복잡한 다중 계정, 다중 클러스터 시스템 관리 아키텍처를 지원합니다. ACK는 읽기 전용 리소스와 읽기 전용 채택을 지원하여 다른 코드형 인프라 도구에서 Kubernetes 기반 시스템으로 쉽게 마이그레이션할 수 있습니다.
[ACK에 대해 자세히 알아보기 →](ack.md)
### Argo CD
Argo CD는 애플리케이션에 대한 GitOps 기반 지속적 배포를 구현하여 Git 리포지토리를 워크로드 및 시스템 상태의 정확한 소스로 사용합니다. Argo CD는 애플리케이션 리소스를 Git 리포지토리의 클러스터에 자동으로 동기화하여 드리프트를 감지하고 수정해 배포된 애플리케이션이 원하는 상태와 일치하는지 확인합니다. 변경 사항이 커밋될 때마다 Git 리포지토리에서 자동화된 배포를 통해 단일 Argo CD 인스턴스에서 여러 클러스터로 애플리케이션을 배포하고 관리할 수 있습니다. Argo CD와 ACK를 함께 사용하면 기본 GitOps 시스템을 제공하여 워크로드 종속성 관리를 단순화하고 클러스터 및 대규모 인프라 관리를 포함한 전체 시스템 설계를 지원할 수 있습니다. Argo CD는 인증 및 권한 부여를 위해 AWS Identity Center에 통합되며, 애플리케이션 상태 및 배포 상태를 시각화하기 위해 호스팅된 Argo UI를 제공합니다.
[Argo CD에 대해 자세히 알아보기 →](argocd.md)
### Kube Resource Orchestrator(kro)
kro를 사용하면 여러 리소스를 상위 수준 추상화로 구성하는 사용자 지정 Kubernetes API를 생성할 수 있으므로 플랫폼 팀이 일반적인 리소스 조합의 클라우드 구성 요소에 대해 재사용 가능한 패턴을 정의할 수 있습니다. kro를 사용하면 Kubernetes 및 AWS 리소스를 모두 통합화된 추상화로 구성하여 간단한 구문을 통해 동적 구성 및 조건부 로직을 활성화할 수 있니다. kro를 사용하면 플랫폼 팀이 적절한 가드레일을 통해 셀프 서비스 기능을 제공하여 개발자가 조직 표준 및 모범 사례를 유지하면서 간단한 목적별 API로 복잡한 인프라를 프로비저닝할 수 있습니다. kro 리소스는 Kubernetes 리소스이며, Git에 저장할 수 있는 Kubernetes 매니페스트에서 지정되거나 광범위한 조직 배포를 위해 Amazon ECR과 같은 OCI 호환 레지스트리로 푸시됩니다.
[kro에 대해 자세히 알아보기 →](kro.md)
## EKS 기능의 이점
EKS 기능은 AWS의 완전관리형 기능으로, 기본 클러스터 서비스의 설치, 유지 관리 및 조정이 필요하지 않습니다. AWS가 보안 패치, 업데이트 및 운영 관리를 처리하므로 팀은 클러스터 운영이 아닌 AWS에 기반한 빌드에 집중할 수 있습니다. 클러스터 리소스를 소비하는 기존 Kubernetes 추가 기능과 달리, 이 기능은 워커 노드가 아닌 EKS에서 실행됩니다. 이를 통해 클러스터 내 컨트롤러 및 기타 플랫폼 구성 요소 관리의 운영 부담을 최소화하면서 워크로드에 대한 클러스터 용량과 리소스를 확보합니다.
EKS 기능을 사용하면 `kubectl`과 같은 기본 Kubernetes API 및 도구를 사용하여 배포, AWS 리소스, 사용자 지정 Kubernetes 리소스 및 구성을 관리할 수 있습니다. 모든 기능은 클러스터의 컨텍스트에서 작동하여 애플리케이션 및 클라우드 인프라 리소스 모두에서 구성 드리프트를 자동으로 감지하고 수정합니다. 단일 제어 지점에서 다중 클러스터, AWS 계정 및 리전에 리소스를 배포하고 관리할 수 있으므로 복잡한 분산 환경에서 작업을 단순화할 수 있습니다.
EKS 기능은 GitOps 워크플로를 위해 설계되었으며 선언적이고 버전으로 제어되는 인프라 및 애플리케이션 관리를 제공합니다. 시스템을 통해 Git에서 흐름을 변경하여 기존 개발 사례에 통합되는 감사 추적, 롤백 기능 및 협업 워크플로를 제공합니다. 이러한 Kubernetes 네이티브 접근 방식은 여러 도구를 사용하거나 클러스터 외부의 코드형 인프라 시스템을 관리할 필요가 없으며, 신뢰할 수 있는 단일 소스를 참조합니다. 버전으로 제어된 Kubernetes의 선언적 구성에 정의된 원하는 상태는 환경 전체에 지속적으로 적용됩니다.
## 가격 책정
EKS 기능을 사용하면 선결제 약정이나 최소 수수료가 없습니다. Amazon EKS 클러스터에서 활성화된 동안 각 기능 리소스에 대해 시간당 요금이 청구됩니다. EKS 기능에서 관리하는 특정 Kubernetes 리소스도 시간당 요금으로 청구됩니다.
현재 요금 정보는 [Amazon EMR 요금](https://aws.amazon.com/eks/pricing/) 페이지를 참조하세요.
**작은 정보**
AWS Cost Explorer와 비용 및 사용 보고서를 사용하여 다른 EKS 요금과 별도로 기능 비용을 추적할 수 있습니다. 비용 할당 목적으로 클러스터 이름, 기능 유형 및 기타 세부 정보를 사용해 기능에 태그를 지정할 수 있습니다.
## EKS 기능 작동 방식
각 기능은 EKS 클러스터에서 사용자가 생성하는 AWS 리소스입니다. 생성되면 기능은 EKS에서 실행되고 AWS에 의해 완전하게 관리됩니다.
**참고**
지정된 클러스터에 대해 각 유형(Argo CD, ACK 및 kro)의 기능 리소스를 하나씩 생성할 수 있습니다. 동일한 클러스터에서 동일한 유형의 여러 기능 리소스를 생성할 수 없습니다.
표준 Kubernetes API 및 도구를 사용하여 클러스터에서 기능과 상호 작용합니다.
+ `kubectl`을 사용하여 Kubernetes 사용자 지정 리소스 적용
+ Git 리포지토리를 GitOps 워크플로의 신뢰할 수 있는 소스로 사용
일부 기능에서는 추가 도구가 지원됩니다. 예제:
+ Argo CD CLI를 사용하여 Argo CD 기능에서 리포지토리 및 클러스터 구성 및 관리
+ Argo CD UI를 사용하여 Argo CD 기능에 의해 관리되는 애플리케이션 시각화 및 관리
기능은 함께 작동하도록 설계되었지만 독립적이며 완전히 옵트인됩니다. 필요에 따라 1개, 2개 또는 3개 기능을 모두 활성화하고 요구 사항이 진화함에 따라 구성을 업데이트할 수 있습니다.
모든 EKS 컴퓨팅 유형은 EKS 기능과 함께 사용하도록 지원됩니다. 자세한 내용은 [노드를 사용하여 컴퓨팅 리소스 관리](eks-compute.md) 섹션을 참조하세요.
IAM 역할에 대한 보안 구성 및 세부 정보는 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요. 다중 클러스터 아키텍처 패턴은 [EKS 기능 및 고려 사항](capabilities-considerations.md) 섹션을 참조하세요.
## 일반 사용 사례
**애플리케이션 및 인프라를 위한 GitOps**
Argo CD를 사용하여 애플리케이션 및 운영 구성 요소를 배포하고, ACK를 사용하여 Git 리포지토리에서 클러스터 구성을 관리하고 인프라를 프로비저닝합니다. 애플리케이션, 데이터베이스, 스토리지, 네트워킹과 같은 전체 스택은 코드로 정의되고 자동으로 배포됩니다.
예제: 개발 팀이 Git에 변경 사항을 푸시합니다. Argo CD는 업데이트된 애플리케이션을 배포하고, ACK는 올바른 구성으로 새 RDS 데이터베이스를 프로비저닝합니다. 모든 변경 사항은 감사 가능하고 되돌릴 수 있으며 여러 환경에서 일관됩니다.
**셀프 서비스를 사용한 플랫폼 엔지니어링**
kro를 사용하여 ACK 및 Kubernetes 리소스를 구성하는 사용자 지정 API를 생성합니다. 플랫폼 팀은 가드레일을 사용하여 승인된 패턴을 정의합니다. 애플리케이션 팀은 간단한 상위 수준 API를 사용하여 전체 스택을 프로비저닝합니다.
예제: 플랫폼 팀은 배포, 서비스, 수신 및 S3 버킷을 프로비저닝하는 'WebApplication' API를 생성합니다. 개발자는 기본 복잡성이나 AWS 권한을 이해하지 않고도 이 API를 사용합니다.
**다중 클러스터 애플리케이션 관리**
Argo CD를 사용하여 여러 리전 또는 계정의 여러 EKS 클러스터에 애플리케이션을 배포합니다. 일관된 정책 및 워크플로를 사용하여 단일 Argo CD 인스턴스에서 모든 배포를 관리합니다.
예제: 여러 리전의 개발, 스테이징 및 프로덕션 클러스터에 동일한 애플리케이션을 배포합니다. Argo CD는 각 환경이 해당 Git 브랜치와 동기화된 상태를 유지하도록 보장합니다.
**다중 클러스터 관리**
ACK를 사용하여 EKS 클러스터를 정의 및 프로비저닝하고, kro를 사용하여 조직 표준에 따라 클러스터 구성을 사용자 지정하며, Argo CD를 사용하여 클러스터 수명 주기 및 구성을 관리합니다. 이를 통해 생성부터 지속적인 작업까지 포괄적으로 클러스터를 관리할 수 있습니다.
예제: ACK 및 kro를 사용하여 EKS 클러스터를 정의해 클러스터 인프라를 프로비저닝 및 관리함으로써 네트워킹, 보안 정책, 추가 기능 및 기타 구성에 대한 조직 표준을 정의합니다. Argo CD를 사용하여 일관된 표준과 자동화된 수명 주기 관리를 활용해 전체 플릿에서 클러스터, 구성 및 Kubernetes 버전 업데이트를 생성하고 지속적으로 관리합니다.
**마이그레이션 및 현대화**
네이티브 클라우드 리소스 프로비저닝 및 GitOps 워크플로를 사용하여 EKS로의 마이그레이션을 단순화합니다. ACK를 사용하여 기존 AWS 리소스를 다시 생성하지 않고 그대로 채택하고, Argo CD를 사용하여 Git에서 워크로드 배포를 운영합니다.
예제: EC2에서 EKS로 마이그레이션하는 팀은 ACK를 사용하여 기존 RDS 데이터베이스와 S3 버킷을 채택한 다음, Argo CD를 사용하여 Git에서 컨테이너화된 애플리케이션을 배포합니다. 마이그레이션 경로는 명확하며, 작업은 첫날부터 표준화됩니다.
**계정 및 리전 부트스트래핑**
Argo CD와 ACK를 함께 사용하여 여러 계정 및 리전에서 인프라 롤아웃을 자동화합니다. Git에서 코드형 인프라를 정의하고, 기능에서 배포 및 관리를 처리하도록 합니다.
예제: 플랫폼 팀은 VPC, IAM 역할, RDS 인스턴스, 모니터링 스택 등 표준 계정 구성을 정의하는 Git 리포지토리를 유지 관리합니다. Argo CD는 이러한 구성을 새 계정 및 리전에 자동으로 배포하여 일관성을 보장하고 수동 설정 시간을 며칠에서 몇 분으로 단축합니다.
# 기능 리소스 작업
이 주제에서는 모든 기능 유형에서 기능 리소스를 관리하기 위한 일반적인 작업을 설명합니다.
## EKS 기능 리소스
EKS 기능은 Amazon EKS 클러스터에서 관리형 기능을 지원하는 AWS 리소스입니다. 기능은 EKS에서 실행되므로 워커 노드에서 컨트롤러 및 기타 운영 구성 요소를 설치하고 유지 관리할 필요가 없습니다. 기능은 특정 EKS 클러스터에 대해 생성되며 전체 수명 주기 동안 해당 클러스터와 연결된 상태로 유지됩니다.
각 기능 리소스에는 다음이 있습니다.
+ 클러스터 내 고유한 이름
+ 기능 유형(ACK, ARGOCD 또는 KRO)
+ 이름과 유형을 모두 지정하는 Amazon 리소스 이름(ARN)
+ 기능 IAM 역할
+ 현재 상태를 나타내는 상태
+ 구성(일반 구성 및 기능 유형에 특정한 구성 모두 포함)
## 기능 상태 이해
기능 리소스에는 현재 상태를 나타내는 상태가 있습니다. EKS 콘솔 또는 AWS CLI를 사용하여 기능 상태를 볼 수 있습니다.
**콘솔**:
1. https://console.aws.amazon.com/eks/home\$1/clusters에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하세요.
1. 모든 기능의 상태를 보려면 **기능** 탭을 선택하세요.
1. 자세한 상태 정보를 보려면 **관찰성** 탭을 선택한 다음 **클러스터 모니터링**, **기능** 탭을 선택하세요.
**AWS CLI**:
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-capability-name
```
### 기능 상태
**CREATING**: 기능이 설정 중입니다. 콘솔에서 다른 위치로 이동할 수 있습니다. 이 기능은 백그라운드에서 계속 생성됩니다.
**ACTIVE**: 기능이 실행 중이며 사용할 준비가 되었습니다. 리소스가 예상대로 작동하지 않는 경우 리소스 상태 및 IAM 권한을 확인합니다. 지침은 [EKS 기능 문제 해결](capabilities-troubleshooting.md) 섹션을 참조하세요.
**UPDATING**: 구성 변경 사항이 적용 중입니다. `ACTIVE` 상태로 돌아갈 때까지 기다립니다.
**DELETING**: 기능이 클러스터에서 제거 중입니다.
**CREATE\$1FAILED**: 설정에서 오류가 발생했습니다. 일반적인 사용 사례는 다음과 같습니다.
+ IAM 역할 신뢰 정책이 잘못되었거나 누락됨
+ IAM 역할이 없거나 이에 액세스할 수 없음
+ 클러스터 액세스 문제
+ 유효하지 않은 구성 파라미터
기능 상태 섹션에서 구체적인 오류 세부 정보를 확인하세요.
**UPDATE\$1FAILED**: 구성 업데이트에 실패했습니다. 기능 상태 섹션에서 세부 정보를 확인하고 IAM 권한을 확인합니다.
**작은 정보**
자세한 문제 해결 지침은 다음을 참조하세요.
[EKS 기능 문제 해결](capabilities-troubleshooting.md) - 일반 기능 문제 해결
[ACK 기능 관련 문제 해결](ack-troubleshooting.md) - ACK 특정 문제
[Argo CD 기능 관련 문제 해결](argocd-troubleshooting.md) - Argo CD 특정 문제
[kro 기능 관련 문제 해결](kro-troubleshooting.md) - kro 특정 문제
## 기능 생성
클러스터에서 기능을 생성하려면 다음 주제를 참조하세요.
+ [ACK 기능 생성](create-ack-capability.md) - Kubernetes API를 사용하여 AWS 리소스를 관리하는 ACK 기능 생성
+ [Argo CD 기능 생성](create-argocd-capability.md) - GitOps 지속적 전송을 위해 Argo CD 기능 생성
+ [kro 기능 생성](create-kro-capability.md) - 리소스 구성 및 오케스트레이션을 위해 kro 기능 생성
## 기능 나열
클러스터의 모든 기능 리소스를 나열할 수 있습니다.
### 콘솔
1. https://console.aws.amazon.com/eks/home\$1/clusters에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하여 클러스터 세부 정보 페이지를 여세요.
1. **기능** 탭을 선택하세요.
1. **관리형 기능**에서 기능 리소스를 보세요.
### AWS CLI
`list-capabilities` 명령을 사용하여 클러스터의 모든 기능을 봅니다. *region-code*를 클러스터를 생성한 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꿉니다.
```
aws eks list-capabilities \
--region region-code \
--cluster-name my-cluster
```
```
{
"capabilities": [
{
"capabilityName": "my-ack",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack/abc123",
"type": "ACK",
"status": "ACTIVE",
"createdAt": "2025-11-02T10:30:00.000000-07:00",
"modifiedAt": "2025-11-02T10:32:15.000000-07:00",
},
{
"capabilityName": "my-kro",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/kro/my-kro/abc123",
"type": "KRO",
"status": "ACTIVE",
"version": "v0.6.3",
"createdAt": "2025-11-02T10:30:00.000000-07:00",
"modifiedAt": "2025-11-02T10:32:15.000000-07:00",
},
{
"capabilityName": "my-argocd",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/argocd/my-argocd/abc123",
"type": "ARGOCD",
"status": "ACTIVE",
"version": "3.1.8-eks-1",
"createdAt": "2025-11-21T08:22:28.486000-05:00",
"modifiedAt": "2025-11-21T08:22:28.486000-05:00"
}
]
}
```
## 기능 설명
해당 구성 및 상태를 포함하여 특정 기능에 대한 자세한 정보를 가져옵니다.
### 콘솔
1. https://console.aws.amazon.com/eks/home\$1/clusters에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하여 클러스터 세부 정보 페이지를 여세요.
1. **기능** 탭을 선택하세요.
1. **관리형 기능**에서 보려는 기능을 선택하세요.
1. 상태, 구성 및 생성 시간을 포함하여 기능 세부 정보를 보세요.
### AWS CLI
`describe-capability` 명령을 사용하여 자세한 정보를 봅니다. *region-code*를 클러스터가 있는 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꾸며 *capability-name*을 기능 이름(ack, argocd 또는 kro)으로 바꿉니다.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name
```
**출력 예제:**
```
{
"capability": {
"capabilityName": "my-ack",
"capabilityArn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack/abc123",
"clusterName": "my-cluster",
"type": "ACK",
"roleArn": "arn:aws:iam::111122223333:role/AmazonEKSCapabilityACKRole",
"status": "ACTIVE",
"configuration": {},
"tags": {},
"health": {
"issues": []
},
"createdAt": "2025-11-19T17:11:30.242000-05:00",
"modifiedAt": "2025-11-19T17:11:30.242000-05:00",
"deletePropagationPolicy": "RETAIN"
}
}
```
## 기능 구성 업데이트
생성 후 기능의 특정 구성 측면을 업데이트할 수 있습니다. 특정 구성 옵션은 기능 유형별로 다릅니다.
**참고**
EKS 기능 리소스는 패치 적용 및 버전 업데이트를 포함하여 완전하게 관리됩니다. 기능을 업데이트하면 리소스 구성이 업데이트되고 관리형 기능 구성 요소의 버전은 업데이트되지 않습니다.
### AWS CLI
`update-capability` 명령을 사용하여 기능을 수정합니다.
```
aws eks update-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name \
--role-arn arn:aws:iam::[.replaceable]111122223333:role/NewCapabilityRole
```
**참고**
생성 후 일부 기능 속성을 업데이트할 수 없습니다. 수정할 수 있는 항목에 대한 자세한 내용은 기능별 설명서를 참조하세요.
## 기능 삭제
클러스터에 더 이상 기능이 필요하지 않은 경우 해당 기능 리소스를 삭제할 수 있습니다.
**중요**
**기능을 삭제하기 전에 클러스터 리소스를 삭제합니다.**
기능 리소스를 삭제해도 해당 기능을 통해 생성된 리소스는 자동으로 삭제되지 않습니다.
모든 Kubernetes 사용자 지정 리소스 정의(CRD)는 클러스터에 설치된 상태로 남아 있음
ACK 리소스는 클러스터에 남아 있고 해당 AWS 리소스는 계정에 남아 있음
Argo CD 애플리케이션 및 해당 Kubernetes 리소스는 클러스터에 남아 있음
kro ResourceGraphDefinitions 및 인스턴스가 클러스터에 남아 있음
분리된 리소스를 방지하기 위해 기능을 삭제하기 전에 이러한 리소스를 삭제해야 합니다.
선택적으로 ACK Kubernetes 리소스와 연결된 AWS 리소스를 유지하도록 선택할 수 있습니다. [ACK 고려 사항](ack-considerations.md)을 참조하세요.
### 콘솔
1. https://console.aws.amazon.com/eks/home\$1/clusters에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하여 클러스터 세부 정보 페이지를 여세요.
1. **기능** 탭을 선택하세요.
1. **관리형 기능** 목록에서 삭제할 기능을 선택하세요.
1. **기능 삭제**를 선택하세요.
1. 확인 대화 상자에서 삭제를 확인하기 위해 기능 이름을 입력하세요.
1. **삭제**를 선택합니다.
### AWS CLI
`delete-capability` 명령을 사용하여 기능 리소스를 삭제합니다.
*region-code*를 클러스터가 있는 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꾸며 *capability-name*을 삭제한 기능 이름으로 바꿉니다.
```
aws eks delete-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name
```
## 다음 단계
+ [기능 Kubernetes 리소스](capability-kubernetes-resources.md) - 각 기능 유형에서 제공하는 Kubernetes 리소스에 대해 알아보기
+ [ACK 개념](ack-concepts.md) - ACK 개념 및 리소스 수명 주기 이해
+ [Argo CD 작업](working-with-argocd.md) - GitOps 워크플로에 대한 Argo CD 기능 작업
+ [kro 개념](kro-concepts.md) - kro 개념 및 리소스 구성 이해
# 기능 Kubernetes 리소스
클러스터에서 기능을 활성화한 후에 대부분 클러스터에서 Kubernetes 사용자 지정 리소스를 생성 및 관리하여 클러스터와 상호 작용하기도 합니다. 각 기능은 기능별 기능으로 Kubernetes API를 확장하는 고유한 사용자 지정 리소스 정의(CRD) 세트를 제공합니다.
## Argo CD 리소스
Argo CD 기능을 활성화하면 다음 Kubernetes 리소스를 생성 및 관리할 수 있습니다.
**애플리케이션**
Git 리포지토리에서 대상 클러스터로의 배포를 정의합니다. `Application` 리소스는 소스 리포지토리, 대상 네임스페이스 및 동기화 정책을 지정합니다. Argo CD 기능 인스턴스당 최대 1,000개의 `Application` 리소스를 생성할 수 있습니다.
**ApplicationSet**
템플릿에서 여러 `Application` 리소스를 생성하여 다중 클러스터 및 다중 환경 배포를 활성화합니다. `ApplicationSet` 리소스는 생성기를 사용하여 클러스터 목록, Git 디렉터리 또는 기타 소스에 기반해 `Application` 리소스를 동적으로 생성합니다.
**AppProject**
`Application` 리소스에 대한 논리적 그룹화 및 액세스 제어를 제공합니다. `AppProject` 리소스는 `Application` 리소스가 사용할 수 있는 리포지토리, 클러스터 및 네임스페이스를 정의하여 다중 테넌시 및 보안 경계를 지원합니다.
`Application` 리소스 예제:
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/org/repo
targetRevision: main
path: manifests
destination:
server: https://kubernetes.default.svc
namespace: production
```
Argo CD 리소스 및 개념에 대한 자세한 내용은 [Argo CD 개념](argocd-concepts.md) 섹션을 참조하세요.
## kro 리소스
kro 기능을 활성화하면 다음 Kubernetes 리소스를 생성 및 관리할 수 있습니다.
**ResourceGraphDefinition(RGD)**
여러 Kubernetes 및 AWS 리소스를 상위 수준의 추상화로 구성하는 사용자 지정 API를 정의합니다. 플랫폼 팀은 가드레일이 있는 재사용 가능한 패턴을 제공하는 `ResourceGraphDefinition` 리소스를 생성합니다.
**사용자 지정 리소스 인스턴스**
`ResourceGraphDefinition` 리소스를 생성한 후 `ResourceGraphDefinition`에서 정의한 사용자 지정 API의 인스턴스를 생성할 수 있습니다. kro는 `ResourceGraphDefinition`에 지정된 리소스를 자동으로 생성 및 관리합니다.
`ResourceGraphDefinition` 리소스 예제:
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: web-application
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
spec:
name: string
replicas: integer
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
# ... deployment spec
- id: service
template:
apiVersion: v1
kind: Service
# ... service spec
```
`WebApplication` 인스턴스 예제:
```
apiVersion: v1alpha1
kind: WebApplication
metadata:
name: my-web-app
namespace: default
spec:
name: my-web-app
replicas: 3
```
이 인스턴스를 적용하는 경우 kro는 `ResourceGraphDefinition`에 정의된 `Deployment` 및 `Service` 리소스를 자동으로 생성합니다.
kro 리소스 및 개념에 대한 자세한 내용은 [kro 개념](kro-concepts.md) 섹션을 참조하세요.
## ACK 리소스
ACK 기능을 활성화하면 Kubernetes 사용자 지정 리소스를 사용하여 AWS 리소스를 생성 및 관리할 수 있습니다. ACK는 50개가 넘는 AWS 서비스에 대해 200개가 넘는 CRD를 제공하므로 Kubernetes 워크로드와 함께 AWS 리소스를 정의하고 Kubernetes에서 전용 AWS 인프라 리소스를 관리할 수 있습니다.
ACK 리소스 예제:
**S3 Bucket**
`Bucket` 리소스는 버전 관리, 암호화 및 수명 주기 정책을 사용하여 Amazon S3 버킷을 생성 및 관리합니다.
**RDS DBInstance**
`DBInstance` 리소스는 자동 백업 및 유지 관리 기간으로 Amazon RDS 데이터베이스 인스턴스를 프로비저닝 및 관리합니다.
**DynamoDB 테이블**
`Table` 리소스는 프로비저닝된 용량 또는 온디맨드 용량으로 DynamoDB 테이블을 생성 및 관리합니다.
[**IAM Role**]
`Role` 리소스는 AWS 서비스 액세스에 대한 신뢰 정책 및 권한 정책을 사용하여 IAM 역할을 정의합니다.
**Lambda 함수**
`Function` 리소스는 코드, 런타임 및 실행 역할 구성을 통해 Lambda 함수를 생성 및 관리합니다.
`Bucket` 리소스 사양 예제:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-app-bucket
spec:
name: my-unique-bucket-name-12345
versioning:
status: Enabled
encryption:
rules:
- applyServerSideEncryptionByDefault:
sseAlgorithm: AES256
```
ACK 리소스 및 개념에 대한 자세한 내용은 [ACK 개념](ack-concepts.md) 섹션을 참조하세요.
## 리소스 제한
EKS 기능에는 다음과 같은 리소스 제한이 적용됩니다.
**Argo CD 사용량 제한**:
+ Argo CD 기능 인스턴스당 최대 1,000개의 `Application` 리소스
+ Argo CD 기능 인스턴스당 구성된 최대 100개의 원격 클러스터
**리소스 구성 제한**:
+ Argo CD의 `Application` 리소스당 최대 150개의 Kubernetes 리소스
+ kro의 `ResourceGraphDefinition`당 최대 64개의 Kubernetes 리소스
**참고**
이러한 제한은 각 기능 인스턴스에서 관리하는 리소스 수에 적용됩니다. 더 높은 제한이 필요한 경우 여러 클러스터에 기능을 배포할 수 있습니다.
## 다음 단계
기능별 태스크 및 고급 구성은 다음 주제를 참조하세요.
+ [ACK 개념](ack-concepts.md) - ACK 개념 및 리소스 수명 주기 이해
+ [Argo CD 작업](working-with-argocd.md) - GitOps 워크플로에 대한 Argo CD 기능 작업
+ [kro 개념](kro-concepts.md) - kro 개념 및 리소스 구성 이해
# EKS 기능 및 고려 사항
이 주제에서는 액세스 제어 설계, EKS 기능과 자체 관리형 솔루션 중 선택, 다중 클러스터 배포에 대한 아키텍처 패턴, 운영 모범 사례 등 EKS 기능 사용에 대한 중요한 고려 사항을 다룹니다.
## 기능 IAM 역할 및 Kubernetes RBAC
각 EKS 기능 리소스에는 구성된 기능 IAM 역할이 있습니다. 기능 역할은 EKS 기능이 사용자를 대신하여 작동할 수 있도록 AWS 서비스 권한을 부여하는 데 사용됩니다. 예를 들어 ACK의 EKS 기능을 사용하여 Amazon S3 버킷을 관리하려면 기능에 S3 버킷 관리 권한을 부여하여 버킷을 생성 및 관리할 수 있도록 합니다.
기능이 구성되면 클러스터의 Kubernetes 사용자 지정 리소스를 사용하여 AWS에서 S3 리소스를 생성 및 관리할 수 있습니다. Kubernetes RBAC는 이러한 사용자 지정 리소스를 생성 및 관리할 수 있는 사용자 및 그룹을 결정하기 위한 클러스터 내 액세스 제어 메커니즘입니다. 예를 들어 특정 Kubernetes RBAC 사용자 및 그룹에 선택한 네임스페이스에서 `Bucket` 리소스를 생성 및 관리할 권한을 부여합니다.
이러한 방식으로 IAM 및 Kubernetes RBAC는 EKS 기능 및 리소스와 관련된 권한을 관리하는 포괄적인 액세스 제어 시스템의 두 부분입니다. 사용 사례에 맞게 IAM 권한과 RBAC 액세스 정책의 올바른 조합을 설계하는 것이 중요합니다.
기능 IAM 역할 및 Kubernetes 권한에 대한 자세한 내용은 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
## 다중 클러스터 아키텍처 패턴
여러 클러스터에 기능을 배포할 때는 다음과 같은 일반적인 아키텍처 패턴을 고려합니다.
**중앙 집중식 관리를 통한 허브 및 스포크**
중앙 관리형 클러스터에서 세 가지 기능을 모두 실행하여 워크로드를 오케스트레이션하고 여러 워크로드 클러스터에서 클라우드 인프라를 관리합니다.
+ 관리 클러스터에서 Argo CD는 서로 다른 리전 또는 계정의 워크로드 클러스터에 애플리케이션을 배포함
+ 관리 클러스터에서 ACK는 모든 클러스터에 대해 AWS 리소스(RDS, S3, IAM)를 프로비저닝함
+ 관리 클러스터에서 kro는 모든 클러스터에서 작동하는 이동식 플랫폼 추상화를 생성함
이 패턴은 워크로드 및 클라우드 인프라 관리를 중앙 집중화하고 여러 클러스터를 관리하는 조직의 운영을 단순화할 수 있습니다.
**분산된 GitOps**
워크로드 및 클라우드 인프라는 워크로드가 실행되는 동일한 클러스터의 기능에 의해 관리됩니다.
+ Argo CD는 로컬 클러스터에서 애플리케이션 리소스를 관리합니다.
+ ACK 리소스는 클러스터 및 워크로드 요구 사항에 사용됩니다.
+ kro 플랫폼 추상화가 설치되고 로컬 리소스를 오케스트레이션합니다.
이 패턴은 하나 이상의 클러스터에서 자체 전용 플랫폼 서비스를 관리하는 팀을 통해 운영을 분산합니다.
**하이브리드 ACK 배포를 사용하는 허브 및 스포크**
범위 및 소유권을 기반으로 중앙 집중식 애플리케이션 배포 및 리소스 관리와 중앙 집중식 및 분산 모델을 결합합니다.
+ 허브 클러스터:
+ Argo CD는 로컬 클러스터 및 모든 원격 워크로드 클러스터에 대한 GitOps 배포를 관리함
+ ACK는 관리자 범위 리소스(프로덕션 데이터베이스, IAM 역할, VPC)에 대해 관리 클러스터에서 사용됨
+ kro는 재사용 가능한 플랫폼 추상화를 위해 관리 클러스터에서 사용됨
+ Spoke 클러스터:
+ 워크로드는 중앙 집중식 허브 클러스터에서 Argo CD를 통해 관리됨
+ ACK는 워크로드 범위 리소스(S3 버킷, ElastiCache 인스턴스, SQS 대기열)에 대해 로컬로 사용됨
+ kro는 리소스 구성 및 구성 요소 패턴에 대해 로컬로 사용됨
이 패턴은 문제를 구분합니다. 플랫폼 팀은 선택적으로 워크로드 클러스터를 포함하여 관리 클러스터에서 중요한 인프라를 중앙에서 관리하는 반면, 애플리케이션 팀은 워크로드와 함께 클라우드 리소스를 지정 및 관리합니다.
**패턴 선택**
아키텍처를 선택할 때 다음 요소를 고려합니다.
+ **조직 구조**: 중앙 집중식 플랫폼 팀은 허브 패턴을 선호하고, 분산 팀은 클러스터별 기능을 선호할 수 있음
+ **리소스 범위**: 관리자 범위 리소스(데이터베이스, IAM)는 중앙 관리에서 종종 더 유리하며, 워크로드 리소스(버킷, 대기열)는 로컬에서 관리할 수 있음
+ **셀프 서비스**: 중앙 집중식 플랫폼 팀은 규범적 사용자 지정 리소스를 작성하고 배포하여 일반적인 워크로드 요구 사항에 맞게 클라우드 리소스를 안전하게 셀프 서비스로 제공할 수 있음
+ **클러스터 플릿 관리**: 중앙 집중식 관리 클러스터는 다른 관리자 범위 리소스와 함께 EKS 클러스터 플릿 관리에 대한 고객 소유 컨트롤 플레인을 제공함
+ **규정 준수 요구 사항**: 일부 조직에서는 감사 및 거버넌스를 위한 중앙 집중식 제어가 필요함
+ **운영 복잡성**: 매우 소수의 기능 인스턴스가 작업을 단순화하지만 병목 현상을 생성할 수 있음
**참고**
하나의 패턴으로 시작하여 플랫폼이 성숙해지면 다른 패턴으로 진화할 수 있습니다. 기능은 독립적입니다. 필요에 따라 여러 클러스터에서 서로 다르게 배포할 수 있습니다.
## EKS 기능과 자체 관리형 솔루션 비교
EKS 기능은 EKS에서 실행되는 인기 Kubernetes 도구 및 컨트롤러에 대한 완전관리형 경험을 제공합니다. 이는 클러스터에 설치 및 운영하는 자체 관리형 솔루션과 다릅니다.
### 주요 차이
**배포 및 관리**
AWS는 구성 요소 소프트웨어를 설치, 구성 또는 유지 관리하지 않고도 EKS 기능을 완벽하게 관리합니다. AWS는 클러스터에 필요한 모든 Kubernetes 사용자 지정 리소스 정의(CRD)를 자동으로 설치 및 관리합니다.
자체 관리형 솔루션을 사용하여 헬름 차트, kubectl 또는 기타 연산자를 사용하여 클러스터 소프트웨어를 설치하고 구성합니다. 자체 관리형 솔루션의 소프트웨어 수명 주기 및 런타임 구성을 완벽하게 제어하여 솔루션의 모든 계층에서 사용자 지정을 제공합니다.
**작업 및 유지 관리**
AWS는 자동 업데이트 및 보안 패치를 통해 EKS 기능의 패치 및 기타 소프트웨어 수명 주기 작업을 관리합니다. EKS 기능은 간소화된 구성을 위해 AWS 기능과 통합되고 기본 제공 고가용성 및 내결함성을 제공하며 컨트롤러 워크로드의 클러스터 내 문제 해결을 제거합니다.
자체 관리형 솔루션을 사용하려면 구성 요소 상태 및 로그를 모니터링하고, 보안 패치 및 버전 업데이트를 적용하며, 여러 복제본 및 포드 중단 예산으로 고가용성을 구성하고, 컨트롤러 워크로드 문제를 해결하며, 릴리스 및 버전을 관리해야 합니다. 배포를 완전히 제어할 수 있지만, 프라이빗 클러스터 액세스 및 기타 통합을 위한 맞춤 솔루션이 필요한 경우가 많습니다. 이때 이러한 솔루션은 조직 표준 및 보안 규정 준수 요구 사항에 부합해야 합니다.
**리소스 소비**
EKS 기능은 EKS 내부 및 클러스터 외부에서 실행되므로 노드 리소스와 클러스터 리소스를 확보할 수 있습니다. 기능은 클러스터 워크로드 리소스를 사용하지 않고, 워커 노드에서 CPU 또는 메모리를 사용하지 않으며, 자동으로 조정되고, 클러스터 용량 계획에 미치는 영향을 최소화합니다.
자체 관리형 솔루션은 워커 노드에서 컨트롤러 및 기타 구성 요소를 실행하여 워커 노드 리소스, 클러스터 IP 및 기타 클러스터 리소스를 직접 사용합니다. 클러스터 서비스를 관리하려면 워크로드에 대한 용량 계획이 필요하며, 조정 및 고가용성 요구 사항을 관리하기 위해 리소스 요청 및 제한을 계획하고 구성해야 합니다.
**기능 지원**
완전관리형 서비스 기능인 EKS 기능은 자체 관리형 솔루션과 비교하여 본질적으로 견고합니다. 이 기능은 대부분의 기능 및 사용 사례를 지원하지만 자체 관리형 솔루션과 비교했을 때 적용 범위에 차이가 있습니다.
자체 관리형 솔루션을 사용하면 소프트웨어의 구성, 선택적 기능 및 기타 기능 측면을 완벽하게 제어할 수 있습니다. 자체 사용자 지정 이미지를 실행하고 구성의 모든 측면을 사용자 지정하며 자체 관리형 솔루션 기능을 완전히 제어하도록 선택할 수 있습니다.
**비용 고려 사항**
각 EKS 기능 리소스에는 관련된 시간당 비용이 있으며, 이는 기능 유형에 따라 다릅니다. 기능에서 관리하는 클러스터 리소스에는 자체 요금이 적용되는 관련된 시간당 비용도 있습니다. 자세한 내용은 [Amazon EKS 요금](https://aws.amazon.com/eks/pricing/)을 참조하세요.
자체 관리형 솔루션에는 AWS 요금과 관련된 직접 비용이 없지만, 컨트롤러 및 관련 워크로드에서 사용하는 클러스터 컴퓨팅 리소스에 대한 비용이 청구됩니다. 노드 및 클러스터 리소스 사용 외에도 자체 관리형 솔루션을 사용할 때 전체 소유권 비용에는 운영 오버헤드 그리고 유지 관리, 문제 해결 및 지원과 관련된 비용이 포함됩니다.
### EKS 기능과 자체 관리형 솔루션 중에서 선택
**EKS 기능** 기본 요구 사항에 대한 클러스터 플랫폼 작업 대신, 운영 오버헤드를 줄이고 소프트웨어 및 시스템의 차별화된 가치에 집중하려는 경우 이 선택을 고려합니다. 보안 패치 및 소프트웨어 수명 주기 관리에 관한 운영 부담을 최소화하고, 애플리케이션 워크로드에 대한 노드 및 클러스터 리소스를 확보하며, 구성 및 보안 관리를 단순화하고, AWS 지원 범위를 활용하려는 경우 EKS 기능을 사용합니다. EKS 기능은 대부분의 프로덕션 사용 사례에 적합이며 새 배포에 권장되는 접근 방식입니다.
**자체 관리형 솔루션** 특정 Kubernetes 리소스 API 버전, 사용자 지정 컨트롤러 빌드가 필요하거나 자체 관리형 배포에서 기존 자동화 및 도구를 빌드하거나 컨트롤러 런타임 구성을 심층적으로 사용자 지정해야 하는 경우 이 선택을 고려합니다. 자체 관리형 솔루션은 특수한 사용 사례에 대한 유연성을 제공하며 배포 및 런타임 구성을 완벽하게 제어할 수 있습니다.
**참고**
EKS 기능은 자체 관리형 솔루션과 클러스터에 공존할 수 있으며, 단계별 마이그레이션을 수행할 수 있습니다.
### 기능별 비교
기능별 특성, 업스트림 차이 및 마이그레이션 경로를 포함한 자세한 비교는 다음을 참조하세요.
+ [EKS의 ACK 기능과 자체 관리형 ACK 비교](ack-comparison.md)
+ [Argo CD의 EKS 기능과 자체 관리형 Argo CD 비교](argocd-comparison.md)
+ [kro의 EKS 기능 및 자체 관리형 kro 비교](kro-comparison.md)
# 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 및 권한 구성
# Argo CD를 사용하는 지속적 배포
Argo CD는 Kubernetes에 대한 선언에 기반한 GitOps의 지속적 전송 도구입니다. Argo CD를 사용하면 여러 클러스터 및 환경에서 애플리케이션의 배포 및 수명 주기 관리를 자동화할 수 있습니다. Argo CD는 Git 리포지토리, 헬름 레지스트리(HTTP 및 OCI), OCI 이미지를 비롯한 여러 소스 유형을 지원하므로 보안 및 규정 준수 요구 사항이 서로 다른 조직에 유연성을 제공합니다.
EKS 기능을 사용하면 Argo CD는 AWS에서 완전하게 관리되므로 클러스터에서 Argo CD 컨트롤러 및 해당 종속성을 설치, 유지 관리 및 조정할 필요가 없습니다.
## Argo CD 작동 방식
Argo CD는 GitOps 패턴을 따릅니다. 이때 애플리케이션 소스(Git 리포지토리, 헬름 레지스트리 또는 OCI 이미지)는 원하는 애플리케이션 상태를 정의하기 위한 신뢰할 수 있는 소스입니다. Argo CD `Application` 리소스를 생성할 때 애플리케이션 매니페스트와 대상 Kubernetes 클러스터 및 네임스페이스를 포함하는 소스를 지정합니다. Argo CD는 클러스터의 소스 및 라이브 상태를 지속적으로 모니터링하므로 변경 사항을 자동으로 동기화하여 클러스터 상태가 원하는 상태와 일치하는지 확인합니다.
**참고**
Argo CD의 EKS 기능을 사용하면 Argo CD 소프트웨어는 워커 노드가 아닌 AWS 컨트롤 플레인에서 실행됩니다. 즉, 워커 노드는 Git 리포지토리 또는 헬름 레지스트리에 직접 액세스할 필요가 없습니다. 이 기능은 AWS 계정의 소스 액세스를 처리합니다.
Argo CD는 다음과 같은 세 가지 기본 리소스 유형을 제공합니다.
+ **Application**: Git 리포지토리에서 대상 클러스터로의 배포를 정의함
+ **ApplicationSet**: 다중 클러스터 배포를 위해 템플릿에서 여러 애플리케이션을 생성함
+ **AppProject**: 애플리케이션에 대한 논리적 그룹화 및 액세스 제어를 제공함
**예제: Argo CD 애플리케이션 생성**
다음 예제에서는 Argo CD `Application` 리소스를 생성하는 방법을 보여줍니다.
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
name: in-cluster
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
```
**참고**
클러스터를 등록할 때 사용한 클러스터 이름으로 `destination.name`을 사용합니다(예: 로컬 클러스터의 경우 `in-cluster`). 이 `destination.server` 필드는 EKS 클러스터 ARN에서도 작동하지만 가독성을 높이려면 클러스터 이름을 사용하는 것이 좋습니다.
## Argo CD의 이점
Argo CD는 Git 리포지토리에서 애플리케이션 구성을 정의하는 GitOps 워크플로를 구현하고, Argo CD는 원하는 상태와 일치하도록 애플리케이션을 자동으로 동기화합니다. 이 Git 중심 접근 방식은 모든 변경 사항에 대한 완전한 감사 추적을 제공하고 쉬운 롤배을 지원하며 기존 코드 검토 및 승인 프로세스와 자연스럽게 통합됩니다. Argo CD는 Git의 원하는 상태와 클러스터의 실제 상태 사이의 드리프트를 자동으로 감지하고 조정하여 선언된 구성과 일관되게 배포를 유지합니다.
Argo CD를 사용하면 단일 Argo CD 인스턴스의 여러 클러스터에서 애플리케이션을 배포 및 관리할 수 있으므로 다중 클러스터 및 다중 리전 환경에서 작업을 단순화할 수 있습니다. Argo CD UI는 시각화 및 모니터링 기능을 제공하여 애플리케이션의 배포 상태, 상태 및 기록을 볼 수 있습니다. UI는 원활한 인증 및 권한 부여를 위해 AWS Identity Center(이전의 AWS SSO)에 통합되어 기존 ID 관리 인프라를 사용하여 액세스를 제어할 수 있습니다.
EKS 관리형 기능의 일환으로 Argo CD는 AWS에서 완전하게 관리되므로 Argo CD 인프라를 설치, 구성 및 유지 관리할 필요가 없습니다. AWS에서 조정, 패치 적용 및 운영 관리를 처리하므로 팀은 도구 유지 관리가 아닌 애플리케이션 제공에 집중할 수 있습니다.
## AWS Identity Center와 통합
EKS 관리형 기능은 Argo CD와 AWS Identity Center 간 직접 통합을 제공하여 사용자에게 원활한 인증 및 권한 부여를 지원합니다. Argo CD 기능을 활성화하면 Identity Center 그룹 및 사용자를 Argo CD RBAC 역할에 매핑하도록 AWS Identity Center 통합을 구성하여 Argo CD에서 애플리케이션에 액세스하고 이를 관리할 수 있는 사용자를 제어할 수 있습니다.
## 다른 EKS 관리형 기능과 통합
Argo CD는 다른 EKS 관리형 기능과 통합됩니다.
+ ** AWS Controllers for Kubernetes(ACK)**: Argo CD를 사용하여 여러 클러스터에서 ACK 리소스 배포를 관리하여 AWS 인프라에 대한 GitOps 워크플로를 지원합니다.
+ **Kube Resource Orchestrator(kro)**: Argo CD를 사용하여 여러 클러스터에 kro 구성을 배포하므로 Kubernetes 자산 전반에서 일관된 리소스 구성을 사용할 수 있습니다.
## Argo CD 시작하기
Argo CD의 EKS 기능을 시작하는 방법:
1. Argo CD가 소스에 액세스하고 애플리케이션을 관리하는 데 필요한 권한이 있는 IAM 기능 역할을 생성 및 구성하세요.
1. AWS 콘솔, AWS CLI 또는 기본 코드형 인프라를 통해 EKS 클러스터에서 [Argo CD 기능 리소스를 생성](create-argocd-capability.md)하세요.
1. 리포지토리 액세스를 구성하고 애플리케이션 배포를 위해 클러스터를 등록하세요.
1. 선언적 소스에서 애플리케이션을 배포하기 위한 Application 리소스를 생성하세요.
# Argo CD 기능 생성
이 주제에서는 Amazon EKS 클러스터에서 Argo CD 기능을 생성하는 방법을 설명합니다.
## 사전 조건
Argo CD 기능을 생성하기 전에 다음이 있는지 확인합니다.
+ 지원되는 Kubernetes 버전(표준 및 확장 지원의 모든 버전이 지원됨)을 실행하는 기존 Amazon EKS 클러스터
+ **구성된 AWS Identity Center** - Argo CD 인증에 필요(로컬 사용자는 지원되지 않음)
+ Argo CD에 대한 권한이 있는 IAM 기능 역할
+ EKS 클러스터에서 기능 리소스를 생성할 수 있는 충분한 IAM 권한
+ 클러스터와 통신하도록 구성된 `kubectl`
+ (선택 사항) 더 쉬운 클러스터 및 리포지토리 관리를 위해 설치된 Argo CD CLI
+ (CLI/eksctl의 경우) 설치 및 구성된 적절한 CLI 도구
IAM 기능 역할을 생성하는 방법에 대한 지침은 [Amazon EKS 기능 IAM 역할](capability-role.md) 섹션을 참조하세요. Identity Center 설정에 대한 자세한 내용은 [Getting started with AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)를 참조하세요.
**중요**
사용자가 제공하는 IAM 기능 역할에 따라 Argo CD에서 액세스할 수 있는 AWS 리소스가 결정됩니다. 여기에는 CodeConnections를 통한 Git 리포지토리 액세스와 Secrets Manager의 보안 암호가 포함됩니다. 최소 권한으로 적절한 역할을 생성하는 방법에 대한 지침은 [Amazon EKS 기능 IAM 역할](capability-role.md) 및 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.
## 도구 선택
AWS Management Console, AWS CLI 또는 eksctl을 사용하여 Argo CD 기능을 생성할 수 있습니다.
+ [콘솔을 사용하여 Argo CD 기능 생성](argocd-create-console.md) - 안내 경험을 이용하려면 콘솔 사용
+ [AWS CLI를 사용하여 Argo CD 기능 생성](argocd-create-cli.md) -스크립트 및 자동화를 이용하려면 AWS CLI 사용
+ [eksctl 사용 시 Argo CD 기능 생성](argocd-create-eksctl.md) - Kubernetes 네이티브 경험을 이용하려면 eksctl 사용
## Argo CD 기능을 생성할 때 상황
Argo CD 기능을 생성할 때:
1. EKS는 AWS 컨트롤 플레인에서 Argo CD 기능 서비스를 생성함
1. 사용자 지정 리소스 정의(CRD)가 클러스터에 설치됨
1. 기준 Kubernetes 권한을 부여하는 기능별 액세스 항목 정책을 사용하여 IAM 기능 역할에 대한 액세스 항목이 자동으로 생성됨([EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 참조)
1. Argo CD에서 사용자 지정 리소스(Applications, ApplicationSets, AppProjects) 감시를 시작함
1. 기능 상태가 `CREATING`에서 `ACTIVE`로 변경됨
1. 해당 URL을 통해 Argo CD UI에 액세스할 수 있음
활성 상태가 되면 클러스터에서 Argo CD 애플리케이션을 생성하여 선언적 소스에서 배포할 수 있습니다.
**참고**
자동으로 생성된 액세스 항목은 클러스터에 애플리케이션을 배포하기 위한 권한을 부여하지 않습니다. 애플리케이션을 배포하려면 각 대상 클러스터에 대해 추가 Kubernetes RBAC 권한을 구성해야 합니다. 클러스터 등록 및 액세스 구성에 대한 자세한 내용은 [대상 클러스터 등록](argocd-register-clusters.md) 섹션을 참조하세요.
## 다음 단계
Argo CD 기능을 생성한 후:
+ [Argo CD 개념](argocd-concepts.md) - GitOps 원칙, 동기화 정책, 다중 클러스터 패턴에 대해 알아보기
+ [Argo CD 작업](working-with-argocd.md) - 리포지토리 액세스 구성, 대상 클러스터 등록, 애플리케이션 생성
+ [Argo CD 고려 사항](argocd-considerations.md) - 다중 클러스터 아키텍처 패턴 및 고급 구성 살펴보기
# 콘솔을 사용하여 Argo CD 기능 생성
이 주제에서는 AWS Management Console을 사용하여 Argo CD 기능을 생성하는 방법을 설명합니다.
## 사전 조건
+ **구성된 AWS Identity Center** - Argo CD에는 인증을 위해 AWS Identity Center가 필요합니다. 로컬 사용자는 지원되지 않습니다. AWS Identity Center를 설정하지 않은 경우 [Getting started with AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)를 참조하여 Identity Center 인스턴스를 생성하고 [사용자 추가](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) 및 [그룹 추가](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)를 통해 Argo CD 액세스를 위한 사용자 및 그룹을 생성합니다.
## Argo CD 기능 생성
1. https://console.aws.amazon.com/eks/home\$1/clusters에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하여 클러스터 세부 정보 페이지를 여세요.
1. **기능** 탭을 선택하세요.
1. 왼쪽 탐색에서 **Argo CD**를 선택하세요.
1. **Argo CD 기능 생성**을 선택하세요.
1. **IAM 기능 역할**의 경우:
+ IAM 기능 역할이 이미 있는 경우 드롭다운 선택
+ 새 역할을 생성해야 하는 경우 **새 Argo CD 역할 생성** 선택
그러면 Secrets Manager에 대한 전체 읽기 액세스 권한과 함께 신뢰 정책이 미리 채워진 새 탭에서 IAM 콘솔이 열립니다. 다른 권한은 기본적으로 추가되지 않지만 필요한 경우 추가할 수 있습니다. CodeCommit 리포지토리 또는 기타 AWS 서비스를 사용하려는 경우 역할을 생성하기 전에 적절한 권한을 추가합니다.
역할을 생성한 후 EKS 콘솔로 돌아가면 역할이 자동으로 선택됩니다.
**참고**
AWS Secrets Manager 또는 AWS CodeConnections와의 선택적 통합을 사용하려는 경우 역할에 권한을 추가해야 합니다. IAM 정책 예제 및 구성 지침은 [AWS Secrets Manager를 사용하여 애플리케이션 보안 암호 관리](integration-secrets-manager.md) 및 [AWS CodeConnections를 사용하여 Git 리포지토리에 연결](integration-codeconnections.md) 섹션을 참조하세요.
1. AWS Identity Center 통합을 구성하세요.
1. **AWS Identity Center 통합 활성화**를 선택하세요.
1. 드롭다운에서 Identity Center 인스턴스를 선택하세요.
1. Argo CD 역할(ADMIN, EDITOR 또는 VIEWER)에 사용자 또는 그룹을 할당하여 RBAC에 대한 역할 매핑을 구성하세요.
1. **생성(Create)**을 선택합니다.
기능 생성 프로세스가 시작됩니다.
## 기능이 활성 상태인지 확인
1. **기능** 탭에서 Argo CD 기능 상태를 확인하세요.
1. 상태가 `CREATING`에서 `ACTIVE`로 변경될 때까지 기다리세요.
1. 활성 상태가 되면 기능을 사용할 준비가 된 것입니다.
기능 상태 및 문제 해결에 대한 자세한 내용은 [기능 리소스 작업](working-with-capabilities.md) 섹션을 참조하세요.
## Argo CD UI에 액세스
기능이 활성 상태가 되면 Argo CD UI에 액세스할 수 있습니다.
1. Argo CD 기능 페이지에서 **Argo CD UI 열기**를 선택하세요.
1. Argo CD UI가 새 브라우저 탭에서 열립니다.
1. 이제 UI를 통해 애플리케이션을 생성하고 배포를 관리할 수 있습니다.
## 다음 단계
+ [Argo CD 작업](working-with-argocd.md) - 리포지토리 구성, 클러스터 등록, 애플리케이션 생성
+ [Argo CD 고려 사항](argocd-considerations.md) - 다중 클러스터 아키텍처 및 고급 구성
+ [기능 리소스 작업](working-with-capabilities.md) - Argo CD 기능 리소스 관리
# AWS CLI를 사용하여 Argo CD 기능 생성
이 주제에서는 AWS CLI를 사용하여 Argo CD 기능을 생성하는 방법을 설명합니다.
## 사전 조건
+ **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) 섹션을 참조하세요.
+ **구성된 AWS Identity Center** - Argo CD에는 인증을 위해 AWS Identity Center가 필요합니다. 로컬 사용자는 지원되지 않습니다. AWS Identity Center를 설정하지 않은 경우 [Getting started with AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)를 참조하여 Identity Center 인스턴스를 생성하고 [사용자 추가](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) 및 [그룹 추가](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)를 통해 Argo CD 액세스를 위한 사용자 및 그룹을 생성합니다.
## 1단계: IAM 기능 역할 생성
신뢰 정책 파일을 생성합니다.
```
cat > argocd-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 ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**참고**
AWS Secrets Manager 또는 AWS CodeConnections와의 선택적 통합을 사용하려는 경우 역할에 권한을 추가해야 합니다. IAM 정책 예제 및 구성 지침은 [AWS Secrets Manager를 사용하여 애플리케이션 보안 암호 관리](integration-secrets-manager.md) 및 [AWS CodeConnections를 사용하여 Git 리포지토리에 연결](integration-codeconnections.md) 섹션을 참조하세요.
## 2단계: Argo CD 기능 생성
클러스터에서 Argo CD 기능 리소스를 생성합니다.
먼저 Identity Center 구성에 대한 환경 변수를 설정합니다.
```
# Get your Identity Center instance ARN (replace region if your IDC instance is in a different region)
export IDC_INSTANCE_ARN=$(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].InstanceArn' --output text)
# Get a user ID for RBAC mapping (replace with your username and region if needed)
export IDC_USER_ID=$(aws identitystore list-users \
--region [.replaceable]`region` \
--identity-store-id $(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text)
echo "IDC_INSTANCE_ARN=$IDC_INSTANCE_ARN"
echo "IDC_USER_ID=$IDC_USER_ID"
```
Identity Center 통합을 사용하여 기능을 생성합니다. *region-code*를 클러스터가 위치한 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꾸며 *idc-region-code*를 IAM Identity Center가 구성된 리전 코드로 바꿉니다.
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--type ARGOCD \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ArgoCDCapabilityRole \
--delete-propagation-policy RETAIN \
--configuration '{
"argoCd": {
"awsIdc": {
"idcInstanceArn": "'$IDC_INSTANCE_ARN'",
"idcRegion": "'[.replaceable]`idc-region-code`'"
},
"rbacRoleMappings": [{
"role": "ADMIN",
"identities": [{
"id": "'$IDC_USER_ID'",
"type": "SSO_USER"
}]
}]
}
}'
```
명령은 즉시 반환되지만, 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-argocd \
--query 'capability.status' \
--output text
```
상태가 `ACTIVE`로 표시되면 기능이 준비된 것입니다. `ACTIVE` 상태가 되면 다음 단계를 계속하지 마세요.
전체 기능 세부 정보를 볼 수도 있습니다.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd
```
## 4단계: 사용자 지정 리소스를 사용할 수 있는지 확인
기능이 활성 상태가 되면 클러스터에서 Argo CD 사용자 지정 리소스를 사용할 수 있는지 확인합니다.
```
kubectl api-resources | grep argoproj.io
```
`Application` 및 `ApplicationSet` 리소스 유형이 나열됩니다.
## 다음 단계
+ [Argo CD 작업](working-with-argocd.md) - 리포지토리 구성, 클러스터 등록, 애플리케이션 생성
+ [Argo CD 고려 사항](argocd-considerations.md) - 다중 클러스터 아키텍처 및 고급 구성
+ [기능 리소스 작업](working-with-capabilities.md) - Argo CD 기능 리소스 관리
# eksctl 사용 시 Argo CD 기능 생성
이 주제에서는 eksctl을 사용하여 Argo CD 기능을 생성하는 방법을 설명합니다.
**참고**
다음 단계에서는 eksctl 버전 `0.220.0` 이상이 필요합니다. 버전을 확인하려면 `eksctl version`을 실행합니다.
## 1단계: IAM 기능 역할 생성
신뢰 정책 파일을 생성합니다.
```
cat > argocd-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 ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**참고**
이 기본 설정에는 추가 IAM 정책이 필요하지 않습니다. 리포지토리 자격 증명 또는 CodeConnections에 Secrets Manager를 사용하려는 경우 역할에 권한을 추가해야 합니다. IAM 정책 예제 및 구성 지침은 [AWS Secrets Manager를 사용하여 애플리케이션 보안 암호 관리](integration-secrets-manager.md) 및 [AWS CodeConnections를 사용하여 Git 리포지토리에 연결](integration-codeconnections.md) 섹션을 참조하세요.
## 2단계: AWS Identity Center 구성 가져오기
RBAC 구성을 위해 Identity Center 인스턴스 ARN 및 사용자 ID를 가져옵니다.
```
# Get your Identity Center instance ARN
aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text
# Get a user ID for admin access (replace 'your-username' with your Identity Center username)
aws identitystore list-users \
--identity-store-id $(aws sso-admin list-instances --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text
```
이 값을 기록합니다. 다음 단계에 해당 값이 필요합니다.
## 3단계: eksctl 구성 파일 생성
다음 콘텐츠가 포함된 `argocd-capability.yaml`이라는 파일을 생성합니다. 자리 표시자 값을 클러스터 이름, 리전, IAM 역할 ARN, Identity Center 인스턴스 ARN, Identity Center 리전 및 사용자 ID로 바꿉니다.
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: cluster-region-code
capabilities:
- name: my-argocd
type: ARGOCD
roleArn: arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole
deletePropagationPolicy: RETAIN
configuration:
argocd:
awsIdc:
idcInstanceArn: arn:aws:sso:::instance/ssoins-123abc
idcRegion: idc-region-code
rbacRoleMappings:
- role: ADMIN
identities:
- id: 38414300-1041-708a-01af-5422d6091e34
type: SSO_USER
```
**참고**
RBAC 매핑에 여러 사용자 또는 그룹을 추가할 수 있습니다. 그룹의 경우 `type: SSO_GROUP`을 사용하고 그룹 ID를 제공합니다. 사용 가능한 역할은 `ADMIN`, `EDITOR` 및 `VIEWER`입니다.
## 4단계: Argo CD 기능 생성
구성 파일을 적용합니다.
```
eksctl create capability -f argocd-capability.yaml
```
명령은 즉시 반환되지만 기능이 활성 상태가 되려면 다소 시간이 걸립니다.
## 5단계: 기능이 활성 상태인지 확인
기능 상태를 확인합니다. *region-code*를 클러스터를 생성한 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꿉니다.
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-argocd
```
상태가 `ACTIVE`로 표시되면 기능이 준비된 것입니다.
## 6단계: 사용자 지정 리소스를 사용할 수 있는지 확인
기능이 활성 상태가 되면 클러스터에서 Argo CD 사용자 지정 리소스를 사용할 수 있는지 확인합니다.
```
kubectl api-resources | grep argoproj.io
```
`Application` 및 `ApplicationSet` 리소스 유형이 나열됩니다.
## 다음 단계
+ [Argo CD 작업](working-with-argocd.md) - Argo CD 애플리케이션을 생성하고 관리하는 방법 알아보기
+ [Argo CD 고려 사항](argocd-considerations.md) - SSO 및 다중 클러스터 액세스 구성
+ [기능 리소스 작업](working-with-capabilities.md) - Argo CD 기능 리소스 관리
# Argo CD 개념
Argo CD는 Git을 애플리케이션 배포의 신뢰할 수 있는 단일 소스로 처리하여 GitOps를 구현합니다. 이 주제에서는 실제 예제를 살펴본 다음 Argo CD의 EKS 기능을 사용할 때 알아야 하는 핵심 개념을 설명합니다.
## Argo CD 시작하기
Argo CD 기능을 생성한 후([Argo CD 기능 생성](create-argocd-capability.md) 참조) 애플리케이션 배포를 시작할 수 있습니다. 이 예제에서는 클러스터를 등록하고 애플리케이션을 생성하는 방법을 안내합니다.
### 1단계: 설정
**클러스터 등록**(필수)
애플리케이션을 배포할 클러스터를 등록합니다. 이 예제에서는 Argo CD가 실행 중인 동일한 클러스터를 등록합니다(대부분의 Argo CD 예제와 호환 가능하도록 `in-cluster` 이름 사용).
```
# Get your cluster ARN
CLUSTER_ARN=$(aws eks describe-cluster \
--name my-cluster \
--query 'cluster.arn' \
--output text)
# Register the cluster using Argo CD CLI
argocd cluster add $CLUSTER_ARN \
--aws-cluster-name $CLUSTER_ARN \
--name in-cluster \
--project default
```
**참고**
EKS에서 Argo CD 기능을 사용하도록 Argo CD CLI를 구성하는 방법에 대한 자세한 내용은 [관리형 기능과 함께 Argo CD CLI 사용](argocd-comparison.md#argocd-cli-configuration) 섹션을 참조하세요.
또는 Kubernetes 보안 암호를 사용하여 클러스터를 등록합니다(자세한 내용은 [대상 클러스터 등록](argocd-register-clusters.md) 참조).
**리포지토리 액세스 구성**(선택 사항)
이 예제에서는 퍼블릭 GitHub 리포지토리를 사용하므로 리포지토리 구성이 필요하지 않습니다. 프라이빗 리포지토리의 경우 AWS Secrets Manager, CodeConnections 또는 Kubernetes 보안 암호를 사용하여 액세스를 구성합니다(자세한 내용은 [리포지토리 액세스 구성](argocd-configure-repositories.md) 참조).
AWS 서비스(헬름 차트, CodeConnections 및 CodeCommit에 대한 ECR)의 경우 리포지토리를 생성하지 않고도 애플리케이션 리소스에서 직접 참조할 수 있습니다. 용량 역할에는 필요한 IAM 권한이 있어야 합니다. 세부 정보는 [리포지토리 액세스 구성](argocd-configure-repositories.md) 섹션을 참조하세요.
### 단계 2: 애플리케이션 만들기
`my-app.yaml`에서 이 애플리케이션 매니페스트를 생성합니다.
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
name: in-cluster
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
```
애플리케이션을 적용합니다.
```
kubectl apply -f my-app.yaml
```
이 애플리케이션을 적용한 후 Argo CD에서 다음을 수행합니다. 1. Git에서 클러스터로 애플리케이션 동기화(초기 배포) 2. Git 리포지토리에서 변경 사항 모니터링 3. 후속 변경 사항을 클러스터와 자동으로 동기화 4. 원하는 상태에서 드리프트 감지 및 수정 5. UI에서 상태 및 동기화 기록 제공
애플리케이션 상태를 봅니다.
```
kubectl get application guestbook -n argocd
```
또한 Argo CD CLI 또는 Argo CD UI(EKS 콘솔의 클러스터의 기능 탭 아래에서 액세스 가능)를 사용하여 애플리케이션을 볼 수도 있습니다.
**참고**
관리형 기능과 함께 Argo CD CLI를 사용하는 경우 네임스페이스 접두사가 `argocd app get argocd/guestbook`인 애플리케이션을 지정합니다.
**참고**
`destination.name`에서 클러스터 이름(클러스터를 등록할 때 사용한 이름)을 사용합니다. 관리형 기능은 로컬 클러스터 내 기본값(`kubernetes.default.svc`)을 지원하지 않습니다.
## 핵심 개념
### GitOps 원칙 및 소스 유형
Argo CD는 GitOps를 구현합니다. 여기서 애플리케이션 소스는 배포를 위한 신뢰할 수 있는 단일 소스입니다.
+ **선언적** - 원하는 상태는 YAML 매니페스트, 헬름 차트 또는 Kustomize 오버레이를 사용하여 선언됨
+ **버전 관리됨** - 모든 변경 사항은 전체 감사 추적을 통해 추적됨
+ **자동화됨** - Argo CD가 소스를 지속적으로 모니터링하고 변경 사항을 자동으로 동기화함
+ **자가 복구** - 원하는 클러스터 상태와 실제 클러스터 상태 사이의 드리프트를 감지하고 수정함
**지원되는 소스 유형**:
+ **Git 리포지토리** - GitHub, GitLab, Bitbucket, CodeCommit(HTTPS, SSH 또는 CodeConnections)
+ **헬름 레지스트리** - HTTP 레지스트리(예: `https://aws.github.io/eks-charts`) 및 OCI 레지스트리(예: `public.ecr.aws`)
+ **OCI 이미지** - 매니페스트 또는 헬름 차트가 포함된 컨테이너 이미지(예: `oci://registry-1.docker.io/user/my-app`)
이러한 유연성을 통해 조직은 보안 및 규정 준수 요구 사항을 충족하는 소스를 선택할 수 있습니다. 예를 들어 클러스터에서 Git 액세스를 제한하는 조직은 헬름 차트 또는 OCI 이미지에 ECR을 사용할 수 있습니다.
자세한 내용은 Argo CD 설명서의 [Application Sources](https://argo-cd.readthedocs.io/en/stable/user-guide/application-sources/)를 참조하세요.
### 동기화 및 조정
Argo CD는 소스와 클러스터를 지속적으로 모니터링하여 차이를 감지하고 수정합니다.
1. 변경 사항에 대한 소스 폴링(기본값: 6분마다)
1. 원하는 상태를 클러스터 상태와 비교
1. 애플리케이션을 `Synced` 또는 `OutOfSync`로 표시
1. 변경 사항을 자동으로 동기화하거나(구성된 경우) 수동 승인 대기
1. 동기화 후 리소스 상태 모니터링
**웨이브 동기화**는 주석을 사용하여 리소스 생성 순서를 제어합니다.
```
metadata:
annotations:
argocd.argoproj.io/sync-wave: "0" # Default if not specified
```
리소스는 웨이브 순서(`-1`과 같은 음수를 포함하여 작은 숫자부터)로 적용됩니다. 지정하지 않으면 Wave `0`이 기본값입니다. 이를 통해 서비스(wave `1`) 이전의 배포(wave `0`)보다 이전에 네임스페이스(wave `-1`)와 같은 종속성을 생성할 수 있습니다.
**자가 복구**는 수동 변경 사항을 자동으로 되돌립니다.
```
spec:
syncPolicy:
automated:
selfHeal: true
```
**참고**
관리형 기능은 Kubernetes 규칙 및 기타 도구와의 호환성 개선을 위해 주석 기반 리소스 추적(레이블 기반이 아님)을 사용합니다.
동기화 단계, 후크 및 고급 패턴에 대한 자세한 내용은 [Argo CD sync 설명서](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/)를 참조하세요.
### 애플리케이션 상태
Argo CD는 애플리케이션에 있는 모든 리소스의 상태를 모니터링합니다.
**상태**: \$1 **정상** - 모든 리소스가 예상대로 실행 중임 \$1 **진행 중** - 리소스가 생성 또는 업데이트 중임 \$1 **성능 저하됨** - 일부 리소스가 정상이 아님(포드 충돌, 작업 실패) \$1 **일시 중단됨** - 애플리케이션이 의도적으로 일시 중지됨 \$1 **누락** - Git에 정의된 리소스가 클러스터에 없음
Argo CD는 일반적인 Kubernetes 리소스(배포, StatefulSets, 작업 등)에 대한 기본 제공 상태 확인 기능을 보유하며, CRD에 대한 사용자 지정 상태 확인을 지원합니다.
애플리케이션 상태는 모든 리소스에 의해 결정됩니다. 리소스가 `Degraded`인 경우 애플리케이션은 `Degraded`입니다.
자세한 내용은 Argo CD 설명서의 [Resource Health](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/)를 참조하세요.
### 다중 클러스터 패턴
Argo CD는 다음과 같은 두 가지 주요 배포 패턴을 지원합니다.
**허브 및 스포크** 여러 워크로드 클러스터에 배포되는 전용 관리 클러스터에서 Argo CD 실행: \$1 중앙 집중식 제어 및 가시성 \$1 모든 클러스터에서 일관된 정책 \$1 관리할 하나의 Argo CD 인스턴스 \$1 컨트롤 플레인과 워크로드 간 명확한 분리
**클러스터별** - 각 클러스터에서 Argo CD를 실행하여 해당 클러스터의 애플리케이션만 관리: \$1 클러스터 분리(한 곳의 장애는 다른 곳에 영향을 주지 않음) \$1 보다 간단한 네트워킹(클러스터 간 통신 없음) \$1 보다 쉬운 초기 설정(클러스터 등록 없음)
많은 클러스터를 관리하는 플랫폼 팀의 경우 허브 및 스포크를 선택하거나 독립된 팀이나 클러스터가 완전히 격리되어야 하는 경우 클러스터별 방법을 선택합니다.
자세한 다중 클러스터 구성은 [Argo CD 고려 사항](argocd-considerations.md) 섹션을 참조하세요.
### Projects
프로젝트는 애플리케이션에 대한 논리적 그룹화 및 액세스 제어를 제공합니다.
+ **소스 제한 사항** - 사용할 수 있는 Git 리포지토리 제한
+ **대상 제한 사항** - 대상으로 지정할 수 있는 클러스터 및 네임스페이스 제한
+ **리소스 제한 사항** - 배포할 수 있는 Kubernetes 리소스 유형 제한
+ **RBAC 통합** - AWS Identity Center 사용자 및 그룹 ID에 프로젝트 매핑
애플리케이션은 단일 프로젝트에 속해 있습니다. 지정하지 않으면 `default` 프로젝트(기본적으로 제한 사항 없음)를 사용합니다. 프로덕션에서 사용하는 경우 액세스를 제한하고 적절한 제한 사항으로 새 프로젝트를 생성하도록 `default` 프로젝트를 편집합니다.
프로젝트 구성 및 RBAC 패턴은 [Argo CD 권한 구성](argocd-permissions.md) 섹션을 참조하세요.
### 동기화 옵션
일반적인 옵션을 사용하여 동기화 동작을 미세 조정합니다.
+ `CreateNamespace=true` - 대상 네임스페이스 자동 생성
+ `ServerSideApply=true` - 더 나은 충돌 해결을 위해 서버 측 적용 사용
+ `SkipDryRunOnMissingResource=true` - CRD가 아직 없을 때 모의 실행 건너뛰기(kro 인스턴스에 유용함)
```
spec:
syncPolicy:
syncOptions:
- CreateNamespace=true
- ServerSideApply=true
- SkipDryRunOnMissingResource=true
```
동기화 옵션의 전체 목록은 [Argo CD sync options 설명서](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/)를 참조하세요.
## 다음 단계
+ [리포지토리 액세스 구성](argocd-configure-repositories.md) - Git 리포지토리 액세스 구성
+ [대상 클러스터 등록](argocd-register-clusters.md) - 배포에 대한 대상 클러스터 등록
+ [애플리케이션 생성](argocd-create-application.md) - 첫 번째 애플리케이션 생성
+ [Argo CD 고려 사항](argocd-considerations.md) - EKS 특정 패턴, Identity Center 통합 및 다중 클러스터 구성
+ [Argo CD 설명서](https://argo-cd.readthedocs.io/en/stable/) - 동기화 후크, 상태 확인 및 고급 패턴을 포함하는 포괄적인 Argo CD 설명서
# Argo CD 권한 구성
Argo CD 관리형 기능은 인증을 위해 AWS Identity Center와 통합되며 권한 부여를 위해 기본 제공 RBAC 역할을 사용합니다. 이 주제에서는 사용자 및 팀에 대한 권한을 구성하는 방법을 설명합니다.
## Argo CD에서 권한이 작동하는 방식
Argo CD 기능은 인증에 AWS Identity Center를 사용하고 권한 부여에 세 가지 기본 제공 RBAC 역할을 제공합니다.
사용자가 Argo CD에 액세스하는 경우:
1. 사용자는 AWS Identity Center(기업 ID 제공업체에 페더레이션할 수 있음)를 사용하여 인증함
1. AWS Identity Center는 Argo CD에 사용자 및 그룹 정보를 제공함
1. Argo CD는 사용자 구성을 기반으로 사용자 및 그룹을 RBAC 역할에 매핑함
1. 사용자는 액세스 권한이 있는 애플리케이션 및 리소스만 볼 수 있음
## 기본 제공 RBAC 역할
Argo CD 기능은 AWS Identity Center 사용자 및 그룹에 매핑하는 세 가지 기본 제공 역할을 제공합니다. 이는 프로젝트, 클러스터 및 리포지토리와 같은 Argo CD 리소스에 대한 액세스를 제어하는 **글로벌 범위의 역할**입니다.
**중요**
글로벌 역할은 애플리케이션과 같은 프로젝트 범위의 리소스가 아닌 Argo CD 자체에 대한 액세스를 제어합니다. EDITOR 및 VIEWER 사용자는 기본적으로 애플리케이션을 보거나 관리할 수 없으며, 프로젝트 범위의 리소스에 액세스하려면 프로젝트 역할이 필요합니다. 애플리케이션 및 기타 프로젝트 범위의 리소스 관련 액세스 권한 부여에 대한 자세한 내용은 [프로젝트 역할 및 프로젝트 범위 액세스](#project-roles) 섹션을 참조하세요.
**ADMIN**
모든 Argo CD 리소스 및 설정에 대한 전체 액세스:
+ Applications 및 ApplicationSets의 생성, 업데이트, 삭제
+ Argo CD 구성 관리
+ 배포 대상 클러스터 등록 및 관리
+ 리포지토리 액세스 구성
+ 프로젝트 생성 및 관리
+ 모든 애플리케이션 상태 및 기록 보기
+ 모든 클러스터 및 리포지토리의 나열 및 액세스
**EDITOR**
프로젝트를 업데이트하고 프로젝트 역할을 구성할 수 있지만 글로벌 Argo CD 설정은 변경할 수 없습니다.
+ 기존 프로젝트 업데이트(프로젝트를 생성하거나 삭제할 수 없음)
+ 프로젝트 역할 및 권한 구성
+ GPG 키 및 인증서 보기
+ 글로벌 Argo CD 구성을 변경할 수 없음
+ 클러스터 또는 리포지토리를 직접 관리할 수 없음
+ 프로젝트 역할 없이 애플리케이션을 보거나 관리할 수 없음
**VIEWER**
Argo CD 리소스에 대한 읽기 전용 액세스 권한:
+ 프로젝트 구성 보기
+ 모든 프로젝트(사용자가 할당되지 않은 프로젝트 포함) 나열
+ GPG 키 및 인증서 보기
+ 클러스터 또는 리포지토리를 나열할 수 없음
+ 변경할 수 없음
+ 프로젝트 역할 없이 애플리케이션을 보거나 관리할 수 없음
**참고**
EDITOR 또는 VIEWER 사용자에게 애플리케이션에 대한 액세스 권한을 부여하려면 ADMIN 또는 EDITOR가 Identity Center 그룹을 프로젝트 내 특정 권한에 매핑하는 프로젝트 역할을 생성해야 합니다.
## 프로젝트 역할 및 프로젝트 범위 액세스
글로벌 역할(ADMIN, EDITOR, VIEWER)은 Argo CD 자체에 대한 액세스를 제어합니다. 프로젝트 역할은 다음을 포함하여 특정 프로젝트 내 리소스 및 기능에 대한 액세스를 제어합니다.
+ **리소스**: 애플리케이션, ApplicationSets, 리포지토리 자격 증명, 클러스터 자격 증명
+ **기능**: 로그 액세스, 애플리케이션 포드에 대한 실행 액세스
**2단계 권한 모델 이해**:
+ **글로벌 범위**: 기본 제공 역할은 사용자가 프로젝트, 클러스터, 리포지토리 및 Argo CD 설정으로 수행할 수 있는 작업을 결정함
+ **프로젝트 범위**: 프로젝트 역할은 사용자가 특정 프로젝트 내 리소스 및 기능으로 수행할 수 있는 작업을 결정함
이는 다음을 의미합니다.
+ ADMIN 사용자는 추가 구성 없이 모든 프로젝트 리소스 및 기능에 액세스할 수 있음
+ 프로젝트 리소스 및 기능에 액세스하려면 EDITOR 및 VIEWER 사용자에게 프로젝트 역할을 부여해야 함
+ EDITOR 사용자는 이들이 업데이트할 수 있는 프로젝트 내에서 자신과 다른 사용자에게 액세스 권한을 부여하기 위해 프로젝트 역할을 생성할 수 있음
**워크플로 예제**:
1. ADMIN은 Identity Center 그룹을 글로벌 범위에서 EDITOR 역할에 매핑함
1. ADMIN은 팀에서 프로젝트를 생성함
1. EDITOR는 팀원에게 프로젝트 범위의 리소스에 대한 액세스 권한을 부여하도록 해당 프로젝트 내에서 프로젝트 역할을 구성함
1. 이제 팀원(VIEWER 글로벌 역할이 있을 수 있음)은 프로젝트 역할 권한을 기반으로 해당 프로젝트의 애플리케이션을 보고 관리할 수 있음
프로젝트 역할 구성에 대한 자세한 내용은 [프로젝트 기반 액세스 제어](#_project_based_access_control) 섹션을 참조하세요.
## 역할 매핑 구성
기능을 생성하거나 업데이트할 때 AWS Identity Center 사용자 및 그룹을 Argo CD 역할에 매핑합니다.
**역할 매핑 예제**:
```
{
"rbacRoleMapping": {
"ADMIN": ["AdminGroup", "alice@example.com"],
"EDITOR": ["DeveloperGroup", "DevOpsTeam"],
"VIEWER": ["ReadOnlyGroup", "bob@example.com"]
}
}
```
**참고**
역할 이름은 대소문자를 구분하며 대문자(ADMIN, EDITOR, VIEWER)여야 합니다.
**중요**
AWS Identity Center와의 EKS 기능 통합은 Argo CD 기능당 최대 1,000개의 ID를 지원합니다. ID는 사용자 또는 그룹일 수 있습니다.
**역할 매핑 업데이트**:
```
aws eks update-capability \
--region us-east-1 \
--cluster-name cluster \
--capability-name capname \
--endpoint "https://eks.ap-northeast-2.amazonaws.com" \
--role-arn "arn:aws:iam::[.replaceable]111122223333:role/[.replaceable]`EKSCapabilityRole`" \
--configuration '{
"argoCd": {
"rbacRoleMappings": {
"addOrUpdateRoleMappings": [
{
"role": "ADMIN",
"identities": [
{ "id": "686103e0-f051-7068-b225-e6392b959d9e", "type": "SSO_USER" }
]
}
]
}
}
}'
```
## 관리자 계정 사용
관리자 계정은 클러스터 등록 및 리포지토리 구성과 같은 초기 설정 및 관리 태스크를 위해 설계되었습니다.
**관리자 계정이 적절한 경우**:
+ 초기 기능 설정 및 구성
+ 단독 개발 또는 빠른 데모
+ 관리 태스크(클러스터 등록, 리포지토리 구성, 프로젝트 생성)
**관리자 계정의 모범 사례**:
+ 버전 관리에 계정 토큰을 커밋하지 않음
+ 공개된 경우 즉시 토큰 교체
+ 계정 토큰 사용을 설정 및 관리 태스크로 제한
+ 짧은 만료 시간 설정(최대 12시간)
+ 지정된 시점에서 한 번에 5개의 계정 토큰만 생성할 수 있음
**대신 프로젝트 기반 액세스를 사용해야 하는 경우**:
+ 여러 사용자와 공유된 개발 환경
+ 프로덕션과 유사한 모든 환경
+ 작업을 수행한 사람에 대한 감사 추적이 필요한 경우
+ 리소스 제한 사항 또는 액세스 경계를 적용해야 하는 경우
프로덕션 환경 및 다중 사용자 시나리오의 경우 AWS Identity Center 그룹에 매핑된 전용 RBAC 역할과 함께 프로젝트 기반 액세스 제어를 사용합니다.
## 프로젝트 기반 액세스 제어
Argo CD 프로젝트(AppProject)를 사용하여 팀에 세분화된 액세스 제어 및 리소스 격리를 제공합니다.
**중요**
사용자 또는 그룹을 프로젝트별 역할에 할당하기 전에 먼저 기능 구성의 글로벌 Argo CD 역할(ADMIN, EDITOR 또는 VIEWER)에 매핑해야 합니다. 사용자는 프로젝트 역할에 할당된 경우에도 글로벌 역할 매핑 없이는 Argo CD에 액세스할 수 없습니다.
사용자를 VIEWER 역할에 글로벌로 매핑한 다음 프로젝트별 역할을 통해 추가 권한을 부여하는 방법을 고려합니다. 그러면 프로젝트 수준에서 세분화된 제어를 허용하면서 기준 액세스를 제공합니다.
프로젝트에서는 다음을 제공합니다.
+ **소스 제한 사항**: 사용할 수 있는 Git 리포지토리 제한
+ **대상 제한 사항**: 대상으로 지정할 수 있는 클러스터 및 네임스페이스 제한
+ **리소스 제한 사항**: 배포할 수 있는 Kubernetes 리소스 유형 제한
+ **RBAC 통합**: 프로젝트를 AWS Identity Center 그룹 또는 Argo CD 역할에 매핑
**팀 격리를 위한 프로젝트 예제**:
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
description: Team A applications
# Required: Specify which namespaces this project watches for Applications
sourceNamespaces:
- argocd
# Source restrictions
sourceRepos:
- https://github.com/myorg/team-a-apps
# Destination restrictions
destinations:
- namespace: team-a-*
server: arn:aws:eks:us-west-2:111122223333:cluster/production
# Resource restrictions
clusterResourceWhitelist:
- group: ''
kind: Namespace
namespaceResourceWhitelist:
- group: 'apps'
kind: Deployment
- group: ''
kind: Service
- group: ''
kind: ConfigMap
```
### 소스 네임스페이스
EKS Argo CD 기능을 사용하는 경우 `spec.sourceNamespaces` 필드가 AppProject 정의에 필요합니다. 이 필드는 이 프로젝트를 참조하는 Applications 또는 ApplicationSets를 포함할 수 있는 네임스페이스를 지정합니다.
**중요**
EKS Argo CD 기능은 기능(일반적으로 `argocd`)을 생성할 때 사용자가 지정한 네임스페이스인 Applications 및 ApplicationSets에 대한 단일 네임스페이스만 지원합니다. 여러 네임스페이스를 지원하는 오픈 소스 Argo CD와는 다릅니다.
**AppProject 구성**
모든 AppProjects는 `sourceNamespaces`에 기능의 구성된 네임스페이스를 포함해야 합니다.
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a-project
namespace: argocd
spec:
description: Applications for Team A
# Required: Specify the capability's configured namespace (configuration.argoCd.namespace)
sourceNamespaces:
- argocd # Must match your capability's namespace configuration
# Source repositories this project can deploy from
sourceRepos:
- 'https://github.com/my-org/team-a-*'
# Destination restrictions
destinations:
- namespace: 'team-a-*'
server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster
```
**참고**
`sourceNamespaces`에서 기능의 네임스페이스를 생략하면 해당 네임스페이스의 Applications 또는 ApplicationSets가 이 프로젝트를 참조할 수 없으므로 배포에 실패합니다.
**프로젝트에 사용자 지정**:
프로젝트 역할은 EDITOR 및 VIEWER 사용자에게 프로젝트 리소스(Applications, ApplicationSets, 리포지토리 및 클러스터 자격 증명) 및 기능(로그, 실행)에 대한 액세스 권한을 부여합니다. 프로젝트 역할이 없으면 글로벌 역할 액세스 권한이 있더라도 이러한 사용자는 이러한 리소스에 액세스할 수 없습니다.
ADMIN 사용자는 프로젝트 역할 없이도 모든 애플리케이션에 액세스할 수 있습니다.
**예제: 팀원에게 애플리케이션 액세스 권한 부여**
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
# ... project configuration ...
sourceNamespaces:
- argocd
# Project roles grant Application-level access
roles:
- name: developer
description: Team A developers - can manage Applications
policies:
- p, proj:team-a:developer, applications, *, team-a/*, allow
- p, proj:team-a:developer, clusters, get, *, allow # See cluster names in UI
groups:
- 686103e0-f051-7068-b225-e6392b959d9e # Identity Center group ID
- name: viewer
description: Team A viewers - read-only Application access
policies:
- p, proj:team-a:viewer, applications, get, team-a/*, allow
- p, proj:team-a:viewer, clusters, get, *, allow # See cluster names in UI
groups:
- 786203e0-f051-7068-b225-e6392b959d9f # Identity Center group ID
```
**참고**
사용자가 UI에서 클러스터 이름을 볼 수 있도록 프로젝트 역할에 `clusters, get, *, allow`를 포함합니다. 이 권한이 없으면 대상 클러스터가 '알 수 없음'으로 표시됩니다.
**프로젝트 역할 정책 이해**:
정책 형식은 다음과 같습니다. `p, proj::, , ,