• EKSクラスターの作成
  • スクリプトによるクラスター作成
  • 手動クラスター作成
• 永続ボリューム管理
• GitLab への外部アクセス
• 次のステップ

GitLabチャート用のEKSリソースの準備

GitLabインスタンスを完全に機能させるには、GitLabチャートをデプロイする前にいくつかのリソースが必要です。

EKSクラスターの作成

簡単に始めるために、クラスター作成を自動化するスクリプトが提供されています。手動でクラスターを作成することもできます。

前提条件：

• 前提条件をインストールします。
• eksctlをインストールします。

手動でクラスターを作成するには、Amazon AWS Getting started with Amazon EKSを参照してください。EKSクラスターにはFargateではなくEC2マネージドノードを使用します。Fargateには多くの制限があり、GitLab Helmチャートでの使用はサポートされていません。

スクリプトによるクラスター作成

ブートストラップスクリプトは、EKS上のユーザーのセットアッププロセスの大部分を自動化するために作成されました。スクリプトを実行する前に、このリポジトリをクローンする必要があります。

このスクリプトは

1. 新しいEKSクラスターを作成します。
2. kubectl をセットアップし、クラスターに接続します。

認証のために、eksctl は AWS コマンドラインと同じオプションを使用します。環境変数や 設定ファイルを使用する方法については、AWSのドキュメントを参照してください。

スクリプトは、環境変数やコマンドライン引数、ブートストラップ用の引数up やクリーンアップ用の引数down から様々なパラメータを読み込みます。

以下の表はすべての変数について説明しています。

必要なパラメータを指定してスクリプトを実行します。デフォルトのパラメータでも動作します。

./scripts/eks_bootstrap_script up

このスクリプトは、作成されたEKSリソースのクリーンアップにも使用できます：

./scripts/eks_bootstrap_script down

手動クラスター作成

• 8vCPU、30GBのRAMを搭載したクラスターを推奨します。

最新の手順については、AmazonのEKSスタートガイドを参照してください。

管理者は、このプロセスを簡素化するために、新しいAWS Service Operator for Kubernetesを検討することもできます。

永続ボリューム管理

Kubernetesでボリュームクレームを管理するには、2つの方法があります：

• 手動で永続ボリュームを作成します。
• ダイナミック・プロビジョニングによる永続ボリュームの自動作成。

現在、永続ボリュームの手動プロビジョニングの使用を推奨しています。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証明書を自動的にプロビジョニングすることは困難です。

独自の証明書を使用し、CNAMEレコードを使用して作成したELBに希望のDNS名をマッピングすることをお勧めします。ELBを作成してからでないとホスト名を取得できないので、次の手順に従ってGitLabをインストールします。

次のステップ

クラスターを稼働させたら、Chartのインストールを続けます。ドメイン名はglobal.hosts.domain オプションで設定しますが、既存のElastic IPを使用する予定がない限り、global.hosts.externalIP オプションによる静的IP設定は省略します。

Helmインストール後、CNAMEレコードに配置するELBのホスト名を以下のようにして取得できます：

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

RELEASE はhelm install <RELEASE> で使われているリリース名に置き換えてください。