クラスター証明書を介して既存のクラスターを接続します（非推奨）。

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed

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

既存のKubernetesクラスターがある場合、それをプロジェクト、グループ、またはインスタンスに追加して、GitLabとのインテグレーションのメリットを享受できます。

前提要件

既存のクラスターをGitLabに追加するための前提条件を以下に示します。

すべてのクラスター

任意のクラスターをGitLabに追加するには、以下が必要です:

GitLab.comまたはGitLab Self-Managedインスタンスのアカウント。
グループレベルおよびプロジェクトレベルのクラスターのメンテナーロール。
インスタンスレベルのクラスターに対する管理者エリアへのアクセス。
Kubernetesクラスター。
kubectlを使用したクラスターへのクラスター管理アクセス。

EKS 、GKE、オンプレミス、およびその他のプロバイダーでクラスターをホストできます。オンプレミスおよびその他のプロバイダーでホストするには、EKSまたはGKEのいずれかの方法を使用して手順を確認し、クラスターの設定を手動で入力します。

GitLabは、arm64クラスターをサポートしていません。詳細については、Helm Tiller fails to install on arm64 clusterイシューを参照してください。

EKSクラスター

既存のEKSクラスターを追加するには、以下が必要です:

適切に構成されたワーカーノードを持つAmazon EKSクラスター。
kubectlがEKSクラスターにアクセスできるようにインストールおよび構成されていること。
アカウントのトークンに、クラスターの管理者権限があることを確認してください。

GKEクラスター

既存のGKEクラスターを追加するには、以下が必要です:

クラスターロールバインディングを作成するためのcontainer.clusterRoleBindings.create権限。アクセスを許可するには、Google Cloud documentationに従ってください。

既存のクラスターを追加する方法

Kubernetesクラスターをプロジェクト、グループ、またはインスタンスに追加するには、次の手順を実行します:

以下に移動します:
1. プロジェクトレベルのクラスターの場合は、プロジェクトの操作 > Kubernetesクラスターページ。
2. グループレベルのクラスターの場合は、グループの Kubernetesページ。
3. インスタンスレベルのクラスターの場合は、管理者エリアのKubernetesページ。
Kubernetesクラスターページで、アクションドロップダウンリストからConnect with a certificate（クラスターに接続）オプションを選択します。
クラスターに接続ページで、詳細を入力します:
1. Kubernetesクラスター名-クラスターに付ける名前。
2. 環境スコープ- このクラスターに関連付けられた関連環境。
3. API URL- これは、GitLabがKubernetes APIにアクセスするために使用するURIです。Kubernetesは複数のAPIを公開していますが、ここではすべてのAPIに共通する「ベース」URIが必要です。たとえば、https://kubernetes.example.comのように指定します（https://kubernetes.example.com/api/v1ではありません）。
  このコマンドを実行して、API URLを取得します:
```
kubectl cluster-info | grep -E 'Kubernetes master|Kubernetes control plane' | awk '/http/ {print $NF}'
```
4. CA certificate（必須）-認証するには、有効なKubernetes証明書がクラスターに必要です。ここではデフォルトで作成された証明書を使用します。
  1. kubectl get secretsでシークレットをリスト表示すると、default-token-xxxxxのような名前のシークレットが表示されます。以下の手順で使用するために、そのトークン名をコピーします。
  2. このコマンドを実行して、証明書を取得します:
    kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
    コマンドが証明書チェーン全体を返す場合は、チェーンの下部にあるルートCA証明書とすべての中間証明書をコピーする必要があります。チェーンファイルの構造は次のとおりです:
    -----BEGIN MY CERTIFICATE----- -----END MY CERTIFICATE----- -----BEGIN INTERMEDIATE CERTIFICATE----- -----END INTERMEDIATE CERTIFICATE----- -----BEGIN INTERMEDIATE CERTIFICATE----- -----END INTERMEDIATE CERTIFICATE----- -----BEGIN ROOT CERTIFICATE----- -----END ROOT CERTIFICATE-----
