|
【作者】蘆葦,，云計(jì)算架構(gòu)師 前言 國(guó)內(nèi)保險(xiǎn)業(yè)客戶向線上遷徙,，對(duì)于保險(xiǎn)產(chǎn)品和服務(wù)形式的期望集中在簡(jiǎn)單、便捷,、透明,、個(gè)性化以及社交化,，開(kāi)始深耕大健康領(lǐng)域,，加快為客戶打造全場(chǎng)景、全覆蓋的保險(xiǎn)服務(wù)生態(tài)圈,。作為一家全球大型保險(xiǎn)金融服務(wù)集團(tuán),，打造“保險(xiǎn)＋醫(yī)療養(yǎng)老”生態(tài)閉環(huán)，引領(lǐng)服務(wù)業(yè)和供給側(cè)改革,，助力民生發(fā)展,，服務(wù)經(jīng)濟(jì)社會(huì)。伴隨互聯(lián)網(wǎng),、大數(shù)據(jù),，以及人工智能等技術(shù)的發(fā)展，新業(yè)務(wù)形態(tài),、新業(yè)務(wù)需求乃至新業(yè)務(wù)創(chuàng)新都對(duì)現(xiàn)有IT提出了新的挑戰(zhàn),。 這就帶來(lái)了對(duì)IT基礎(chǔ)設(shè)施的敏捷化需求，計(jì)算資源從物理機(jī),，到虛擬化,，再到IaaS；新一代企業(yè)云建設(shè)的重點(diǎn)由IaaS來(lái)到了PaaS,，作為云計(jì)算市場(chǎng)的制高點(diǎn),，成了眾人追逐的對(duì)象。與已經(jīng)趨向成熟的IaaS和SaaS相比,，PaaS仍處于持續(xù)演進(jìn)的過(guò)程中,，從Openstack和VMware的產(chǎn)品技術(shù)動(dòng)向來(lái)看,，IaaS與PaaS正快速融合。如今,，隨著技術(shù)和社區(qū)的成熟,，容器、Kubernetes,、微服務(wù)等新事物不再只是概念,，已在很多企業(yè)落地并發(fā)揮了生產(chǎn)力,，對(duì)容器和PaaS的需求也從試探性轉(zhuǎn)向規(guī)模化推廣和縱深探索，建設(shè)企業(yè)級(jí)容器PaaS平臺(tái)成為必然趨勢(shì),。 背景 技術(shù)方面： 1.容器 - 量變引發(fā)質(zhì)變，形成PaaS平臺(tái)新契機(jī)
虛擬機(jī) VS 容器 2.微服務(wù)架構(gòu)引領(lǐng)企業(yè)軟件架構(gòu)的變革
3.Kubernetes成為容器編排技術(shù)標(biāo)準(zhǔn)
企業(yè)方面： 企業(yè)業(yè)務(wù)應(yīng)用系統(tǒng)分層 微服務(wù)和云原生對(duì)PaaS的需求越發(fā)強(qiáng)烈，必須要用全新的視角建設(shè)容器云PaaS平臺(tái),；PaaS帶來(lái)的不只是技術(shù)的變化,，還有開(kāi)發(fā)模式和運(yùn)維模式的轉(zhuǎn)變，以及IT資源生命周期的管理等,。 容器云PaaS的建設(shè)目標(biāo) 容器云PaaS平臺(tái)是企業(yè)IT集中化建設(shè)的基礎(chǔ)設(shè)施平臺(tái),，目標(biāo)一定是結(jié)合業(yè)務(wù)使用場(chǎng)景實(shí)際需求，而不是追求大而全,，要杜絕技術(shù)上的投機(jī)主義,，做到技術(shù)和成本的權(quán)衡；構(gòu)建容器PaaS基礎(chǔ)設(shè)施,，,；在容器云PaaS框架下，擴(kuò)展提供軟件定義網(wǎng)絡(luò),、軟件定義存儲(chǔ),、權(quán)限管理、企業(yè)級(jí)鏡像倉(cāng)庫(kù),、統(tǒng)一入口路由,、CI/CD、統(tǒng)一管理控制臺(tái),、監(jiān)控日志等功能,，形成覆蓋整個(gè)軟件生命周期的解決方案，并配套建設(shè)DevOps工具鏈,、微服務(wù)管理平臺(tái),、IT運(yùn)營(yíng)/監(jiān)控平臺(tái),。 企業(yè)需要怎樣的一個(gè)PaaS平臺(tái)，首先要認(rèn)識(shí)到云計(jì)算技術(shù)的復(fù)雜性,，比如OpenStack,，Kubernetes 和Ceph，代表了開(kāi)源云技術(shù)領(lǐng)域的三個(gè)典型,，企業(yè)想用好并不容易,，其所涉及到技術(shù)棧幾乎覆蓋全部的計(jì)算領(lǐng)域知識(shí)，又處于數(shù)據(jù)中心的底座,，牽一發(fā)而動(dòng)全身,，企業(yè)之大事，存亡之道,，不可不察也,。不可盲目得追求大而全得功能，花哨的功能,，做加法容易,，做減法難，PaaS建設(shè)的核心需求是數(shù)據(jù)中心技術(shù)底座,，健壯,、可運(yùn)維性強(qiáng)、長(zhǎng)生命周期支持是根本,。 建設(shè)原則 技術(shù)先進(jìn)性和成熟性 互聯(lián)網(wǎng)和開(kāi)源帶來(lái)了新技術(shù)的迅猛發(fā)展,，大廠積極參與社區(qū),，一定要立足高起點(diǎn),，積極吸收社區(qū)的養(yǎng)分，把握技術(shù)的方向,，選擇先進(jìn)性和成熟度融合較好的技術(shù),，在保障平臺(tái)穩(wěn)定性的基礎(chǔ)上，考慮到技術(shù)折舊,，滿足3-5年的技術(shù)需求即可,。 開(kāi)發(fā)性和標(biāo)準(zhǔn)化 平臺(tái)總體設(shè)計(jì)上一定不能偏離業(yè)界標(biāo)準(zhǔn)和實(shí)踐，充分利用開(kāi)源社區(qū),，例如kubernetes為了保證社區(qū)不分裂,，推出了一致性認(rèn)證計(jì)劃，產(chǎn)品要和主流的技術(shù)棧如DevOps工具鏈,、CI/CD,、微服務(wù)框架保持較好的兼容，松耦合 標(biāo)準(zhǔn)化,，易于調(diào)整,，可較好的適應(yīng)企業(yè)現(xiàn)有技術(shù)棧和基礎(chǔ)環(huán)境,，可靈活組合，這樣也可最大程度的利用已有技術(shù),，降低成本,。 可靠性與安全性 安全和可靠是整個(gè)系統(tǒng)建設(shè)的基礎(chǔ)，復(fù)雜的容器云PaaS平臺(tái)更是如此,，平臺(tái)需提供良好的可靠性工具,，可運(yùn)維性強(qiáng)、可觀測(cè)(監(jiān)控),、可全方位容錯(cuò),、備份恢復(fù)與自診斷、良好的debug與故障診斷,，確保系統(tǒng)數(shù)據(jù)的準(zhǔn)確性,、正確性。 合理的技術(shù)演進(jìn)路線 考慮到容器云PaaS的技術(shù)成熟度,，哪些應(yīng)用要上容器云,，數(shù)據(jù)庫(kù)要不要上，現(xiàn)在不上何時(shí)上,，上的話需要具備哪些條件,，都需要有合理的規(guī)劃，采取正確的實(shí)施策略,，分為一期二期三期甚至更多來(lái)實(shí)現(xiàn),，正確準(zhǔn)確得邁出第一步很關(guān)鍵。 風(fēng)險(xiǎn)與應(yīng)對(duì)措施 1,、 容器技術(shù)的弱隔離性 容器（container）,，并不是一種虛擬化（virtualization）技術(shù)，而是一種進(jìn)程隔離（isolation）技術(shù),，從內(nèi)核空間,、資源和安全等方面對(duì)進(jìn)程做隔離，其不具備和虛擬機(jī)以及沙盒（sanbox）一樣的隔離能力,，目前以kata為代表的輕量級(jí)vm容器技術(shù)還不能成為主流,，目前只能選擇Docker(Containerd)作為容器引擎，所以要從業(yè)務(wù)所使用的技術(shù)棧來(lái)考慮是否適合容器化,，切忌一刀切,。 2、 企業(yè)多租戶隔離 多租戶隔離在容器云PaaS主要分為考慮網(wǎng)絡(luò)上的隔離性,，主要分為弱隔離和強(qiáng)隔離,。弱隔離的場(chǎng)景適合同一個(gè)組織多個(gè)租戶使用同一個(gè)集群，能達(dá)到在邏輯上隔離的目的；強(qiáng)隔離的技術(shù)需求通過(guò)一個(gè)集群很難解決,，最好采用多集群的方案,，容器云在上層做統(tǒng)一納管即可； 3,、 配套的DevOps工具鏈和CI/CD流水線 容器的應(yīng)用交付完全不同于vm時(shí)代,，其模糊了開(kāi)發(fā)和運(yùn)維的邊界，需要通過(guò)DevOps去解決,，需要建設(shè)配套的工具鏈如Helm,、Jenkins、統(tǒng)一鏡像倉(cāng)庫(kù),、CMDB,、代碼托管倉(cāng)庫(kù)、Dockerfile編寫(xiě)等都需要去解決,，涉及到的工具很多,，配套跟不上，企業(yè)內(nèi)部的采購(gòu)流程一般又較長(zhǎng),，善于利用開(kāi)源工具去解決這個(gè)問(wèn)題,； 4、 應(yīng)用的容器化改造 應(yīng)用要上容器云PaaS,，比如進(jìn)行無(wú)狀態(tài)化改造,，日志的標(biāo)準(zhǔn)化輸出、監(jiān)控埋點(diǎn),、CI/CD自動(dòng)化等,； 產(chǎn)品/技術(shù)選型 我司從2016年還是對(duì)容器技術(shù)進(jìn)行試驗(yàn)性研究，不像現(xiàn)在的Kubernetes一統(tǒng)江湖,，當(dāng)時(shí)的container領(lǐng)域docker一家獨(dú)大,，容器編排領(lǐng)域swarm、mesos,、kubernetes上演三國(guó)演義,，Mesos定位數(shù)據(jù)中心技術(shù)底座,，天然吸引大型企業(yè),，kubernetes戴著谷歌的光環(huán)，swarm是Docker自家產(chǎn)品,，各懷千秋,；國(guó)內(nèi)的容器技術(shù)創(chuàng)業(yè)公司也雨后春筍般出現(xiàn)，可見(jiàn)其火熱程度,，炙手可熱,。一圈下來(lái)，編排發(fā)現(xiàn)落地太難,，不知道從何處下手,，尚不敢做容器PaaS的假設(shè),。 就這樣時(shí)間到了2017年，容器編排領(lǐng)域技術(shù)一下失去懸念,，Kubernetes脫穎而出,；上半年我們就迅速確定了kubernetes作為容器PaaS的技術(shù)核心，視線開(kāi)始轉(zhuǎn)向產(chǎn)品解決方案,，建設(shè)目標(biāo)也逐漸清晰起來(lái),；作為一個(gè)技術(shù)底座，容器PaaS的底層技術(shù)健壯性的重要不言而喻,，雖然kubernetes已成編排領(lǐng)域事實(shí)標(biāo)準(zhǔn),，但kubernetes本身只專注于編排領(lǐng)域，其余的上下游技術(shù)棧都由社區(qū)提供,，怎樣良好的集成就成了擺在眼前的難題,；經(jīng)過(guò)研究和試用，我們最終把視角投向了Openshift,，OpenShift是一個(gè)私有的基于Kubernetes的企業(yè)級(jí)PaaS（Platform-as-a-Service）解決方案,，基于Docker和Kubernetes構(gòu)建，具有Kubernetes的全部?jī)?yōu)點(diǎn),，又針對(duì)Kubernetes的弱項(xiàng)又做了多方面的功能補(bǔ)充,，以滿足企業(yè)在業(yè)務(wù)應(yīng)用、開(kāi)發(fā)及運(yùn)維用戶在生產(chǎn)效率上的訴求,。 Openshift VS Kubernetes OpenShift項(xiàng)目和Kubernetes項(xiàng)目的定位不同,，屬于不同層次的創(chuàng)新。 Kubernetes項(xiàng)目目的是為了提供一個(gè)通用的容器部署和編排平臺(tái),，側(cè)重于提供基礎(chǔ)技術(shù)支持應(yīng)用在容器集群環(huán)境中的快速部署和運(yùn)行管理,。 OpenShift項(xiàng)目的關(guān)注點(diǎn)在于為用戶提供一個(gè)可用的基于容器的應(yīng)用云平臺(tái)的解決方案（Platform-as-a-Service）。這個(gè)方案包含具體的SDN,、日志,、儲(chǔ)存、高可用,、編程框架,、UI、自動(dòng)化等開(kāi)箱即用的方案,。 作為基礎(chǔ)技術(shù),，Kubernetes提供盡可能廣泛地支持各種技術(shù)和提供最大的可能性。 作為接近用戶側(cè)的解決方案,， OpenShift傾向于從眾多的可能性中實(shí)現(xiàn)某一種或多種具體的方案,。 通過(guò)OpenShift，企業(yè)可以快速搭建穩(wěn)定、安全,、高效的容器應(yīng)用平臺(tái),。在這個(gè)平臺(tái)上： 1、 可以構(gòu)建企業(yè)內(nèi)部的容器應(yīng)用市場(chǎng),，為開(kāi)發(fā)人員快速提供應(yīng)用開(kāi)發(fā)所依賴的中間件,、數(shù)據(jù)庫(kù)等服務(wù)。 2,、 通過(guò)OpenShift,，用戶可以貫通從應(yīng)用開(kāi)發(fā)到測(cè)試，再到上線的全流程,，開(kāi)發(fā),、測(cè)試和運(yùn)維等不同的角色可以在一個(gè)平臺(tái)上進(jìn)行協(xié)作，可以有效地幫助企業(yè)推進(jìn)DevOps,，提高資源利用率,，提升生產(chǎn)效率。 3,、 支持LDAP用戶權(quán)限管理,，支持細(xì)粒度的權(quán)限資源管理。 4,、良好的開(kāi)源社區(qū)支持,。 5、 強(qiáng)大的廠商支持和長(zhǎng)生命周期管理,。 6,、 支持軟件自定義網(wǎng)絡(luò)（SDN）。通過(guò)OpenVSwitch,，為用戶提供了靈活強(qiáng)健的軟件定義網(wǎng)絡(luò),。可實(shí)現(xiàn)跨主機(jī)共享網(wǎng)絡(luò)及多租戶隔離網(wǎng)絡(luò)模式；此外,，Openshift還支持與紅帽認(rèn)證過(guò)的第三方軟件定義網(wǎng)絡(luò)產(chǎn)品進(jìn)行集成,，例如： Cisco Contiv、Juniper Contrail,、Nokia Nuage,、Tigera Calico、VMware NSX-T,。 7,、 支持性能監(jiān)控及日志管理。Openshift提供了開(kāi)箱可用的性能監(jiān)控及日志管理組件,。能快速獲取業(yè)務(wù)的運(yùn)行狀態(tài)指標(biāo)，對(duì)業(yè)務(wù)日志進(jìn)行收集及分析。 8,、 支持多用戶接口,。可以通過(guò)友好的Web用戶界面、命令行工具及RESTful API放訪問(wèn)和使用Openshfit提供的各項(xiàng)功能,。 9,、 支持自動(dòng)化集群部署及管理。Openshift通過(guò)Ansible實(shí)現(xiàn)了集群的自動(dòng)化部署,，為集群的自動(dòng)化擴(kuò)容提供了接口,。 架構(gòu)方案 主機(jī)： 虛擬機(jī)方案： 雙方各有千秋，虛擬機(jī)部署優(yōu)點(diǎn)是靈活部署與配置,，節(jié)點(diǎn)擴(kuò)容方便,，可借助已有IaaS層的能力。遷移靈活,，虛擬機(jī)使用戶能夠使用image輕松地在主機(jī)之間移動(dòng)工作負(fù)載,，回滾方便。從平臺(tái)健壯性上考慮,，相當(dāng)于上了2道保險(xiǎn)：虛擬化層和paas層,；缺點(diǎn)：多了一層虛擬化，從復(fù)雜度上講,，整體可靠性會(huì)下降,； 裸金屬方案： 高性能，無(wú)虛擬化層的性能開(kāi)銷,，根據(jù)性能測(cè)試,，在裸機(jī)上運(yùn)行Kubernetes和容器，實(shí)現(xiàn)了顯著降低的延遲 - 比在虛擬機(jī)上運(yùn)行Kubernetes低大約3倍,。社區(qū)和廠商也在探索Container-native Virtualization,，比如kubevirt；從成本上看,，虛擬化和容器都是彈性計(jì)算的方案,，從license成本上考慮，作為用戶沒(méi)必要同時(shí)為2個(gè)技術(shù)買單,，因?yàn)槿萜鹘鉀Q了問(wèn)題,。綜合和長(zhǎng)遠(yuǎn)上看，推薦私有云環(huán)境下直接上裸金屬部署,；(備注：本次主要討論裸金屬方案) 高可用： 對(duì)于openshift集群來(lái)說(shuō),，有兩種類型的高可用。一種是集群自身不同組件的高可用,，另一種是運(yùn)行在集群內(nèi)部的應(yīng)用的高可用,。Openshift從設(shè)計(jì)之初就考慮了這兩種不同類型的高可用,。 對(duì)于集群組件高可用來(lái)說(shuō)，openshift有多種類型的組件,，包括master,，etcd，node,，router,，registry等，每個(gè)組件都默認(rèn)支持高可用的部署,。Openshift的router組件可以通過(guò)oc scale命令隨時(shí)進(jìn)行擴(kuò)展,，最多可以達(dá)到集群node的數(shù)量。 對(duì)于運(yùn)行在集群內(nèi)部的應(yīng)用來(lái)說(shuō),，openshift可以將應(yīng)用的多個(gè)實(shí)例分散在不同的物理拓?fù)涞膁omain概念上,，比如node，機(jī)架,，機(jī)房等,，這樣盡可能的保證應(yīng)用的實(shí)例不會(huì)再同一時(shí)間發(fā)生故障。Openshift可以提供對(duì)于應(yīng)用實(shí)例運(yùn)行情況的健康檢查探針,，當(dāng)openshift發(fā)現(xiàn)某個(gè)實(shí)例異常時(shí),，它會(huì)在其他的node上重新啟動(dòng)一個(gè)新的實(shí)例來(lái)代替故障的實(shí)例，并保證集群內(nèi)部的應(yīng)用總實(shí)例數(shù)量和管理人員配置的是一致的,。Openshift節(jié)點(diǎn)主要分為主控節(jié)點(diǎn)(Master)和受控節(jié)點(diǎn)(Node),，受控節(jié)點(diǎn)根據(jù)用途又分為基礎(chǔ)節(jié)點(diǎn)(Infra)和計(jì)算節(jié)點(diǎn)(Compute)，Master * 3 Infra *2 Infra *n,，具體角色 硬件配置配置示例(企業(yè)可根據(jù)自己情況進(jìn)行定制)： Master控制節(jié)點(diǎn) *3  Infra-node節(jié)點(diǎn) *2  Compute-node節(jié)點(diǎn) *n  部署架構(gòu)圖 網(wǎng)絡(luò)架構(gòu)圖  網(wǎng)絡(luò) Openshift使用軟件定義網(wǎng)絡(luò)（SDN）提供集群內(nèi)部統(tǒng)一的網(wǎng)絡(luò)環(huán)境,，可以使集群內(nèi)部不同節(jié)點(diǎn)之間的Pod進(jìn)行通訊。Openshift的SDN框架是非常靈活的,，可以通過(guò)配置切換不同的SDN實(shí)現(xiàn),。當(dāng)前版本的Openshift使用的是基于Open vSwitch的VXLAN方案。該方案為用戶提供了兩種不同類型的選擇,，ovs-subnet可以提供一個(gè)整體連通的平面網(wǎng)絡(luò),，所有集群中的Pod默認(rèn)都是可以直接通訊的;ovs-multitenant 提供了Project相互隔離的方式，每個(gè)Project有一個(gè)獨(dú)特的 Virtual Network ID（VNID）,，Project內(nèi)部的資源可以互通,，但是不同Project之間的Pods和服務(wù)是無(wú)法相互訪問(wèn)的。管理人員可以手動(dòng)的打通Project之間的網(wǎng)絡(luò),，使其可以相互訪問(wèn),。此方案對(duì)企業(yè)既有網(wǎng)絡(luò)無(wú)侵入性，可快速部署,； 多租戶支持： 每個(gè)用戶項(xiàng)目分配一個(gè)惟一的虛擬網(wǎng)絡(luò)ID (VNID)
 節(jié)點(diǎn)內(nèi)的SDN 流量  存儲(chǔ) 持久化存儲(chǔ)分為平臺(tái)內(nèi)置組件的持久化存儲(chǔ)和應(yīng)用的持久化存儲(chǔ),。 平臺(tái)的持久化存儲(chǔ)可根據(jù)企業(yè)已有的存儲(chǔ)平臺(tái)確定,，openshift本身支持NFS,、GlusterFS、Cinder,、Ceph等存儲(chǔ),。 應(yīng)用系統(tǒng)需要使用持久化數(shù)據(jù)的，優(yōu)先建議使用對(duì)象存儲(chǔ),，其次是使用nas,。 監(jiān)控和日志 推薦和企業(yè)已有的統(tǒng)一監(jiān)控和日志平臺(tái)。 監(jiān)控推薦直接使用內(nèi)置的Prometheus,，可定制多層次豐富的告警策略,，node節(jié)點(diǎn)的基礎(chǔ)監(jiān)控可使用zabbix之類的工具作為平臺(tái)帶外監(jiān)控工具補(bǔ)充，除此還需重點(diǎn)關(guān)注OCP內(nèi)部基礎(chǔ)組件的監(jiān)控,，如etcd,、ovs-sdn、router等監(jiān)控,，另外還要增加syslog關(guān)鍵字監(jiān)控用來(lái)探查平臺(tái)整體的監(jiān)控狀況,，提前處理。 平臺(tái)調(diào)度 Openshift從API Server接收到創(chuàng)建Pod的請(qǐng)求以后,，會(huì)為其安排一個(gè)可以運(yùn)行的節(jié)點(diǎn),。在調(diào)度的過(guò)程中首先會(huì)選取所有滿足Pod要求的節(jié)點(diǎn)，然后根據(jù)不同的算法為所有的節(jié)點(diǎn)進(jìn)行打分,，最后將Pod調(diào)度到合適的節(jié)點(diǎn)上,。結(jié)合Node labels和NodeSelector的使用，可以實(shí)現(xiàn)復(fù)雜的pod調(diào)度策略,。管理員可以為基礎(chǔ)設(shè)施打上多級(jí)標(biāo)簽（比如region=r1, zone=z1, rack=s1）,，部署應(yīng)用時(shí)可以通過(guò)Label指定該應(yīng)用需要運(yùn)行的基礎(chǔ)設(shè)施。部署人員可以指定Pod之間的親和關(guān)系（Affinity）,，將互相訪問(wèn)頻繁的Pod同時(shí)部署在網(wǎng)絡(luò)距離短的節(jié)點(diǎn)上（比如同一個(gè)節(jié)點(diǎn),、機(jī)架）。也可以指定服務(wù)的反親和屬性,，使同一個(gè)服務(wù)的多個(gè)Pod盡可能的在集群上分散部署（不同的節(jié)點(diǎn),、機(jī)架、機(jī)房）,，這樣也就提高了服務(wù)的高可用性,。 權(quán)限和多租戶管理 租戶是指多組不同的應(yīng)用或者用戶同時(shí)運(yùn)行在一個(gè)基礎(chǔ)資源池之上,，實(shí)現(xiàn)軟件、硬件資源的共享,，為了安全需求,，平臺(tái)需要提供資源隔離的能力。在OCP中,，project是一個(gè)進(jìn)行租戶隔離的概念,，它來(lái)源于kubernetes的namespace，并對(duì)其進(jìn)行了功能的擴(kuò)展,。利用Project,，OCP平臺(tái)從多個(gè)層面提供了多租戶的支持。 1. 權(quán)限控制 2. 網(wǎng)絡(luò)隔離 3. Router隔離 4. 物理資源池隔離 5. 對(duì)接外部LDAP,，可實(shí)現(xiàn)細(xì)粒度的權(quán)限控制,； 6. 根據(jù)要求定制個(gè)性化scc角色； 負(fù)載均衡 router本身可做平臺(tái)層內(nèi)部的多層次的7層控制,，外部還需增加一個(gè)負(fù)載均衡層,，對(duì)接企業(yè)已有的F5、LVS,、Nginx等負(fù)載均衡設(shè)備,，建議新增一層7層控制，分為內(nèi)網(wǎng)負(fù)載均衡器和外網(wǎng)負(fù)載均衡器,。 https證書(shū)也置于這一層,，這樣router直接啟用http的80服務(wù)即可。 團(tuán)隊(duì)組織架構(gòu) 應(yīng)用系統(tǒng)上云方案 上容器云流程 開(kāi)發(fā)測(cè)試環(huán)境流程 生產(chǎn)環(huán)境流程 應(yīng)用上容器云評(píng)估(架構(gòu)梳理) 1. 了解目前項(xiàng)目的架構(gòu),，確定哪些組件采用容器化方案 2. 目前數(shù)據(jù)庫(kù)采用傳統(tǒng)架構(gòu),，部署到物理機(jī)或虛機(jī) 3. 微服務(wù)架構(gòu)，單體應(yīng)用 4. 主流微服務(wù)框架(SpringCloud,、dubbo)的kubernetes方案,； 混合云下的交付 Jenkins Helm，這里不做展開(kāi) 應(yīng)用容器化改造過(guò)程中應(yīng)注意的幾個(gè)問(wèn)題 應(yīng)用的無(wú)狀態(tài)化,，日志輸出 1,、jdk版本是否要升級(jí) 參考：https://developers./blog/2017/04/04/openjdk-and-containers/#more-433899 java開(kāi)發(fā)時(shí)企業(yè)應(yīng)用的主力，相信java類開(kāi)發(fā)上容器云是第一要?jiǎng)?wù),，jdk11提供原生容器(containerd)支持,，另外Java 8u131及以上版本開(kāi)始支持了Docker的cpu和memory限制。如果應(yīng)用不能升級(jí)jdk11,，那就升級(jí)到Java 8u131,。 cpu limit 即如果沒(méi)有顯式指定-XX:ParalllelGCThreads 或者 -XX:CICompilerCount, 那么JVM使用docker的cpu限制。如果docker有指定cpu limit,，jvm參數(shù)也有指定-XX:ParalllelGCThreads 或者 -XX:CICompilerCount,，那么以指定的參數(shù)為準(zhǔn),。 memory limit 在java8u131 及java9，需要加上-XX: UnlockExperimentalVMOptions -XX: UseCGroupMemoryLimitForHeap才能使得Xmx感知docker的memory limit,。 2,、Debug工具： 不建議將基礎(chǔ)鏡像搞大，添加過(guò)多的dubug工具,，BusyBox 是一個(gè)集成了三百多個(gè)最常用Linux命令和工具的軟件,。BusyBox 包含了一些簡(jiǎn)單的工具，例如ls,、cat和echo等等,，還包含了一些更大,、更復(fù)雜的工具,，例grep、find,、mount以及telnet,。有些人將 BusyBox 稱為 Linux 工具里的瑞士軍刀。簡(jiǎn)單的說(shuō)BusyBox就好像是個(gè)大工具箱,，它集成壓縮了 Linux 的許多工具和命令,，也包含了 Android 系統(tǒng)的自帶的shell。 平臺(tái)運(yùn)維過(guò)程的幾點(diǎn)問(wèn)題 1,、 一次Node節(jié)點(diǎn)hang死的處理記錄 查看系統(tǒng)syslog發(fā)現(xiàn)一下關(guān)鍵日志： rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused 'open /proc/self/task/124250/attr/exec: too many open files in system' 更改文件數(shù)解決 2,、 擴(kuò)容計(jì)算節(jié)點(diǎn)，新節(jié)點(diǎn)的pod報(bào)”dial tcp:lookup …no such host”錯(cuò)誤 經(jīng)查,，是新增節(jié)點(diǎn)的dnsmasq信息未同步到其他節(jié)點(diǎn)上,，需重啟其他節(jié)點(diǎn)的dnsmsq服務(wù)； 3,、 擴(kuò)容新節(jié)點(diǎn)后,，新節(jié)點(diǎn)報(bào)錯(cuò)； atomic-openshift-node[2588]: E0701 19:02:26.547994 2588 summary.go:102] Failed to get system container stats for '/system.slice/atomic-openshift-node.service': failed to get cgroup stats for '/system.slice/atomic-openshift-node.service': failed to get container info for '/system.slice/atomic-openshift-node.service': unknown container '/system.slice/atomic-openshift-node.service' 經(jīng)查此為openshift的一個(gè)bug,參考 https://bugzilla./show_bug.cgi?id=1623261 https://github.com/openshift/origin/pull/21138 涉及到的文件（cat /etc/systemd/system.conf.d/origin-accounting.conf）修改如下,， [Manager] DefaultCPUAccounting=yes DefaultMemoryAccounting=yes # systemd v230 or newer #DefaultIOAccounting=yes # Deprecated, remove in future DefaultBlockIOAccounting=yes 最后,，需重啟主機(jī)； 4,、 平臺(tái)升級(jí) 應(yīng)用遷移的一些腳本： # 1.全量導(dǎo)出項(xiàng)目 ## 切換project oc project <projectName> # 新建$projectName mkdir <projectName-export> # 導(dǎo)出配置 for object in ingress route configmap service rolebindings serviceaccounts secrets imagestreamtags podpreset cms egressnetworkpolicies rolebindingrestrictions limitranges resourcequotas pvcs templates cronjobs statefulsets hpas deployments replicasets poddisruptionbudget endpoints dc role do oc get -o yaml --export $object > $object.yaml done ## 2.復(fù)制到新系群環(huán)境下 scp ... ## 3.導(dǎo)入新集群 # 切換project oc project <projectName> # 導(dǎo)入配置 for object in ingress route configmap service rolebindings serviceaccounts secrets imagestreamtags podpreset cms egressnetworkpolicies rolebindingrestrictions limitranges resourcequotas pvcs templates cronjobs statefulsets hpas deployments replicasets poddisruptionbudget endpoints dc role do oc create -f $object.yaml done 總結(jié) 企業(yè)要想落地容器云平臺(tái),，人是第一位的，需要數(shù)據(jù)中心團(tuán)隊(duì),、架構(gòu)團(tuán)隊(duì),、開(kāi)發(fā)團(tuán)隊(duì)及項(xiàng)目管理團(tuán)隊(duì)的密切配合，容器云PaaS自2018年初正式上線,，數(shù)據(jù)中心的運(yùn)維交付模式發(fā)生了變化,，逐漸向服務(wù)中心和價(jià)值中心轉(zhuǎn)變,，在計(jì)算資源利用率上得到了顯著提升，經(jīng)評(píng)估,，開(kāi)發(fā)資源池的資源利用率相比虛擬化提升5倍以上,；部署上通過(guò)helm Jenkins的交付真正可以做到了一鍵式交付，GitOps威力逐漸顯現(xiàn),；k8s springboot對(duì)微服務(wù)的支持可以直接替換負(fù)載的springcloud架構(gòu),，微服務(wù)治理的壓力得到了極大釋放。 上云一時(shí)爽,，一直上云一直爽,。
|
|
|
