一、如何提升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)維效率)
01
開發(fā)效率:微服務(wù)與CI 開發(fā)
微服務(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í)間。
02
調(diào)試效率:開發(fā)集群網(wǎng)絡(luò)
在調(diào)試效率上,Kubernetes的痛點(diǎn)在于debug流程復(fù)雜耗時(shí)長,因?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ù)的需求。
03
運(yùn)維效率:Kubernetes APP平臺(tái)
在運(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)找到適合的方案。
01
個(gè)推K8s集群概覽
首先簡要介紹下我們的組件地圖與各組件的用途。如果用一把傘來比喻我們的組件地圖,那么傘的核心組件是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í)的鏡像倉庫開源解決方案;consul/Apollo是配置中心;Ingress用于提供負(fù)載均衡功能,是我們暴露集群外到集群內(nèi)服務(wù)的http和https路由的方案之一。
02
使用規(guī)范
為了更好地對(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)境以及測試環(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ā)展的原因。
03
填坑經(jīng)驗(yàn)分享
在制定標(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專場完整版嘉賓分享PPT!
分享題目:個(gè)推在Kubernetes的效率提升舉措揭秘及最佳實(shí)踐解析
本文網(wǎng)址:http://m.rwnh.cn/article46/ghsdhg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供做網(wǎng)站、App開發(fā)、全網(wǎng)營銷推廣、小程序開發(fā)、品牌網(wǎng)站制作、網(wǎng)站維護(hù)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)