グループレベルのKubernetesクラスター

GitLab 11.6から導入されました。

プロジェクトレベルやインスタンスレベルのKubernetesクラスタと同様に、グループレベルのKubernetesクラスタでは、Kubernetesクラスタをグループに接続できるため、複数のプロジェクトで同じクラスタを使用できます。

アプリケーションのインストール

GitLabはグループレベルのクラスターにいくつかのアプリケーションをインストールして管理することができます。 グループクラスターのアプリケーションのインストール、アップグレード、アンインストール、トラブルシューティングの詳細については、GitLab Managed Appsを参照してください。

RBACの互換性

Kubernetesクラスターを持つグループ配下の各プロジェクトに対して、GitLabはedit 権限を持つ制限付きサービスアカウントをプロジェクト名前空間に作成します。

クラスターの優先順位

プロジェクトのクラスターが使用可能で無効になっていない場合、GitLabはプロジェクトを含むグループに属するクラスターを使用する前に、プロジェクトのクラスターを使用します。 サブグループの場合、GitLabはプロジェクトに最も近い祖先グループのクラスターを使用します。

複数のKubernetesクラスター

グループに複数のKubernetesクラスターを関連付け、開発、ステージング、本番といった環境ごとに異なるクラスターをメンテナーすることができます。

別のクラスターを追加する場合は、新しいクラスターを他のクラスターと区別するために環境スコープを設定します。

GitLabが管理するクラスター

GitLabにクラスターを管理させることもできます。 GitLabがクラスターを管理する場合、プロジェクトのリソースは自動的に作成されます。 GitLabが作成するリソースの詳細については、アクセスコントロールのセクションを参照してください。

GitLabによって管理されていないクラスターの場合、プロジェクト固有のリソースは自動的に作成されません。 GitLabによって管理されていないクラスターを使用したデプロイにAuto DevOpsを使用する場合は、次のことを確認する必要があります：

  • プロジェクトのデプロイサービスアカウントには、KUBE_NAMESPACEにデプロイする権限があります。
  • KUBECONFIG への変更が正しく反映されますKUBE_NAMESPACE（これは自動的ではありません）。KUBE_NAMESPACE直接KUBE_NAMESPACE編集するKUBE_NAMESPACEことはお勧めしません。
注：クラスターにアプリケーションをインストールする場合、自分でクラスターを管理することを選択しても、GitLabはアプリケーションの実行に必要なリソースを作成します。

クラスター・キャッシュのクリア

GitLab 12.6 で導入されました。

GitLab にクラスターの管理を任せることにした場合、GitLab はプロジェクト用に作成した名前空間とサービスアカウントのキャッシュを保存します。 クラスター内のこれらのリソースを手動で変更すると、このキャッシュがクラスターと同期しなくなり、デプロイジョブが失敗することがあります。

キャッシュをクリアするには

  1. グループの Kubernetesページに移動し、クラスターを選択します。
  2. 詳細設定セクションを展開します。
  3. 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クラスターをご覧ください。