通過kubeadmin安裝K8S集群可以做到快速部署，但是如果需要調(diào)整K8S各個(gè)組件及服務(wù)的安全配置，高可用模式，最好通過二進(jìn)制模式進(jìn)行K8S的安裝
創(chuàng)新互聯(lián)公司主營(yíng)興隆網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,app軟件定制開發(fā),興隆h5重慶小程序開發(fā)公司搭建,興隆網(wǎng)站營(yíng)銷推廣歡迎興隆等地區(qū)企業(yè)咨詢
生產(chǎn)環(huán)境K8S Master節(jié)點(diǎn)最好在3個(gè)節(jié)點(diǎn)以上，且配置不低于4核16g
生產(chǎn)環(huán)境：確保Master高可用，啟用安全訪問機(jī)制
PS：
服務(wù)器節(jié)點(diǎn)只是起名字，與是否為k8s-master或k8s-node無關(guān)，可根據(jù)需要增加或刪減測(cè)試用例的數(shù)量，如多臺(tái)master主機(jī)只部署k8s-master組件。多臺(tái)node主機(jī)只部署k8s-node組件
master1 192.168.100.100
node1 192.168.100.101
node2 192.168.100.102
注：本節(jié)中創(chuàng)建的證書為部署流程全過程證書，測(cè)試用例為openssl生成證書，cfssl生成證書需要參考cfssl生成k8s證書，并在對(duì)應(yīng)配置文件的相關(guān)證書位置替換對(duì)應(yīng)證書
在配置文件中需要在[alt_names]設(shè)置Master服務(wù)的全部域名和IP地址，包括：
參數(shù)解析
配置文件詳解：
分發(fā)配置文件
配置文件詳解：
配置詳解
分發(fā)配置文件
分發(fā)配置文件
在三個(gè)kube-apiserver的前段部署HAProxy和keepalived，使用VIP（虛擬IP地址）192.168.100.200作為Master的唯一入口地址，供客戶端訪問
將HAProxy和keepalived均部署為至少有兩個(gè)實(shí)例的高可用架構(gòu)，以避免單點(diǎn)故障。
接下來在主機(jī)master（192.168.100.100）和主機(jī)node1（192.168.100.101）中部署
HAProxy負(fù)責(zé)將客戶端請(qǐng)求轉(zhuǎn)發(fā)到后端的3個(gè)kube-apiserver實(shí)例上，keepalived負(fù)責(zé)維護(hù)VIP的高可用
準(zhǔn)備 HAProxy 的配置文件 haproxy.cfg
參數(shù)說明：
分發(fā)配置文件
在master（192.168.100.100）和node1（192.168.100.101）上使用docker部署HAProxy，并將配置文件掛載到容器的/usr/local/etc/haproxy下
訪問192.168.100.100:8888/stats，192.168.100.101:8888/stats
keepalived用于維護(hù)VIP地址的高可用，同樣在master和node1中部署
主節(jié)點(diǎn)配置文件
子節(jié)點(diǎn)配置文件
參數(shù)解析
主節(jié)點(diǎn)和子節(jié)點(diǎn)配置異同
健康檢查腳本
keeplived需要持續(xù)監(jiān)控HAProxy的運(yùn)行狀態(tài)，在某個(gè)節(jié)點(diǎn)運(yùn)行不正常時(shí)轉(zhuǎn)移到另外的節(jié)點(diǎn)上去
監(jiān)控運(yùn)行狀態(tài)需要?jiǎng)?chuàng)建健康檢查腳本，定期運(yùn)行監(jiān)控
腳本內(nèi)容如下：
分發(fā)腳本
在master（192.168.100.100）和node1（192.168.100.101）上使用docker部署keeplived，并將配置文件掛載到容器的/container/service/keepalived/assets下，將腳本掛載到容器的/usr/bin下
檢查ens33網(wǎng)卡是否存在keeplived VIP地址
檢測(cè)keeplived是否進(jìn)行轉(zhuǎn)發(fā)
注：master集群已經(jīng)配置完畢，后續(xù)需要在node中需要部署docker，kubelet，kube-proxy，且在加入k8s集群后，還需要部署CNI網(wǎng)絡(luò)插件、DNS插件等
之前已經(jīng)在master，node1，node2中部署了docker，接下來需要部署其他服務(wù)組件，本節(jié)部署kubelet組件
參數(shù)說明
參數(shù)說明
參數(shù)說明
當(dāng)前顯示所有node為NOT READY，需要部署完網(wǎng)絡(luò)插件才可使用
為方便使用kubectl
防火墻等禁用
將橋接的IPv4流量傳遞到iptables的鏈
NTP時(shí)間同步
配置國(guó)內(nèi)k8s鏡像地址
k8s鏡像倉(cāng)庫需要翻出去,所以配置國(guó)內(nèi)鏡像地址
安裝K8s（安裝和使能kubelet）
配置cgroupdriver=systemd
默認(rèn)docker的Cgroup是cgroups，kubelet的Cgroups是systemd，兩者的Cgroups不一樣，兩邊需要修改成一致的配置
然后依據(jù)提示執(zhí)行:
然后重新初始化
然后檢查健康狀況：
上面kubectl get cs結(jié)果顯示系統(tǒng)不健康，解決方案如下：
把下面文件的 - --port=0注釋掉，即前面加上#
修改kube-flannel.yml里面為(vi中使用:set number，然后 :106定位到106行)：
2、高可用測(cè)試
接下來我們分別嘗試刪除pod和停止Container來測(cè)試高可用性：
修改內(nèi)容為：
用firefox瀏覽器訪問：訪問
一共有3個(gè)Master：
master：192.168.108.88 k8s-master03
backup：192.168.108.87 k8s-master02
backup：192.168.108.86 k8s-master04
二個(gè)worker節(jié)點(diǎn)：
k8s-node1：192.168.100.49
k8s-node2：192.168.100.50
各個(gè)master把自己公鑰發(fā)到同一個(gè)master上匯總（這里選用k8s-master01），然后分發(fā)到各個(gè)master上：
接下來把匯總的公鑰分發(fā)給其他master主機(jī)（k8s-master02和k8s-master03）：
到各個(gè)master上修改文件訪問權(quán)限：
各個(gè)master節(jié)點(diǎn)依據(jù)自己情況做少量更改，主要是：
1、自己的被選舉權(quán)重
2、自己的網(wǎng)卡名稱
在本例中，主master節(jié)點(diǎn)配置（/etc/keepalived/keepalived.conf）為：
第一個(gè)備份master節(jié)點(diǎn)配置（/etc/keepalived/keepalived.conf）：
第二個(gè)備份master節(jié)點(diǎn)配置為（/etc/keepalived/keepalived.conf）：
仿造前面做node和master的配置（master到初始化master的前一步）這里略去，參考前面即可
鑒于我們是在非master高可用基礎(chǔ)上做的高可用，即原來的master上曾經(jīng)執(zhí)行過kubeadm init，所以這里需要在這個(gè)節(jié)點(diǎn)上先執(zhí)行reset操作(只需要在原來的那一個(gè)master節(jié)點(diǎn)上執(zhí)行即可)
在MASTER上建一個(gè)腳本然后執(zhí)行：
在所有其他的BACKUP master上建一個(gè)腳本然后執(zhí)行：
對(duì)5臺(tái)機(jī)器分別修改，同時(shí)修改hosts文件
1.1.2修改其它的主機(jī)名
所有主機(jī)操作
本文的k8s網(wǎng)絡(luò)使用flannel，該網(wǎng)絡(luò)需要設(shè)置內(nèi)核參數(shù)bridge-nf-call-iptables=1，修改這個(gè)參數(shù)需要系統(tǒng)有br_netfilter模塊。
查看br_netfilter模塊：
如果系統(tǒng)沒有br_netfilter模塊則執(zhí)行下面的新增命令，如有則忽略。
臨時(shí)新增br_netfilter模塊:
永久新增br_netfilter模塊：
永久修改
在所有機(jī)器上都添加以下源
所有服務(wù)器均安裝
查看docker版本
安裝docker
在三臺(tái)master主機(jī)上都需要安裝keepalived
所有機(jī)器全部安裝
kubelet 運(yùn)行在集群所有節(jié)點(diǎn)上，用于啟動(dòng)Pod和容器等對(duì)象的工具
kubeadm 用于初始化集群，啟動(dòng)集群的命令工具
kubectl 用于和集群通信的命令行，通過kubectl可以部署和管理應(yīng)用，查看各種資源，創(chuàng)建、刪除和更新各種組件
安裝版本為最新 1.22.2
也可以根據(jù)自己所需要的版本來安裝部署
查看版本
安裝yum install -y kubelet kubeadm kubectl
啟動(dòng)kubelet并設(shè)置開機(jī)啟動(dòng)
初始化失敗，或出現(xiàn)以下錯(cuò)誤，可以重新初始化
如果初始化失敗，可執(zhí)行kubeadm reset后重新初始化
記錄kubeadm join的輸出，后面需要這個(gè)命令將work節(jié)點(diǎn)和其他master節(jié)點(diǎn)加入集群中。
master01分發(fā)證書：
在master01上運(yùn)行腳本cert-main-master.sh，將證書分發(fā)至master02和master03
同時(shí)執(zhí)行
同時(shí)執(zhí)行
work01加入集群
work02加入集群
如果出現(xiàn)worker節(jié)點(diǎn)名字沒改，后面添加有問題,按以下執(zhí)行則可以后續(xù)添加
CNI網(wǎng)絡(luò)插件
先關(guān)閉master01
查看master02
正常轉(zhuǎn)移。
k8s高可用部署完畢
從 Gitlab 8.0 開始，Gitlab CI 就已經(jīng)集成在 Gitlab 中，只要在項(xiàng)目中添加一個(gè) .gitlab-ci.yml 文件，然后添加一個(gè) Runner ，即可進(jìn)行持續(xù)集成。在介紹 Gitlab CI 之前，先看看一些 Gitlab CI 的一些相關(guān)概念。
Jobs-Stages-Pipeline
一次 Pipeline 其實(shí)相當(dāng)于一次構(gòu)建任務(wù)，里面可以包含很多個(gè)流程，如安裝依賴、運(yùn)行測(cè)試、編譯、部署測(cè)試服務(wù)器、部署生產(chǎn)服務(wù)器等流程。任何提交或者 Merge Request 的合并都可以觸發(fā) Pipeline 構(gòu)建，如下圖所示：
Stages 表示一個(gè)構(gòu)建階段，也就是上面提到的一個(gè)流程?？梢栽谝淮?Pipeline 中定義多個(gè) Stages，這些 Stages 會(huì)有以下特點(diǎn)：
Stages 和 Pipeline 的關(guān)系如下所示：
Jobs 表示構(gòu)建工作，表示某個(gè) Stage 里面執(zhí)行的工作?？梢栽?Stages 里面定義多個(gè) Jobs，這些 Jobs 會(huì)有以下特點(diǎn)：
Jobs 和 Stage 的關(guān)系如下所示：
如果理解了上面的基本概念之后，可能我們就會(huì)發(fā)現(xiàn)一個(gè)問題，我們的構(gòu)建任務(wù)在什么地方來執(zhí)行呢，以前用 Jenkins 在 Master 和 Slave 節(jié)點(diǎn)都可以用來運(yùn)行構(gòu)建任務(wù)，而來執(zhí)行我們的 Gitlab CI 構(gòu)建任務(wù)的就是 Gitlab Runner。
我們知道大多數(shù)情況下構(gòu)建任務(wù)都是會(huì)占用大量的系統(tǒng)資源的，如果直接讓 Gitlab 本身來運(yùn)行構(gòu)建任務(wù)的話，顯然 Gitlab 的性能會(huì)大幅度下降的。GitLab CI 最大的作用是管理各個(gè)項(xiàng)目的構(gòu)建狀態(tài)，因此，運(yùn)行構(gòu)建任務(wù)這種浪費(fèi)資源的事情交給一個(gè)獨(dú)立的 Gitlab Runner 來做就會(huì)好很多，更重要的是 Gitlab Runner 可以安裝到不同的機(jī)器上，甚至是我們本機(jī)，這樣完全就不會(huì)影響到 Gitlab 本身了。
安裝 Gitlab Runner 非常簡(jiǎn)單，我們可以完全安裝官方文檔： 即可，比如可以直接使用二進(jìn)制、Docker 等來安裝。同樣的，我們這里還是將 Gitlab Runner 安裝到 Kubernetes 集群中來，讓我們的集群來統(tǒng)一管理 Gitlab 相關(guān)的服務(wù)。
1.驗(yàn)證 Kubernetes 集群
執(zhí)行下面的命令驗(yàn)證 Kubernetes 集群：
cluster-info這個(gè)命令會(huì)顯示當(dāng)前鏈接的集群狀態(tài)和可用的集群服務(wù)列表。
2.獲取 Gitlab CI Register Token
上節(jié)已經(jīng)成功安裝了 Gitlab，在瀏覽器中打開 hwzxgit.sinoing點(diǎn)虐 頁面，然后登錄后進(jìn)入到管理頁面 ，然后點(diǎn)擊導(dǎo)航欄中的Runner，可以看到該頁面中有兩個(gè)總要的參數(shù)，一個(gè)是 URL，另外一個(gè)就是 Register Token，下面的步驟中需要用到這兩個(gè)參數(shù)值。
圖一、
同樣將 Runner 相關(guān)的資源對(duì)象都安裝到kube-ops這個(gè) namespace 下面，首先，通過 ConfigMap 資源來傳遞 Runner 鏡像所需的環(huán)境變量（runner-cm.yaml）:
要注意 CI_SERVER_URL 對(duì)應(yīng)的值需要指向 Gitlab 實(shí)例的 URL（可以是外網(wǎng)地址，也可以是 Kubernetes 集群內(nèi)部的 Service DNS 地址，因?yàn)?Runner 也是運(yùn)行在 Kubernetes 集群中的），并加上 /ci （ ），也可以是CI_SERVER_URL: " "此外還添加了一些構(gòu)建容器運(yùn)行的資源限制，可以自己根據(jù)需要進(jìn)行更改即可。
除了上面的一些環(huán)境變量相關(guān)的配置外，還需要一個(gè)用于注冊(cè)、運(yùn)行和取消注冊(cè) Gitlab CI Runner 的小腳本。只有當(dāng) Pod 正常通過 Kubernetes（TERM信號(hào)）終止時(shí)，才會(huì)觸發(fā)轉(zhuǎn)輪取消注冊(cè)。 如果強(qiáng)制終止 Pod（SIGKILL信號(hào)），Runner 將不會(huì)注銷自身。必須手動(dòng)完成對(duì)這種被殺死的 Runner 的清理，配置清單文件如下：（runner-scripts-cm.yaml）
可以看到需要一個(gè) GITLAB_CI_TOKEN，然后復(fù)制下圖中的Gitlab CI runner token 來創(chuàng)建一個(gè) Kubernetes secret 對(duì)象。將 token 進(jìn)行 base64 編碼：
然后接下來就可以來編寫一個(gè)用于真正運(yùn)行 Runner 的控制器對(duì)象，這里使用 Statefulset。首先，在開始運(yùn)行的時(shí)候，嘗試取消注冊(cè)所有的同名 Runner，當(dāng)節(jié)點(diǎn)丟失時(shí)（即NodeLost事件），這尤其有用。然后再嘗試重新注冊(cè)自己并開始運(yùn)行。在正常停止 Pod 的時(shí)候，Runner 將會(huì)運(yùn)行unregister命令來嘗試取消自己，所以 Gitlab 就不能再使用這個(gè) Runner 了，這個(gè)是通過 Kubernetes Pod 生命周期中的hooks來完成的。
另外通過使用envFrom來指定Secrets和ConfigMaps來用作環(huán)境變量，對(duì)應(yīng)的資源清單文件如下：(runner-statefulset.yaml)
可以看到上面我們使用了一個(gè)名為 gitlab-ci 的 serviceAccount，新建一個(gè) rbac 資源清單文件：(runner-rbac.yaml)
4.創(chuàng)建 Runner 資源對(duì)象
資源清單文件準(zhǔn)備好后，直接創(chuàng)建上面的資源對(duì)象：
創(chuàng)建完成后，可以通過查看 Pod 狀態(tài)判斷 Runner 是否運(yùn)行成功：
可以看到已經(jīng)成功運(yùn)行了兩個(gè)（具體取決于StatefulSet清單中的副本數(shù)) Runner 實(shí)例，然后切換到 Gitlab Admin 頁面下面的 Runner 頁面：
至此，在kubernetes中安裝Gitlab CI Runner結(jié)束，當(dāng)然也可以根據(jù)需要更改 Runner 的一些配置，比如添加 tag 標(biāo)簽等。
重慶分公司
重慶分公司
