個(gè)推在Kubernetes的效率提升舉措揭秘及最佳實(shí)踐解析

一、如何提升Kubernetes研發(fā)效率

成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供鲅魚圈網(wǎng)站建設(shè)、鲅魚圈做網(wǎng)站、鲅魚圈網(wǎng)站設(shè)計(jì)、鲅魚圈網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、鲅魚圈企業(yè)網(wǎng)站模板建站服務(wù)，十年鲅魚圈做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

本文將從三方面闡述如何提升Kubernetes研發(fā)效率：

微服務(wù)與CI開發(fā)（提升開發(fā)效率）

研發(fā)網(wǎng)絡(luò)與Kubernetes互通（提升調(diào)試效率）

服務(wù)端軟件管理平臺(tái)建設(shè)（提升運(yùn)維效率）

微服務(wù)目前已成為主流的容器編排技術(shù)，然而不少開發(fā)者在使用過中或多或少會(huì)遇到一些問題，主要在于以下四點(diǎn)：

1）Kubernetes涉及較多專業(yè)知識(shí)，而研發(fā)掌握有關(guān)知識(shí)有一定的門檻。

2）Kubernetes鏡像常常沒有充分利用 Build Cache，導(dǎo)致占用構(gòu)建存儲(chǔ)大，傳輸慢。

3）不同的業(yè)務(wù)其鏡像差異大，運(yùn)維在對(duì)鏡像進(jìn)行維護(hù)時(shí)操作過程非常復(fù)雜。

4）Kubernetes安全更新后，不僅要確保程序沒有漏洞，還要確保編程語言、基礎(chǔ)鏡像、業(yè)務(wù)本身都沒有安全漏洞。如果研發(fā)人員要維護(hù)全部的更新內(nèi)容，負(fù)擔(dān)比較重，一定程度上會(huì)影響其研發(fā)效率。

開發(fā)一個(gè)新的微服務(wù)涉及諸多環(huán)節(jié)，比如Dockerfile的編寫、安全更新的維護(hù)、緩存層的設(shè)計(jì)，監(jiān)控指標(biāo)的接入等。而這些環(huán)節(jié)會(huì)出現(xiàn)一些問題，主要包括容器體系重復(fù)建設(shè)、安全更新需求需要在各個(gè)服務(wù)重復(fù)實(shí)現(xiàn)、Build Cache難以跨服務(wù)復(fù)用等。

為解決以上問題，我們采用了以下措施：

1）在容器體系統(tǒng)一建設(shè)的同時(shí)，做到允許自定義，降低門檻；

2）將鏡像統(tǒng)一為公用幾類（Node.js/Java/Golang），統(tǒng)一維護(hù)安全更新；

3） 跨服務(wù)共用Build Cache；

4） 統(tǒng)一置入工具鏈、依賴、ARM適配、監(jiān)控指標(biāo)等。這樣一來，對(duì)于ARM問題，在構(gòu)建鏡像時(shí)，我們會(huì)先構(gòu)建完X86，再構(gòu)建統(tǒng)一的ARM。這些步驟都在統(tǒng)一的CI腳本中完成，從而節(jié)省時(shí)間。

在調(diào)試效率上，Kubernetes的痛點(diǎn)在于debug流程復(fù)雜耗時(shí)長(zhǎng)，因?yàn)槲⒎?wù)通常需要依賴服務(wù)進(jìn)行調(diào)試，但是開發(fā)機(jī)無法連接集群內(nèi)Kubernetes Service 進(jìn)行調(diào)試，且服務(wù)可能不位于流量入口位置，需要將中間環(huán)節(jié)的流量轉(zhuǎn)發(fā)。

怎么樣才能縮短debug流程，讓調(diào)試完的代碼能夠秒級(jí)生效呢？

