クラスタ証明書によるEKSクラスタの接続（非推奨）
GitLabを通じて、新しいクラスターを作成したり、Amazon Elastic Kubernetes Service(EKS) でホストされている既存のクラスターを追加したりすることができます。
既存のEKSクラスターを接続
すでにEKSクラスターがあり、それをGitLabに接続したい場合は、GitLabエージェントを使用します。
新しいEKSクラスターを作成
GitLabから新しいクラスターを作成するには、Infrastructure as Codeを使います。
クラスタ証明書を使ってEKS上に新しいクラスタを作成する方法（非推奨）
GitLab 14.0では非推奨です。
前提条件：
- Amazon Web Servicesアカウント。
- IAM リソースを管理する権限。
インスタンスレベルのクラスターについては、自己管理インスタンスの追加要件を参照してください。
証明書ベースの方法でプロジェクト、グループ、またはインスタンス用に新しいKubernetesクラスタを作成するには、以下の手順に従います：
さらなるステップ
- デフォルトのストレージ・クラスを作成します。
- アプリをEKSにデプロイします。
GitLab で新しい EKS クラスターを作成します。
プロジェクト、グループ、インスタンス用のEKSクラスターを新しく作成するには、クラスター証明書を使います：
- に移動します：
- プロジェクトのOperate > Kubernetesクラスターのページで、プロジェクトレベルのクラスターを確認します。
- グループのKubernetesページ、グループレベルのクラスター用。
- 管理エリアのKubernetesページ、インスタンスレベルのクラスター用。
- クラスター証明書とのインテグレーションを選択します。
-
Create new clusterタブで、Amazon EKSを選択し、後のステップに必要な
Account ID、External ID。 -
IAM管理コンソールで、IAMポリシーを作成します：
- 左側のパネルから、[Policies] を選択します。
- Create Policy］を選択すると、新しいウィンドウが開きます。
-
JSONタブを選択し、既存の内容の代わりに以下のスニペットを貼り付けます。これらの権限はGitLabにリソースを作成する権限を与えますが、削除する権限は与えません：
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "autoscaling:CreateAutoScalingGroup", "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeScalingActivities", "autoscaling:UpdateAutoScalingGroup", "autoscaling:CreateLaunchConfiguration", "autoscaling:DescribeLaunchConfigurations", "cloudformation:CreateStack", "cloudformation:DescribeStacks", "ec2:AuthorizeSecurityGroupEgress", "ec2:AuthorizeSecurityGroupIngress", "ec2:RevokeSecurityGroupEgress", "ec2:RevokeSecurityGroupIngress", "ec2:CreateSecurityGroup", "ec2:createTags", "ec2:DescribeImages", "ec2:DescribeKeyPairs", "ec2:DescribeRegions", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "eks:CreateCluster", "eks:DescribeCluster", "iam:AddRoleToInstanceProfile", "iam:AttachRolePolicy", "iam:CreateRole", "iam:CreateInstanceProfile", "iam:CreateServiceLinkedRole", "iam:GetRole", "iam:listAttachedRolePolicies", "iam:ListRoles", "iam:PassRole", "ssm:GetParameters" ], "Resource": "*" } ] }この処理中にエラーが発生しても、GitLabは変更をロールバックしません。リソースの削除は手動で行わなければなりません。関連するCloudFormationスタックを削除することで可能です。
- レビューポリシーを選択します。
- このポリシーの適切な名前を入力し、[ポリシーの作成] を選択します。これでこのウィンドウを閉じることができます。
Amazonでクラスターを準備します。
- クラスター用のEKS IAMロール（ロールA）を作成します。
- Amazonを使ったGitLab認証のために、別のEKS IAMロールを作成します（ロールB）。
クラスター用のEKS IAMロールを作成します。
IAM管理コンソールで、Amazon EKSクラスタIAMロールの説明に従ってEKS IAMロール（ロールA）を作成します。このロールは、Amazon EKSによって管理されるKubernetesクラスタが、サービスで使用するリソースを管理するために、あなたに代わって他のAWSサービスに呼び出しを行うことができるようにするために必要です。
GitLabがEKSクラスターを正しく管理するためには、ガイドが提案するポリシーに加えてAmazonEKSClusterPolicy 。
Amazon を使って GitLab 認証用の別の EKS IAM ロールを作成します。
IAM Management Consoleで、AWSでのGitLab認証用に別のIAMロール（ロールB）を作成します：
- AWS IAMコンソールで、左側のパネルからロールを選択します。
- Create roleを選択します。
- Select type of trusted entity]で、[Another AWS account]を選択します。
- Account IDフィールドにGitLabのアカウントIDを入力します。
- Require external IDにチェックを入れます。
- 外部IDフィールドにGitLabの外部IDを入力します。
- Nextを選択します：権限を選択し、先ほど作成したポリシーを選択します。
- 次へ」を選択します：タグ]を選択し、オプションでこのロールに関連付けたいタグを入力します。
- 次へ」を選択します：レビュアー」を選択します。
- ロール名とオプションの説明を入力フィールドに入力します。
-
ロールの作成」を選択します。新しいロール名が上部に表示されます。その名前を選択し、新しく作成されたロールから
Role ARN。
GitLabでクラスターのデータを設定します。
- GitLabに戻って、コピーしたロールARNをロールARNフィールドに入力します。
- Cluster Regionフィールドに、新しいクラスターで使用する予定のリージョンを入力します。GitLabはロールを認証する際に、あなたがこのリージョンにアクセスできることを確認します。
- Authenticate with AWSを選択します。
- クラスターの設定を調整します。
- Kubernetesクラスターの作成ボタンを選択します。
約10分後、クラスターは準備完了です。
kubectl をインストールして設定し、それを使ってクラスターを管理したい場合は、AWS の設定に AWS 外部 ID を追加する必要があります。AWS CLIの設定方法については、AWS CLIでIAMロールを使用するを参照してください。クラスターの設定
新しいクラスターを作成すると、以下の設定があります：
| 設定 | 説明 |
|---|---|
| Kubernetesクラスター名 | クラスターの名前です。 |
| 環境スコープ | 関連する環境。 |
| サービスのロール | EKS IAMロール（ロールA）。 |
| Kubernetesバージョン | クラスターのKubernetesバージョン。 |
| キーペア名 | ワーカーノードへの接続に使用するキーペアです。 |
| VPC | EKSクラスタリソースに使用するVPCです。 |
| サブネット | ワーカーノードが動作する VPC 内のサブネットです。2つ必要です。 |
| セキュリティグループ | ワーカーノードのサブネットに作成される、EKS が管理する Elastic Network Interfaces に適用するセキュリティグループです。 |
| インスタンスタイプ | ワーカーノードのインスタンスタイプです。 |
| ノード数 | ワーカーノードの数。 |
| GitLab 管理クラスター | GitLabにこのクラスターの名前空間とサービスアカウントを管理させるかどうかをチェックします。 |
デフォルトのストレージクラスを作成
Amazon EKSにはデフォルトのストレージクラスがないため、永続ボリュームへの要求が自動的に満たされません。Auto DevOpsの一環として、デプロイされたPostgreSQLインスタンスは永続ストレージを要求しますが、デフォルトのストレージクラスがなければ起動できません。
デフォルトのストレージクラスがまだ存在せず、必要な場合は、Amazonのストレージクラスに関するガイドに従って作成してください。
あるいは、プロジェクト変数POSTGRES_ENABLED をfalse に設定して PostgreSQL を無効にします。
アプリをEKSにデプロイします。
RBAC を無効にしてサービスをデプロイすると、Auto DevOps を活用してアプリをビルド、テスト、デプロイできるようになります。
まだ有効になっていない場合は、Auto DevOps を有効にします。ロードバランサーを解決するワイルドカード DNS エントリーが作成されている場合は、Auto DevOps 設定のdomain フィールドに入力します。そうしないと、デプロイしたアプリはクラスターの外部では利用できません。
GitLab は新しいパイプラインを作成し、アプリのビルド、テスト、デプロイを開始します。
パイプラインが終了すると、アプリはEKSで実行され、ユーザーが利用できるようになります。オペレーション > 環境を選択します。
GitLab は環境のリストとそのデプロイステータスを表示し、アプリへのブラウズ、モニタリングメトリクスの表示、さらには実行中のポッド上のシェルにアクセスするオプションも表示します。
セルフマネージドインスタンスの追加要件
セルフマネージドGitLabインスタンスを使用する場合、Amazonクレデンシャルを設定する必要があります。GitLabはこれらの認証情報を使ってAmazon IAMロールを引き受け、クラスターを作成します。
IAMユーザーを作成し、そのユーザーがEKSクラスターを作成するために必要なロールを引き受ける権限を持っていることを確認します。
たとえば、次のポリシー文書では、アカウント123456789012 で名前がgitlab-eks- で始まるロールを引き受けることを許可しています：
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/gitlab-eks-*"
}
}
Amazon認証の設定
GitLabでAmazon認証を設定するには、Amazon AWSコンソールでIAMユーザーのアクセスキーを生成し、以下の手順に従ってください：
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 設定] > [全般]を選択します。
- Amazon EKSを展開します。
- Amazon EKSインテグレーションを有効にするをチェックします。
- アカウントIDを入力します。
- アクセスキーとIDを入力してください。
- 変更を保存を選択します。
EKSアクセスキーとID
GitLab 13.7でインスタンスプロファイルを導入。
GitLab 13.7以降を使用している場合、インスタンスプロファイルを使用して必要な時にAWSから一時的な認証情報を動的に取得することができます。この場合、Access key ID とSecret access key フィールドは空欄にしておき、EC2インスタンスにIAMロールを渡します。
それ以外の場合は、Access key IDと Secret access keyにアクセスキーのクレデンシャルを入力します。
トラブルシューティング
新しいクラスターを作成するときによく遭遇するエラーは次のとおりです。
バリデーションに失敗しました：ロールARNは有効なAmazonリソース名でなければなりません。
Provision Role ARN が正しいか確認してください。有効な ARN の例：
arn:aws:iam::123456789012:role/gitlab-eks-provision'
アクセスが拒否されました：Access denied: ユーザーarn:aws:iam::x はリソースに対してsts:AssumeRole を実行する権限がありません：arn:aws:iam::y
このエラーは、Amazon 認証の設定で定義された資格情報が Provision Role ARN で定義されたロールに対応できない場合に発生します。確認してください：
- AWS 認証情報の初期セットには AssumeRole ポリシーがあります。
- Provision Roleは、指定されたリージョンにクラスターを作成するアクセス権を持っています。
-
アカウントIDと外部IDは、AWSのTrust relationshipsタブで定義された値と一致します：
この VPC のセキュリティグループをロードできませんでした。
設定フォームのオプションを入力する際、GitLabはこのエラーを返します。これは、GitLabが提供されたロールを成功裏に引き受けたものの、そのロールにはフォームに必要なリソースを取得する権限が不足しているためです。ロールに正しい権限を割り当てているか確認してください。
キーペアが読み込まれません
GitLabは指定されたクラスター・リージョンからキー・ペアをロードします。そのリージョンにキーペアが存在することを確認してください。
ROLLBACK_FAILED クラスター作成中
1つ以上のリソースを作成する際にGitLabがエラーに遭遇したため、作成プロセスが停止しました。関連するCloudFormation スタックを調べて、作成に失敗した特定のリソースを見つけることができます。
Cluster リソースがエラーThe provided role doesn't have the Amazon EKS Managed Policies associated with it. で失敗した場合、Role nameで指定されたロールが正しく設定されていません。
AmazonEKSClusterPolicy ポリシーを含める必要があります。