EKSクラスターの追加

GitLabは新規および既存のEKSクラスターの追加をサポートしています。

EKSの要件

GitLabのインテグレーションを使ってAmazon EKS上に最初のクラスターを作成する前に、以下の要件が満たされていることを確認してください:

  • AmazonWeb Servicesアカウントが設定され、ログインできるようになります。
  • IAMリソースを管理する権限があります。
  • 既存のEKSクラスターを使用する場合:
    • ワーカーノードが適切に設定されたAmazon EKSクラスター。
    • kubectl をインストールし、EKSクラスターにアクセスできるように設定します。

自己管理インスタンスの追加要件

セルフマネージド GitLab インスタンスを使う場合は、まず GitLab に Amazon の認証情報を設定する必要があります。 これらの認証情報は、クラスターを作成するユーザが提供する 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-*"
  }
}

IAMユーザーのアクセスキーを生成し、その認証情報でGitLabを設定します:

  1. 管理エリア > 設定 >インテグレーションに移動し、AmazonEKSセクションを展開します。
  2. AmazonEKSインテグレーションを有効にします。
  3. Account IDAccess key IDSecret access key の各欄に、アカウントIDとアクセスキーの認証情報を入力してください。
  4. 変更を保存する]をクリックします。

新しいEKSクラスター

GitLab 12.5で導入されました

新しいKubernetesクラスターを作成し、プロジェクト、グループ、またはインスタンスに追加します:

  1. に移動します:
    • プロジェクトの オペレーション > Kubernetesページで、プロジェクトレベルのクラスターを作成します。
    • グループの Kubernetesページ、グループレベルのクラスターの場合。
    • 管理エリア > Kubernetes、インスタンスレベルのクラスターの場合。
  2. Add Kubernetes clusterをクリックします。
  3. Create new clusterタブでAmazonEKSをクリックします。次のステップで使用するAccount IDExternal ID
  4. IAM管理コンソールで、IAMロールを作成します:
    1. 左のパネルからロール」を選択します。
    2. ロールの作成をクリックします。
    3. Select type of trusted entityで、[別の AWS アカウント] を選択します。
    4. GitLabのアカウントIDをAccount ID フィールドに入力します。
    5. 外部IDが必要です
    6. GitLabの外部IDをExternal ID フィールドに入力します。
    7. 次へ:権限」をクリックします。
    8. Create Policyをクリックすると、新しいウィンドウが開きます。
    9. JSONタブを選択し、既存のコンテンツの代わりに以下のスニペットを貼り付けます:

      {
          "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:ListRoles",
                      "iam:PassRole",
                      "ssm:GetParameters"
                  ],
                  "Resource": "*"
              }
          ]
      }
      
      注意:これらの権限はGitLabにリソースを作成する権限を与えますが、削除する権限は与えません。 つまり、作成プロセス中にエラーが発生した場合、変更はロールバックされないので、手動でリソースを削除する必要があります。 これを行うには、関連するCloudFormationスタックを削除します。
    10. ポリシーのレビューをクリックします。
    11. このポリシーの適切な名前を入力し、[ポリシーの作成] をクリックします。 これで、このウィンドウを閉じることができます。
    12. ロールの作成」ウィンドウに戻り、先ほど作成したポリシーを選択します。
    13. 次へ:タグ」をクリックし、オプションでこのロールに関連付けたいタグを入力します。
    14. 次へ:レビュー」をクリックします。
    15. ロール名とオプションの説明を入力します。
    16. ロールの作成]をクリックすると、新しいロール名が上部に表示されます。 その名前をクリックし、新しく作成されたロールからRole ARN
  5. GitLabで、コピーしたロールARNをRole ARN フィールドに入力します。
  6. Authenticate with AWSをクリックします。
  7. クラスターの設定を選択します:
    • Kubernetesクラスター名- クラスターに付けたい名前。
    • Environment scope- このクラスターに関連する環境。
    • Kubernetes version- 使用するKubernetesのバージョン。 現在サポートされているバージョンは1.14のみです。
    • ロール名- Amazon EKSとKubernetesコントロールプレーンがあなたに代わってAWSリソースを管理することを許可するIAMロールを選択します。 このIAMロールは上記で作成したIAMロールとは別のもので、まだ存在しない場合は作成する必要があります。
    • Region- クラスターが作成される地域
    • キーペア名- 必要に応じて、ワーカーノードへの接続に使用するキーペアを選択します。
    • VPC- EKSクラスタリソースに使用するVPCを選択します。
    • サブネット- ワーカーノードが実行される VPC 内のサブネットを選択します。 少なくとも 2 つを選択する必要があります。
    • セキュリティグループ- ワーカーノードのサブネットに作成されるEKS管理下のElastic Network Interfacesに適用するセキュリティグループを選択します。
    • インスタンスタイプ- ワーカーノードのインスタンスタイプです。
    • Node count- ワーカーノードの数。
    • GitLab-managed cluster- このクラスターのネームスペースとサービスアカウントをGitLabに管理させたい場合はチェックを入れたままにしてください。 詳細はManaged clusterセクションを参照してください。
  8. 最後に「Kubernetesクラスターを作成」ボタンをクリックします。

約10分後、クラスターは準備完了となります。 ここで、いくつかの事前定義されたアプリケーションのインストールに進むことができます。

注:kubectlを使用してクラスターを管理するには、AWS CLI の IAM ロールに AWS 外部 ID を追加する必要があります。

新しいクラスターの作成に関するトラブルシューティング

新しいクラスターを作成するときによく遭遇するエラーは次のとおりです。

エラー: リクエストはステータスコード422で失敗しました。

初期認証フォームを送信する際、GitLabはあなたが提供したロールを判断できない場合、ステータスコード422のエラーを返します。 GitLabが提供するアカウントIDと外部IDでロールを正しく設定していることを確認してください。 GitLabで、正しいロールARNを入力していることを確認してください。

このVPCのセキュリティグループをロードできませんでした。

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

ROLLBACK_FAILED クラスター作成時

GitLab が 1 つ以上のリソースを作成する際にエラーに遭遇したため、作成プロセスが停止しました。 関連するCloudFormation スタックを調べて、作成に失敗した特定のリソースを見つけることができます。

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

注:このロールは、上記で作成したものと同じであってはなりません。 既存のEKSクラスターIAMロールがない場合は、作成する必要があります。

既存のEKSクラスター

既存のEKSクラスターの追加については、既存のKubernetesクラスターを参照してください。

デフォルトのストレージ・クラスの作成

Amazon EKSにはデフォルトのストレージクラスがないため、永続ボリュームへの要求が自動的に満たされません。 Auto DevOpsの一環として、デプロイされたPostgreSQLインスタンスは永続ストレージを要求しますが、デフォルトのストレージクラスがないと起動に失敗します。

デフォルトのストレージクラスがまだ存在せず、必要な場合は、Amazonのストレージクラスに関するガイドに従って作成してください。

あるいは、プロジェクト変数POSTGRES_ENABLEDfalseに設定して PostgreSQL を無効にしてください。

アプリをEKSにデプロイします。

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

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

Deploy Pipeline

新しいパイプラインが自動的に作成され、アプリのビルド、テスト、デプロイが開始されます。

パイプラインが終了すると、アプリがEKSで実行され、ユーザーが利用できるようになります。CI/CD > Environmentsをクリックします。

Deployed Environment

環境とそのデプロイステータスのリストが表示され、アプリへのブラウズ、モニタリングメトリクスの表示、さらには実行中のポッドのシェルにアクセスするオプションも表示されます。