GitLab Kubernetes接続(オンプレ)

毎度、ググっても出てこない小ネタを取り扱っております。
本記事は個人的な見解であり、筆者の所属するいかなる団体も関係ございません。


# この記事の機能はGitLabバージョン 16で削除予定です

GitLabとKubernetesを接続するGitLab agent for KubernetesがGitLab 14.5で無料利用できるようになりました。
この記事の方法で接続しない事をお勧めします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15176/fe0b09b0-0727-acf5-910e-116248f48f76.png)

[Deprecations by version \| GitLab](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes)

後継機能のGitLab Agent for Kubernetesについては以下の記事を参照してください。
[GitLab Agent for Kubernetesを使ってみる\(GitLab Kubernetes Agent改め\) \- Qiita](https://qiita.com/ynott/items/35e9492d0681ea8ac60a)

# ~~GitLab を Kubernetes へ接続(オンプレのKubernetes環境)~~

## 0. ~~GitLab と Kubernetes環境の統合~~

GitLab はバージョン10.1からKubernetes へ接続することができるようになっています。
AutoDevOps機能の延長で開発が進められています。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/e3cb2c0c-4a7f-3132-b736-d538dc51673b.png)

> Add a Kubernetes cluster integration
このプロジェクトに Kubernetes クラスターを関連付けることで、Review Apps の使用、
アプリケーションのデプロイ、パイプラインの実行などを簡単に行うことができます。

とありますが、まだまだ開発中です。

本記事でも、GitLabのメニューからKubernetesへの認証に成功したということだけで、Knativeも動かしていませんし、Runnerも現時点では動かせていません。

## 1. 環境
```
GitLab : Community Edition 11.7.5
Kubernetes : v1.13.1
  PodSecurityPolicy:false
Docker : 18.9.1
OS : Ubuntu 16.04.5
```

Kubernetesは、rke でインストールしました。.kube/config を整備して、kubectl で接続できるようにしておいてください。Rancher UIからインストールした場合、Rancher上のkubectl は、Rancher側がKubernetes APIサーバーをラップしているので上手くいきません。rkeが出力した `kube_config_cluster.yml` やkubeadm のconfigを使ってKubernetes APIサーバーに直接接続するようにしましょう。

また、tillerが入っているとGitLabからKubernetes接続時にインストールしようとしてエラーになります。現時点では、なるべく作ったばかりのKubernetesクラスターが良いでしょう。現時点では、`PodSecurityPolicy` は、Falseにしておく必要があります。

## 2. Kubernetes側の準備

Index · Clusters · Project · User · ヘルプ · GitLab
[Project\-level Kubernetes clusters \(certificate\-based\) \(DEPRECATED\) \| GitLab](https://docs.gitlab.com/ee/user/project/clusters/)
ゴニョゴニョ書いてありますが、重要なのは Token です。

GitLabへ入力するアカウントとそのTokenの情報を作成するために以下の手順を行います。
1. ServiceAccountを作成(gitlabという名前は固定のようです)
2. ClusterRoleBindingを作成
3. 1のアカウントのToken名を取得
4. 3のtoken中身を取得
を行います。

### 2-1. ServiceAccountを作成
```bash:shell
kubectl create -f  - <<EOF
  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: gitlab
    namespace: default
EOF
```

### 2-2. ClusterRoleBindingを作成

```bash:shell
kubectl create -f - <<EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: gitlab-cluster-admin
subjects:
- kind: ServiceAccount
  name: gitlab
  namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
```

### 2-3. 1のアカウントのToken名を取得

```bash:shell
kubectl get secrets
NAME                  TYPE                                  DATA   AGE
gitlab-token-XXXXX    kubernetes.io/service-account-token   3      59s
```

`gitlab-token-XXXXX` がToken名です。

### 2-4. token中身を取得

```bash:shell
kubectl get secret gitlab-token-XXXXX -o jsonpath="{['data']['token']}" | base64 --decode
＜ダラダラっとTokenが表示されるはず＞
```

### 2-5. Tokenの証明書を取得

```bash:shell
kubectl get secret gitlab-token-XXXXX -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
＜ダラダラっとca.crtが表示されるはず＞
```

## 3. GitLab へ設定

0. の `Add a Kubernetes cluster integration` 画面に各項目を追記します。
1. Kubernetes クラスター名：任意
2. API URL：kubeconfigの server: 行を貼ります
3. CA 証明書：2-5のTokenの証明書 を貼ります
4. トークン：2-4のTokenの中身 を貼ります
5. プロジェクトの名前空間：空(指定しない場合はgitlab-managed-appsが作成されました)

変更を保存します。

## 4. 結果

以下のような画面が表示され、「インストール」ボタンが押せるようになります。
（ここでは既にインストールしたので「インストール済み」になっています）
![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/b221d82e-c6a5-4e33-938b-23e57bea7f88.png)

kubectl で確認すると、gitlab-managed-apps というネームスペースが作成されて、tillerとingres-nginxがデプロイされていました。

```bash:shell
kubectl get pods --all-namespaces | grep gitlab
NAMESPACE             NAME                                                     READY   STATUS      RESTARTS   AGE
gitlab-managed-apps   ingress-nginx-ingress-default-backend-78fc87c466-5wrdj   1/1     Running     0          21h
gitlab-managed-apps   tiller-deploy-7dd47f89cc-x8mxk                           1/1     Running     0          21h
```

恐らく、このネームスペースに各種アプリがAutoDevOpsでデプロイされるものと思われます。

Rancherから見てみました。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/3e3bfde2-a191-a719-5a6e-a351d847234b.png)

PodSecurityPolicyのValidationに引っかかって止まっていました。現時点ではPodSecurityPolicy はFalseの方がよさそうです。

# まとめ
残念ながら、ここまでしかまだ実現していません。

続報があれば追記したいと思います。