Kubernetesクラスタの追加と削除

GitLabでは、以下のKubernetesプロバイダーのクラスター作成をインテグレーションしています:

  • Google Kubernetes Engine(GKE).
  • Amazon Elastic Kubernetes Service(EKS).

GitLabは、オンプレミスでもホスト型でも、標準的なKubernetesプロバイダーともインテグレーションできます。

GitLabと Google Cloud Platform によるスケーラブルなアプリデプロイウェブキャストを視聴して、Google Cloud Platform(GCP)で管理される Kubernetes クラスターを数クリックでスピンアップする方法を学びましょう。
ヒント:Google Cloud Platform(GCP) の新規アカウントには、登録時に300ドルのクレジットが付与されます。Googleとのパートナーシップにより、GitLabはGitLabのGoogle Kubernetes Engineインテグレーションを開始するために、新規GCPアカウントにさらに200ドルのクレジットを提供することができます。このリンクをたどってクレジットを申請するだけです。

始める前に

GitLabを使ってKubernetesクラスターを追加する前に、必要なものがあります:

アクセス制御

GitLabでクラスターを作成するとき、どちらを作成するか尋ねられます:

Note:RBACは推奨されており、GitLabのデフォルトです。

GitLabは、GitLab管理アプリケーションをインストールして実行するために必要なサービスアカウントと権限を作成します。 GitLabがクラスターを作成すると、default 名前空間にcluster-admin 権限を持つgitlab サービスアカウントが作成され、新しく作成されたクラスターを管理します。

注:デプロイ用の制限付きサービスアカウントはGitLab 11.5で導入されました。

クラスターに初めてアプリケーションをインストールするとき、gitlab-managed-apps 名前空間にcluster-admin 権限でtiller サービスアカウントが作成されます。このサービスアカウントは、Helm がGitLab 管理アプリケーションをインストールして実行するときに使われます。

Helmは、インストールされたアプリケーションごとに追加のサービスアカウントやその他のリソースも作成します。 詳細は、各アプリケーションのHelmチャートのドキュメントを参照してください。

既存のKubernetesクラスターを追加する場合は、アカウントのトークンがクラスターの管理者権限を持っていることを確認してください。

GitLabが作成するリソースはクラスターの種類によって異なります。

重要な注意事項

アクセス制御については、以下の点に注意してください:

  • 環境固有のリソースは、クラスターがGitLabによって管理されている場合にのみ作成されます。
  • クラスターがGitLab 12.2より前に作成された場合は、すべてのプロジェクト環境に対して単一の名前空間を使用します。

RBACクラスタリソース

GitLabはRBACクラスター用に以下のリソースを作成します。

名称 タイプ 詳細 作成日時
gitlab ServiceAccount default 名前空間 新しいクラスターの作成
gitlab-admin ClusterRoleBinding cluster-admin ロールレフ 新しいクラスターの作成
gitlab-token Secret gitlab ServiceAccount 用トークン 新しいクラスターの作成
tiller ServiceAccount gitlab-managed-apps 名前空間 Helmチャートのインストール
tiller-admin ClusterRoleBinding cluster-admin ロールレフ Helmチャートのインストール
環境名前空間 Namespace 環境固有のリソースをすべて含みます。 クラスターへのデプロイ
環境名前空間 ServiceAccount 環境の名前空間を使用 クラスターへのデプロイ
環境名前空間 Secret 環境用トークン ServiceAccount クラスターへのデプロイ
環境名前空間 RoleBinding edit ロールレフ クラスターへのデプロイ

ABACクラスタリソース

GitLabはABACクラスター用に以下のリソースを作成します。

