クラスター証明書を使用したKubernetesクラスターへのデプロイ (非推奨)

Kubernetesクラスターは、デプロイメントジョブの宛先になることがあります。次の場合:

• クラスターがGitLabとインテグレーションされている場合、特別なdeployment variableがジョブで使用できるようになり、設定は不要です。kubectlやhelmなどのツールを使用して、ジョブからクラスターとのインテグレーションをすぐに開始できます。
• GitLabクラスターインテグレーションを使用しない場合でも、クラスターにデプロイできます。ただし、ジョブからクラスターとのインテグレーションを行う前に、CI/CD変数を使用してKubernetesツールを自分で設定する必要があります。

デプロイ変数

デプロイメント変数では、デプロイトークンという名前の有効なgitlab-deploy-tokenが必要です。また、Kubernetesがレジストリにアクセスできるようにするには、デプロイメントジョブスクリプトに次のコマンドが必要です:

• Kubernetes 1.18以降を使用する場合:

  kubectl create secret docker-registry gitlab-registry --docker-server="$CI_REGISTRY" --docker-username="$CI_DEPLOY_USER" --docker-password="$CI_DEPLOY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL" -o yaml --dry-run=client | kubectl apply -f -

• Kubernetes 1.18より前のバージョンを使用する場合:

  kubectl create secret docker-registry gitlab-registry --docker-server="$CI_REGISTRY" --docker-username="$CI_DEPLOY_USER" --docker-password="$CI_DEPLOY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL" -o yaml --dry-run | kubectl apply -f -

Kubernetesクラスターインテグレーションは、これらのdeployment variableをGitLab CI/CDビルド環境でデプロイメントジョブに公開します。デプロイメントジョブには、定義されたターゲット環境があります。

カスタムネームスペース

Kubernetesインテグレーションは、自動生成されたネームスペースを持つKUBECONFIGをデプロイメントジョブに提供します。これは、<prefix>-<environment>という形式のプロジェクト環境固有のネームスペースを使用するようにデフォルト設定されています。ここで、<prefix>は<project_name>-<project_id>という形式です。詳細については、デプロイ変数を参照してください。

いくつかの方法でデプロイネームスペースをカスタマイズできます:

• ネームスペースを環境ごとにするか、プロジェクトごとにするかを選択できます。環境ごとのネームスペースは、本番環境と非本番環境間でリソースが混在するのを防ぐため、デフォルトの推奨設定です。
• プロジェクトレベルのクラスターを使用する場合、さらにネームスペースプレフィックスをカスタマイズできます。ネームスペースごとの環境を使用する場合、デプロイネームスペースは<prefix>-<environment>ですが、それ以外の場合は<prefix>のみです。
• non-managed（非管理対象） クラスターの場合、自動生成されたネームスペースはKUBECONFIGに設定されますが、ユーザーはその存在を確認する必要があります。.gitlab-ci.ymlのenvironment:kubernetes:namespaceを使用して、この値を完全にカスタマイズできます。

ネームスペースをカスタマイズすると、クラスターキャッシュをクリアするまで、既存の環境は現在のネームスペースにリンクされたままになります。

認証情報の保護

デフォルトでは、デプロイメントジョブを作成できるユーザーは誰でも、環境のデプロイメントジョブ内の任意のCI/CD変数にアクセスできます。これには、クラスター内の関連付けられたサービスアカウントで使用可能なすべてのシークレットへのアクセスを提供するKUBECONFIGが含まれます。本番環境認証情報を安全に保つために、次のいずれかと組み合わせて、protected environmentの使用を検討してください:

• GitLab管理対象クラスターと環境ごとのネームスペース。
• 保護環境ごとの環境スコープクラスター。同じクラスターを、複数の制限されたサービスアカウントで複数回追加できます。

KubernetesクラスターのWeb端末

Kubernetesインテグレーションにより、Web端末のサポートが環境に追加されます。これはDockerとKubernetesにあるexec機能に基づいているため、既存のコンテナに新しいシェルセッションが表示されます。このインテグレーションを使用するには、このページのデプロイメント変数を使用してKubernetesにデプロイする必要があります。これにより、すべてのデプロイ、レプリカセット、およびポッドに次の注釈が付けられるようになります:

• app.gitlab.com/env: $CI_ENVIRONMENT_SLUG
• app.gitlab.com/app: $CI_PROJECT_PATH_SLUG

$CI_ENVIRONMENT_SLUGと$CI_PROJECT_PATH_SLUGは、CI/CD変数の値です。

ターミナルを使用するには、プロジェクトオーナーであるか、maintainer権限を持っている必要があります。サポートは、環境の最初のポッド内の最初のコンテナに限定されています。

トラブルシューティング

デプロイメントジョブが開始される前に、GitLabは、特にデプロイメントジョブのために次のものを作成します:

• ネームスペース。
• サービスアカウント。

ただし、GitLabがそれらを作成できない場合があります。そのようなインスタンスでは、ジョブが次のメッセージで失敗する可能性があります:

This job failed because the necessary resources were not successfully created.

ネームスペースとサービスアカウントの作成時にこのエラーの原因を特定するには、ログを確認してください。

失敗の理由としては、次のものがあります:

• GitLabに提供したトークンに、GitLabに必要なcluster-admin権限がありません。
• KUBECONFIGまたはKUBE_TOKENのデプロイメント変数がありません。ジョブに渡されるには、一致するenvironment:nameが必要です。ジョブにenvironment:nameが設定されていない場合、Kubernetes認証情報は渡されません。