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

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

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

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
2. 操作 > Kubernetesを選択します。

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

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

RBACの互換性

Kubernetesクラスターを持つグループのプロジェクトごとに、GitLabはプロジェクトのネームスペースにedit権限を持つ制限付きサービスアカウントを作成します。

クラスターの優先順位

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

複数のKubernetesクラスター

複数のKubernetesクラスターをグループに関連付け、開発、ステージング、本番環境など、さまざまな環境に対して異なるクラスターを維持できます。

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

GitLab管理のクラスター

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

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

• プロジェクトのデプロイサービスアカウントには、KUBE_NAMESPACEへのデプロイ権限があります。
• KUBECONFIGは、KUBE_NAMESPACEへの変更を正しく反映しています（これは自動ではありません）。KUBE_NAMESPACEを直接編集することはお勧めできません。

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

GitLabがクラスターを管理できるように選択した場合、GitLabは、プロジェクト用に作成するネームスペースとサービスアカウントのキャッシュされたバージョンを保存します。これらのリソースをクラスターで手動で変更すると、このキャッシュがクラスターと同期しなくなり、デプロイメントジョブが失敗する可能性があります。

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

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
2. 操作 > Kubernetesを選択します。
3. クラスターを選択します。
4. Advanced settings（高度な設定）を展開するします。
5. クラスターのキャッシュを削除を選択します。

ベースドメイン

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

ドメインには、Ingress IPアドレスに構成されたワイルドカードDNSが必要です。詳細。

環境スコープ

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

クラスターの環境スコープに一致する環境を評価する際に、クラスターの優先順位が有効になります。プロジェクトレベルのクラスターが優先され、次に最も近い祖先グループ、次にそのグループの親というようになります。

たとえば、プロジェクトに次のKubernetesクラスターがある場合:

そして、次の環境が.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を安全に構成する方法に関する重要な情報については、プロジェクトレベルのクラスターのRunnerのセキュリティに関するドキュメントを参照してください。

詳細情報

GitLabとKubernetesの統合については、Kubernetesクラスターを参照してください。