BLOG
Kubernetes용 AWS 컨트롤러 (ACK)는 Kubernetes에서 AWS 서비스를 직접 관리할 수 있는 새로운 도구입니다. ACK를 사용하면 AWS 서비스를 활용하는 확장 가능하고 가용성이 높은 Kubernetes 애플리케이션을 간단하게 구축할 수 있습니다.
ACK는 GitHub 개발자 프리뷰에서 사용 가능합니다.
이 게시물에서는 ACK 프로젝트 배경을 간략히 소개하고, ACK의 작동 방식과 사용법을 보여줍니다.
배경
2018년 말 Chris Hein은 개인 실험 프로젝트로 AWS Service Operator를 도입했습니다. 그 후 커뮤니티 및 내부 이해 관계자의 피드백을 검토하고 1단계 오픈 소스 프로젝트로 재 런칭하기로 결정했습니다. 이 과정에서 프로젝트 이름을 Kubernetes용 AWS 컨트롤러(ACK)로 변경했으며 우리의 신조는 다음과 같습니다.
- ACK는 역할과 책임을 정의하는 거버넌스 모델을 기반으로 하는 커뮤니티 중심 프로젝트이다.
- ACK는 성능 및 확장성 테스트 스위트를 포함한 전체 테스트 범위를 통해 프로덕션 용도로 최적화된다.
- ACK는 Kubernetes 운영자를 통해 AWS 서비스를 노출하는 유일한 코드 기반이 되기 위해 노력한다.
지난 1년 동안 우리는 프로젝트의 디자인을 크게 향상시켰고, 내부 담당자와 논의를 계속했으며(이것이 중요한 이유는 곧 알려드리겠습니다), 공간 관련 프로젝트를 검토했습니다. Crossplane프로젝트는 크로스 클라우드 사용 사례를 위해 훌륭한 역할을 하였으며 CNCF 프로젝트로 선정된 것에 인사를 보냅니다.
새로운 ACK 프로젝트는 기존의 AWS Service Operator 역할을 유지하지만 몇 가지 업데이트 사항이 있습니다.
- AWS 클라우드 리소스는 CloudFormation 대신 AWS API를 통해 직접 관리됩니다. 이를 통해 Kubernetes는 원하는 리소스 상태에 대한 단일 ‘SOT’가 될 수 있습니다.
- 컨트롤러 및 사용자 지정 리소스 정의에 대한 코드는 사람이 편집하고 승인하여 AWS Go SDK에서 자동으로 생성됩니다. 이를 통해 수작업은 줄이고 더 많은 최신 기술을 활용해 프로젝트를 최신 상태로 유지할 수 있습니다.
- 이것은 AWS Kubernetes 팀이 구축하고 유지 관리하는 공식 프로젝트입니다. 우리는 AWS의 동료들과 함께 이 프로젝트에 계속 투자할 계획입니다.
ACK 작동 원리
AWS 서비스 API에 관계없이 AWS에 일관된 Kubernetes 인터페이스를 제공하는 것이 ACK의 목표입니다. 이에 대한 한 가지 예는 필드 이름과 식별자가 정규화되고 태그가 AWS 리소스에서 동일한 방식으로 처리되도록 하는 것입니다.
위에서 설명한 대로 상위 수준에서 ACK 워크 플로는 다음과 같습니다.
- 우리는 “저자의 프로젝트 팀”에서와 같이 아티팩트 컬렉션 (바이너리, 컨테이너 이미지, Helm 차트 등)을 생성하고 유지 관리합니다. 이러한 아티팩트는 AWS 서비스 API에서 자동으로 파생되며 Kubernetes 내에서 AWS 리소스를 관리하는 방법에 대한 비즈니스 로직을 나타냅니다.
- 클러스터 관리자는 담당하는 클러스터에 대해 설치 및 구성하려는 하나 이상의 ACK 컨트롤러를 선택합니다.
- 애플리케이션 개발자는 AWS 리소스를 나타내는 (Kubernetes) 사용자 지정 리소스를 생성합니다.
- 각각의 ACK 컨트롤러 (2 단계에서 설치됨)는 해당 사용자 지정 리소스와 기본 AWS 리소스를 관리합니다. 3 단계에서 정의한 사용자 지정 리소스를 기반으로 컨트롤러는 AWS API를 사용하여 기본 AWS 리소스를 생성, 업데이트 또는 삭제합니다.
이제 구체적인 예를 사용하여 워크 플로를 자세히 살펴보겠습니다.
- 아티팩트 생성
아티팩트 생성은 Kubernetes를 사용하여 AWS 서비스를 관리할 수 있는 필수 코드 구성 요소를 생성합니다. 우리는 다단계 접근 방식을 취하여 하이브리드 맞춤형 컨트롤러 런타임을 산출했습니다.
- 첫째, AWS 서비스에 대한 표준 SOT의 모델 정보를 사용합니다. 우리는 aws/aws-sdk-go 저장소의 모델 파일로 SOT을 정했습니다. AWS SDK는 모든 API 변경 사항으로 정기적으로 업데이트되므로 정확한 정보 소스이며 서비스 API 가용성을 면밀히 추적합니다. 이 단계에서 우리는 거기에서 발견된 객체 및 인터페이스에 대한 Go 유형을 노출하는 코드를 포함하는 파일을 생성합니다.
- AWS API에 의해 노출된 최상위 리소스에 대한 Kubernetes API 유형 정의를 생성한 후에는 해당 최상위 리소스와 유형 정의를 Kubernetes 런타임 패키지에서 사용할 수 있도록 인터페이스 구현을 생성해야 합니다.
- 다음으로 이전 단계에서 식별된 각 최상위 리소스에 대해 하나씩 사용자 지정 리소스 정의(CRD) 구성 파일을 생성합니다. 그런 다음 대상 서비스에 대한 ACK 컨트롤러 구현을 생성합니다. 이러한 이동 제어기의 구현과 함께 또한 이 설정 단계는 다음 단계Role의Deployment과 ClusterRoleBinding에 대한Kubernetes매니페스트 세트를 출력합니다.
- 마지막으로 각 ACK 서비스 컨트롤러를 실행하는 Kubernetes Role용 Kubernetes 매니페스트를 생성합니다. 최소 권한 원칙을 준수하려면 Role은 당 서비스 컨트롤러가 관리하는 사용자 지정 리소스Kind를 읽고 쓸 수 있는 정확한 권한이 있어야 합니다.
Go 코드, 컨테이너 이미지, CRD용 Kubernetes 매니페스트, 역할, 배포 등 아티팩트는 Kubernetes 내에서 AWS 리소스를 관리하는 방법에 대한 비즈니스 로직을 나타내며 이는 커뮤니티에서 입력과 함께 생성 및 유지 관리하는 AWS 서비스 팀의 책임입니다.
- 사용자 지정 리소스 및 컨트롤러 설치
클러스터에서 ACK를 사용하려면 다음을 고려하여 원하는 AWS 서비스 컨트롤러를 설치합니다.
- ACK 사용자 지정 리소스에 대한 각각의 Kubernetes 역할 기반 액세스 제어(RBAC) 권한을 설정합니다. 각 ACK 서비스 컨트롤러는 자체 포드에서 실행되며 권한 경계 또는 서비스 제어 정책을 포함한 기존 IAM 제어를 적용하여 누가 어떤 리소스에 액세스 할 수 있는지 정의하고 RBAC를 통해 전 이적으로 정의해야 합니다.
- AWS 계정 ID를 Kubernetes 네임 스페이스에 연결합니다. 결과적으로 모든 ACK 사용자 지정 리소스는 네임 스페이스가 지정되어야 합니다 (클러스터 전체 사용자 지정 리소스 없음).
AWS 공유 책임 모델에 따라, 클러스터 관리의 맥락에서, 사용자는 정기적으로 ACK 서비스 컨트롤러를 업그레이드 할뿐만 아니라 보안 패치를 적용할 책임이 있습니다.
- Kubernetes에서 AWS 리소스 시작
애플리케이션 개발자는 ACK 사용 클러스터 중 하나에 네임 스페이스가 지정된 사용자 지정 리소스를 만듭니다. 예를 들어 ACK가 Amazon Elastic Container Registry (ECR) 리포지토리를 생성하도록 하려는 경우 다음과 같이 정의하고 이후에 적용합니다.
apiVersion: “ecr.services.k8s.aws/v1alpha1”kind: Repositorymetadata: name: “my-ecr-repo”spec: repositoryName: “encrypted-repo-managed-by-ack” encryptionConfiguration: encryptionType: AES256 tags: – key: “is-encrypted” value: “true”
- Kubernetes에서 AWS 리소스 관리
클러스터 관리자가 설치한 ACK 서비스 컨트롤러는 개발자가 이전 단계에서 정의한 사용자 지정 리소스에서 찾은 의도에 따라 AWS 리소스를 생성, 업데이트 또는 삭제할 수 있습니다. 즉, ACK 지원 대상 클러스터에서 사용자 지정 리소스를 적용하면 해당 AWS 리소스 (이 예에서는 ECR 리포지토리)가 생성되고 이에 대한 액세스 권한이 부여됩니다.
대부분의 사용자가 ACK와 상호 작용하는 방식이므로 Kubernetes에서 AWS 리소스를 만들고 관리하는 데 조금 더 초점을 맞추겠습니다. 이 예에서는 클러스터에서 S3 버킷을 생성합니다.
연습: ACK로 S3 버킷 관리
다음에서는 ACK를 사용하여 S3 버킷을 관리하려고 합니다. 이것은 개발자 프리뷰이므로 기고자 문서에 따라 테스트 지침을 사용하고 있습니다. 이 맥락에서 우리는 kind를 사용하여 Docker를 유일한 종속성으로 사용하여 로컬 엔드 투 엔드 테스트를 수행합니다.
S3 서비스 컨트롤러 용 컨테이너 이미지를 빌드하고, 클러스터를 생성하고, make kind-test -s SERVICE=s3명령을 사용하여 모든 리소스를 배포하는 데 처음에는 (콜드 캐시) 약 45분이 소요될 수 있습니다. 완료되면 ACK 설정을 볼 수 있습니다.
$ kubectl –n ack–system get allNAME READY STATUS RESTARTS AGEpod/ack–s3–controller–86d9cf5cd7–z7l42 1/1 Running 0 10m NAME READY UP–TO–DATE AVAILABLE AGEdeployment.apps/ack–s3–controller 1/1 1 1 10m NAME DESIRED CURRENT READY AGE
replicaset.apps/ack–s3–controller–86d9cf5cd7 1 1 1 10
또한 S3 CRD가 테스트 클러스터에 설치되고 사용 가능할 것이며 실제로 다음과 같습니다.
$ kubectl get crdNAME CREATED AT
buckets.s3.services.k8s.aws 2020–08–17T06:15:22Z
CRD를 기반으로 S3 버킷 사용자 지정 리소스를 찾을 수 있습니다.
$ kubectl get bucketsNAME AGE
ack–test–smoke–s3 3m8s
이제 클러스터에서 S3 버킷 고객 리소스를 살펴 보겠습니다 (참고: 여기에 표시된 것은 통합 테스트에서 자동으로 생성된 사용자 지정 리소스이며 가독성을 위해 편집 됨).
$ kubectl get buckets ack–test–smoke–s3 –o yamlapiVersion: s3.services.k8s.aws/v1alpha1kind: Bucketmetadata: name: ack–test–smoke–s3 namespace: defaultspec:
name: ack–test–smoke–s3
모두 종합하면 위의 설정은 다음과 같습니다.
이 실습을 통해 이제 ACK가 어떻게 작동하는지 알아보았습니다. 이제 참여 방법과 다음 단계에 대해 살펴보겠습니다.
다음 단계
오늘부터 ACK가 다음 AWS 서비스를 지원하는 개발자 미리보기로 제공되어 매우 기쁩니다.
- Amazon API Gateway V2
- Amazon DynamoDB
- Amazon ECR
- 아마존 S3
- 아마존 SNS
- 아마존 SQS
설명서를 통해 ACK 설치 및 사용을 시작할 수 있습니다. 개발자 미리보기는 최종 사용자용 설치 메커니즘이 아직 제자리에 있지 않음을 의미합니다.
향후 서비스
저희는 가능한 많은 AWS 서비스를 지원 및 활성화하고 ACK에 대한 완전한 지원을 통해 온 보딩할 것으로 기대합니다. 특히 앞으로 몇 달 동안 아래 내용에 집중할 계획입니다.
- Amazon Relational Database Service (RDS)는 RDS 레이블을 통해 추적
- Amazon ElastiCache이 Elasticache 레이블을 통해 추적하는 완전 관리형 Redis 및 Memcached를 제공
RDS 및 ElastiCache외에도 Amazon Elastic Kubernetes Service (EKS) 및 Amazon Managed Streaming for Apache Kafka (MSK)에 대한 지원도 고려하고 있습니다.
예정된 기능
우리가 작업하고 있으며 앞으로 몇 주 혹은 몇 달 내에 사용할 수 있는 중요한 기능은 다음과 같습니다.
지원
ACK는 여전히 새로운 프로젝트이며 개발에 도움이 될 여러분의 의견을 기다리고 있습니다. 이론 부분에서는 아래와 같은 여러분들의 의견이 궁금합니다.