クラスタ証明書を使用したKubernetesクラスタへのデプロイ（非推奨）
GitLab 14.5 で非推奨。
Kubernetesクラスターをデプロイジョブのデスティネーションにすることができます。もし
- クラスターがGitLabとインテグレーションされている場合、特別なデプロイ変数がジョブで利用できるようになり、設定は不要です。
kubectlやhelmなどのツールを使って、ジョブからすぐにクラスターとのやり取りを始めることができます。 - GitLabクラスターインテグレーションを使用しない場合でも、クラスターへのデプロイは可能です。ただし、ジョブからクラスターとやり取りする前に、CI/CD変数を使ってKubernetesツールを自分で設定する必要があります。
デプロイ変数
デプロイメント変数は、Kubernetesがレジストリにアクセスするために、gitlab-deploy-token という名前の有効なデプロイトークンと、デプロイジョブスクリプト内の以下のコマンドが必要です：
-
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クラスタインテグレーションは、GitLab CI/CDビルド環境のこれらのデプロイ変数をデプロイジョブに公開します。デプロイジョブはターゲット環境を定義しています。
| デプロイ変数 | 説明 |
|---|---|
KUBE_URL | APIのURLに等しい |
KUBE_TOKEN |
環境サービスアカウントのKubernetesトークン。GitLab 11.5以前では、KUBE_TOKEN 、クラスター統合のメインサービスアカウントのKubernetesトークンでした。 |
KUBE_NAMESPACE | プロジェクトのデプロイサービスアカウントに関連付けられた名前空間。形式は<project_name>-<project_id>-<environment> 。GitLabが管理するクラスターの場合、一致する名前空間はGitLabによってクラスター内に自動的に作成されます。クラスターがGitLab 12.2より前に作成された場合、デフォルトのKUBE_NAMESPACE は<project_name>-<project_id> に設定されます。 |
KUBE_CA_PEM_FILE | PEMデータを含むファイルへのパス。カスタムCAバンドルが指定された場合のみ表示されます。 |
KUBE_CA_PEM | (非推奨）生の PEM データ。カスタム CA バンドルが指定された場合のみ。 |
KUBECONFIG | このデプロイのkubeconfig を含むファイルへのパス。指定された場合、CA バンドルが埋め込まれます。この設定では、KUBE_TOKEN で定義されているのと同じトークンも埋め込まれるため、この変数だけが必要になる可能性があります。この変数名も.NET Frameworkが自動的に取得kubectl するので、.NET Frameworkを使用する場合は明示的に参照する必要は kubectlありません。 |
KUBE_INGRESS_BASE_DOMAIN | GitLab 11.8からは、この変数を使ってクラスターごとにドメインを設定できるようになりました。詳しくはクラスターのドメインを参照してください。 |
カスタム名前空間
Kubernetesインテグレーションは、デプロイジョブに自動生成された名前空間をKUBECONFIG 。デフォルトでは、<prefix>-<environment> 、<prefix> は<project_name>-<project_id>という形式のプロジェクト環境固有の名前空間を使用します。詳細については、デプロイ変数を参照してください。
デプロイメント ネームスペースは、いくつかの方法でカスタマイズできます：
- 環境ごとの名前空間またはプロジェクトごとの名前空間を選択できます。環境ごとの名前空間は、本番環境と非本番環境の間でリソースが混在することを防ぐため、デフォルトで推奨される設定です。
- プロジェクト・レベルのクラスターを使用する場合は、さらにネームスペース・プレフィックスをカスタマイズできます。namespace-per-environment を使用する場合、デプロイ名前空間は
<prefix>-<environment>になりますが、それ以外は<prefix>になります。 -
非管理クラスターの場合、自動生成されるネームスペースは
KUBECONFIGに設定されますが、その存在を確認する責任はユーザーにあります。.gitlab-ci.ymlのenvironment:kubernetes:namespaceを使用して、この値を完全にカスタマイズできます。
ネームスペースをカスタマイズすると、クラスター・キャッシュをクリアするまで、既存の環境は現在のネームスペースにリンクされたままになります。
資格情報の保護
デフォルトでは、デプロイジョブを作成できる人は誰でも環境のデプロイジョブ内のCI/CD変数にアクセスできます。これにはKUBECONFIG が含まれ、クラスター内の関連するサービスアカウントで利用可能なシークレットにアクセスできます。本番環境の認証情報を安全に保つには、以下のいずれかと組み合わせた保護環境の使用を検討してください：
- 環境ごとにGitLabが管理するクラスターと名前空間。
- 保護環境ごとの環境スコープ付きクラスター。同じクラスターを複数の制限付きサービスアカウントで複数回追加できます。
Kubernetesクラスタ用Webターミナル
GitLab 8.15 で導入されました。
Kubernetesインテグレーションは、あなたの環境に ウェブターミナルのサポートを追加します。これはDockerとKubernetesにあるexec の機能に基づいており、既存のコンテナで新しいシェルセッションを利用できます。このインテグレーションを使用するには、上記のデプロイ変数を使用してKubernetesにデプロイし、デプロイ、レプリカセット、ポッドにアノテーションを付ける必要があります：
app.gitlab.com/env: $CI_ENVIRONMENT_SLUGapp.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 クレデンシャルは渡されません。