摘要：從開始，部署管理的集群時，默認情況下會啟用授權(quán)群集端點功能。我們將首先在中創(chuàng)建一個新項目，該項目將使用功能與我們的集群集成。完成后單擊創(chuàng)建項目。這不僅意味著已被設(shè)為默認值，還能夠觸發(fā)構(gòu)建。例如，負載均衡選項卡顯示已部署的以及創(chuàng)建的主機名。

在這篇文章中，我們將介紹如何將GitLab的Auto DevOps功能與Rancher管理的Kubernetes集群連接起來，利用Rancher v2.2.0中引入的授權(quán)集群端點的功能。通過本文，你將能全面了解GitLab如何與Kubernetes集成，以及Rancher如何使用授權(quán)集群端點簡化這一集成工作的流程。本文非常適合Kubernetes管理員、DevOps工程師，或任何想將其開發(fā)工作流與Kubernetes進行集成的人。

Auto DevOps是在GitLab 10.0中引入的功能，它讓用戶可以設(shè)置自動檢測、構(gòu)建、測試和部署項目的DevOps管道。將GitLab Auto DevOps與Kubernetes集群配合使用，這意味著用戶可以無需配置CI / CD資源和其他工具，即可以部署應(yīng)用程序。

從v2.2.0開始，Rancher引入了一項名為Authorized Cluster Endpoint的新功能，用戶可以直接訪問Kubernetes而無需通過Rancher進行代理。在v2.2.0之前，如果要直接與下游Kubernetes集群通信，用戶必須從各個節(jié)點手動檢索kubeconfig文件以及API服務(wù)器地址。這不僅增加了操作的復(fù)雜度，而且還沒有提供一種機制來控制通過Rancher管理集群時可用的細化權(quán)限。

從Rancher v2.2.0開始，部署Rancher管理的集群時，默認情況下會啟用授權(quán)群集端點（ACE）功能。ACE將部分Rancher身份驗證和授權(quán)機制推送到下游Kubernetes集群，允許Rancher用戶直接連接到這些集群，同時仍遵守安全策略。

如果您已為某些項目中的某個用戶明確授予了權(quán)限，則當該用戶使用授權(quán)集群端點進行連接時，這些權(quán)限能自動生效應(yīng)用?，F(xiàn)在，無論用戶是通過Rancher還是直接連接到Kubernetes集群，安全性都能得到保障。

授權(quán)集群端點功能的相關(guān)文檔對此有更詳細的說明：

https://rancher.com/docs/ranc...

注意
目前，授權(quán)集群端點功能暫時僅適用于使用Rancher Kubernetes Engine（RKE）啟動的下游Kubernetes進群。

要將GitLab Auto DevOps與Rancher管理的Kubernetes集群進行對接，您需要實現(xiàn)準備好：

一個GitLab.com帳戶，或一個自托管GitLab實例上的帳戶（需已啟用Auto
DevOps）：GitLab.com帳戶需要已經(jīng)配置好了Auto
DevOps。如果您使用的是自托管GitLab實例，則可以參考這一GitLab文檔了解如何啟用Auto
DevOps：https://docs.gitlab.com/ee/to...

運行版本v2.2.0或更高版本的Rancher實例：您可以以單節(jié)點模式啟動Rancher（https://rancher.com/quick-start/），也可以創(chuàng)建HA安裝（https://rancher.com/docs/ranc...）。

Rancher管理的Kubernetes集群：您還需要一個通過RKE配置的、Rancher上管理的集群。此外，集群中需要有一個管理員用戶，如果您使用的是GitLab.com，則需要通過公共網(wǎng)絡(luò)訪問控制平面節(jié)點。

首先，我們需要先將Rancher和Kubernetes設(shè)置好。該過程的第一部分主要涉及收集信息。

注意
為簡單起見，這些步驟使用的是Rancher中默認的admin帳戶。最佳實踐要求您使用獨立用戶執(zhí)行此類過程，并限制該用戶對正在集成GitLab的集群的權(quán)限。

