EKS용 ACK 고려 사항

EKS용 ACK 캐퍼빌리티 사용 시 고려해야 할 중요한 사항을 설명합니다. IAM 구성, 멀티 계정 패턴, 다른 EKS 캐퍼빌리티와의 통합을 다룹니다.

출처: 문서

본문

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"],
          "aws:ResourceTag/ManagedBy": "ACK"
        }
      }
    }
  ]
}

이 예시는 S3와 RDS 작업을 특정 리전으로 제한하고, RDS 리소스에 ManagedBy: ACK 태그가 있어야 합니다.

프로덕션: IAM Role Selector

프로덕션 환경에서는 IAM Role Selector를 사용해 최소 권한 접근과 네임스페이스 수준 격리를 구현하세요.

사용 시기:
- 프로덕션 환경
- 멀티 팀 클러스터
- 멀티 계정 리소스 관리
- 최소 권한 보안 요구 사항
- 서비스별로 서로 다른 권한이 필요할 때
이점:
- 각 네임스페이스에 필요한 권한만 부여
- 팀 격리 - 팀 A가 팀 B의 권한을 사용할 수 없음
- 감사와 규정 준수 용이
- 교차 계정 리소스 관리에 필요

자세한 IAM Role Selector 구성은 ACK 권한 구성을 참고하세요.

다른 EKS 캐퍼빌리티와의 통합

Argo CD로 GitOps

Argo CD용 EKS 캐퍼빌리티를 사용해 Git 리포지토리에서 ACK 리소스를 배포하여 인프라 관리에 GitOps 워크플로를 적용할 수 있습니다.

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

GitOps는 감사 추적, 롤백 기능, 선언적 인프라 관리를 제공합니다. Argo CD에 대한 자세한 내용은 Argo CD 사용하기를 참고하세요.

kro로 리소스 구성

kro(Kube Resource Orchestrator)용 EKS 캐퍼빌리티를 사용해 여러 ACK 리소스를 더 높은 수준의 추상화와 커스텀 API로 구성합니다.

ACK와 함께 kro를 사용할 때:
- 일반적인 인프라 스택(데이터베이스 + 백업 + 모니터링)을 위한 재사용 가능한 패턴 생성
- 애플리케이션 팀을 위한 단순화된 API로 셀프 서비스 플랫폼 구축
- 리소스 간 의존성을 관리하고 값을 전달(S3 버킷 ARN을 Lambda 함수로)
- 팀 전반의 인프라 구성을 표준화
- 커스텀 리소스 뒤에 구현 세부 사항을 숨겨 복잡성 감소
예시 패턴:
- 애플리케이션 스택: S3 버킷 + SQS 큐 + 알림 구성
- 데이터베이스 설정: RDS 인스턴스 + 파라미터 그룹 + 보안 그룹 + 시크릿
- 네트워킹: VPC + 서브넷 + 라우팅 테이블 + 보안 그룹

kro는 구성된 리소스의 의존성 순서, 상태 전파, 수명 주기 관리를 처리합니다. kro에 대한 자세한 내용은 kro 개념을 참고하세요.

리소스 구성하기

Kubernetes 네임스페이스와 AWS 리소스 태그를 사용해 ACK 리소스를 구성하면 관리, 접근 제어, 비용 추적이 좋아집니다.

네임스페이스 구성

Kubernetes 네임스페이스를 사용해 ACK 리소스를 환경(production, staging, development), 팀(platform, data, ml), 또는 애플리케이션별로 논리적으로 분리합니다.

이점:
- 접근 제어를 위한 네임스페이스 범위 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: 접두사를 사용합니다.

권장되는 추가 태그:
- 비용 할당, 소유권 추적, 조직 목적을 위한 커스텀 태그 추가
- 환경(Production, Staging, Development)
- 팀 또는 부서 소유권
- 청구 배분을 위한 비용 센터
- 애플리케이션 또는 서비스 이름

다른 Infrastructure-as-Code 도구에서 마이그레이션

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

삭제 정책

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

Delete(기본값)

Kubernetes 리소스를 삭제하면 AWS 리소스도 삭제됩니다. 이는 클러스터와 AWS 간의 일관성을 유지해 리소스가 누적되지 않도록 보장합니다.

delete를 사용할 때:
- 정리가 중요한 개발 및 테스트 환경
- 애플리케이션 수명 주기에 묶인 임시 리소스(테스트 데이터베이스, 임시 버킷)
- 애플리케이션보다 오래 지속되지 않아야 하는 리소스(SQS 큐, ElastiCache 클러스터)
- 미사용 리소스를 자동 정리하는 비용 최적화
- Git에서 리소스 제거 시 인프라를 삭제해야 하는 GitOps 관리 환경

기본 delete 정책은 Kubernetes의 선언적 모델과 일치합니다. 클러스터에 있는 것이 AWS에 존재하는 것과 일치합니다.

Retain

Kubernetes 리소스를 삭제해도 AWS 리소스는 유지됩니다. 이는 중요 데이터를 보호하고 리소스가 Kubernetes 표현보다 오래 지속되도록 합니다.

retain을 사용할 때:
- 클러스터 변경에도 반드시 살아남아야 하는 중요 데이터가 있는 프로덕션 데이터베이스
- 규정 준수나 감사 요구 사항이 있는 장기 저장 버킷
- 여러 애플리케이션이나 팀이 사용하는 공유 리소스
- 다른 관리 도구로 마이그레이션 중인 리소스
- 인프라를 보존하려는 재해 복구 시나리오
- 신중한 폐기가 필요한 복잡한 의존성을 가진 리소스

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 사용에 대한 자세한 정보는 ACK 웹사이트의 다음 페이지를 참고하세요.

리소스 생성과 관리는 ACK 사용 가이드(usage guide)를 참고하세요.
모든 서비스의 전체 API 문서는 ACK API 레퍼런스를 참고하세요.
종합적인 사용자 문서는 ACK 문서를 참고하세요.

다음 단계

ACK 권한 구성 - IAM 권한과 멀티 계정 패턴 구성
ACK 개념 - ACK 개념과 리소스 수명 주기 이해하기
ACK 캐퍼빌리티 문제 해결 - ACK 문제 해결
Argo CD 사용하기 - GitOps로 ACK 리소스 배포
kro 개념 - ACK 리소스를 더 높은 수준의 추상화로 구성

더 알아보기 (Learn more)

공식 문서