クラスター証明書を使用したEKSクラスターへの接続（非推奨）

GitLabを通じて、新しいクラスターを作成したり、Amazon Elastic Kubernetes Service（Amazon EKS）でホストされている既存のクラスターを追加したりできます。

既存のEKSクラスターを接続する

すでにEKSクラスターがあり、GitLabに接続する場合は、Kubernetes向けGitLabエージェントを使用してください。

新しいEKSクラスターを作成する

GitLabから新しいクラスターを作成するには、Infrastructure as Codeを使用します。

クラスター証明書を使用したEKS上に新しいクラスターを作成する方法（非推奨）

前提要件:

• Amazon Web Servicesアカウント。
• IAMリソースを管理するための権限。

インスタンスレベルのクラスターについては、GitLab Self-Managedインスタンスの追加要件を参照してください。

証明書ベースの方法でプロジェクト、グループ、またはインスタンスの新しいKubernetesクラスターを作成するには:

1. クラスターのアクセス制御（RBACまたはABAC）を定義します。
2. GitLabでクラスターを作成します。
3. Amazonでクラスターを準備します。
4. GitLabでクラスターのデータを設定します。

追加の手順:

1. デフォルトのストレージクラスを作成する。
2. EKSにアプリをデプロイします。

GitLabで新しいEKSクラスターを作成します

クラスター証明書を使用して、プロジェクト、グループ、またはインスタンスの新しいEKSクラスターを作成するには:

1. 以下に移動します:
   • プロジェクトレベルのクラスターの場合は、プロジェクトの操作 > Kubernetesクラスターページ。
   • グループレベルのクラスターの場合は、グループのKubernetesページ。
   • インスタンスレベルのクラスターの場合は、管理者エリアのKubernetesページ。
2. Integrate with a cluster certificate（クラスター証明書とのインテグレーション）を選択します。
3. Create new cluster（新しいクラスターの作成）タブで、Amazon EKSを選択すると、後続の手順で必要となるAccount IDとExternal IDが表示されます。
4. IAM管理コンソールで、IAMポリシーを作成します:

   1. 左側のパネルからポリシーを選択します。

   2. Create Policy（ポリシーの作成）を選択します。新しいウィンドウが開きます。

   3. 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スタックを削除します。

   4. Review policy（ポリシーのレビュー）を選択します。

   5. このポリシーに適した名前を入力し、Create Policy（ポリシーの作成）を選択します。これでこのウィンドウを閉じることができます。

Amazonでクラスターを準備する

1. クラスターのEKS IAM role（EKS IAMロール）を作成します（role A（ロールA））。
2. AmazonとのGitLab認証のためにanother EKS IAM role（別のEKS IAMロール）を作成します（role B（ロールB））。

クラスターのEKS IAMロールを作成する

IAM管理コンソールで、EKS IAM role（EKS IAMロール）（role A（ロールA））をAmazon EKSクラスターのIAMロールの手順に従って作成します。このロールは、Amazon EKSによって管理されるKubernetesクラスターが、サービスで使用するリソースを管理するために、ユーザーに代わって他のAWSサービスを呼び出すことができるようにするために必要です。

GitLabがEKSクラスターを正しく管理するには、ガイドが提案するポリシーに加えてAmazonEKSClusterPolicyを含める必要があります。

AmazonとのGitLab認証のために別のEKS IAMロールを作成する

IAM管理コンソールで、AWSとのGitLab認証のために別のIAMロール（role B（ロールB））を作成します:

1. AWS IAMコンソールで、左側のパネルからロールを選択します。
2. ロールを作成するを選択します。
3. Select type of trusted entity（信頼されたエンティティの種類の選択）で、Another AWS account（別のAWSアカウント）を選択します。
4. GitLabからのアカウントIDをアカウントIDフィールドに入力します。
5. Require external ID（外部IDを必須にする）をオンにします。
6. GitLabからの外部IDを［External ID（外部ID）］フィールドに入力します。
7. 次へを選択します: 権限を選択し、作成したポリシーを選択します。
8. 次へを選択します: タグを選択し、必要に応じてこのロールに関連付けるタグを入力します。
9. 次へを選択します: 確認を選択します。
10. 表示されたフィールドに、ロール名とオプションの説明を入力します。
11. ロールを作成するを選択します。新しいロール名が上部に表示されます。名前を選択し、新しく作成されたロールからRole ARNをコピーします。

GitLabでクラスターのデータを設定する

1. GitLabに戻り、コピーしたAmazonリソースネームを［Role ARN（Amazonリソースネーム）］フィールドに入力します。
2. ［Cluster Region（クラスターリージョン）］フィールドに、新しいクラスターに使用する予定のリージョンを入力します。GitLabは、ロールを認証するときに、このリージョンへのアクセス権があることを確認します。
3. Authenticate with AWS（AWSで認証する）を選択します。
4. クラスターの設定を調整します。
5. Create Kubernetes cluster（Kubernetesクラスターの作成）ボタンを選択します。