來看上面左邊這張圖。左圖上半部分由開發(fā)機(jī)與DNS組成。下半部分是k8s集群，包含它的CoreDNS以及service B。為縮短調(diào)試流程，我們?cè)陂_發(fā)區(qū)的網(wǎng)絡(luò)拓?fù)渲胁渴鹆薔ginx，用于把所有的 k8s cluster的域名解析到 k8s服務(wù)上。

比如我們統(tǒng)一取名為*.svc. cluster.local，并把它都統(tǒng)一解析到 k8s集群上，集群上我們調(diào)起Nginx，Nginx收到來自b.app.svc.cluster.local的請(qǐng)求后，直接向 k8s的CoreDNS去獲取它svc的cluster IP。獲取到IP后，它就可以知道，該項(xiàng)服務(wù)是 APP內(nèi)service中的B服務(wù)，以及cluster的IP地址，然后Nginx便可以通過proxy pass進(jìn)行轉(zhuǎn)發(fā)。這樣我們就實(shí)現(xiàn)了在開發(fā)機(jī)內(nèi)任意地訪問開發(fā)網(wǎng)k8s內(nèi)進(jìn)行的服務(wù)的需求。

在運(yùn)維效率上，Kubernetes的痛點(diǎn)主要來自以下四方面：

1）微服務(wù)化導(dǎo)致服務(wù)數(shù)量增加，需要將服務(wù)分組及模塊化管理，而這會(huì)增加管理成本。

2）每個(gè)服務(wù)都有各自的依賴，當(dāng)我們想針對(duì)服務(wù)進(jìn)行管理的時(shí)候，存在依賴管理的問題。

3）由于服務(wù)數(shù)量眾多，服務(wù)手工升級(jí)過程也耗時(shí)耗力。

4）在私有化部署背景下，我們很難直接將應(yīng)用快速分發(fā)到客戶集群上。

為解決以上痛點(diǎn)，我們提出了Kubernetes APP平臺(tái)思路，并設(shè)計(jì)了如下技術(shù)架構(gòu)。

架構(gòu)圖由四部分組成：Helm、ChartMuseum、APP Installer Container、Kubeapps。Helm是包管理器，可以管理依賴，并提供鉤子機(jī)制，幫助實(shí)現(xiàn)模板化。ChartMuseum用于包存儲(chǔ)。APP Installer Container執(zhí)行定制的APP結(jié)構(gòu)規(guī)范、自動(dòng)升級(jí)SQL Schema、自動(dòng)導(dǎo)入Consul配置以及注冊(cè)網(wǎng)關(guān)入口及插件。Kubeapps方便UI管理。

要想提升運(yùn)維效率，需要將運(yùn)維管理維度從服務(wù)層面轉(zhuǎn)換成APP層面。為此，我們把相近的業(yè)務(wù)合并成一個(gè)統(tǒng)一的模塊去管理，降低管理復(fù)雜度。具體來看，每個(gè)服務(wù)生成一個(gè)helm包，包含自身標(biāo)準(zhǔn)化的SQL、Consul配置等，掛在Helm Hook上由定制化的Runner執(zhí)行，并通過標(biāo)準(zhǔn)化SQL升級(jí)、Consul配置管理等，提升運(yùn)維管理效率。

個(gè)推K8S最佳實(shí)踐解析

個(gè)推Kubernetes最佳實(shí)踐將從個(gè)推k8s集群概覽、使用規(guī)范制定、使用經(jīng)驗(yàn)總結(jié)三方面展開，以幫助開發(fā)者在Kubernetes使用過程中根據(jù)企業(yè)自身應(yīng)用和環(huán)境特點(diǎn)找到適合的方案。

