GitlabCI+kubernetes
有点混乱，先整理有关kubernetes相关概念如下：
1. kubernetes executor
2. connecting gitlab with a kubernetes cluster
3. run gitlab-runner on a kubernetes cluster
根据持续集成探索：使用过程为安装runner、注册runner即可
1. 安装runner可以为在各系统平台上安装(linux、macos、windows、freebsd等)、docker安装、以及在kubernetes上安装等方式
2. 注册runner，注册命令会指定executor、docker-image、url、registration-token、description、tag-list、run-untagged、locked等。
其中，docker-image是使用docker或kubernetes方式执行build时的默认镜像，url为gitlab地址，registration-token为项目的注册token等
什么是executor
GitLab Runner实现了许多executor，可以在不同场景下使用指定的执行器来运行你的builds。若不确定要选择哪一个executor，可以参考 I am not sure 部分。可以查看 compatibility chart 部分了解每个executor所支持的特性。
SSH Executor
SSH executor只是为了完整，是所有executor中支持最少的. ssh executor可以使GitLab Runner连接外部服务并在外部运行builds。
Shell Executor
Shell 是最易配置的executor。builds所需的所有依赖都需要事先在runner所在服务器上手动安装。
Virtual Machine Executor
我们也提供了两个系统虚拟化选项：VirtualBox、 Parallels。这一类的executor允许你使用已经创建的虚拟机，可以用来clone也可以用来运行builds。由于该executor可以创建Windows, Linux, OSX or FreeBSD虚拟机，并且可以使用GitLab Runner访问虚拟机，在虚拟机上运行builds，因此你想要在不同的操作系统上运行，使用该executor正好可以满足，减少了基础构建所花费的代价。
Docker Executor
Docker可以清理build环境，方便依赖管理(building一个项目需要的所有依赖都可以放进docker image里)。Docker executor可以让你创建一个由services依赖比如说mysql这样的build环境更简单方便。
Docker Machine
Docker Machine 是Docker executor的一个特定版本，支持auto-scaling。工作模式与Docker executor类似，只是由Docker Machine创建本地的build。
kubernetes Executor
Kubernetes executor可以让你使用已有的Kubernetes cluster来运行你的builds。 executor会调用Kubernetes cluster API并且会为每一个GitLab CI job创建一个新的pod(用有build container和services container)
头脑风暴
.gitlab-ci.yml是用来给runner取执行的，而runner中有一个executor是否是用来执行.gitlab-ci.yml命令的。若是shell executor则所有的脚本、指定的阶段等，执行命令全都以shell命令进行执行，类似于linux上敲的任何命令。若是docker executor呢。。。是否是以docker命令去执行？？若是kubernetes executor呢，是否是以kubectl命令去执行？？？？
那如果是kubernetes难不成还要在安装kubernetes集群？？应该不需要，但还是需要docker in docker的环境？不对，那kubectl呢？？？？
run gitlab-runner on a kubernetes cluster (install gitlab-runner on a kubernetes cluster)
将runner使用kubernetes方式启动，首先需定义所使用的资源。推荐的一个方式就是使用configmap定义。
apiVersion: v1
kind: ConfigMap
metadata:
name: gitlab-runner
namespace: gitlab-managed-apps
data:
config.toml: |
concurrent = 4
[[runners]]
name = "Kubernetes Runner"
url = "http://**.**.**.**"
token = ""
executor = "kubernetes"
[runners.kubernetes]
namespace = "gitlab-managed-apps"
image = "maven:latest"注：image是docker运行job时使用的默认镜像，token存储在/etc/gitlab-runner/config.toml文件内，在runner注册后自动生成。这个token不要跟gitlab内相关项目Settings > CI/CD > Runners settings处的注册token所混淆。
完成上述后，创建一个使用该configmap的deployment或replication controller，以下是使用示例：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: gitlab-runner
namespace: gitlab
spec:
replicas: 1
selector:
matchLabels:
name: gitlab-runner
template:
metadata:
labels:
name: gitlab-runner
spec:
containers:
- args:
- run
image: gitlab-runner
imagePullPolicy: IfNotPresent
name: gitlab-runner
volumeMounts:
- mountPath: /etc/gitlab-runner
name: config
- mountPath: /etc/ssl/certs
name: cacerts
readOnly: true
restartPolicy: Always
volumes:
- configMap:
name: gitlab-runner
name: config
- hostPath:
path: /usr/share/ca-certificates/mozilla
name: cacertsrunner运行后，注册
kubectl get pods -n gitlab
kubectl exec -it gitlab-runner-7f98cbb9dd-7q7pr -n gitlab /bin/bash
gitlab-runner register
Running in system-mode.
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://**.**.**.**
Please enter the gitlab-ci token for this runner:
SMkc_ayGUszY9wWELERf
Please enter the gitlab-ci description for this runner:
[gitlab-runner-7f98cbb9dd-7q7pr]: fig-k8s-runner
Please enter the gitlab-ci tags for this runner (comma separated):
kubernetes
Whether to run untagged builds [true/false]:
[false]: true
Whether to lock the Runner to current project [true/false]:
[true]: false
Registering runner... succeeded runner=SMkc_ayG
Please enter the executor: shell, virtualbox, docker-ssh+machine, kubernetes, docker, docker-ssh, docker+machine, parallels, ssh:
kubernetes
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!kubernetes Executor
kubernetes executor 通过访问集群的Kubernetes API为每一个job创建一个pod。这个pod至少由两个容器组成，一个是构建容器，另一个是yaml文件定义的service的容器。容器的命名方式为build容器就是build，服务容器就是svc-X ，X is [0-9]+
注意：当service和container运行在同一个pod内，他们除了共享localhost地址，同时也会应用以下规则：
1. service通过域名无法访问，只能通过localhost访问
2. 多个service不能使用同一端口。
Workflow
kubernetes执行器将构建过程分为多个步骤：
- prepare：对应于kubernetes的创建pod阶段。创建build和服务需要运行的容器。
- pre-build：Clone, restore cache and download artifacts from previous stages. This is run on a special container as part of the Pod.
- Build: User build.
- Post-build: Create cache, upload artifacts to GitLab. This also uses the special container as part of the Pod.
Connecting to the Kubernetes API
为了能够访问Kubernetes API，提供了如下选择：
* host: 指定Kubernetes apiserver 地址 (若没有指定，则使用自动发现功能)
* cert_file: Optional Kubernetes apiserver user auth certificate
* key_file: Optional Kubernetes apiserver user auth private key
* ca_file: Optional Kubernetes apiserver ca certificate
user account 在指定的namespace下必须拥有create、list、attach pods的权利。如果GitLab CI Runner运行在Kubernetes cluster内， 那么你可以忽略以上字段，让runner使用自动发现功能来访问Kubernetes API. 如果runner运行在Cluster外部，那么就需要设置以上字段确保runner有权访问Kubernetes API。
connecting gitlab with a kubernetes cluster
使用kubernetes集群，可以使用review apps用一种更简单的方式来部署应用、运行pipeline等。当项目使用kubernetes集群来继续CI时，提供了两种方法，一是，使用已有的GKE账号关联gitlab，从而在GKE创建一个新的集群；二是，对一个已存在的kubernetes集群提供访问资格。
Adding an existing kubernetes cluster
- CI/CD > Kubernetes
- Add Kubernetes cluster
- Add an existing Kubernetes cluster，并完成填写内容
点击Create Kubernetes cluster按钮
Kubernetes cluster name：集群命名
Environment scope：集群相关环境
API URL：kubernetes的api地址，如http://kubernetes.example.com，而不是http://kubernetes.example.com/api/v1
CA certificate：如果API服务使用了自签名TLS认证方式，此处需要填写ca.crt
Token：Gitlab认证kubernetes使用的service token，覆盖范围为指定的namespace。如果还没有service token，可以参考kubernetes文档创建。也可以在kubernetes的dashboard中查找Config->Secrets查看或创建service tokens。
Project namespace：遵守以下规则- 默认不需要填写，Gitlab会自动创建；
- 每个project都应该有一个唯一的namespace
- project的namespace不一定是secret的namespace
- 不应该使用default作为project的namespace
- 如果为project创建了一个指定的并且仅有特定权限的secret，secret的namespace可以作为project的namespace。
Installing applications
Gitlab CI集成的kubernetes提供了应用的安装：Helm Tiller、Ingress、Prometheus、Gitlab Runner。其他的应用安装均以Helm Tiller为基础，使用helm命令进行安装，因此安装runner前需安装helm tiller应用。点击Installed按钮，由于kubernetes默认拉取google镜像gcr.io/kubernetes-helm/tiller:v2.7.0，因此需事先将该镜像拉至只本地。其他缺啥装啥。
安装完helm tiller后，继续安装其他想要的应用，如runner。
runner安装好后，查看config.toml文件如下所示：
$ kubectl exec -it runner /bin/bash
$ cat /etc/gitlab-runner/config.toml
concurrent = 4
check_interval = 3
[[runners]]
name = "runner-gitlab-runner-5998d8ddcb-5qgwt"
url = "http://**.**.**.**/"
token = "e805af6c91f724588ef4b9e7beda26"
executor = "kubernetes"
[runners.cache]
[runners.kubernetes]
host = ""
bearer_token_overwrite_allowed = false
image = "ubuntu:16.04"
namespace = "gitlab-managed-apps"
namespace_overwrite_allowed = ""
privileged = true
service_account_overwrite_allowed = ""
[runners.kubernetes.volumes]自定义安装runner时，运行时报错
是因为没有指定kubernetes的apiserver地址，因此runner无法找到kubernetes。
更改配置文件，添加host
concurrent = 4
check_interval = 3
[[runners]]
name = "runner-gitlab-runner-5998d8ddcb-5qgwt"
url = "http://**.**.**.**/"
token = "e805af6c91f724588ef4b9e7beda26"
executor = "kubernetes"
[runners.cache]
[runners.kubernetes]
host = "http://kubernetes.api.com"
bearer_token_overwrite_allowed = false
image = "ubuntu:16.04"
namespace = "gitlab-managed-apps"
namespace_overwrite_allowed = ""
privileged = true
service_account_overwrite_allowed = ""
[runners.kubernetes.volumes]再次运行CI，success。。。。
总结：以上两种方式将runner安装至kubernetes集群中
其一：使用导航CI/CD->kubernetes内部的applications进行安装
其二：自定义kubernetes的deployment进行部署runner
参考翻译自：
https://docs.gitlab.com/runner/executors/kubernetes.html#connecting-to-the-kubernetes-api