約10分後、クラスターを使用できるようになります。

クラスターの設定

新しいクラスターを作成するときは、次の設定があります:

デフォルトのストレージクラスを作成する

Amazon EKSには、すぐに使用できるデフォルトのストレージクラスがないため、永続ボリュームのリクエストが自動的に実行されることはありません。Auto DevOpsの一部として、デプロイされたPostgreSQLインスタンスは永続ストレージをリクエストし、デフォルトのストレージクラスがないと開始できません。

まだ存在しない場合にデフォルトのストレージクラスを作成するには、ストレージクラスを参照してください。

または、プロジェクト変数POSTGRES_ENABLEDをfalseに割り当てて、PostgreSQLを無効にします。

EKSにアプリをデプロイする

RBACが無効になり、サービスがデプロイされると、Auto DevOpsを活用して、アプリをビルド、テスト、およびデプロイできるようになります。

まだ有効になっていない場合は、Auto DevOpsを有効にします。ロードバランサーに解決されるワイルドカードDNSエントリが作成された場合は、Auto DevOps設定のdomainフィールドに入力します。そうでない場合、デプロイされたアプリはクラスターの外部では外部から利用できません。

GitLabは新しいパイプラインを作成し、アプリのビルド、テスト、およびデプロイを開始します。

パイプラインが終了すると、アプリはEKSで実行され、ユーザーが利用できるようになります。操作 > 環境を選択します。

GitLabは、環境とそのデプロイステータスのリスト、およびアプリを閲覧したり、モニタリングメトリクスを表示したり、実行中のポッドでShellにアクセスしたりするためのオプションを表示します。

GitLab Self-Managedインスタンスの追加要件

GitLab Self-Managedを使用している場合は、Amazon認証情報を設定する必要があります。GitLabはこれらの認証情報を使用して、Amazon Web Services 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ユーザーのアクセスキーを生成し、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。
2. 設定 > 一般を選択します。
3. Amazon EKSを展開します。
4. Amazon EKS連携を有効にするをオンにします。
5. アカウントIDを入力します。
6. アクセスキーとIDを入力します。
7. 変更を保存を選択します。

EKSアクセスキーとID

インスタンスプロファイルを使用して、必要に応じてAWSから一時的な認証情報を動的に取得することができます。この場合は、Access key IDフィールドとSecret access keyフィールドを空白のままにして、IAMロールをEC2インスタンスに渡します。

それ以外の場合は、Access key ID（アクセスキーID）とSecret access key（シークレットアクセスキー）にアクセスキー認証情報を入力します。

トラブルシューティング

新しいクラスターを作成する際に、次のエラーがよく発生します。

検証に失敗しました: Amazonリソースネームは有効なAmazon Web Servicesリソース名である必要があります

Provision Role ARNが正しいことを確認してください。有効なAmazonリソースネームの例:

arn:aws:iam::123456789012:role/gitlab-eks-provision'

アクセスが拒否されました」: ユーザーにリソースarn:aws:iam::yに対するsts:AssumeRoleを実行する権限がありません

このエラーは、Amazon認証の設定で定義された認証情報が、プロビジョンロールAmazonリソースネームによって定義されたロールを引き受けることができない場合に発生します:

User `arn:aws:iam::x` is not authorized to perform: `sts:AssumeRole` on resource: `arn:aws:iam::y`

以下を確認してください:

1. AWS認証情報の初期セットにAssumeRoleポリシーがある。

2. プロビジョンロールには、指定されたリージョンにクラスターを作成するアクセス権があります。

3. アカウントIDと外部IDが、AWSの［Trust relationships（信頼関係）］タブで定義された値と一致すること:

   

このVPCのセキュリティグループを読み込むことができませんでした

設定フォームでオプションを入力されたとき、GitLabは、GitLabが提供されたロールを正常に引き受けましたが、そのロールにはフォームに必要なリソースを取得するための十分な権限がないため、このエラーを返します。ロールに正しい権限が割り当てられていることを確認してください。

キーペアが読み込まれていません

GitLabは、指定されたCluster Region（クラスターリージョン）からキーペアを読み込むします。キーペアがそのリージョンに存在することを確認してください。

クラスターの作成中にROLLBACK_FAILED

1つまたは複数のリソースの作成中にGitLabでエラーが発生したため、作成プロセスが停止しました。関連付けられているCloudFormationスタックを調べて、作成に失敗した特定のリソースを見つけることができます。

ClusterリソースがエラーThe provided role doesn't have the Amazon EKS Managed Policies associated with it.で失敗した場合、Role name（ロール名）で指定されたロールが正しく設定されていません。