- アプリケーションのインストール
- RBACの互換性
- クラスターの優先順位
- 複数のKubernetesクラスター
- GitLabが管理するクラスター
- ベースドメイン
- 環境スコープ
- クラスター環境
- ランナーのセキュリティ
- 詳細情報
グループレベルのKubernetesクラスター
GitLab 11.6から導入されました。
プロジェクトレベルやインスタンスレベルのKubernetesクラスタと同様に、グループレベルのKubernetesクラスタでは、Kubernetesクラスタをグループに接続できるため、複数のプロジェクトで同じクラスタを使用できます。
アプリケーションのインストール
GitLabはグループレベルのクラスターにいくつかのアプリケーションをインストールして管理することができます。 グループクラスターのアプリケーションのインストール、アップグレード、アンインストール、トラブルシューティングの詳細については、GitLab Managed Appsを参照してください。
RBACの互換性
Kubernetesクラスターを持つグループ配下の各プロジェクトに対して、GitLabはedit
権限を持つ制限付きサービスアカウントをプロジェクト名前空間に作成します。
クラスターの優先順位
プロジェクトのクラスターが使用可能で無効になっていない場合、GitLabはプロジェクトを含むグループに属するクラスターを使用する前に、プロジェクトのクラスターを使用します。 サブグループの場合、GitLabはプロジェクトに最も近い祖先グループのクラスターを使用します。
複数のKubernetesクラスター
- 13.2でGitLab Coreに導入されました。
グループに複数のKubernetesクラスターを関連付け、開発、ステージング、本番といった環境ごとに異なるクラスターをメンテナーすることができます。
別のクラスターを追加する場合は、新しいクラスターを他のクラスターと区別するために環境スコープを設定します。
GitLabが管理するクラスター
GitLabにクラスターを管理させることもできます。 GitLabがクラスターを管理する場合、プロジェクトのリソースは自動的に作成されます。 GitLabが作成するリソースの詳細については、アクセスコントロールのセクションを参照してください。
GitLabによって管理されていないクラスターの場合、プロジェクト固有のリソースは自動的に作成されません。 GitLabによって管理されていないクラスターを使用したデプロイにAuto DevOpsを使用する場合は、次のことを確認する必要があります:
- プロジェクトのデプロイサービスアカウントには、
KUBE_NAMESPACE
にデプロイする権限があります。 -
KUBECONFIG
への変更が正しく反映されますKUBE_NAMESPACE
(これは自動的ではありません)。KUBE_NAMESPACE
直接KUBE_NAMESPACE
編集するKUBE_NAMESPACE
ことはお勧めしません。
クラスター・キャッシュのクリア
GitLab 12.6 で導入されました。
GitLab にクラスターの管理を任せることにした場合、GitLab はプロジェクト用に作成した名前空間とサービスアカウントのキャッシュを保存します。 クラスター内のこれらのリソースを手動で変更すると、このキャッシュがクラスターと同期しなくなり、デプロイジョブが失敗することがあります。
キャッシュをクリアするには
- グループの Kubernetesページに移動し、クラスターを選択します。
- 詳細設定セクションを展開します。
- Clearclustercache]をクリックします。
ベースドメイン
GitLab 11.8 で導入されました。
クラスター単位でドメインを指定することで、複数のKubernetesクラスターごとに複数のドメインをサポート ドメインを指定すると、Auto DevOpsのステージで環境変数(KUBE_INGRESS_BASE_DOMAIN
)として自動的に設定されます。
ドメインは、Ingress IPアドレスにワイルドカードDNSが設定されている必要があります。
環境スコープ
プロジェクトに複数のKubernetesクラスタを追加する場合は、環境スコープで区別する必要があります。 環境スコープは、環境固有の変数が機能するのと同様に、クラスタを環境に関連付けます。
どの環境がクラスタの環境スコープに一致するかを評価する際には、クラスタの優先順位が適用されます。 プロジェクトレベルのクラスタが優先され、その次に最も近い祖先グループ、そのグループの親というように続きます。
例えば、プロジェクトに以下のKubernetesクラスターがある場合:
クラスター | 環境範囲 | どこで |
---|---|---|
プロジェクト | *
| プロジェクト |
ステージ | staging/*
| プロジェクト |
製造 | production/*
| プロジェクト |
テスト | test
| グループ |
開発者 | *
| グループ |
そして、.gitlab-ci.yml
に以下の環境が設定されています:
stages:
- test
- deploy
test:
stage: test
script: sh test
deploy to staging:
stage: deploy
script: make deploy
environment:
name: staging/$CI_COMMIT_REF_NAME
url: https://staging.example.com/
deploy to production:
stage: deploy
script: make deploy
environment:
name: production/$CI_COMMIT_REF_NAME
url: https://example.com/
結果はこうです:
- プロジェクトクラスタは、
test
ジョブに使用されます。 - ステージングクラスタは
deploy to staging
ジョブに使用されます。 -
deploy to production
、本番クラスタがジョブに使用されます。
クラスター環境
どのCI環境がKubernetesクラスタにデプロイされているかについては、クラスタ環境のドキュメントを参照してください。
ランナーのセキュリティ
GitLab Runnerを安全に設定するための重要な情報については、プロジェクトレベルのクラスター用のRunnersのセキュリティのドキュメントを参照してください。
詳細情報
GitLabとKubernetesのインテグレーションについては、Kubernetesクラスターをご覧ください。