GitLab 整合企業網路內的 K8S 叢集（GitLab 整合 K8S 系列之一）
在軟體開發過程中，通常會使用版本控制的工具，方便管理不同時間與分支上的開發紀錄。依照不同副本之間的管理架構，以及處理併發編輯的方式，目前已經發展出各式各樣這種類型的管理工具。常見的免費版本控制工具像是 Git、SVN、CVS 等，或是微軟推出的 TFS。
除了需要一個版本控制工具之外，在大型軟體開發過程中，還需要有一個更進階的代碼托管平台，例如 GitHub、GitLab、Bitbucket 等。每個平台提供了更多在軟體開發生命週期中所需要用到的功能，例如 issue 追蹤、merge/pull request 的管理、CI/CD、專案時程管理等。
我們公司最早從使用 SVN，轉換到 GitHub 代碼托管平台，一直到 2018 年將開發流程轉移到 GitLab 上管理。網路上可以找到這些工具和平台之間的優缺點分析，而我們這篇文章重點不在這邊，因此就不著墨太多這些比較資訊。
本篇文章目的，是想分享在我們開發軟體的這些年，一直在找尋一個可以改善持續開發、部署和交付的方式，以及因為我們產品與 K8S 有很密切的整合，有開發團隊自己的 K8S 測試環境，想多善加利用。我們找到一個最適合我們的解決方案，就是使用 GitLab 平台與 K8S 叢集的整合功能，來達到我們想改善的軟體開發流程。
本篇是屬於一系列文章的第一篇，介紹 GitLab 是如何與 K8S 叢集串接整合，之後會再陸續發佈進階使用的功能，包含整合 Prometheus 服務來監控實體資源與專案服務，以及如何透過 K8S 叢集來讓 CI/CD 流程更流暢。
一、前置作業
GitLab 有分 SaaS 與 self-managed 兩種版本，前者就是雲端版，使用者不需要自行部署與管理服務，而後者就是 On-Premise 版，使用者自行部署與維護。
這兩個版本對於使用者來說功能幾乎相同，只是在整合過程中如果遇到問題，self-managed 版本可以到 host 主機上，查看相關 log，排除問題。而在 SaaS 版本使用上有錯誤發生，就必須發 ticket 給 GitLab.com，詢問相關問題。
K8S 叢集的部分可以使用 Amazon EKS 或 Google GKE，甚至自己獨立建置的 K8S 叢集也可以。我們公司開發團隊原本就有一套 K8S 叢集，所以接下來就會以自行建置的 K8S 叢集當作範例。
相關軟體版本
- GitLab.com(SaaS): 14.3.0-pre
所有的 GitLab 等級皆支援（Free and higher tiers） - Kubernetes: 1.16.15
網路設定
當 K8S 叢集的 endpoint 在 Internet 可以存取到，且防火牆也沒有阻擋，就沒什麼大問題。
如果 K8S 叢集是在私有網域底下，必須先透過 NAT 等設定方式，讓 K8S API 可以被 GitLab.com 存取到。相關網路設定細節如下：
- K8S API 的連接埠通常預設是 6443。在 K8S 叢集位於私有網域情況下，必須使用 NAT 轉換位址。對於 GitLab.com 來說，K8S API 的連接埠也可以被轉換成任意其它埠，不受影響。
- 如果 Internet 與 K8S 叢集之間有防火牆，此防火牆必須開放 GitLab.com 的來源 IP 範圍（34.74.90.64/28 和 34.74.226.0/24）可以存取 K8S endpoint。
二、串接
GitLab.com 要串接 K8S 叢集，有以下三種方式：
- GitLab Kubernetes Agent: 如果要加入一個已經部署完的 K8S 叢集，目前官方建議使用部署 agent 的方式。但此方式目前只有 Premium 等級有支援，並且只支援 project level 的整合。（可參考官方文件）
- Cluster Certificates: 這是官方最早支援的整合方式，整合度最高，支援所有 level 的整合（projects, group, instance）。因為安全性考量而不建議，但是所有 GitLab 等級都支援此方式。（可參考官方文件）
- Infrastructure as Code: 如果是希望從頭部署一套 K8S 叢集，官方建議直接使用 IaC 部署（使用 Terraform 模板），就能直接讓 GitLab 納管。目前支援 Amazon EKS 和 Google GKE 平台，且所有 level 的整合都支援。（可參考官方文件）
因為我們公司的 K8S 叢集是 host 在自己家裡，所以優先排除第三種整合方式。最後我們選擇採用第二種整合方式（Cluster Certificates），因為我們 GitLab group 底下有多個 projects，為了串接整個 CI/CD 開發流程（後續文章會再提到），我們必須採用 group level 的 K8S 叢集整合方式。雖然因為安全性考量，在 14.0 版本之後就不推薦使用，但我們已經在前面 網路設定 的段落提到，如何在私有網域以及採用防火牆保護的情況下，依然可以使用，而不需要關閉所有防火牆保護。
Cluster levels
根據不同情境，GitLab.com 介接 K8S 叢集可以分成不同 level。
- Project Level: 將一座 K8S 叢集專門指定給某一個 GitLab project 使用。
- Group Level: 將一座 K8S 叢集指定給一個 GitLab group 使用，底下的每一個 projects 以及 subgroup 底下的 projects 都能共同使用。
- Instance Level: 將一座 K8S 叢集給多個 GitLab groups 與底下的 projects 共同使用。
GitLab-managed cluster
在串接 K8S 叢集的過程中，會看到 GitLab-managed cluster 這個選項，如果開啟這個功能，GitLab.com 就會針對你後續 CI/CD 定義的 environment，自動建立出對應的資源（namespace, service account…）。由於在我們的使用情境中，希望多個 GitLab projects 部署在同一個 K8S namespace 中一起監控，因此我們會把此功能關閉。
Namespace per environment
在串接 K8S 叢集的過程中，會看到 Namespace per environment 這個選項，如果關閉這個功能，一個 GitLab project 底下的所有 environment 都會共用同一個 K8S namespace。由於在我們後續的使用情境中，希望一個 project 底下的每個 feature branches 有自己獨立的 K8S namespace (environment)，因此我們會把此功能開啟。
當 GitLab-managed cluster 功能關閉，Namespace per environment 功能開啟時，GitLab.com 紀錄每個 environment 與 K8S namespace 之間的 mapping 是屬於 late binding 機制。只有在第一次 CI/CD 指定 environment 對應到哪個 K8S namespace 時，才會記錄下來，之後 environment 就會使用對應的 K8S namespace。
三、功能呈現
串接完成後，可以在 Kubernetes 列表，看到實際的叢集節點數。點擊 K8S 叢集名稱，可查看相關資訊。切換到 Health 分頁，還不能看到叢集的健康狀態，因為尚未與叢集上的監控服務（Prometheus）整合。這個部分會在下一篇 “GitLab 整合 Prometheus 服務（GitLab 整合 K8S 系列之二）” 做更進一步的介紹。
