Flux를 사용하여 Amazon EKS 멀티 테넌트 애플리케이션 배포 간소화 - 권장 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Flux를 사용하여 Amazon EKS 멀티 테넌트 애플리케이션 배포 간소화

Nadeem Rahaman, Aditya Ambati, Aniket Dekate, Shrikant Patil, Amazon Web Services

요약

알림: AWS CodeCommit 신규 고객은 더 이상를 사용할 수 없습니다. 의 기존 고객은 평소와 같이 서비스를 계속 사용할 AWS CodeCommit 수 있습니다. 자세히 알아보기

제품 및 서비스를 제공하는 많은 회사는 내부 비즈니스 기능 간에 데이터 장벽을 유지하는 데 필요한 데이터 규제 산업입니다. 이 패턴은 Amazon Elastic Kubernetes Service(Amazon EKS)의 다중 테넌시 기능을 사용하여 단일 Amazon EKS 클러스터를 공유하는 테넌트 또는 사용자 간에 논리적 및 물리적 격리를 달성하는 데이터 플랫폼을 구축하는 방법을 설명합니다. 이 패턴은 다음 접근 방식을 통해 격리를 제공합니다.

  • Kubernetes 네임스페이스 격리

  • 역할 기반 액세스 제어(RBAC)

  • 네트워크 정책

  • 리소스 할당량

  • AWS Identity and Access Management 서비스 계정에 대한 (IAM) 역할(IRSA)

또한이 솔루션은 애플리케이션을 배포할 때 Flux를 사용하여 테넌트 구성을 변경 불가능하게 유지합니다. 구성에 Flux kustomization.yaml 파일이 포함된 테넌트 리포지토리를 지정하여 테넌트 애플리케이션을 배포할 수 있습니다.

이 패턴은 다음을 구현합니다.

  • Terraform 스크립트를 수동으로 배포하여 생성되는 리포지 AWS CodeCommit 토리, AWS CodeBuild 프로젝트 및 AWS CodePipeline 파이프라인입니다.

  • 테넌트를 호스팅하는 데 필요한 네트워크 및 컴퓨팅 구성 요소입니다. 이는 Terraform을 사용하여 CodePipeline 및 CodeBuild를 통해 생성됩니다.

  • 테넌트 네임스페이스, 네트워크 정책 및 리소스 할당량은 Helm 차트를 통해 구성됩니다.

  • Flux를 사용하여 배포된 서로 다른 테넌트에 속하는 애플리케이션.

고유한 요구 사항 및 보안 고려 사항에 따라 멀티테넌시를 위한 자체 아키텍처를 신중하게 계획하고 구축하는 것이 좋습니다. 이 패턴은 구현의 시작점을 제공합니다.

사전 조건 및 제한 사항

사전 조건 

제한 사항

  • Terraform 수동 배포에 대한 종속성: CodeCommit 리포지토리, CodeBuild 프로젝트 및 CodePipeline 파이프라인 생성을 포함한 워크플로의 초기 설정은 수동 Terraform 배포를 사용합니다. 이로 인해 인프라 변경에 대한 수동 개입이 필요하므로 자동화 및 확장성 측면에서 잠재적인 제한이 발생합니다.

  • CodeCommit 리포지토리 종속성: 워크플로는 CodeCommit 리포지토리를 소스 코드 관리 솔루션으로 사용하며 긴밀하게 연결됩니다 AWS 서비스.

아키텍처

대상 아키텍처

이 패턴은 다음 다이어그램과 같이 세 개의 모듈을 배포하여 데이터 플랫폼의 파이프라인, 네트워크 및 컴퓨팅 인프라를 구축합니다.

파이프라인 아키텍처:

Amazon EKS 멀티 테넌트 아키텍처를 위한 파이프라인 인프라

네트워크 아키텍처:

Amazon EKS 멀티 테넌트 아키텍처를 위한 네트워크 인프라

컴퓨팅 아키텍처:

Amazon EKS 멀티 테넌트 아키텍처를 위한 컴퓨팅 인프라

도구

