

 **이 페이지 개선에 도움 주기** 

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

# EKS에 대한 ACK 고려 사항
<a name="ack-considerations"></a>

이 주제에서는 IAM 구성, 다중 계정 패턴, 다른 EKS 기능과의 통합 등 EKS의·ACK 기능 사용에 대한 중요한 고려 사항을 다룹니다.

## IAM 구성 패턴
<a name="_iam_configuration_patterns"></a>

ACK 기능은 IAM 기능 역할을 사용하여 AWS로 인증합니다. 요구 사항에 따라 올바른 IAM 패턴을 선택합니다.

### 단순: 단일 기능 역할
<a name="_simple_single_capability_role"></a>

개발, 테스트 또는 간단한 사용 사례의 경우 필요한 모든 권한을 기능 역할에 직접 부여합니다.

 **사용해야 하는 경우**:
+ 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 역할 선택기
<a name="_production_iam_role_selectors"></a>

프로덕션 환경의 경우 IAM 역할 선택기를 사용하여 최소 권한 액세스 및 네임스페이스 수준 격리를 구현합니다.

 **사용해야 하는 경우**:
+ 프로덕션 환경
+ 다중 팀 클러스터
+ 다중 계정 리소스 관리
+ 최소 권한 보안 요구 사항
+ 서비스마다 다른 권한이 필요함

 **이점:**
+ 각 네임스페이스는 필요한 권한만 얻음
+ 팀 격리 - 팀 A는 팀 B의 권한을 사용할 수 없음
+ 보다 쉬운 감사 및 규정 준수
+ 교차 계정 리소스 관리에 필요함

자세한 IAM 역할 선택기 구성은 [ACK 권한 구성](ack-permissions.md) 섹션을 참조하세요.

## 다른 EKS 기능과 통합
<a name="_integration_with_other_eks_capabilities"></a>

### Argo CD와 함께 사용하는 GitOps
<a name="_gitops_with_argo_cd"></a>

Argo CD의 EKS 기능을 사용해 Git 리포지토리에서 ACK 리소스를 배포하여 인프라 관리를 위한 GitOps 워크플로를 지원합니다.

 **고려 사항:**
+ 포괄적인 GitOps에 대한 애플리케이션 매니페스트와 함께 ACK 리소스 저장
+ 팀 구조를 기반으로 환경, 서비스 또는 리소스 유형별로 구성
+ 지속적인 조정을 위해 Argo CD의 자동화된 동기화 사용
+ 삭제된 리소스를 자동으로 제거하도록 정리 활성화
+ 다중 클러스터 인프라 관리를 위해 허브 및 스포크 패턴 고려

GitOps는 감사 추적, 롤백 기능 및 선언적 인프라 관리를 제공합니다. Argo CD에 대한 자세한 내용은 [Argo CD 작업](working-with-argocd.md) 섹션을 참조하세요.

### kro를 사용하는 리소스 구성
<a name="_resource_composition_with_kro"></a>

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) 섹션을 참조하세요.

## 리소스 구성
<a name="_organizing_your_resources"></a>

더 나은 관리, 액세스 제어 및 비용 추적을 위해 Kubernetes 네임스페이스와 AWS 리소스 태그를 사용하여 ACK 리소스를 구성합니다.

### 네임스페이스 구성
<a name="_namespace_organization"></a>

Kubernetes 네임스페이스를 사용하여 환경(프로덕션, 스테이징, 개발), 팀(플랫폼, 데이터, ml) 또는 애플리케이션을 기준으로 ACK 리소스를 논리적으로 분리합니다.

 **이점:**
+ 액세스 제어를 위한 네임스페이스 범위의 RBAC
+ 주석을 사용하여 네임스페이스당 기본 리전 설정
+ 더 쉬운 리소스 관리 및 정리
+ 조직 구조에 맞게 정렬된 논리적 분리

### 리소스에 태깅
<a name="_resource_tagging"></a>

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:` 접두사를 사용합니다.

 **추가 권장 태그**:

비용 할당, 소유권 추적 및 구성 목적을 위해 사용자 지정 태그를 추가합니다.
+ 환경(프로덕션, 스테이징, 개발)
+ 팀 또는 부서 소유권
+ 결제 할당을 위한 비용 센터
+ 애플리케이션 또는 서비스 이름

## 다른 코드형 인프라 도구에서 마이그레이션
<a name="_migration_from_other_infrastructure_as_code_tools"></a>

많은 조직이 워크로드 오케스트레이션을 넘어 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) 섹션을 참조하세요.

## 삭제 정책
<a name="_deletion_policies"></a>

삭제 정책은 해당 Kubernetes 리소스를 삭제할 때 AWS 리소스에 어떤 일이 발생하는지 제어합니다. 리소스 수명 주기와 운영 요구 사항에 따라 올바른 정책을 선택합니다.

### 삭제(기본값)
<a name="_delete_default"></a>

Kubernetes 리소스를 삭제하면 AWS 리소스가 삭제됩니다. 이를 통해 클러스터와 AWS 사이에서 일관성을 유지 관리하여 리소스가 누적되지 않도록 합니다.

 **삭제를 사용하는 경우**:
+ 정리가 중요한 개발 및 테스트 환경
+ 애플리케이션 수명 주기에 연결된 임시 리소스(테스트 데이터베이스, 임시 버킷)
+ 애플리케이션보다 수명이 짧아야 하는 리소스(SQS 대기열, ElastiCache 클러스터)
+ 비용 최적화 - 미사용 리소스 자동 정리
+ Git에서 리소스를 제거하면 인프라가 삭제되는 GitOps로 관리되는 환경

기본 삭제 정책은 Kubernetes의 선언적 모델에 맞게 조정됩니다. 클러스터의 내용은 AWS에 있는 것과 일치합니다.

### 보관
<a name="_retain"></a>

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) 섹션을 참조하세요.

## 업스트림 설명서
<a name="_upstream_documentation"></a>

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/) - 포괄적인 사용자 설명서

## 다음 단계
<a name="_next_steps"></a>
+  [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 리소스를 상위 수준 추상화로 구성