GitLab 차트를 위한 EKS 자원 준비

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

완전히 기능적인 GitLab 인스턴스를 위해 GitLab 차트를 배포하기 전에 몇 가지 자원이 필요합니다.

EKS 클러스터 생성

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

전제 조건:

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

스크립트로 클러스터 생성

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

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

  1. 새 EKS 클러스터를 생성합니다.
  2. kubectl을 설정하고 클러스터에 연결합니다.

인증을 위해 eksctl은 AWS 명령줄과 동일한 옵션을 사용합니다. 환경 변수(https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html)나 구성 파일(https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)을 사용하는 방법에 대해 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 서비스 오퍼레이터를 고려할 수 있습니다.

참고: AWS 서비스 오퍼레이터를 활성화하려면 클러스터 내에서 역할을 관리하는 방법이 필요합니다. 초기 서비스 관리 작업은 제3자 개발자가 제공합니다. 관리자는 배포를 계획할 때 이 점을 염두에 두어야 합니다.

지속적 볼륨 관리

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 이름을 미리 알 수 없기 때문에 자동으로 HTTPS 인증서를 제공하기 위해 Let’s Encrypt를 활용하는 것이 어렵습니다.

사용자 고유의 인증서를 사용하고, 그 후에 원하는 DNS 이름을 ELB에 CNAME 레코드를 사용하여 매핑하는 것을 권장합니다. ELB의 호스트 이름을 검색하려면 먼저 ELB를 생성해야 하므로, GitLab을 설치하기 위한 다음 지침을 따르세요.

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

다음 단계

클러스터가 실행 중이라면 차트 설치를 계속하세요. global.hosts.domain 옵션을 통해 도메인 이름을 설정하고, 기존 Elastic IP를 사용할 계획이 아니라면 global.hosts.externalIP 옵션을 생략하세요.

Helm 설치 후 다음 명령을 사용하여 ELB의 호스트 이름을 검색하여 CNAME 레코드에 넣을 수 있습니다: 

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

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