AWS 서비스

  • AWS CodeBuild는 소스 코드를 컴파일하고, 단위 테스트를 실행하고, 배포할 준비가 된 아티팩트를 생성하는 데 도움이 되는 완전 관리형 빌드 서비스입니다.

  • AWS CodeCommit는 자체 소스 제어 시스템을 관리할 필요 없이 Git 리포지토리를 비공개로 저장하고 관리하는 데 도움이 되는 버전 관리 서비스입니다.

  • AWS CodePipeline를 사용하면 소프트웨어 릴리스의 다양한 단계를 신속하게 모델링 및 구성하고 소프트웨어 변경 사항을 지속적으로 릴리스하는 데 필요한 단계를 자동화할 수 있습니다.

  • Amazon Elastic Kubernetes Service(Amazon EKS)를 사용하면 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치하거나 유지 관리할 필요 AWS 없이에서 Kubernetes를 실행할 수 있습니다.

  • AWS Transit Gateway는 Virtual Private Cloud(VPC)와 온프레미스 네트워크를 연결하는 중앙 허브입니다.

  • Amazon Virtual Private Cloud(Amazon VPC)를 사용하면 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사합니다.

기타 도구

  • Cilium 네트워크 정책은 Kubernetes L3 및 L4 네트워킹 정책을 지원합니다. L7 정책으로 확장하여 HTTP, Kafka, gRPC 및 기타 유사한 프로토콜에 대한 API 수준 보안을 제공할 수 있습니다.

  • Flux는 Kubernetes에서 애플리케이션 배포를 자동화하는 Git 기반 지속적 전달(CD) 도구입니다.

  • Helm은 Kubernetes 클러스터에 애플리케이션을 설치하고 관리하는 데 도움이 되는 Kubernetes용 오픈 소스 패키지 관리자입니다.

  • Terraform은 HashiCorp의 코드형 인프라(IaC) 도구로, 클라우드 및 온프레미스 리소스를 생성하고 관리하는 데 도움이 됩니다.

코드 리포지토리

이 패턴의 코드는 GitHub EKS Multi-Tenancy Terraform Solution 리포지토리에서 사용할 수 있습니다.

모범 사례

이 구현 사용에 대한 지침과 모범 사례는 다음을 참조하세요.

에픽

작업설명필요한 기술

프로젝트 리포지토리를 복제합니다.

터미널 창에서 다음 명령을 실행하여 GitHub EKS Multi-Tenancy Terraform Solution 리포지토리를 복제합니다.

git clone https://github.com/aws-samples/aws-eks-multitenancy-deployment.git
DevOps

Terraform S3 버킷과 Amazon DynamoDB를 부트스트랩합니다.

  1. bootstrap 폴더에서 bootstrap.sh 파일을 열고 S3 버킷 이름, DynamoDB 테이블 이름 및 AWS 리전다음 변수 값을 업데이트합니다.

    S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME>" REGION="<AWS_REGION>"
  2. bootstrap.sh 스크립트 실행. 스크립트에는 사전 조건의 일부로 설치 AWS CLI한이 필요합니다.

    cd bootstrap ./bootstrap.sh
DevOps

run.shlocals.tf 파일을 업데이트합니다.

  1. 부트스트랩 프로세스가 성공적으로 완료되면 bootstrap.sh 스크립트의 variables 섹션에서 S3 버킷 및 DynamoDB 테이블 이름을 복사합니다.

    # Variables S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME"
  2. 이러한 값을 프로젝트의 루트 디렉터리에 있는 run.sh 스크립트에 붙여 넣습니다.

    BACKEND_BUCKET_ID="<SAME_NAME_AS_S3_BUCKET_NAME>" DYNAMODB_ID="<SAME_NAME_AS_DYNAMODB_NAME>"
  3. 프로젝트 코드를 CodeCommit 리포지토리에 업로드합니다. demo/pipeline/locals.tf 파일true에서 다음 변수를 로 설정하여 Terraform을 통해이 리포지토리를 자동으로 생성할 수 있습니다.

    create_new_repo = true
  4. 요구 사항에 따라 locals.tf 파일을 업데이트하여 파이프라인 리소스를 생성합니다.

DevOps

파이프라인 모듈을 배포합니다.

파이프라인 리소스를 생성하려면 다음 Terraform 명령을 수동으로 실행합니다. 이러한 명령을 자동으로 실행하기 위한 오케스트레이션은 없습니다.

./run.sh -m pipeline -e demo -r <AWS_REGION> -t init ./run.sh -m pipeline -e demo -r <AWS_REGION> -t plan ./run.sh -m pipeline -e demo -r <AWS_REGION> -t apply
DevOps
작업설명필요한 기술

