從 Gitlab 8.0 開始，Gitlab CI 就已經集成在 Gitlab 中，只要在項目中添加壹個 .gitlab-ci.yml 文件，然後添加壹個 Runner ，即可進行持續集成。在介紹 Gitlab CI 之前，先看看壹些 Gitlab CI 的壹些相關概念。
Jobs->Stages->Pipeline
壹次 Pipeline 其實相當於壹次構建任務，裏面可以包含很多個流程，如安裝依賴、運行測試、編譯、部署測試服務器、部署生產服務器等流程。任何提交或者 Merge Request 的合並都可以觸發 Pipeline 構建，如下圖所示：
Stages 表示壹個構建階段，也就是上面提到的壹個流程。可以在壹次 Pipeline 中定義多個 Stages，這些 Stages 會有以下特點：
Stages 和 Pipeline 的關系如下所示：
Jobs 表示構建工作，表示某個 Stage 裏面執行的工作。可以在 Stages 裏面定義多個 Jobs，這些 Jobs 會有以下特點：
Jobs 和 Stage 的關系如下所示：
如果理解了上面的基本概念之後，可能我們就會發現壹個問題，我們的構建任務在什麽地方來執行呢，以前用 Jenkins 在 Master 和 Slave 節點都可以用來運行構建任務，而來執行我們的 Gitlab CI 構建任務的就是 Gitlab Runner。
我們知道大多數情況下構建任務都是會占用大量的系統資源的，如果直接讓 Gitlab 本身來運行構建任務的話，顯然 Gitlab 的性能會大幅度下降的。GitLab CI 最大的作用是管理各個項目的構建狀態，因此，運行構建任務這種浪費資源的事情交給壹個獨立的 Gitlab Runner 來做就會好很多，更重要的是 Gitlab Runner 可以安裝到不同的機器上，甚至是我們本機，這樣完全就不會影響到 Gitlab 本身了。
安裝 Gitlab Runner 非常簡單，我們可以完全安裝官方文檔： /runner/install/ 即可，比如可以直接使用二進制、Docker 等來安裝。同樣的，我們這裏還是將 Gitlab Runner 安裝到 Kubernetes 集群中來，讓我們的集群來統壹管理 Gitlab 相關的服務。
1.驗證 Kubernetes 集群
執行下面的命令驗證 Kubernetes 集群：
cluster-info這個命令會顯示當前鏈接的集群狀態和可用的集群服務列表。
2.獲取 Gitlab CI Register Token
上節已經成功安裝了 Gitlab，在瀏覽器中打開 hwzxgit.sinoing.net 頁面，然後登錄後進入到管理頁面 /admin ，然後點擊導航欄中的Runner，可以看到該頁面中有兩個總要的參數，壹個是 URL，另外壹個就是 Register Token，下面的步驟中需要用到這兩個參數值。
圖壹、
同樣將 Runner 相關的資源對象都安裝到kube-ops這個 namespace 下面，首先，通過 ConfigMap 資源來傳遞 Runner 鏡像所需的環境變量（runner-cm.yaml）:
要註意 CI_SERVER_URL 對應的值需要指向 Gitlab 實例的 URL（可以是外網地址，也可以是 Kubernetes 集群內部的 Service DNS 地址，因為 Runner 也是運行在 Kubernetes 集群中的），並加上 /ci （ /ci "此外還添加了壹些構建容器運行的資源限制，可以自己根據需要進行更改即可。
除了上面的壹些環境變量相關的配置外，還需要壹個用於註冊、運行和取消註冊 Gitlab CI Runner 的小腳本。只有當 Pod 正常通過 Kubernetes（TERM信號）終止時，才會觸發轉輪取消註冊。 如果強制終止 Pod（SIGKILL信號），Runner 將不會註銷自身。必須手動完成對這種被殺死的 Runner 的清理，配置清單文件如下：（runner-scripts-cm.yaml）
可以看到需要壹個 GITLAB_CI_TOKEN，然後復制下圖中的Gitlab CI runner token 來創建壹個 Kubernetes secret 對象。將 token 進行 base64 編碼：
然後接下來就可以來編寫壹個用於真正運行 Runner 的控制器對象，這裏使用 Statefulset。首先，在開始運行的時候，嘗試取消註冊所有的同名 Runner，當節點丟失時（即NodeLost事件），這尤其有用。然後再嘗試重新註冊自己並開始運行。在正常停止 Pod 的時候，Runner 將會運行unregister命令來嘗試取消自己，所以 Gitlab 就不能再使用這個 Runner 了，這個是通過 Kubernetes Pod 生命周期中的hooks來完成的。
另外通過使用envFrom來指定Secrets和ConfigMaps來用作環境變量，對應的資源清單文件如下：(runner-statefulset.yaml)
可以看到上面我們使用了壹個名為 gitlab-ci 的 serviceAccount，新建壹個 rbac 資源清單文件：(runner-rbac.yaml)
4.創建 Runner 資源對象
資源清單文件準備好後，直接創建上面的資源對象：
創建完成後，可以通過查看 Pod 狀態判斷 Runner 是否運行成功：
可以看到已經成功運行了兩個（具體取決於StatefulSet清單中的副本數) Runner 實例，然後切換到 Gitlab Admin 頁面下面的 Runner 頁面：
至此，在kubernetes中安裝Gitlab CI Runner結束，當然也可以根據需要更改 Runner 的壹些配置，比如添加 tag 標簽等。