登錄Rancher并導航到要集成的下游集群。在本演示中，我們將在EC2實例上創(chuàng)建一個名為testing的集群，該集群在Amazon中運行：

在集群的儀表板上，單擊頂部的Kubeconfig File按鈕。這將打開kubeconfig集群的文件，其中包括授權(quán)集群端點的信息。

kubeconfig文件中的第一個條目是通過Rancher服務(wù)器的集群端點。向下滾動以標識此集群的授權(quán)群集端點，該集群列為多帶帶的集群條目：

在我的示例中，此集群的名稱是testing-testing-2，并且端點server是AWS提供的公共IP。

復(fù)制server和certificate-authority-data字段的值，不包括引號，并保存它們。

在kubeconfig文件中進一步向下滾動并找到您的用戶名和token：

復(fù)制token字段（不包括引號）并保存。

接下來解碼證書授權(quán)機構(gòu)數(shù)據(jù)的base64版本，將其轉(zhuǎn)換回原始版本并保存。根據(jù)您的工具，一些可行的選項包括：

通過我們從Rancher收集的信息，我們現(xiàn)在可以配置GitLab了。我們將首先在GitLab中創(chuàng)建一個新項目，該項目將使用Auto DevOps功能與我們的Kubernetes集群集成。

首先，登錄GitLab，然后選擇New Project。

在“新建項目”頁面上，選擇“從模板創(chuàng)建”選項卡。這將為您提供要使用的模板項目列表。選擇NodeJS Express，然后單擊“Use template”：

為項目命名，并將“可見性級別”設(shè)置為“ 公共”。完成后單擊“ 創(chuàng)建項目”。

注意
在我撰寫本文時，可見性級別可以設(shè)為“私密”，不過這是GitLab的Auto DevOps實驗性功能。

在項目頁面左側(cè)的菜單窗格中，選擇“設(shè)置”>“CI / CD”。展開“ 環(huán)境變量”部分，并設(shè)置以下變量：

我們這次會禁用下圖這些功能，因為我們的簡單示例暫時不需要它們，并且它們會延長部署所需的時間。在實際項目中，您可以根據(jù)您的實際需求啟用其中一些選項：

單擊“ 保存變量”以完成GitLab項目配置。

現(xiàn)在，我們已準備好將我們的GitLab項目與Rancher管理的Kubernetes集群集成。

在GitLab中，選擇新克隆的項目。在左側(cè)菜單中，選擇“ 操作”>“Kubernetes”。單擊綠色“添加Kubernetes集群”按鈕。在下一頁上，選擇“添加現(xiàn)有集群”選項卡。

按以下信息填寫相應(yīng)字段：

單擊“ 添加Kubernetes集群”。GitLab將添加集群，并在其中創(chuàng)建新的命名空間。您可以查看Rancher接口，確認新創(chuàng)建的命名空間已經(jīng)創(chuàng)建成功。

注意
GitLab連接到集群時所做的第一件事就是為項目創(chuàng)建一個命名空間。如果您在一段時間后沒有看到創(chuàng)建名稱空間，則說明可能出現(xiàn)了一些問題。

將集群添加到GitLab后，將顯示要安裝到集群中的應(yīng)用程序列表。第一個是Helm Tiller。繼續(xù)，單擊“ 安裝”將其添加到集群。

接下來，安裝Ingress，它將允許GitLab將流量路由到您的應(yīng)用程序：

根據(jù)您配置進群的方式，您的入口端點可能會自動填充，也可能不會。在本教程中，我將使用xip.io主機名來指向單個節(jié)點的流量。至于您的用例，您可能需要設(shè)置通配符域并將其指向此ingress（或指向您的節(jié)點IP等）。

部署好ingress后，滾動到頁面頂部并找到“基本域”字段。輸入其中一個節(jié)點的公共IP地址，然后輸入.xip.io。這將創(chuàng)建一個解析為該IP地址的通配符域，這對于我們的示例就足夠了：

