Preparing EKS resources for the GitLab chart

For a fully functional GitLab instance, you need a few resources before deploying the GitLab chart.

Creating the EKS cluster

Prerequisites:

• Install the prerequisites.
• Install eksctl.

To authenticate, eksctl uses the same options as the AWS command line. See the AWS documentation for how to use environment variables, or configuration files.

Size the cluster to meet the cluster requirements.

Use EC2 managed nodes for the EKS cluster, and not Fargate. Fargate has a number of limitations and is not supported for use with the GitLab Helm chart.

For the most up to date instructions, follow Amazon’s EKS getting started guide.

Administrators may also want to consider the new AWS Service Operator for Kubernetes to simplify this process.

Persistent Volume Management

There are two methods to manage volume claims on Kubernetes:

• Manually create a persistent volume.
• Automatic persistent volume creation through dynamic provisioning.

We currently recommend using manual provisioning of persistent volumes. Amazon EKS clusters default to spanning multiple zones. Dynamic provisioning, if not configured to use a storage class locked to a particular zone leads to a scenario where pods may exist in a different zone from storage volumes and be unable to access data. For more information, see how to provision persistent volumes.

In the Amazon EKS 1.23 and later clusters, regardless of whether manual or dynamic provisioning, you need to install the Amazon EBS CSI add-on on the cluster.

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*

External Access to GitLab

By default, installing the GitLab chart deploys the bundled Envoy Gateway, which creates an associated Elastic Load Balancer (ELB). Since the DNS names of the ELB cannot be known ahead of time, it’s difficult to utilize Let’s Encrypt to automatically provision HTTPS certificates.

We recommend using your own certificates, and then mapping your desired DNS name to the created ELB using a CNAME record. Since the ELB must be created first before its hostname can be retrieved, follow the next instructions to install GitLab.

Next Steps

Continue with the installation of the chart once you have the cluster up and running. Set the domain name via the global.hosts.domain option, but omit the static IP setting via the global.hosts.externalIP option unless you plan on using an existing Elastic IP.

After the Helm install, you can fetch your ELB’s hostname to place in the CNAME record with the following:

kubectl get gateway/RELEASE-gw -ojsonpath='{.status.addresses[0].value}'

RELEASE should be substituted with the release name used in helm install <RELEASE>.