GitLab 차트용 EKS 리소스 준비하기

Tier: Free, Premium, Ultimate Offering: Self-managed

프로젝트를 배포하기 전에 GitLab 차트를 배포하기 위해 몇 가지 리소스가 필요합니다.

EKS 클러스터 생성

시작하기 쉽도록 클러스터 생성을 자동화하는 스크립트를 제공합니다. 또는 수동으로 클러스터를 생성할 수도 있습니다.

전제 조건:

클러스터를 수동으로 생성하려면 Amazon AWS에서 Amazon EKS 시작하기를 참조하세요. EKS 클러스터에 EC2 관리형 노드를 사용하고 Fargate는 사용하지 않도록 합니다. Fargate에는 여러 가지 제한 사항이 있으며 GitLab Helm 차트와 호환되지 않습니다.

스크립트를 사용한 클러스터 생성

사용자들을 위해 설정 프로세스의 많은 부분을 자동화하는 부트스트랩 스크립트가 만들어졌습니다. 스크립트를 실행하기 전에 해당 리포지토리를 복제해야 합니다.

이 스크립트는 다음을 수행합니다.

  1. 새로운 EKS 클러스터 생성
  2. kubectl 설정 및 클러스터에 연결

인증을 위해 eksctl은 AWS 명령줄과 동일한 옵션을 사용합니다. 환경 변수 또는 구성 파일을 사용하는 방법에 대한 AWS 문서를 참조하세요.

스크립트는 환경 변수 또는 명령행 인수에서 여러 매개변수를 읽고 up을 사용하여 부트스트랩하거나 down을 사용하여 정리합니다.

아래 표는 모든 변수를 설명합니다.

변수 설명 기본값
REGION 클러스터가 위치한 지역 us-east-2
CLUSTER_NAME 클러스터의 이름 gitlab-cluster
CLUSTER_VERSION EKS 클러스터 버전 1.29
NUM_NODES 필요한 노드 수 2
MACHINE_TYPE 배포할 노드의 유형 m5.xlarge

원하는 매개변수를 전달하여 스크립트를 실행합니다. 기본 매개변수로도 작동할 수 있습니다. 

./scripts/eks_bootstrap_script up

스크립트는 작성된 EKS 리소스를 정리하는 데에도 사용할 수 있습니다. 

./scripts/eks_bootstrap_script down

수동 클러스터 생성

  • 8vCPU와 30GB RAM이 있는 클러스터를 권장합니다.

가장 최신의 지침은 Amazon의 EKS 시작 가이드를 따릅니다.

관리자는 또한 이 프로세스를 간소화하기 위해 새로운 AWS 서비스 오퍼레이터 for Kubernetes를 고려할 수 있습니다.

참고: AWS 서비스 오퍼레이터는 클러스터 내에서 역할을 관리하는 방법이 필요합니다. 초기 서비스 관리는 서드파티 개발자가 제공합니다. 배포 계획 시 관리자는 이 점을 염두에 두어야 합니다.

Amazon EKS용 영구 볼륨 관리

Kubernetes에서 볼륨 클레임을 관리하는 두 가지 방법이 있습니다.

  • 수동으로 영구 볼륨 생성
  • 동적 프로비저닝을 통한 자동 영구 볼륨 생성

우리는 현재 영구 볼륨의 수동 프로비저닝을 권장합니다. Amazon EKS 클러스터는 기본적으로 여러 가지 영역에 걸쳐 있습니다. 동적 프로비저닝은 특정 영역에 잠겨 있는 스토리지 클래스를 사용하지 않도록 구성되지 않는 한, 스토리지 볼륨과 다른 영역에 존재하는 팟이 데이터에 액세스할 수 없는 시나리오를 유발할 수 있습니다. 자세한 내용은 영구 볼륨 프로비저닝을 참조하세요.

Amazon EKS 1.23 이상 클러스터에서는 수동 또는 동적 프로비저닝 여부와 관계없이 Amazon EBS CSI 애드온을 클러스터에 설치해야 합니다. 

eksctl utils associate-iam-oidc-provider --cluster **CLUSTER_NAME** --approve

eksctl create iamserviceaccount \
    --name ebs-csi-controller-sa \
    --namespace kube-system \
    --cluster **CLUSTER_NAME** \
    --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
    --approve \
    --role-only \
    --role-name *ROLE_NAME*

eksctl create addon --name aws-ebs-csi-driver --cluster **CLUSTER_NAME** --service-account-role-arn arn:aws:iam::*AWS_ACCOUNT_ID*:role/*ROLE_NAME* --force

kubectl annotate serviceaccount ebs-csi-controller-sa -n kube-system eks.amazonaws.com/role-arn=arn:aws:iam::*AWS_ACCOUNT_ID*:role/*ROLE_NAME*

GitLab 외부 액세스

기본적으로 GitLab 차트를 설치하면 Ingress가 배포되어 관련된 Elastic Load Balancer (ELB)를 생성합니다. ELB의 DNS 이름이 사전에 알 수 없기 때문에 Let’s Encrypt를 사용하여 자동으로 HTTPS 인증서를 제공하는 것이 어렵습니다.

우리는 자체 인증서를 사용하는 것을 권장하고, 그런 다음 원하는 DNS 이름을 CNAME 레코드를 사용하여 생성된 ELB에 매핑합니다. ELB는 호스트 이름을 검색하려면 미리 생성해야하므로 다음 지침을 따라 GitLab을 설치하세요.

참고: AWS 로드 밸런서가 필요한 환경에서는 Amazon의 Elastic Load Balancers에 특별한 구성이 필요합니다. 클라우드 제공 업체 로드 밸런서를 참조하세요.

다음 단계

클러스터를 시작하고 실행한 후 차트를 설치하세요. global.hosts.domain 옵션을 통해 도메인 이름을 설정하고, global.hosts.externalIP 옵션을 통해 정적 IP 설정을 생략하세요. Helm 설치 후, 다음 명령을 사용하여 ELB의 호스트명을 검색하여 CNAME 레코드에 배치할 수 있습니다. 

kubectl get ingress/RELEASE-webservice-default -ojsonpath='{.status.loadBalancer.ingress[0].hostname}'

RELEASE은 helm install <RELEASE>에서 사용한 릴리스 이름으로 대체되어야 합니다.