名称 タイプ 詳細 作成日時
gitlab ServiceAccount default 名前空間 新しいクラスターの作成
gitlab-token Secret gitlab ServiceAccount 用トークン 新しいクラスターの作成
tiller ServiceAccount gitlab-managed-apps 名前空間 Helmチャートのインストール
tiller-admin ClusterRoleBinding cluster-admin ロールレフ Helmチャートのインストール
環境名前空間 Namespace 環境固有のリソースをすべて含みます。 クラスターへのデプロイ
環境名前空間 ServiceAccount 環境の名前空間を使用 クラスターへのデプロイ
環境名前空間 Secret 環境用トークン ServiceAccount クラスターへのデプロイ

GitLabランナーのセキュリティ

GitLab Runnerはデフォルトで特権モードを有効にしており、特別なコマンドを実行したり、DockerでDockerを実行したりすることができます。 この機能はAuto DevOpsジョブの一部を実行するために必要です。 これはコンテナが特権モードで実行されていることを意味するので、いくつかの重要な詳細を認識しておく必要があります。

特権フラグは実行中のコンテナにすべての機能を与え、コンテナはホストができることのほとんどすべてを行うことができます。 任意のイメージに対してdocker run のオペレーションを実行すると、事実上 root アクセスを持つことになるため、内部セキュリティリスクに注意してください。

GitLab Runnerを特権モードで使いたくない場合も同様です:

  • GitLab.comの共有Runnerを使ってください。 このセキュリティ問題はありません。
  • 共有ランナーで説明されているコンフィギュレーションを使用して、あなた自身のランナーをセットアップします。 これには以下が含まれます:
    1. アプリケーション経由でインストールされていないことを確認してください。
    2. docker+machine](https://docs.gitlab.com/runner/executors/docker_machine.html)を使用したランナーのインストール[.

新しいクラスターの作成

新しいクラスターは、プロジェクト、グループ、インスタンスレベルで、Google Kubernetes Engine(GKE) または Amazon Elastic Kubernetes Service(EKS) 上で GitLab を使用して作成できます:

  1. に移動します:
    • プロジェクトの オペレーション > Kubernetesページで、プロジェクトレベルのクラスターを作成します。
    • グループの Kubernetesページ、グループレベルのクラスターの場合。
    • インスタンスレベルのクラスターの場合、 Admin Area > Kubernetesページ。
  2. Add Kubernetes clusterをクリックします。
  3. 新しいクラスターを作成]タブをクリックします。
  4. AmazonEKSまたはGoogleGKEのいずれかをクリックし、ご希望のサービスの指示に従ってください:

既存クラスターの追加

既存のKubernetesクラスターがある場合は、プロジェクト、グループ、インスタンスに追加できます。

注意:Kubernetesインテグレーションはarm64クラスターではサポートされていません。 詳細はarm64クラスターでHelmTillerがインストールに失敗するイシューを参照してください。

既存のKubernetesクラスター