파이프라인을 시작합니다.

  1. templates 폴더에서 buildspec 파일에 다음 변수가 로 설정되어 있는지 확인합니다. network

    TF_MODULE_TO_BUILD: "network"
  2. CodePipeline 콘솔의 파이프라인 세부 정보 페이지에서 변경 릴리스를 선택하여 파이프라인을 시작합니다.

이 첫 번째 실행 후 CodeCommit 리포지토리 기본 브랜치에 변경 사항을 커밋할 때마다 파이프라인이 자동으로 시작됩니다.

파이프라인에는 다음 단계가 포함됩니다.

  • validate는 Terraform을 초기화하고, checkovtfsec 도구를 사용하여 Terraform 보안 스캔을 실행하고, 스캔 보고서를 S3 버킷에 업로드합니다.

  • plan 는 Terraform 계획을 보여주고 S3 버킷에 계획을 업로드합니다.

  • apply는 S3 버킷의 Terraform 계획 출력을 적용하고 AWS 리소스를 생성합니다.

  • destroyapply 단계에서 생성된 AWS 리소스를 제거합니다. 이 선택적 단계를 활성화하려면 demo/pipeline/locals.tf 파일true에서 다음 변수를 로 설정합니다.

    enable_destroy_stage = true
DevOps

네트워크 모듈을 통해 생성된 리소스를 검증합니다.

파이프라인이 성공적으로 배포된 후 다음 AWS 리소스가 생성되었는지 확인합니다.

  • 3개의 퍼블릭 서브넷과 3개의 프라이빗 서브넷, 인터넷 게이트웨이 및 NAT 게이트웨이가 있는 송신 VPC입니다.

  • 3개의 프라이빗 서브넷이 있는 Amazon EKS VPC.

  • 각각 3개의 프라이빗 서브넷이 있는 테넌트 1 및 테넌트 2 VPCs.

  • 모든 VPC 연결 및 각 프라이빗 서브넷으로 라우팅되는 전송 게이트웨이입니다.

  • 대상 CIDR 블록이 인 Amazon EKS 송신 VPC에 대한 정적 전송 게이트웨이 경로입니다0.0.0.0/0. 이는 모든 VPCs Amazon EKS 송신 VPC를 통해 아웃바운드 인터넷에 액세스할 수 있도록 하는 데 필요합니다.

DevOps
작업설명필요한 기술

CodeBuild 프로젝트가 VPC에 액세스할 수 locals.tf 있도록 업데이트합니다.

Amazon EKS 프라이빗 클러스터에 대한 추가 기능을 배포하려면 CodeBuild 프로젝트를 Amazon EKS VPC에 연결해야 합니다.

  1. demo/pipeline 폴더에서 locals.tf 파일을 열고 vpc_enabled 변수를 로 설정합니다true.

  2. run.sh 스크립트를 실행하여 파이프라인 모듈에 변경 사항을 적용합니다.

    demo/pipeline/locals.tf ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd init ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd plan ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd apply
DevOps

buildspec 파일을 업데이트하여 컴퓨팅 모듈을 빌드합니다.

templates 폴더의 모든 buildspec YAML 파일에서 TF_MODULE_TO_BUILD 변수 값을에서 network로 설정합니다compute.

TF_MODULE_TO_BUILD: "compute"
DevOps

테넌트 관리 차트 Helm의 values 파일을 업데이트합니다.

  1. 다음 위치에서 values.yaml 파일을 엽니다.

    cd cfg-terraform/demo/compute/cfg-tenant-mgmt

    파일은 다음과 같습니다.

    --- global: clusterRoles: operator: platform-tenant flux: flux-tenant-applier flux: tenantCloneBaseUrl: ${TEANT_BASE_URL} repoSecret: ${TENANT_REPO_SECRET} tenants: tenant-1: quotas: limits: cpu: 1 memory: 1Gi flux: path: overlays/tenant-1 tenant-2: quotas: limits: cpu: 1 memory: 2Gi flux: path: overlays/tenant-2
  2. globaltenants 섹션에서 요구 사항에 따라 구성을 업데이트합니다.

    • tenantCloneBaseUrl - 모든 테넌트에 대해 코드를 호스팅하는 리포지토리의 경로(모든 테넌트에 대해 동일한 Git 리포지토리 사용)

    • repoSecret - 글로벌 테넌트 Git 리포지토리에 인증하기 위해 SSH 키와 알려진 호스트를 보유하는 Kubernetes 보안 암호

    • quotas - 각 테넌트에 적용할 Kubernetes 리소스 할당량

    • flux path - 글로벌 테넌트 리포지토리의 테넌트 애플리케이션 YAML 파일 경로

