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

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

완전히 기능하는 GitLab 인스턴스를 위해 GitLab 차트를 배포하기 전에 몇 가지 리소스가 필요합니다.

EKS 클러스터 생성

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

사전 요구 사항:

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

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

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

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

  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 시작하기 가이드를 참조하세요.

관리자는 이 프로세스를 단순화하기 위해 Kubernetes를 위한 새로운 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 차트를 설치하면 관련된 Elastic Load Balancer (ELB)를 생성하는 Ingress가 배포됩니다. ELB의 DNS 이름을 미리 알 수 없기 때문에 Let’s Encrypt를 사용하여 HTTPS 인증서를 자동으로 프로비저닝하는 것이 어렵습니다.

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

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

다음 단계

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

Helm 설치 후에는 다음 명령어로 ELB의 호스트 이름을 가져와 CNAME 레코드에 배치할 수 있습니다.

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

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