GitLab 차트를 위한 EKS 리소스 준비

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

GitLab 인스턴스를 완전히 활성화하려면 GitLab 차트를 배포하기 전에 몇 가지 리소스가 필요합니다.

EKS 클러스터 생성

더 쉽게 시작하려면 클러스터 생성을 자동화하는 스크립트가 제공됩니다. 또는 매뉴얼으로 클러스터를 생성할 수도 있습니다.

전제 조건:

클러스터를 매뉴얼으로 생성하려면 Amazon AWS Amazon EKS 시작하기를 참조하세요. EKS 클러스터에 EC2 관리 노드를 사용하고 Fargate 대신에 사용하세요. Fargate에는 여러 가지 제한 사항이 있으며 GitLab Helm 차트와 함께 사용할 수 없습니다.

스크립트로 클러스터 생성

EKS 사용자들을 위해 설정 프로세스의 많은 부분을 자동화하기 위해 부트스트랩 스크립트가 생성되었습니다. 이 스크립트를 실행하기 전에 이 리포지터리를 복제해야 합니다.

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

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

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

이 스크립트는 환경 변수 또는 명령행 인수에서 다양한 매개변수를 읽고 부트스트랩 또는 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 Service Operator를 고려할 수 있습니다.

note
AWS Service Operator를 활성화하려면 클러스터 내에서 역할을 관리하는 방법이 필요합니다. 초기 서비스 관리 작업은 타사 개발자들에 의해 제공됩니다. 관리자들은 배포를 계획할 때 이 점을 염두에 두어야 합니다.

영구 볼륨 관리

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 차트를 설치하면 연결된 Elastic Load Balancer (ELB)를 생성하는 인그레스가 배포됩니다. ELB의 DNS 이름을 미리 알 수 없기 때문에 Let’s Encrypt를 사용하여 HTTPS 인증서를 자동으로 제공하는 것이 어려울 수 있습니다.

자체 인증서를 사용하는 것을 권장하고, 그런 다음 원하는 DNS 이름을 생성된 ELB에 CNAME 레코드를 사용하여 매핑하세요. ELB는 생성되기 전에 호스트명을 검색할 필요가 있기 때문에 GitLab을 설치하기 전에 다음 지침을 따르세요.

note
AWS 로드 밸런서가 필요한 환경에서는 Amazon의 Elastic Load Balancers가 특별한 구성을 필요로 합니다. Cloud provider LoadBalancers를 참조하세요.

다음 단계

클러스터를 실행한 후 차트 설치를 계속하세요. global.hosts.domain 옵션을 통해 도메인 이름을 설정하고, global.hosts.externalIP 옵션을 통해 정적 IP 설정을 제외하십시오. 기존 Elastic IP를 사용할 계획이 아닌 경우에는 ELB의 호스트명을 가져오기 위해 Helm 설치 후에 다음을 사용할 수 있습니다.

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

RELEASEhelm install <RELEASE>에서 사용한 릴리스 이름으로 대체해야 합니다.