|
容器云平臺建設(shè)行業(yè)背景 當(dāng)前銀行業(yè)普遍的共識之一是要以金融科技為依托，通過科技創(chuàng)新引領(lǐng)銀行的轉(zhuǎn)型升級。云計(jì)算、大數(shù)據(jù)、人工智能成為各銀行科技部門重點(diǎn)的投資建設(shè)領(lǐng)域。云計(jì)算領(lǐng)域的建設(shè)主要集中在IaaS和PaaS，目標(biāo)是降低數(shù)據(jù)中心成本的同時(shí)，為上層應(yīng)用的創(chuàng)新、快速迭代和穩(wěn)定運(yùn)行提供有效支撐。傳統(tǒng)的IaaS調(diào)度的是虛擬機(jī)或者物理機(jī)，粒度較大，相對傳統(tǒng)的虛擬化技術(shù)，在資源使用率、靈活性和彈性方面提升度并不高。依托傳統(tǒng)IaaS建設(shè)而成的PaaS，也會面臨同樣的問題。而容器技術(shù)恰好可以比較好的解決這些問題，并且在微服務(wù)、DevOps、分布式等方面天生具備優(yōu)勢，因此成為數(shù)據(jù)中心新一代云基礎(chǔ)架構(gòu)的選擇。 建設(shè)容器云平臺的意義 1.讓應(yīng)用真正意義上彈性擴(kuò)縮容 傳統(tǒng)方式下應(yīng)用和基礎(chǔ)環(huán)境資源（計(jì)算、網(wǎng)絡(luò)、存儲、監(jiān)控等） 是緊耦合的關(guān)系，應(yīng)用的擴(kuò)容、縮容意味著基礎(chǔ)環(huán)境資源的擴(kuò)容和縮容?；A(chǔ)環(huán)境的擴(kuò)、縮容耗時(shí)會非常長，因?yàn)樯婕暗椒浅６嘈枰斯そ槿氲沫h(huán)境，而且都是串行的，比如創(chuàng)建主機(jī)、分配存儲、網(wǎng)絡(luò)接入、操作系統(tǒng)安裝、網(wǎng)絡(luò)訪問關(guān)系開通、應(yīng)用部署、監(jiān)控審計(jì)部署、接入負(fù)載均衡等等。整個(gè)流程走下來通常需要數(shù)天到數(shù)周的時(shí)間。后來我們通過IaaS、虛擬化、自動(dòng)化工具已經(jīng)大幅度縮減了基礎(chǔ)環(huán)境資源擴(kuò)容的時(shí)間，但是整個(gè)流程下來仍然需要數(shù)個(gè)小時(shí)到數(shù)天，這對于真正需要彈性的應(yīng)用來說還是不夠。 容器云環(huán)境下，應(yīng)用和基礎(chǔ)環(huán)境資源是解耦的，應(yīng)用的擴(kuò)縮容不需要涉及基礎(chǔ)環(huán)境資源的擴(kuò)縮容，僅僅需要修改應(yīng)用部署模板文件中的副本數(shù)，然后在容器云平臺執(zhí)行即可。容器云平臺會根據(jù)副本數(shù)來自動(dòng)創(chuàng)建或者刪除副本，使得最終的副本數(shù)是部署模板文件中定義的副本數(shù)。整個(gè)擴(kuò)容或縮容流程可以在數(shù)秒到數(shù)十秒內(nèi)完成。這樣當(dāng)應(yīng)用面臨突發(fā)業(yè)務(wù)量增長，需要緊急擴(kuò)容的時(shí)候，就可以非?？斓耐瓿桑瑢?shí)現(xiàn)了真正意義上的彈性擴(kuò)容。 2.為應(yīng)用微服務(wù)化提供有力支撐 應(yīng)用微服務(wù)化是當(dāng)前應(yīng)用改造的一個(gè)重點(diǎn)方向，因?yàn)榇蠹叶伎吹搅宋⒎?wù)的好處，就是迭代效率高、資源使用率高(單一微服務(wù)可自行擴(kuò)容)、單一微服務(wù)故障 對全局影響有限。但是傳統(tǒng)方式下的應(yīng)用微服務(wù)化開發(fā)運(yùn)營是缺乏體系支撐的，成本高昂、便捷性差。比如一個(gè)應(yīng)用由20個(gè)微服務(wù)組成，每個(gè)微服務(wù)需要2個(gè)副本保持高可用，傳統(tǒng)方式下就需要申請20個(gè)負(fù)載均衡、40個(gè)虛擬機(jī)來確保隔離性，同時(shí)還要為這40個(gè)虛擬機(jī)分配相應(yīng)的網(wǎng)絡(luò)、存儲，部署配套的監(jiān)控審計(jì)等，消耗了大量的資源。傳統(tǒng)方式下的這套架構(gòu)沒有彈性擴(kuò)縮容能力，也缺乏自動(dòng)化的部署管理工具，對運(yùn)維人員來說，管理的應(yīng)用從1個(gè)變?yōu)?0個(gè)，大大增加了工作量和復(fù)雜度，便利性會很差。從應(yīng)用開發(fā)人員的角度看，傳統(tǒng)方式下做微服務(wù)化改造，隨著微服數(shù)量的增加，服務(wù)之間依賴關(guān)系的增加，開發(fā)人員會面臨很大的挑戰(zhàn)。需要部署專門的服務(wù)注冊發(fā)現(xiàn)系統(tǒng)，需要對應(yīng)用層代碼做侵入實(shí)現(xiàn)服務(wù)的注冊發(fā)現(xiàn)機(jī)制，需要對應(yīng)用代碼做修改以實(shí)現(xiàn)服務(wù)的探活和依賴性處理。這些服務(wù)治理方面的工作牽扯了開發(fā)人員很大的精力，使得應(yīng)用人員無法將精力集中在業(yè)務(wù)開發(fā)本身上，是一種低效率的做法。 容器云環(huán)境提供了一套成熟的支撐體系，可以很好的支撐應(yīng)用的微服務(wù)化改造，成本低廉、便捷性好。還是以之前的應(yīng)用為例，20個(gè)微服務(wù)中，僅僅對外部提供服務(wù)的微服務(wù)需要申請負(fù)載均衡，內(nèi)部微服務(wù)之間的調(diào)用通過service機(jī)制即可實(shí)現(xiàn)。如果很多微服都需要對外提供服務(wù)，也可以通過ingress將所有服務(wù)收斂到一個(gè)入口上，這樣對負(fù)載均衡的需求數(shù)量就大幅度下降。容器化的微服務(wù)都是運(yùn)行在一個(gè)計(jì)算機(jī)群內(nèi)，可以共享計(jì)算節(jié)點(diǎn)，擴(kuò)容、縮容都不需要申請?zhí)摂M機(jī)，資源的使用效率可以最高。容器云也為應(yīng)用的部署運(yùn)行提供很好的編排工具，可以實(shí)現(xiàn)應(yīng)用變更的完全自動(dòng)化、滾動(dòng)升級、一鍵回滾。對應(yīng)用開發(fā)人員來說，容器云環(huán)境可以提供比較完善的可配置化的微服治理框架，包括服務(wù)注冊發(fā)現(xiàn)、服務(wù)探活、依賴性處理等，不需要對應(yīng)用代碼做侵入修改，這樣可以讓應(yīng)用開發(fā)人員將更多精力集中在業(yè)務(wù)開發(fā)本身。 3.讓應(yīng)用實(shí)現(xiàn)自動(dòng)化故障探測、隔離和恢復(fù) 傳統(tǒng)方式下的應(yīng)用故障判斷、隔離和恢復(fù)完全依賴人工介入，耗時(shí)很長。比如一旦出現(xiàn)某個(gè)應(yīng)用節(jié)點(diǎn)的故障，需要運(yùn)維人員人工判斷是哪一個(gè)節(jié)點(diǎn)出了問題，然后人工將該節(jié)點(diǎn)從負(fù)載均衡摘除。隨后人工恢復(fù)故障節(jié)點(diǎn)，再掛到負(fù)載均衡下面。這就導(dǎo)致很長的故障窗口期，對業(yè)務(wù)連續(xù)性并不友好. 容器方式下，應(yīng)用的故障判別、隔離和恢復(fù)完全自動(dòng)化實(shí)現(xiàn)，無需人工干預(yù)。容器云環(huán)境提供一套應(yīng)用服務(wù)的自主探測和處理機(jī)制，同時(shí)也會檢測每一個(gè)節(jié)點(diǎn)，一旦發(fā)現(xiàn)某個(gè)應(yīng)用副本異常，會立即將其從service摘除，之后自動(dòng)刪除故障副本，并在可用的節(jié)點(diǎn)上新建新的副本。當(dāng)探測到新建副本已經(jīng)可以提供服務(wù)后，會自動(dòng)將新建副本掛載到service下面。這種完全自動(dòng)化的故障處理恢復(fù)機(jī)制為應(yīng)用提供了故障自愈能力，將故障窗口減小到最小。 4.大幅度提升資源使用效率 在沒有虛擬機(jī)之前，我們使用裸機(jī)部署應(yīng)用，一個(gè)裸機(jī)部署一個(gè)應(yīng)用，造成了大量的 資源閑置。后來使用虛擬機(jī)后，一個(gè)裸機(jī)上可以虛擬出多個(gè)主機(jī)，可以部署多個(gè)應(yīng)用，資源使用效率得到了很大的提升。虛擬機(jī)之間可以共享CPU，但是無法共享內(nèi)存和存儲，比如一個(gè)虛擬機(jī)申請了32GB內(nèi)存和100GB存儲，這些資源只能被這個(gè)虛擬機(jī)獨(dú)占，無法和其它虛擬機(jī)共享。 容器的本質(zhì)是進(jìn)程，進(jìn)程間是可以共享宿主機(jī)的CPU、內(nèi)存、存儲和網(wǎng)絡(luò)的，資源使用效率得到最充分的利用。當(dāng)然做到這一點(diǎn)的前提是容器能夠確保進(jìn)程運(yùn)行的基本資源不被搶占，資源層面實(shí)現(xiàn)良好的隔離性。同時(shí)允許設(shè)置資源使用配額上限，避免影響其它應(yīng)用進(jìn)程。 容器云平臺架構(gòu)設(shè)計(jì) 1.總體架構(gòu)設(shè)計(jì) 總體架構(gòu)圖如下：  hnzut12lza 自服務(wù)管理平臺提供8大板塊服務(wù)，都是按照支持多租戶的目標(biāo)設(shè)計(jì)實(shí)現(xiàn)。其中資源申請板塊是租戶申請容器資源的入口，包含賬號申請，K8S和鏡像庫資源申請，日志接入申請。資源變更板塊是租戶進(jìn)行資源變更的入口，包括K8S資源擴(kuò)容和回收，以及賬號權(quán)限的修改。集群管理板塊為云平臺管理員和租戶提供集群范圍資源的管理，鏡像庫管理板塊提供鏡像庫和鏡像的管理，應(yīng)用管理板塊主要為租戶提供K8S namespace內(nèi)資源的管理，模板管理板塊包含K8S資源模板和Helm模板，運(yùn)維助手提供Pod歷史查詢以及集群健康檢查管理，賬號授權(quán)管理板塊為云平臺管理員提供租戶授權(quán)管理。 自服務(wù)管理平臺南向通過K8S API和鏡像庫API對接多個(gè)K8S集群和兩個(gè)鏡像庫，實(shí)現(xiàn)容器資源的統(tǒng)一納管。最右邊的是行內(nèi)的運(yùn)營支撐工具體系，其中統(tǒng)一身份認(rèn)證為自服務(wù)管理平臺提供租戶賬號的登陸鑒權(quán)服務(wù)，流程系統(tǒng)(即ITOMS)通過API和自服務(wù)管理平臺的資源申請板塊對接，提供統(tǒng)一的資源申請入口。CMDB和自服務(wù)管理平臺自身的CMDB交互，提供應(yīng)用、容器、資源之間的關(guān)系視圖；DevOps工具鏈可以從自服務(wù)平臺獲取用戶和權(quán)限，然后通過K8S API和鏡像庫API實(shí)現(xiàn)應(yīng)用的自動(dòng)化流水線發(fā)布。ELK日志系統(tǒng)用于存儲容器應(yīng)用的日志，集中監(jiān)控告警系統(tǒng)接收來自K8S節(jié)點(diǎn)和容器應(yīng)用的監(jiān)控?cái)?shù)據(jù)，提供告警推送、置維護(hù)、統(tǒng)一監(jiān)控視圖的能力。 2.多集群管理設(shè)計(jì) 根據(jù)銀行內(nèi)網(wǎng)絡(luò)安全的要求，K8S集群不能通過Overlay網(wǎng)絡(luò)跨網(wǎng)絡(luò)隔離區(qū)。因此一個(gè)K8S集群只能限定在一個(gè)網(wǎng)絡(luò)隔離區(qū)內(nèi)。目前生產(chǎn)和災(zāi)備數(shù)據(jù)中心的每個(gè)網(wǎng)絡(luò)隔離區(qū)部署一套或多套K8S集群，所有集群統(tǒng)一由自服務(wù)管理平臺納管。同一網(wǎng)絡(luò)隔離區(qū)內(nèi)，生產(chǎn)和災(zāi)備數(shù)據(jù)中心各部署K8S集群，為應(yīng)用提供雙活容災(zāi)部署架構(gòu)支撐。生產(chǎn)和災(zāi)備數(shù)據(jù)中心分別部署一套鏡像庫系統(tǒng)，為各自數(shù)據(jù)中心內(nèi)的K8S集群提供鏡像服務(wù)。允許租戶跨集群管理自己的容器資源。整體示意圖如下：  qsgqjlpf4u 3.多租戶管理設(shè)計(jì) 通過K8S命名空間和鏡像庫命名空間實(shí)現(xiàn)租戶資源隔離，一個(gè)租戶對應(yīng)于一個(gè)或者多個(gè)命名空間。云平臺管理員可以通過RBAC機(jī)制為租戶授予相應(yīng)命名空間的管理權(quán)限。租戶對授權(quán)命名空間內(nèi)的資源具有管理員權(quán)限，但是無法訪問非授權(quán)命名空間。對于一個(gè)租戶來說，管理員可以授予他一個(gè)K8S集群內(nèi)一個(gè)或多個(gè)命名空間的管理權(quán)限，也可以授予他多個(gè)K8S集群內(nèi)命名空間的管理權(quán)限。整體示意圖如下：  i855qvjyodt 4.專用和共享計(jì)算節(jié)點(diǎn) 容器云平臺為應(yīng)用提供兩種類型的K8S集群，分別是計(jì)算節(jié)點(diǎn)共享的K8S集群和計(jì)算節(jié)點(diǎn)專用的K8S集群。從資源利用率角度，首推共享計(jì)算節(jié)點(diǎn)的K8S集群。計(jì)算節(jié)點(diǎn)直接采用物理機(jī)，多個(gè)應(yīng)用共享計(jì)算節(jié)點(diǎn)組成的資源池，資源的彈性和使用效率最高。 如應(yīng)用需要調(diào)整缺省Linux Kernel參數(shù)，或者有特殊的敏感的出網(wǎng)絡(luò)訪問關(guān)系，或者有很高的安全隔離性要求，可以考慮采用計(jì)算節(jié)點(diǎn)專用的K8S集群。專用的計(jì)算節(jié)點(diǎn)考慮資源利用率，主要以虛擬機(jī)為主。特殊的應(yīng)用場景（如GPU）可以使用物理機(jī)。通過給計(jì)算節(jié)點(diǎn)打應(yīng)用標(biāo)簽的方式，然后在應(yīng)用部署模板里指定nodeSelector的方式，實(shí)現(xiàn)計(jì)算節(jié)點(diǎn)的獨(dú)占。 5.存儲后端實(shí)現(xiàn) 使用Ceph分布式存儲作為容器云平臺的后端存儲，為應(yīng)用提供持久化的數(shù)據(jù)存儲能力。在生產(chǎn)和災(zāi)備數(shù)據(jù)中心各部署一個(gè)Ceph集群，為所屬數(shù)據(jù)中心的K8S集群提供持久化存儲后端服務(wù)。每個(gè)K8S集群創(chuàng)建2個(gè)Storage Class。rbd-class提供ReadWriteOnce類型PVC，后臺對接的是Ceph RBD；cephfs-class提供ReadWriteMany類型PVC，后臺對接的是CephFS。租戶可動(dòng)態(tài)申請PVC，僅有創(chuàng)建權(quán)限，沒有刪除權(quán)限。整體示意圖如下：  z1jejzxjnog 6.應(yīng)用監(jiān)控告警 每一個(gè)計(jì)算節(jié)點(diǎn)上會部署一個(gè)監(jiān)控Agent。應(yīng)用如需監(jiān)控，需要在應(yīng)用部署模板的環(huán)境變量里聲明監(jiān)控類型。應(yīng)用容器啟動(dòng)后，監(jiān)控Agent會通過容器接口獲得容器監(jiān)控類型環(huán)境變量，并自動(dòng)匹配監(jiān)控模板(腳本)。監(jiān)控Agent將監(jiān)控?cái)?shù)據(jù)發(fā)送到監(jiān)控服務(wù)器。監(jiān)控服務(wù)器根據(jù)觸發(fā)條件判斷是否發(fā)送告警信息到集中告警平臺。在集中告警平臺上為每個(gè)應(yīng)用創(chuàng)建虛擬節(jié)點(diǎn)，和IP解耦。告警平臺收到告警信息后，根據(jù)告警數(shù)據(jù)包含的應(yīng)用名稱字段自動(dòng)匹配到虛擬節(jié)點(diǎn)。虛節(jié)點(diǎn)上可設(shè)置維護(hù)狀態(tài)，應(yīng)用變更的時(shí)候?yàn)榱吮苊飧婢梢栽O(shè)置虛節(jié)點(diǎn)為維護(hù)狀態(tài)，變更完成后可以解除維護(hù)狀態(tài)。示意圖如下：  opefduny42j 目前可監(jiān)控的應(yīng)用指標(biāo)如下： 1.應(yīng)用容器狀態(tài)。如果容器狀態(tài)異常會觸發(fā)告警; 2.應(yīng)用Deployment副本數(shù)，如果副本數(shù)和期望的不一致，會觸發(fā)告警; 3.應(yīng)用Statefulset副本數(shù)， 如果副本數(shù)和期望的不一致，會觸發(fā)告警; 4.應(yīng)用Pod狀態(tài)，如異常，會觸發(fā)告警; 5.應(yīng)用容器內(nèi)部文件系統(tǒng)使用率，如超過80%，會觸發(fā)告警; 7.應(yīng)用日志處理 每個(gè)計(jì)算節(jié)點(diǎn)部署一個(gè)日志收集代理，該代理面向節(jié)點(diǎn)上所有的容器。如應(yīng)用容器需要監(jiān)控，就需要在Pod yaml里通過環(huán)境變量聲明日志路徑和kafka topic。容器啟動(dòng)后，日志代理會根據(jù)容器環(huán)境變量定義的日志路徑自動(dòng)匹配對應(yīng)的宿主機(jī)日志文件路徑，并將日志抓取后發(fā)送到kafka topic。當(dāng)前的日志代理以換行符作為分割符，如應(yīng)用的一條日志里有多行紀(jì)錄，這條日志會被切分成多個(gè)消息來處理，在Kibana上也會呈現(xiàn)多條記錄。為了適配這類一條日志有多行紀(jì)錄的應(yīng)用，我們也正在設(shè)計(jì)開發(fā)一種可定制化分隔符的日志引擎，可以允許應(yīng)用在Pod的yaml里聲明日志分隔符。 8.應(yīng)用雙活容災(zāi)部署架構(gòu) 生產(chǎn)、災(zāi)備中心每個(gè)網(wǎng)絡(luò)區(qū)都建設(shè)一個(gè)K8S集群，都有各自獨(dú)立的鏡像庫和后端分布式存儲。應(yīng)用雙活要求應(yīng)用同時(shí)運(yùn)行在生產(chǎn)、災(zāi)備中心的兩個(gè)K8S集群上，前端可以通過負(fù)載均衡引流。任意一個(gè)數(shù)據(jù)中心的集群故障不影響應(yīng)用的可用性。示意圖如下：  ev6i39ygdkg 應(yīng)用容器化最佳實(shí)踐總結(jié) 1.鏡像和配置分離原則：制作應(yīng)用鏡像時(shí)，需要將配置分離出來，這樣做可以讓應(yīng)用鏡像在不同環(huán)境（比如測試和生產(chǎn)）都一致，變得只是配置信息。配置信息可通過環(huán)境變量或者加載卷的方式注入容器。在K8S環(huán)境下，除了環(huán)境變量注入，還可以通過ConfigMap和Serect方式注入配置。ConfigMap和Secret都支持通過卷加載的方式掛載到容器。Secret通常用于保存敏感信息（如密碼）. 2.微服務(wù)原則：容器環(huán)境天生要求微服務(wù)化，一個(gè)容器只提供一種服務(wù)。每個(gè)容器原則上只對外提供一個(gè)服務(wù)監(jiān)聽端口。 3.使用第三方基礎(chǔ)鏡像制作應(yīng)用鏡像的時(shí)候必須包含必要的系統(tǒng)trouleshooting工具，至少包括ps、netstat、ping、curl。否則出現(xiàn)問題的時(shí)候會妨礙排錯(cuò)。 4.支持通過NodePort和Ingress對外發(fā)布服務(wù)。NodePort適用于對外服務(wù)較少場景；Ingress適用于對外服務(wù)較多，需要統(tǒng)一入口場景。Ingress需要作為應(yīng)用的的一部分部署在應(yīng)用命名空間。使用Ingress只需要對外通過一個(gè)NodePort暴露服務(wù)。 5.NodePort需要向容器平臺管理員申請。請僅僅使用分配給項(xiàng)目組的NodePort，禁止使用未經(jīng)申請的NodePort，否則容易其它項(xiàng)目組產(chǎn)生端口沖突 . 6.如使用StatefulSet部署有狀態(tài)應(yīng)用，副本數(shù)必須大于等于2，并且在驗(yàn)證了單個(gè)Pod失效不影響服務(wù)的前提下，才可以生產(chǎn)上線。原因是StatefulSet的Pod在宿主機(jī)故障情況下沒有自動(dòng)HA能力，需要人為干預(yù)殺死Pod才能觸發(fā)重建。 7.Deployment/StatefulSet/Pod的yaml里，必須配置liveness/readiness探測，并通過測試才能生產(chǎn)上線。這對于應(yīng)用的可用性非常重要，請一定重視 。 8.Deployment/StatefulSet/Pod的yaml里，必須對Container的resources做設(shè)置。因?yàn)樯a(chǎn)環(huán)境出于考慮極端情況（一半節(jié)點(diǎn)不可用）下的應(yīng)用高可用。對于獨(dú)占計(jì)算節(jié)點(diǎn)的應(yīng)用，要求應(yīng)用namespace下所有Pod的request總合不能超過分配總資源(CPU，內(nèi)存)的50%-1，單個(gè)Pod的limit不能超過單個(gè)節(jié)點(diǎn)資源的60%。 9.對于可以和其它應(yīng)用共享計(jì)算節(jié)點(diǎn)(通常是物理節(jié)點(diǎn))的應(yīng)用，namespace下所有Pod的request總合和limites總合不能超過分配的總資源（比如分配了16C/64G，那么request總合/limites總合不能超過16C/64G）。 10.對于使用獨(dú)占宿主機(jī)節(jié)點(diǎn)的應(yīng)用，Deployment/StatefulSet/Pod的yaml里，必須配置NodeSelector。生產(chǎn)環(huán)境NodeSelector的value值是項(xiàng)目的英文名，測試環(huán)境統(tǒng)一是testapp。對于和其它應(yīng)用共享宿主機(jī)節(jié)點(diǎn)的應(yīng)用，可以不配置NodeSelector。 11.對于重要系統(tǒng)，Deployment/StatefulSet里，副本(replica)數(shù)必須大于2（包含2），禁止為1。這樣才能確保服務(wù)在單個(gè)副本故障的情況下依然可用。對于可靠性要求不高的系統(tǒng)，在資源充足的情況下盡量也保持副本數(shù)大于等于2。如資源受限，并且上線前明確說明對可靠性要求不高，可以允許副本數(shù)為1 。 12.Pod產(chǎn)生的日志，推薦通過直接寫入stdout并配置Kafka Topic的方式，轉(zhuǎn)發(fā)到ELK。如果一定要持久化保存，有如下三種方案，但是都要求首先應(yīng)用層面要做好日志輪循(rotation)，控制好總量大小，因?yàn)镻VC和HostPath用的宿主機(jī)目錄通常是無法擴(kuò)容的。目前僅寫入stdout、HostPath的日志，才可以被日志引擎處理發(fā)往ELK，HostPath需要掛載到日志目錄。HostPath方式受限使用，需要一事一議。寫入PVC或者直接寫入容器自身的日志將不能被日志引擎抓取。 a)使用StatefulSet方式部署Pod，需要在yaml里聲明PVC容量和StorageClass（名字為rbd-class，提供ReadWriteOnce類型的PV），并且通過將日志同時(shí)寫入stdout，且在yaml里聲明stdout日志路徑和Kafka Topic的方式，將日志發(fā)往ELK。一旦使用PVC，Pod的可用性就會和PVC的可用性關(guān)聯(lián)起來。對于可用性要求很高的系統(tǒng)（A/B類系統(tǒng)），如果使用PVC，前提條件是應(yīng)用實(shí)現(xiàn)了災(zāi)備雙活部署。 b)使用Deployment方式部署Pod，需要在yaml里聲明共享型（ReadWriteMany類型）PVC的名字，并且通過將日志同時(shí)寫入stdout，且在yaml里聲明stdout日志路徑和Kafka Topic的方式，將日志發(fā)往ELK。在多副本情況下，需要應(yīng)用做好日志文件區(qū)分，避免多副本寫同一個(gè)日志文件。一旦使用PVC，Pod的可用性就會和PVC的可用性關(guān)聯(lián)起來。對于可用性要求很高的系統(tǒng)（A/B類系統(tǒng)），如果使用PVC，前提條件是應(yīng)用實(shí)現(xiàn)了災(zāi)備雙活部署。 c)使用HostPath，將日志寫入宿主機(jī)的某個(gè)目錄。這需要應(yīng)用在多副本的情況下，能夠做好日志區(qū)分，將所有Pod的日志放到同一個(gè)父目錄下。如需使用此種方式，請?zhí)崆奥?lián)系容器平臺管理員創(chuàng)建目錄。即使使用HostPath存放日志，可直接通過在yaml里聲明日志文件路徑和Kafka Topic的方式，將日志發(fā)往ELK。使用HostPath存放日志主要的問題是Pod一旦遷移到新的節(jié)點(diǎn)，日志寫入也會遷移到新的節(jié)點(diǎn)，舊節(jié)點(diǎn)上的日志文件寫入會中斷。HostPath僅僅適用于專用計(jì)算節(jié)點(diǎn)場景，并且需要一事一議。 13.如果兩個(gè)服務(wù)之間有依賴關(guān)系，必須在上線前解決啟動(dòng)順序問題?？梢钥紤]使用K8S的initcontainer機(jī)制做探測。 14.對于重要系統(tǒng)，原則上要求應(yīng)用層面必須實(shí)現(xiàn)災(zāi)備雙活部署，也即應(yīng)用同時(shí)運(yùn)行在生產(chǎn)、災(zāi)備的兩個(gè)K8S集群上，前端可通過負(fù)載均衡引流。任意一個(gè)集群的故障不影響應(yīng)用的可用性 15.生產(chǎn)上線前，請確保在測試環(huán)境完成應(yīng)用HA測試驗(yàn)證，具體的要求是： a) 殺死任意服務(wù)中的單個(gè)Pod不影響整體業(yè)務(wù) b) 殺死任意服務(wù)中的所有Pod，待Pod重啟完成后，整體業(yè)務(wù)服務(wù)不受影響 c) 節(jié)點(diǎn)故障不影響整體業(yè)務(wù) 16. 盡可能通過配置prestop或者處理SIGTERM信號，來實(shí)現(xiàn)應(yīng)用容器的優(yōu)雅停止。缺省情況下，沒有配置優(yōu)雅停止的話，K8S會在grace-period時(shí)間（缺省30秒，可在Pod Yaml里調(diào)整）到期后，通過SIGKILL殺死Pod內(nèi)進(jìn)程。 應(yīng)用容器化改造案例(某支付類系統(tǒng)) 1.改造背景 支付類系統(tǒng)作為銀行的核心系統(tǒng)之一，為了保證可用性和性能，之前都是運(yùn)行在小型機(jī)上，運(yùn)行成本高昂、可擴(kuò)展性較差。為了解決這些問題，支付類系統(tǒng)需要進(jìn)行分布式改造，把應(yīng)用程序從小型機(jī)遷移到X86 PC服務(wù)器上，導(dǎo)致服務(wù)器的規(guī)模從幾臺擴(kuò)展為幾十臺，使得部署環(huán)節(jié)更加復(fù)雜、容易出錯(cuò)。因此希望利用容器平臺提供的服務(wù)注冊發(fā)現(xiàn)、動(dòng)態(tài)伸縮以及快速故障檢測恢復(fù)等能力，降低分布式系統(tǒng)的部署和管理難度。 2.技術(shù)實(shí)現(xiàn) 如下是某支付類系統(tǒng)容器化后的部署架構(gòu)，該系統(tǒng)的后端采用容器化方式部署運(yùn)行。后端也根據(jù)微服務(wù)的方式，從一個(gè)大模塊拆分成幾個(gè)微服務(wù)模塊，更便于分布式的部署。  bllnwnnjmrt 行內(nèi)現(xiàn)有的支付類系統(tǒng)大多是有狀態(tài)的，因?yàn)橐珊凸?jié)點(diǎn)相關(guān)的交易流水號。容器化改造時(shí)，為了盡可能不影響現(xiàn)有業(yè)務(wù)邏輯，也需要維持這種有狀態(tài)的方式?？梢岳肒8S提供的StatefulSet實(shí)現(xiàn)有狀態(tài)的部署，每個(gè)Pod會有固定的名字，比如payapp-01、payapp-02。這樣可以根據(jù)Pod名字中的索引（01、02等）自動(dòng)生成交易流水號。 由于現(xiàn)有前置應(yīng)用和后端應(yīng)用之間是長連接，只能采用一個(gè)Pod一個(gè)Service的方式提供服務(wù)。每一個(gè)Pod都要通過NodePort Service對外提供服務(wù)。后端Pod在啟動(dòng)后，會將Pod所在的節(jié)點(diǎn)IP地址和自己的NodePort注冊到前置應(yīng)用里，然后由前置應(yīng)用校驗(yàn)適配后，發(fā)起到后端Pod的連接，并一直保持這個(gè)連接。為了保持較好的可擴(kuò)展性，可以預(yù)先在前置應(yīng)用里配置額外的服務(wù)端口，這樣需要擴(kuò)展的時(shí)候，只需要擴(kuò)容后端的副本(Pod)數(shù)量和Service數(shù)量即可。當(dāng)然，后期如果可以改造為短連接方式，就可以采用1個(gè)Service對應(yīng)多個(gè)副本的方式，擴(kuò)容會更方便，也可省略服務(wù)向前置應(yīng)用的注冊環(huán)節(jié)。 支付類系統(tǒng)是銀行的重要系統(tǒng)，必須具備雙活容災(zāi)能力，具體實(shí)現(xiàn)是在生產(chǎn)和同城災(zāi)備數(shù)據(jù)中心的兩個(gè)K8S集群上分別部署一個(gè)多副本的StatefulSet，各副本(Pod)僅和所在數(shù)據(jù)中心的前置交互。任意數(shù)據(jù)中心的故障不影響整體業(yè)務(wù)。 3.效果總結(jié) 通過上述容器化改造，達(dá)到了如下目的和效果：
 |
|
|