5. パイプライントークン - GitLabは、特定のnamespaceにスコープされているサービスアカウントトークンを使用してKubernetesに対して認証します。The token used should belong to a service account with cluster-admin privileges（使用されるトークンは、特権を持つサービスアカウントに属している必要があります）。このサービスアカウントを作成するには、次の手順を実行します:
  1. 内容が次のファイルgitlab-admin-service-account.yamlを作成します:
    apiVersion: v1 kind: ServiceAccount metadata: name: gitlab namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: gitlab-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: gitlab namespace: kube-system
  2. サービスアカウントとクラスターロールバインディングをクラスターに適用します:
    kubectl apply -f gitlab-admin-service-account.yaml
    クラスターレベルのロールを作成するには、container.clusterRoleBindings.create権限が必要です。この権限がない場合は、代わりに基本認証を有効にして、管理者としてkubectl applyコマンドを実行します:
    kubectl apply -f gitlab-admin-service-account.yaml --username=admin --password=<password>
    基本認証を有効にして、Google Cloud Consoleを使用してパスワード認証情報を取得できます。
    出力:
    serviceaccount "gitlab" created clusterrolebinding "gitlab-admin" created
  3. gitlabサービスアカウントのトークンを取得します:
    kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab | awk '{print $1}')
    <authentication_token>値を出力からコピーします:
    Name: gitlab-token-b5zv4 Namespace: kube-system Labels: <none> Annotations: kubernetes.io/service-account.name=gitlab kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1025 bytes namespace: 11 bytes token: <authentication_token>
6. GitLab管理クラスター - このクラスターのネームスペースとサービスアカウントをGitLabで管理する場合は、このチェックボックスをオンのままにします。詳細については、Managed clusters sectionを参照してください。
7. Project namespace（オプション）- これを記入する必要はありません。空白のままにすると、GitLabによって作成されます。また、次の点に注意してください:
  - 各プロジェクトには、一意のネームスペースが必要です。
  - より広範な権限を持つシークレット（defaultのシークレットなど）を使用している場合、プロジェクトのネームスペースがシークレットのネームスペースと一致するとは限りません。
  - プロジェクトのネームスペースとしてdefaultをnot（使用しないでください）。
  - 自分または他の誰かがプロジェクト用に特別にシークレットを作成した場合、通常は権限が制限されており、シークレットのネームスペースとプロジェクトのネームスペースが同じになることがあります。
Kubernetesクラスターを追加ボタンを選択します。

約10分後、クラスターの準備が完了します。

ロールベースのアクセス制御（RBAC）を無効にする（オプション）

GitLabインテグレーションを介してクラスターを接続する場合、クラスターがRBAC対応かどうかを指定できます。これは、特定の操作でGitLabがクラスターとやり取りする方法に影響します。作成時にRBAC有効クラスターチェックボックスをオンにしなかった場合、GitLabは、クラスターとのやり取り時にRBACが無効になっていると見なします。その場合は、インテグレーションが正しく機能するように、クラスターでRBACを無効にする必要があります。

RBACを無効にすると、クラスターで実行されているアプリケーション、またはクラスターに対して認証できるユーザーは、完全なAPIアクセス権を持つことになります。これはセキュリティ上の懸念事項であり、望ましくない可能性があります。

RBACを効果的に無効にするには、グローバル権限を適用してフルアクセスを許可します:

kubectl create clusterrolebinding permissive-binding \
  --clusterrole=cluster-admin \
  --user=admin \
  --user=kubelet \
  --group=system:serviceaccounts

トラブルシューティング

CA証明書とトークンのエラー認証時

Kubernetesクラスターの接続中にこのエラーが発生した場合:

There was a problem authenticating with your cluster.
Please ensure your CA Certificate and Token are valid

サービスアカウントトークンを適切に貼り付けていることを確認してください。一部のシェルは、サービスアカウントトークンに改行を追加して、無効にする場合があります。追加のスペースを削除し、エディタにトークンを貼り付けて、改行がないことを確認します。

証明書が有効でない場合も、このエラーが発生する可能性があります。証明書のサブジェクトの別名に、クラスターのAPIの正しいドメインが含まれていることを確認するには、次のコマンドを実行します:

echo | openssl s_client -showcerts -connect kubernetes.example.com:443 -servername kubernetes.example.com 2>/dev/null |
openssl x509 -inform pem -noout -text

-connect引数は、host:portの組み合わせを予期します。たとえば、https://kubernetes.example.comはkubernetes.example.com:443になります。-servername引数は、URIを含まないドメインを予期します（例: kubernetes.example.com）。