EKSクラスタプロビジョニングのベストプラクティス

GitLabはEKSクラスタをAWSにプロビジョニングするために使用できますが、必然的に基本的なEKS設定に焦点を当てます。AWSツールを使用することで、高度なクラスター設定、自動化、および保守を行うことができます。

このドキュメントはGitLab自体をデプロイするためのクラスターではなく、そのために構築されたクラスターを対象としています：

GitLab を EKS 上にデプロイする情報はProvisioning GitLab Cloud Native Hybrid on AWS EKS にあります。

使用方法`eksctl`

eksctl を使用すると、EKS クラスタを構築する際に以下のことが可能になります：

さまざまなクラスター設定オプションがあります：
- オペレーティングシステムの選択：Amazon Linux 2、Windows、Bottlerocket
- ハードウェアアーキテクチャの選択： x86、ARM、GPU
- Kubernetesバージョンの選択（プロジェクトのアプリケーション用のGitLab管理クラスターには、特定のKubernetesバージョン要件があります。）
など、付加価値の高いものをクラスターにデプロイすることができます：
- クラスターのエンドポイントを非公開にし、パフォーマンステストを実行するためのバスティオンホスト。
- モニタリング用のPrometheusとGrafana。
K8sノードの自動スケーリングのためのEKS Autoscaler。
2つまたは3つの可用性ゾーン(AZ) 高可用性(HA) とコストコントロールのバランスをとるための分散。
スポット計算を指定する機能。

Amazon EKSアーキテクチャのクイックスタートガイドの詳細はこちら：

アプリデプロイのクラスターを設定し、そこから情報を抽出してGitLabにインテグレーションする方法を詳しくお読みください。

GitLab Runner Helm Chartを使ってランナーをクラスターにデプロイする方法をお読みください。

EKSクイックスタートではEFSプロビジョニングを提供しているため、ランナーキャッシュにEFSを使用するのが最良の方法です。最終的には、ランナーキャッシュにS3バケットを使用する情報をここで公開する予定です。