首先簡(jiǎn)要介紹下我們的組件地圖與各組件的用途。如果用一把傘來比喻我們的組件地圖，那么傘的核心組件是Kubernetes，docker則是底層最基礎(chǔ)的運(yùn)行環(huán)境，calico和fannel是網(wǎng)絡(luò)cni的選型；coreDns是k8s內(nèi)部的域名解析組件；kube-stat-metrics是主要的監(jiān)控組件，kube-stat-metrics主要用于采集pod的狀態(tài); dashboard是運(yùn)維管理工具；Harbor是企業(yè)級(jí)的鏡像倉(cāng)庫開源解決方案；consul/Apollo是配置中心；Ingress用于提供負(fù)載均衡功能，是我們暴露集群外到集群內(nèi)服務(wù)的http和https路由的方案之一。

為了更好地對(duì)k8s進(jìn)行管理和維護(hù)，我們制定了詳細(xì)的k8s使用規(guī)范。在個(gè)推實(shí)踐中，規(guī)范主要分為五類：參數(shù)、安全、資源、日志、YAML。參數(shù)規(guī)范主要指的是對(duì)參數(shù)命名規(guī)則的規(guī)范。常見參數(shù)主要包含dns、ulimit、kubelet insufficient pods、calico、內(nèi)核參數(shù)、xfs系統(tǒng)的d_type支持、label等。安全規(guī)范是面對(duì)網(wǎng)絡(luò)各信息安全相關(guān)的規(guī)范，主要包括業(yè)務(wù)線的隔離、資源的限制、訪問的控制以及PSP相關(guān)的設(shè)置；

資源類規(guī)范主要指的是資源可見性以及資源的控制與分配；日志規(guī)范是為了所有日志能夠被統(tǒng)一采集和管理所制定的 規(guī)范，比如日志格式、日志分類以及日志存放目錄規(guī)范；YAML的規(guī)范是為了保持線網(wǎng)環(huán)境以及測(cè)試環(huán)境的一致性，讓功能更加穩(wěn)定、發(fā)布更加高效和安全而制定的一些列規(guī)范和標(biāo)準(zhǔn)。

規(guī)范標(biāo)準(zhǔn)化是一個(gè)持續(xù)的過程。我們通過學(xué)習(xí)、思考以及經(jīng)驗(yàn)汲取來制定執(zhí)行和完善這個(gè)規(guī)范的過程，就是我們?cè)诓粩嗵岣哔|(zhì)量、提高管理水平、提高收益的過程，這也是k8s集群得以持續(xù)發(fā)展的原因。

在制定標(biāo)準(zhǔn)的過程中，我們踩過一些坑，以下將分享有關(guān)經(jīng)驗(yàn)供參考。

問題：

我們發(fā)現(xiàn)在service轉(zhuǎn)發(fā)過程中，流量負(fù)載并不均衡，導(dǎo)致單個(gè)pod請(qǐng)求壓力過高。

解決方案：

1）對(duì)邊緣節(jié)點(diǎn)進(jìn)行了改造，在node上部署了nginx，upstream中的節(jié)點(diǎn)通過實(shí)時(shí)從consul中獲取服務(wù)的狀態(tài)和ip實(shí)時(shí)更新，以此繞過了service的流量分發(fā)，避免了流量負(fù)載不均的問題。k8s集群內(nèi)部服務(wù)模塊之間的轉(zhuǎn)發(fā)也可以通過類似的方法予以實(shí)現(xiàn)。

2） 由于ingress抗壓能力強(qiáng)，故使用ingress也能實(shí)現(xiàn)流量負(fù)載均衡的需求，保證ingress到后端的流量是均衡的。

總之，k8s服務(wù)已經(jīng)逐漸成熟，但也仍存在一些問題，需要我們開發(fā)者共同去解決這些問題，讓k8s生態(tài)發(fā)展更健康，讓工作更高效。

PPT獲取方式

關(guān)注【個(gè)推技術(shù)學(xué)院】微信公眾號(hào)

（微信號(hào)：getuitech）

回復(fù)關(guān)鍵詞“ k8s”

即可領(lǐng)取Kubernetes專場(chǎng)完整版嘉賓分享PPT！