プロジェクト、グループ、インスタンスにKubernetesクラスターを追加するには:

  1. に移動します:
    1. プロジェクトの オペレーション > Kubernetesページで、プロジェクトレベルのクラスターを作成します。
    2. グループの Kubernetesページ、グループレベルのクラスターの場合。
    3. インスタンスレベルのクラスターの場合、 Admin Area > Kubernetesページ。
  2. Add Kubernetes clusterをクリックします。
  3. Add existing cluster]タブをクリックし、詳細を入力します:
    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 'Kubernetes master' | 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証明書をコピーする必要があります。
    5. トークン- GitLabは、特定のnamespaceにスコープされたサービストークンを使用してKubernetesに対して認証を行います。使用するトークンは、cluster-admin権限を持つサービスアカウントに属する必要があります。 このサービスアカウントを作成するには:
      1. gitlab-admin-service-account.yaml というファイルを作成します:

        apiVersion: v1
        kind: ServiceAccount
        metadata:
          name: gitlab-admin
          namespace: kube-system
        ---
        apiVersion: rbac.authorization.k8s.io/v1beta1
        kind: ClusterRoleBinding
        metadata:
          name: gitlab-admin
        roleRef:
          apiGroup: rbac.authorization.k8s.io
          kind: ClusterRole
          name: cluster-admin
        subjects:
          - kind: ServiceAccount
            name: gitlab-admin
            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>
        
        注:ベーシック認証をオンにし、Google Cloud Consoleを使用してパスワード情報を取得することができます。

        出力:

        serviceaccount "gitlab-admin" created
        clusterrolebinding "gitlab-admin" created
        
      3. gitlab-admin サービスアカウントのトークンを取得します:

        kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab-admin | awk '{print $1}')
        

        出力から<authentication_token> の値をコピーします:

        Name:         gitlab-admin-token-b5zv4
        Namespace:    kube-system
        Labels:       <none>
        Annotations:  kubernetes.io/service-account.name=gitlab-admin
                     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>
        
      注:GKEクラスタの場合、クラスタロールバインディングを作成するにはcontainer.clusterRoleBindings.create 権限が必要です。 GoogleCloudのドキュメントに従ってアクセス権を付与できます。
    6. GitLab-managed cluster- このクラスターのネームスペースとサービスアカウントをGitLabに管理させたい場合はチェックを入れたままにしてください。 詳細はManaged clusterセクションを参照してください。
    7. プロジェクトネームスペース(オプション) - 入力する必要はありません。空白のままにしておくと、GitLabが作成してくれます:
      • 各プロジェクトは固有の名前空間を持つべきです。
      • defaultのシークレットのように、より広い権限のシークレットを使用している場合、プロジェクトの名前空間は必ずしもシークレットの名前空間とは限りません。
      • プロジェクト・ネームスペースとしてdefault を使うべきではありません
      • あなたや誰かがプロジェクト専用のシークレットを作成した場合、通常は権限が制限されているので、シークレットの名前空間とプロジェクトの名前空間は同じかもしれません。
  4. 最後に「Kubernetesクラスターを作成」ボタンをクリックします。

数分後、クラスターは準備完了となります。 ここで、いくつかの事前定義されたアプリケーションのインストールに進むことができます。

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

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

rbac

注意: RBACを無効にするということは、クラスターで実行されているすべてのアプリケーション、またはクラスターに認証できるユーザがAPIにフルアクセスできることを意味します。 これはセキュリティ上の問題であり、望ましくない場合があります。

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

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

インテグレーションの有効化または無効化

Kubernetesクラスタインテグレーションが有効になるのは、新しいクラスターを作成するか、既存のクラスターを追加した後です。 Kubernetesクラスタインテグレーションを無効にするには、以下の手順に従います:

  1. に移動します:
    • プロジェクトの オペレーション > Kubernetesページで、プロジェクトレベルのクラスターを作成します。
    • グループの Kubernetesページ、グループレベルのクラスターの場合。
    • インスタンスレベルのクラスターの場合、 Admin Area > Kubernetesページ。
  2. クラスター名をクリックします。
  3. GitLab インテグレーションのトグルをクリックします。
  4. 変更を保存する]をクリックします。

インテグレーションの除去

プロジェクトからKubernetesクラスタインテグレーションを削除するには、まずクラスタの詳細ページのAdvanced Settingsタブに移動し、次のいずれかを行います:

  • Kubernetesインテグレーションのみを削除する場合は、Remove integrationを選択します。
  • GitLab 12.6からインテグレーションとリソースを削除を選択すると、インテグレーションを削除する際に関連するGitLabクラスターのリソース(例えば、名前空間、ロール、バインディング)もすべて削除されます。

クラスター・インテグレーションを取り外す際には、以下の点に注意してください:

  • Kubernetesクラスタインテグレーションを削除するには、メンテナー権限以上が必要です。
  • クラスターを削除すると、GitLabとの関係だけが削除され、クラスター自体は削除されません。クラスターを削除するには、GKEまたはEKSのダッシュボードにアクセスするか、kubectlを使用します。

もっと詳しく

アプリケーションの自動デプロイについて詳しくは、Auto DevOpsをご覧ください。