EKSクラスターの追加
GitLabは新規および既存のEKSクラスターの追加をサポートしています。
EKSの要件
GitLabのインテグレーションを使ってAmazon EKS上に最初のクラスターを作成する前に、以下の要件が満たされていることを確認してください:
- AmazonWeb Servicesアカウントが設定され、ログインできるようになります。
- IAMリソースを管理する権限があります。
- 既存の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を設定します:
- 管理エリア > 設定 >インテグレーションに移動し、AmazonEKSセクションを展開します。
- AmazonEKSインテグレーションを有効にします。
-
Account ID
、Access key ID
、Secret access key
の各欄に、アカウントIDとアクセスキーの認証情報を入力してください。 - 変更を保存する]をクリックします。
新しいEKSクラスター
GitLab 12.5で導入されました。
新しいKubernetesクラスターを作成し、プロジェクト、グループ、またはインスタンスに追加します:
- に移動します:
- プロジェクトの オペレーション > Kubernetesページで、プロジェクトレベルのクラスターを作成します。
- グループの Kubernetesページ、グループレベルのクラスターの場合。
- 管理エリア > Kubernetes、インスタンスレベルのクラスターの場合。
- Add Kubernetes clusterをクリックします。
-
Create new clusterタブでAmazonEKSをクリックします。次のステップで使用する
Account ID
、External ID
。 -
IAM管理コンソールで、IAMロールを作成します:
- 左のパネルから「ロール」を選択します。
- ロールの作成をクリックします。
-
Select type of trusted entity
で、[別の AWS アカウント] を選択します。 - GitLabのアカウントIDを
Account ID
フィールドに入力します。 - 外部IDが必要です。
- GitLabの外部IDを
External ID
フィールドに入力します。 - 次へ:権限」をクリックします。
- Create Policyをクリックすると、新しいウィンドウが開きます。
-
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スタックを削除します。 - ポリシーのレビューをクリックします。
- このポリシーの適切な名前を入力し、[ポリシーの作成] をクリックします。 これで、このウィンドウを閉じることができます。
- ロールの作成」ウィンドウに戻り、先ほど作成したポリシーを選択します。
- 次へ:タグ」をクリックし、オプションでこのロールに関連付けたいタグを入力します。
- 次へ:レビュー」をクリックします。
- ロール名とオプションの説明を入力します。
-
ロールの作成]をクリックすると、新しいロール名が上部に表示されます。 その名前をクリックし、新しく作成されたロールから
Role ARN
。
- GitLabで、コピーしたロールARNを
Role ARN
フィールドに入力します。 - Authenticate with AWSをクリックします。
- クラスターの設定を選択します:
- 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セクションを参照してください。
- 最後に「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クラスター
既存のEKSクラスターの追加については、既存のKubernetesクラスターを参照してください。
デフォルトのストレージ・クラスの作成
Amazon EKSにはデフォルトのストレージクラスがないため、永続ボリュームへの要求が自動的に満たされません。 Auto DevOpsの一環として、デプロイされたPostgreSQLインスタンスは永続ストレージを要求しますが、デフォルトのストレージクラスがないと起動に失敗します。
デフォルトのストレージクラスがまだ存在せず、必要な場合は、Amazonのストレージクラスに関するガイドに従って作成してください。
あるいは、プロジェクト変数POSTGRES_ENABLED
をfalse
に設定して PostgreSQL を無効にしてください。
アプリをEKSにデプロイします。
RBAC を無効にしてサービスをデプロイすると、Auto DevOps を活用してアプリをビルド、テスト、デプロイできるようになります。
まだ有効になっていない場合は、Auto DevOpsを有効にします。 ロードバランサーを解決するワイルドカードDNSエントリが作成されている場合は、Auto DevOps設定のdomain
フィールドに入力します。そうしないと、デプロイされたアプリはクラスター外部で利用できなくなります。
新しいパイプラインが自動的に作成され、アプリのビルド、テスト、デプロイが開始されます。
パイプラインが終了すると、アプリがEKSで実行され、ユーザーが利用できるようになります。CI/CD > Environmentsをクリックします。
環境とそのデプロイステータスのリストが表示され、アプリへのブラウズ、モニタリングメトリクスの表示、さらには実行中のポッドのシェルにアクセスするオプションも表示されます。