DevOps

컴퓨팅 리소스를 검증합니다.

이전 단계에서 파일을 업데이트하면 CodePipeline이 자동으로 시작됩니다. 컴퓨팅 인프라에 대해 다음 AWS 리소스를 생성했는지 확인합니다.

  • 프라이빗 엔드포인트가 있는 Amazon EKS 클러스터

  • Amazon EKS 워커 노드

  • Amazon EKS 추가 기능: 외부 보안 암호, aws-loadbalancer-controllermetrics-server

  • GitOps 모듈, Flux Helm 차트, Cilium Helm 차트 및 테넌트 관리 Helm 차트

DevOps
작업설명필요한 기술

Kubernetes에서 테넌트 관리 리소스를 검증합니다.

다음 명령을 실행하여 Helm의 도움을 받아 테넌트 관리 리소스가 성공적으로 생성되었는지 확인합니다.

  1. 에 지정된 대로 테넌트 네임스페이스가 생성되었습니다values.yaml.

    kubectl get ns -A
  2. 할당량은에 지정된 대로 각 테넌트 네임스페이스에 할당됩니다values.yaml.

    kubectl get quota --namespace=<tenant_namespace>
  3. 할당량에 대한 세부 정보는 각 테넌트 네임스페이스에 대해 정확합니다.

    kubectl describe quota cpu-memory-resource-quota-limit -n <tenant_namespace>
  4. Cilium 네트워크 정책은 각 테넌트 네임스페이스에 적용되었습니다.

    kubectl get CiliumNetworkPolicy -A
DevOps

테넌트 애플리케이션 배포를 확인합니다.

다음 명령을 실행하여 테넌트 애플리케이션이 배포되었는지 확인합니다.

  1. Flux는 GitOps 모듈에 지정된 CodeCommit 리포지토리에 연결할 수 있습니다.

    kubectl get gitrepositories -A
  2. Flux kustomization 컨트롤러는 CodeCommit 리포지토리에 YAML 파일을 배포했습니다.

    kubectl get kustomizations -A
  3. 모든 애플리케이션 리소스는 테넌트 네임스페이스에 배포됩니다.

    kubectl get all -n <tenant_namespace>
  4. 각 테넌트에 대해 수신이 생성되었습니다.

    kubectl get ingress -n <tenant_namespace>

문제 해결

문제Solution

다음과 비슷한 오류 메시지가 표시됩니다.

Failed to checkout and determine revision: unable to clone unknown error: You have successfully authenticated over SSH. You can use Git to interact with AWS CodeCommit.

다음 단계에 따라 문제를 해결합니다.

  1. 테넌트 애플리케이션 리포지토리 확인: 비어 있거나 잘못 구성된 리포지토리로 인해 오류가 발생할 수 있습니다. 테넌트 애플리케이션 리포지토리에 필요한 코드가 포함되어 있는지 확인합니다.

  2. tenant_mgmt 모듈 재배포: tenant_mgmt 모듈 구성 파일에서 app 블록을 찾은 다음 deploy 파라미터를 로 설정합니다0.

    deploy = 0

    Terraform apply 명령을 실행한 후 deploy 파라미터 값을 다시 로 변경합니다1.

    deploy = 1
  3. 상태 다시 확인: 이전 단계를 실행한 후 다음 명령을 사용하여 문제가 지속되는지 확인합니다.

     kubectl get gitrepositories -A

    지속되면 Flux 로그를 자세히 살펴보거나 Flux 일반 문제 해결 가이드를 참조하세요.

관련 리소스

추가 정보

다음은 테넌트 애플리케이션을 배포하기 위한 리포지토리 구조의 예입니다.

applications sample_tenant_app ├── README.md ├── base │ ├── configmap.yaml │ ├── deployment.yaml │ ├── ingress.yaml │ ├── kustomization.yaml │ └── service.yaml └── overlays ├── tenant-1 │ ├── configmap.yaml │ ├── deployment.yaml │ └── kustomization.yaml └── tenant-2 ├── configmap.yaml └── kustomization.yaml