接下來，在導航欄中，選擇“設(shè)置”>“CI / CD”。展開“ 自動DevOps”部分，然后選中“默認為自動DevOps管道”框。這不僅意味著Auto DevOps已被設(shè)為默認值，還能夠觸發(fā)構(gòu)建。將“部署策略”設(shè)置為“ 繼續(xù)部署到生產(chǎn)”：

檢查Auto DevOps框后，管道運行將開始。導航到GitLab中的CI / CD>管道。您應(yīng)該看到類似于下圖的內(nèi)容，這表明GitLab正在部署您的應(yīng)用程序：

下面讓我們回到Rancher，查看一下我們的部署的情況，看看資源是如何轉(zhuǎn)換為Rancher界面中的Kubernetes對象的。

在Rancher中，導航到您的進群，然后單擊頂部導航菜單中的Projects / Namespaces。

GitLab代表您創(chuàng)建了兩個命名空間：一個是gitlab-managed-apps，另一個是唯一的應(yīng)用程序命名空間。gitlab-managed-apps命名空間包含資源，如用于部署應(yīng)用程序的nginx 和Helm tiller實例。那個應(yīng)用程序的唯一命名空間，包含著應(yīng)用程序的部署。

為了將這些進一步可視化，我們可以將這些命名空間移動到我們的Default項目中。您也可以使用任何其他項目。單擊“移動”按鈕，然后選擇所需的項目：

移動命名空間后，導航到他們所屬的項目，然后導航到Workloads頁面。該頁面將在其特定于應(yīng)用程序的命名空間中顯示您的新部署：

請注意部署名稱下的443 / https鏈接。單擊該鏈接，您就可以跳轉(zhuǎn)至您的部署的通配符域的ingress。如果一切順利，你將可以看到這個象征著成功的頁面：

結(jié) 語

恭喜！您剛剛成功地使用授權(quán)集群端點將GitLab的Auto DevOps與Rancher管理的Kubernetes集群連接，以實現(xiàn)更安全、直接的連接了！

當探索Rancher的其他區(qū)域時，你可能會注意到GitLab以你的名義為你創(chuàng)建的其他對象。例如，“負載均衡”選項卡顯示已部署的L7 ingress以及創(chuàng)建的主機名。您還可以在“服務(wù)發(fā)現(xiàn)”選項卡下查看部署的應(yīng)用程序的內(nèi)部服務(wù)。

GitLab的Auto DevOps功能不僅易于使用，而且可定制且功能強大。在本文的演示中，我們禁用了一些高級功能，如自動測試、依賴項掃描和許可管理。這些功能在后期也可以重新啟用，并通過配置GitLab，為您的開發(fā)環(huán)境提供更多意想不到的便利與價值。除了Auto DevOps之外，GitLab還為CI / CD提供了.gitlab-ci.yml文件，用戶可以借此進行更多的擴展定制。在GitLab的文檔中您可以了解到更多信息：

https://docs.gitlab.com

在Kubernetes和Rancher上構(gòu)建CI / CD流水線

Kubernetes的一大價值，就是為企業(yè)優(yōu)化開發(fā)操作流程，而CI工作流與Kubernetes的集成，是大多團隊極關(guān)注的重要部分。

本周三（4月24日）晚20:30，Rancher將舉辦免費的在線培訓《企業(yè)如何構(gòu)建CI/CD流水線》，本次直播中，我們將分享：

如何對接GitLab

構(gòu)建鏡像

發(fā)布鏡像到內(nèi)置的鏡像倉庫

發(fā)布鏡像到遠端倉庫

通過流水線部署應(yīng)用

通過應(yīng)用商店發(fā)布自己的應(yīng)用

如何設(shè)置流水線通知

您可以點擊鏈接：http://live.vhall.com/729465809 預(yù)約此次課程，周三晚使用同一鏈接即可觀看直播！