クラスター証明書による既存クラスターとの接続（非推奨）

GitLab 14.5 で非推奨。

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

既存のKubernetesクラスターがある場合は、プロジェクト、グループ、インスタンスに追加してGitLabとのインテグレーションを利用することができます。

前提条件

既存のクラスターをGitLabに追加するには、以下の前提条件を参照してください。

全てのクラスター

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

  • GitLab.comアカウントか、GitLab 12.5以降を実行しているセルフマネージドインストールのアカウント。
  • グループレベルとプロジェクトレベルのクラスターのメンテナーのロール。
  • インスタンス・レベル・クラスタの管理領域へのアクセス。
  • Kubernetesクラスター。
  • kubectl を使ったクラスタへのクラスタ管理アクセス。

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

caution
GitLabはarm64 クラスターを arm64サポートしていません。詳しくはarm64 イシューHelm Tiller fails to install on arm64cluster をarm64 ご覧 arm64ください。

EKSクラスタ

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

  • ワーカーノードが適切に設定されたAmazon EKSクラスター。
  • kubectl がインストールされ、EKS クラスターにアクセスできるように設定されていること。
  • アカウントのトークンがクラスターの管理者権限を持っていることを確認します。

GKEクラスタ

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

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

プロジェクト、グループ、インスタンスにKubernetesクラスターを追加するには、以下の手順に従います：

  1. に移動します：
    1. プロジェクトのページにアクセスします。Operate > Kubernetes clustersページで、プロジェクトレベルのクラスターを確認します。
    2. グループのページ。Kubernetesページ、グループレベルのクラスタの場合。
    3. 管理エリアのKubernetesページ、インスタンスレベルのクラスター用。
  2. Kubernetesクラスター]ページで、[アクション]ドロップダウンリストから[証明書で接続]オプションを選択します。
  3. クラスターの接続ページで、詳細を入力します：
    1. Kubernetesクラスター名（必須） - クラスターに付けたい名前。
    2. Environment scope(必須) - このクラスターに関連する環境。

    3. API URL(必須) - GitLabがKubernetes APIにアクセスするためのURLです。Kubernetesは複数のAPIを公開しているので、それら全てに共通する “ベース “URLが必要です。例えば、https://kubernetes.example.com/api/v1よりもhttps://kubernetes.example.com.

      以下のコマンドを実行してAPI URLを取得します：

      kubectl cluster-info | grep -E 'Kubernetes master|Kubernetes control plane' | awk '/http/ {print $NF}'
    4. CA証明書（必須） - クラスターへの認証には有効なKubernetes証明書が必要です。デフォルトで作成された証明書を使用します。
      1. kubectl get secrets でシークレットをリストアップし、1つは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 に対して認証を行います。使用するトークンは、cluster-admin の権限を持つサービスアカウントに属する必要があります。 このサービスアカウントを作成するには

      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 権限が必要です。この権限がない場合は、Basic認証を有効にしてから管理者としてkubectl apply ：

        kubectl apply -f gitlab-admin-service-account.yaml --username=admin --password=<password>
        note
        Basic認証を有効にし、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-managed cluster- このクラスターのネームスペースとサービスアカウントをGitLabに管理させたい場合は、チェックを入れたままにします。詳細はマネージドクラスターのセクションを参照してください。
    7. Project namespace(optional) - 記入する必要はありません。空白のままにしておくと、GitLabが作成してくれます。また
      • 各プロジェクトは固有の名前空間を持つ必要があります。
      • default のシークレットのように、より広い権限のシークレットを使う場合、プロジェクトの名前空間は必ずしもシークレットの名前空間とは限りません。
      • プロジェクトの名前空間としてdefault を使うべきではありません。
      • あなたや誰かがプロジェクト専用のシークレットを作成した場合、通常は権限が制限されているので、シークレットの名前空間とプロジェクトの名前空間は同じかもしれません。
  4. Add Kubernetes clusterボタンを選択します。

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

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

GitLabインテグレーション経由でクラスターを接続する際、クラスターがRBACを有効にしているかどうかを指定することができます。これは、特定のオペレーションでGitLabがクラスターとどのようにやり取りするかに影響します。作成時にRBAC-enabled clusterチェックボックスをチェックしなかった場合、GitLabはクラスターと対話する際にRBACが無効になっているとみなします。その場合は、インテグレーションを正しく動作させるためにクラスターのRBACを無効にする必要があります。

RBAC

caution
RBAC を無効にするということは、クラスターで動いているアプリケーションやクラスターを認証できるユーザーが API にフルアクセスできるということです。これはセキュリティ上の問題であり、望ましいことではありません。

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

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

トラブルシューティング

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

Kubernetesクラスター接続中にこのエラーが発生した場合は、サービストークンを正しく貼り付けているか確認してください。Shellによっては、サービストークンに改行が追加され、無効になってしまう場合があります。トークンをエディタに貼り付け、追加のスペースを削除して改行がないことを確認してください。

証明書が有効でない場合も、このエラーが発生することがあります。証明書のサブジェクトの代替名に、クラスターの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を想定しています。