グループレベルのKubernetesクラスター（証明書ベース）（非推奨）

caution
この機能はGitLab 14.5で非推奨となりました。クラスターをGitLabに接続するには、GitLabエージェントを使用してください。

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

グループレベルのKubernetesクラスタを表示するには：

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. オペレーション > Kubernetesを選択します。

クラスター管理プロジェクト

クラスタ管理プロジェクトをクラスタにアタッチして、Ingressコントローラなど、インストールにcluster-admin の権限が必要な共有リソースを管理します。

RBACの互換性

  • GitLab 11.4で導入されました。
  • プロジェクト名前空間の制限は GitLab 11.5 で導入されました。

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

クラスターの優先順位

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

複数のKubernetesクラスタ

GitLab 13.2 で導入されました。

グループに複数の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はプロジェクト用に作成した名前空間とサービスアカウントのキャッシュを保存します。クラスター内のこれらのリソースを手動で変更すると、このキャッシュがクラスターと同期しなくなり、デプロイジョブが失敗することがあります。

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

  1. 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
  2. オペレーション > Kubernetesを選択します。
  3. クラスターを選択します。
  4. 詳細設定を展開します。
  5. Clear cluster cache]を選択します。

ベースドメイン

GitLab 11.8 で導入されました。

クラスター・レベルでのドメインにより、複数のKubernetesクラスターごとに複数のドメインをサポート ドメインを指定すると、Auto DevOpsステージで環境変数(KUBE_INGRESS_BASE_DOMAIN)として自動的に設定されます。

ドメインは、Ingress IPアドレスにワイルドカードDNSが設定されている必要があります。詳細はこちら。

環境スコープ

プロジェクトに複数のKubernetesクラスターを追加する場合、環境スコープで区別する必要があります。環境スコープは、環境固有のCI/CD変数が機能するのと同様に、クラスターを環境に関連付けます。

どの環境がクラスターの環境スコープに一致するかを評価する際には、クラスターの優先順位が適用されます。プロジェクト・レベルのクラスターが優先され、最も近い祖先グループが続き、そのグループの親グループが続きます。

例えば、プロジェクトに以下の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クラスタにデプロイされているかについては、クラスタ環境のドキュメントを参照してください。

ランナーのセキュリティ

Runnerを安全に設定するための重要な情報については、プロジェクトレベルのクラスタのためのRunnerのセキュリティのドキュメントを参照してください。

詳細情報

GitLabとKubernetesのインテグレーションについては、Kubernetesクラスターをご覧ください。